Вступить в Клуб Войти
Введите логин
Введите пароль
напомнить пароль

Сергей Горшенин, член Правления "SPb CIO Club": «САУНА» как инструмент автоматизации недвижимости

13.05.2012

Неожиданный вопрос:
— А почему программа называется «САУНА»?
Это потому, что вы с нами уже напарились?

Именно такой вопрос задала сотрудница подразделения-заказчика в ходе проекта по автоматизации деятельности управления недвижимости, вызвав тем самым легкую улыбку на моем лице. Собственно говоря, улыбка возникает каждый раз, когда этот вопрос вспоминается. И даже сейчас не обошлось без нее. Но давайте обо всем по порядку.

Шел конец 2009 года, кипела работа во всех подразделениях компании, обусловленная процессом подготовки и защиты бюджета на следующий год. Напомню, что согласно бюджетной политике ОАО «Светлана», консолидированный бюджет на следующий финансовый год, а он совпадает с календарным, готовится в конце третьего — начале четвертого квартала. Далее идет согласование и защита. И, как правило, к декабрю он уже утверждается. Естественно, бюджет ИТ-подразделения, как часть общего бюджета компании, не был исключением.

Однажды, просматривая сводную заявку по проектам, напрямую или косвенно затрагивающим ИТ-подразделение, которая отличается от основной тем, что в ней все проекты отражаются общими цифрами, в глаза бросилась строка: «создание и внедрение программы автоматизации деятельности управления недвижимости». Напротив строки значилась цифра 50 тыс. Цифра вызвала удивление, так как одно дело — внедрение продукта, а другое — создание и внедрение. Меня заинтересовал этот проект, а потому далее последовали детали.

Модель «AS-IS»

Как оказалось, речь шла об автоматизации деятельности подразделения, отвечавшего за регистрацию прав собственности и учет объектов недвижимости. На тот момент весь учет производился в таблицах Excel. Такая модель учета на определенном этапе оправдывает себя, например, можно вспомнить историю автоматизации службы поддержки пользователей, описанную в статье Ивана Козлова «Сервис-деск на коленке».1 Отчасти это вполне разумное и экономичное решение. С одной стороны, его очень просто реализовать, с другой — учитывая, что все привыкли работать с электронными таблицами, срок внедрения минимален. Но со временем объем информации увеличивается. Следом повышаются и запросы к структуре и полноте предоставляемой управленческой информации. И вот тут электронные таблицы начинают проигрывать своим старшим братьям по эволюционной линейке информационных систем, автоматизирующих бизнес-деятельность. Именно такой момент наступил и в нашем случае — большие и «тяжелые» многомерные таблицы вместо сокращения времени для получения необходимой информации увеличивали ее. При открытии таблицы можно было успеть заварить чашку кофе. Идентификация одного и того же контрагента или объекта на большом количестве листов — вообще отдельный разговор. То же можно сказать и о сложности расширения числа учитываемых свойств и получения отчетной информации, особенно сводной по нескольким листам. А что же хотел заказчик?

Модель «to-be де-юре»

Для нужд ОАО «Светлана» необходимо было создание информационной системы оперативного учета наличия объектов недвижимости, как согласно ведомостям ПИБ в разрезе зданий, так и согласно внутренним ведомостям в разрезе корпусов, ведение учета движения объектов недвижимости в разрезе потребителей объектов недвижимости, таких как внутренние подразделения организации и внешние арендаторы. Цель создания — стремление свести воедино всю (правовую, техническую, справочно-аналитическую) информацию о недвижимости ОАО «Светлана» и получить инструмент комплексной оценки и анализа с гибкой структурой вывода данных. Была поставлена задача надежного сохранения данных, представляющих интерес, таким образом, чтобы информация по вводимым запросам не была избыточной и минимизировала риск противоречивости. Но это на бумаге, а по факту?

Модель «to-be де-факто»

По факту же предполагалось нанять стороннего разработчика, который за небольшие деньги перевел бы экселевские таблички в веб-приложение на основе новомодных облачных технологий, не меняя при этом существенно парадигму учета данных.

Если закрыть глаза на то, что новый программный продукт не предполагал качественного перехода с электронных таблиц в класс ERP-систем, то решение о разработке собственного ПО имеет ряд плюсов.

Плюсы собственной разработки:

  • программное обеспечение собственной разработки в процессе своего развития максимально наиболее полно отвечает нуждам организации;
  • созданное ПО обладает максимальной мобильностью с точки зрения изменений внешней среды (при условии наличия эффективной структуры управления организацией);
  • с точки зрения совокупной стоимости владения ПО собственной разработки тоже на высоте;
  • возможность осуществления максимально эффективного контроля со стороны организации над процессом разработки.

