Статьи и публикации

Аналитические системы – проблемы развития

Балахонов Е.В.

Балахонов Е.В.

Технический директор ООО «ЭнергоДата»

Очевидно, что аналитическая отчетность – один из важнейших инструментов управления бизнесом для любой компании. И понятно почему – управлять можно тем, что умеешь и можешь измерять. Поэтому нет ни одной компании в мире, которой не хотелось бы иметь качественную, информационно полную, оперативную и непротиворечивую аналитическую отчетность.

Работая в консалтинге, я со стороны постоянно вижу как у российских компаний стремление к достижению данной цели вытекает в многолетние затраты финансовых и временных ресурсов на развитие информационных систем. При этом распространённой ситуацией является то, что спустя годы и десятки успешно завершённых ИТ-проектов, такие компании все еще не получают желаемого качества аналитической отчетности. Бизнес недоволен, ИТ приводит массу убедительных причин, что бизнес сам виноват и крайне необходимо еще вложить сколько-то денег. Знакомая ситуация?

Почему так происходит? Давайте кратко рассмотрим типовые стадии развития систем аналитической отчетности, через которые, так или иначе, проходит любая компания.

Начальная стадия, «время героев»

На данной стадии никаких аналитических систем еще не существует и никто не предполагает их быстрого появления. Основной инструмент – электронные таблицы. Хранилище данных – набор каталогов с кучей файлов на общем разделе файлового сервера.

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

Стадия вторая: «Информационные острова»

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

В разных компаниях такое индивидуальное творчество профильных подразделений может проявляться в разных формах: от относительно простых баз на Microsoft Access до «тяжелого» решения на одной из ведущих BI-платформ уровня предприятия. Все зависит от финансовых и административных ресурсов конкретного подразделения.

Стоит отметить, что весь этот процесс, как правило, происходит в условиях недостаточного административного веса ИТ-подразделения.

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

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

Стадия третья: Торжество ИТ-подразделения

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

Естественно ИТ-подразделение начинает делать единое корпоративное хранилище данных (КХД) для всей компании. Но делает это как понимает, преследуя в первую очередь свои цели, такие как:

  • Современная программная платформа
  • Удобство сопровождения
  • Богатый инструментарий и технические возможности
  • Техническая надежность, производительность, масштабируемость
  • Техническая совместимость с другими информационными системами

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

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

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

В процессе развития корпоративного хранилища данных компании, увеличения его сложности, ситуация часто только усугубляется:

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

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

Стадия четвертая: Корпоративное хранилище данных

Известно, что корпоративное хранилище данных действительно становится опорой в управлении бизнесом тогда, когда оно обладает такими качествами как:

  • Информационная достаточность для задач бизнеса – предоставлять данные своевременно, в нужном объеме и представлении.
  • Достоверность и непротиворечивость предоставляемой информации.
  • Способность оперативного развития в соответствии с запросами бизнеса без деградации свойств, перечисленных выше.

Банально информации КХД должны верить все. И не потому, что так указано в регламентах и должностных инструкциях.

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

В чем секрет их успеха? Если исследовать их опыт, то можно сформулировать некоторые общие пункты «рецепта» успеха создания КХД. Прежде чем их перечислять, давайте пройдем через несколько простых и даже очевидных логических заключений.

Любая информационная система, и КХД в частности, является отражением действующих в компании бизнес-процессов, принятых методик, правил, регламентов и т.д. И если в методической базе процессов компании зияют дыры и противоречия, то о какой качественной ИТ-системе может идти речь?

Следовательно, для построения КХД необходимо иметь непротиворечивую общую методическую базу формирования аналитических показателей, ведения НСИ по всем предметным областям бизнеса компании. В этом случае, концептуальная и логическая модели КХД сами собой унаследуют качество методической базы.