Это в общем. В частности же нас интересовало максимальное соответствие готового программного продукта требованиям подразделения-заказчика, а также финансовая сторона вопроса.

Но в данном случае изначально планируемый к разработке программный комплекс нельзя отнести в чистом виде к «собственной разработке», так как разработчик не сотрудничает с организацией постоянно, а это значит, что принцип единоначалия не действует. Напомним: «принцип единоначалия» для ПО собственной разработки подразумевает, что на каком-то уровне руководящей иерархии организации есть лицо, управляющее как разработчиком, так и организацией, что способствует соответствию планов развития ПО и стратегии организации.

Не стоит забывать и об общих рисках, присущих самостоятельно разрабатываемому программному обеспечению.

Риски собственной разработки:

  • высочайшие кадровые риски («незаменимость разработчика»);
  •  проблема «закрытости»;
  • ограниченность ресурса, хотя и не в ярко выраженной форме. 

Постараюсь пояснить вышеперечисленное. Речь идет о том, что зачастую высокая мобильность программного обеспечения собственной разработки, как правило, достигается за счет грубейших нарушений классического процесса разработки ПО, особенно в области документирования данного процесса. Таким образом, чаще всего программное обеспечение собственной разработки практически неотчуждаемо от его автора, что дает ему возможность (и небезосновательно) чувствовать себя незаменимым. Немаловажно и то, что разработчик смотрит на решение поставленной задачи исходя из проблем собственной организации. Поэтому зачастую технологические решения аналогичных организаций остаются вне зоны его внимания.

Итак, передо мной стоял выбор: согласиться на предложенный вариант с облаком, уложиться в бюджет и поставить формальную галочку в проекте (причем понимая, что через год новое ПО столкнется с теми же «трудностями», что и текущее) или же найти иной выход из сложившейся ситуации.

От «to-be » к автоматизации бизнес-процессов

В традиционном реинжинирингепроизводить автоматизацию бизнес-процессов и проектировать КИС рекомендуется на основе модели to-be. Подразумевается, что это позволяет существенно снизить риск проявления автоматизации как исключительно источника затрат из-за автоматизации несовершенных процессов. Аналогично предполагается, что без описания бизнес-процесса переходить к выбору платформы автоматизации рано. Но в данном случае было жесткое ограничение по финансам. Это «но» и предопределило дальнейшее направление развития данного проекта.

Как уже было сказано, требовалось найти выход из сложившейся ситуации. И он был найден —Continuous Process Improvement. CPI — методология управления процессами, в основе которой лежит идея непрерывного усовершенствования процесса. На самом деле, будь я по то сторону журнала, задал бы вопрос о том, как данная методология может решить поднятые ранее проблемы.

Прежде чем ответить, немного теории. В настоящее время, в связи с возрастающей популярностью «эволюционного» реинжиниринга, основанного на методологии CPI, снижается необходимость в долгой и трудоемкой подготовке модели to-be. И это вполне оправданно. Внедрение системы постоянного совершенствования процессов дает предприятию существенное конкурентное преимущество и способствует достижению стратегических целей компании за счет повышения эффективности ее бизнес-процессов и их непрерывной адаптации к изменяющимся внешним условиям. Определяющими принципами CPI являются постоянство и постепенность улучшений, обеспечивающие длительный и стабильный эффект при минимальных затратах на внесение изменений. Иначе говоря, CPI в общем виде — подход к реструктуризации бизнес-процессов, отличием которого от традиционного реинжиниринга является идея необходимости поддержки всего жизненного цикла процесса.

А теперь обещанный ответ. Разложим общую задачу на составляющие, вспомнив «рыбную» модель Исикавы. Есть ряд ограничений, с одной стороны, и требования заказчика, которые необходимо выполнить, с другой. При каких условиях можно решить поставленную задачу? Ответ очень прост: использовать корпоративный стандарт построения информационных систем, который используется в организации. Принимая во внимание ряд финансово‑организационных факторов, четыре года назад в ОАО «Светлана» за основу был принят стандарт разработки, основанный на системе «1С:Предприятие». Согласитесь, сейчас в большинстве компаний есть свой программист «1С», а если и нет, то открытость платформы позволяет минимизировать затраты на доработку и изменение любого решения. Итак, выбрав такое направление движения, мы минимизировали затраты и обеспечили гибкость и адаптивность, а главное — преемственность будущего программного продукта. И как показало время, решение было верным.

Проектирование КИС