Но как создать такую методическую базу? Ведь, как я и писал выше, часто мы видим в компаниях иное – каждое профильное подразделение оптимизирует свои процессы и методики, формируя себе комфортный «информационный остров».

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

  • подразделение компании, способное ресурсно и административно обеспечить:
  • Координацию работы профильных подразделений над единой методической базой показателей
  • Сведение отдельных методик предметных областей в общую единую методическую базу показателей КХД
  • Ведение концептуальной и логической моделей КХД на базе единой методической базы

Далее такое подразделение давайте называть «Центром компетенций КХД». Полноправными владельцами прикладных областей по-прежнему остаются профильные подразделения и ничто не происходит там без их ведома.

Центр компетенций КХД становится непосредственным участником всех ИТ-проектов, в рамках которых в КХД вносятся какие-либо изменения. Именно он согласует все проектные решения, плодотворные идеи подрядчиков сэкономить на Заказчике, попытки ИТ-подразделения в очередной раз упростить себе жизнь и так далее. ИТ-подразделение, как и ранее, отвечает за качество технической реализации КХД и функционирование программно-аппаратной платформы.

Конечно, вся эта полезная для бизнеса деятельность невозможна без четко регламентированного и действующего в компании процесса сопровождения КХД и внесения в нее изменений.

Таким образом, формируем некоторые пункты «рецепта» (далее будет скучно и формализовано):

  • У корпоративного хранилища данных должен появиться единый хозяин в виде обособленного от ИТ подразделения – Центра компетенции КХД, выполняющего следующие функции:
    • Ведение единой методической базы формирования всех признаков и показателей по всем функциональным областям. При этом формирование конкретных методик осуществляется профильными подразделениями, а Центр компетенции осуществляет организационную, согласительную и интеграционную функцию.
    • Ведение единой концептуальной и логической модели хранилища данных аналитической системы.
    • Управление развитием системы: ни один ИТ-проект в компании, приносящий в КХД новую функциональность или изменения текущей, не может проходить мимо Центра компетенции и регламентированного процесса внесения изменений в методическую базу, модели данных и функционал.
    • Определение источников данных и методики извлечения информации.
  • Профильные подразделения компании должны стать владельцами соответствующих им предметных областей общей модели данных компании. В модели данных КХД ни один логический объект не может появиться или измениться без ведома профильного подразделения, отвечающего за соответствующую функциональную область.
  • Техническая модель и технические аспекты реализации и сопровождения системы остаются в ведении ИТ-подразделения. Внесение изменений проводится только с ведома Центра компетенции.
  • В компании должен быть организованы четко регламентированные процессы внесения изменений и эксплуатации КХД, гарантирующие сохранение целостности и непротиворечивости информации.

Конечно, невозможно изменить существующее положение дел в одночасье. Необходимо сделать следующие последовательные шаги:

  • Разработать Концепцию КХД, в рамках которой:
    • Определить организационные и функциональные рамки КХД
    • Разработать концептуальный подход к построению КХД:
      • Сформулировать основные принципы построения КХД
      • Разработать требования к концептуальной, логической и технической моделям данных КХД
      • Разработать концептуальную и логическую модели КХД
    • Определить предметные области и закрепить их владельцев
    • Разработать концептуальную архитектуру КХД
    • Сформулировать задачи, права и обязанности Центра компетенции КХД
    • Сформулировать требования к функционалу и инструментарию КХД
    • Разработать процессы развития и эксплуатации КХД, необходимые регламенты и методики
  • Организовать Центр компетенции КХД и обеспечить его работу в соответствии с поставленными ему задачами.
  • На ограниченном пилотном объеме проверить работоспособность разработанных в рамках Концепции КХД подходов и процессов, при необходимости внести корректировки в Концепцию и соответствующие ОРД.
  • Провести реконструкцию существующего хранилища данных и аналитического инструментария в соответствии с Концепцией, внедрить новые процессы развития и эксплуатации КХД.
  • В дальнейшем эксплуатировать и развивать КХД в соответствии с Концепцией и установленными регламентами и правилами.

В качестве заключения

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

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