Решение о выборе платформы и смене внешнего разработчика на внутреннего было принято, а  значит, дело оставалось за малым — спроектировать и внедрить. Необходимо было создать информационную систему, позволяющую полностью отразить все стадии жизненного цикла объекта недвижимости от момента ввода в эксплуатацию, согласно учетным данным ПИБ, и до его списания. Конфигурация должна была способствовать оперативному решению ряда задач, с которыми приходится ежедневно сталкиваться при учете объектов недвижимости: 

  • учет объектов недвижимости в различных разрезах;
  • учет потребителей и функциональных групп, к которым они относятся;
  • дополнительный учет вспомогательных объектов (дополнительные характеристики объектов недвижимости, подразделения, должности, сотрудники и т. д.)
  • автоматизация расчетов различных показателей:
  • земельного налога;
  • инвестированного капитала;
  • площадей в различных разрезах анализа;
  • получение разноплановых статистических данных и форм отчетности по заданным фильтрам;
  • сохранение предшествующей информации по параметрам объектов учета;
  • возможность поиска в базе данных информации по заданным параметрам;
  • возможность присоединения различных документов (doc, xls, jpg, png…) для формирования всесторонней информации об объекте.
  • И так далее…

ВАЖНО!

В соответствии с методологией CPI нововведения в бизнес-процессах рекомендуется проводить поэтапно, сначала в отдельных структурных подразделениях предприятия, а при положительном результате и во всей организации в целом. Параллельно с этим проводить обучение сотрудников и передачу новой технологии.

С точки зрения проектной деятельности, этот проект ничем не отличался от стандартной проектной модели. В ходе проекта были проведены следующие работы: обследование бизнес-процессов управления недвижимости в области учета объектов; недвижимости; выборочная оптимизация бизнес-процессов; моделирование информационной системы; проектирование и разработка информационной системы; опытная эксплуатация и оптимизация информационной системы; дальнейшая поддержка и постоянная адаптация.

Да и сложности, с которыми мы столкнулись в процессе проекта, вполне стандартны:

  • наличие двух подходов к учету недвижимости: ПИБ (здания) и бухгалтерский учет (корпуса);
  • отсутствие программных продуктов подобного класса;
  • необходимость внесения большого количества информации на стадии первичного заполнения базы данных;
  • отсутствие у сотрудников управления недвижимости опыта работы с аналогичными продуктами и длительное «привыкание» к программному продукту.

Добились ли мы поставленных перед собой целей?

Результаты эволюционного реинжиниринга

Следует отметить, что в начальные 50 тысяч рублей мы так и не уложились, да и со сроками начала промышленной эксплуатации запоздали. За счет того, что модель информационной системы строилась «на вырост» и предполагала учет большего количества данных, нежели до автоматизации, ввод первоначальных сведений в систему потребовал около месяца работы одного сотрудника. Тем не менее, если оперировать информацией из официального пресс-релиза, то были достигнуты следующие результаты:

  • автоматизированы бизнес-процессы управления недвижимости в области учета объектов недвижимости;
  • достигнуто существенное повышение оперативности и качества управленческих решений;
  • повышено качество обслуживания потребителей данной управленческой информации за счет большей прозрачности процессов учета объектов недвижимости;
  • произведено качественное улучшение процессов формирования отчетности;
  • достигнута высокая оперативность получения отчетности;
  • минимизация времени обучения для начала работы за счет интуитивно понятного пользовательского интерфейса и наличия подробного руководства пользователя.
  • за счет формирования единого информационного поля достигнуто повышение общей производительности труда сотрудников холдинга — потребителей выходной управленческой отчетности внедренной системы;
  • стоимость разработки и внедрения собственными силами — 75 тыс. руб., экономия при условии разработки и внедрения сторонними компаниями — около 0,5 млн руб.

Но помимо целей проекта была достигнута еще одна цель, основанная на CPI.

А именно — данный проект создал основу для автоматизации отдельных направлений деятельности компании в рамках стратегии развития информационных технологий. На текущий момент аналогичным образом автоматизировано несколько подразделений, и еще два проекта готовятся во 2–3 квартале этого года. И как вы догадываетесь, к каждому из них применимы три критерия:

  • максимальное соответствие модели решаемых задач;
  • минимальные затраты на внедрение и поддержку;
  • постоянная и непрерывная адаптация под задачи бизнеса.

Этот проект, благодаря своему «подпольному» названию и искренне заданным вопросом, сформулированным в начале статьи, останется в моей памяти на всем протяжении профессиональной карьеры.

Сергей Горшенин

Директор по цифровой трансформации

Другие публикации Сергей Горшенин