Я работаю в «Инфосистемы Джет» около 7 лет, большую часть из которых проектировал и внедрял BI-решения и системы, на них построенные: ситуационные центры, информационно-аналитические системы и всё, что создано, чтобы собирать и анализировать данные. За это время у меня накопился ряд историй и наблюдений на тему особенностей BI-проектов, о которых хотелось бы рассказать.
История 1
Заказчик – крупная территориально распределенная компания. Задача – собирать информацию, формировать отчеты, контрольные панели, а также автоматизировать пару бизнес-процессов. Планировали собрать всё это из решений разных вендоров. Так мы думали до тех пор, пока не явились на установочную встречу.
На ней выяснилось, что от нас требуется реализовать полноценный ситуационный центр с огромным количеством кастомного кода и скрестить порядка 10 вендорских решений, часть из которых уже внедрены. И, что самое неприятное, надо было написать ядро системы с нуля, потому что использовать систему управления метаданными выбранного BI-решения было невозможно. Нам просто не хватало того, что было доступно «из коробки».
Проблема заключалась также в том, что часто требовались довольно сложные отчеты. С этим кое-как удалось справиться штатными функциями вендорских решений. Потом выяснилось, что нужны еще и контрольные панели (дэшборды), причем размером на всю стену (3x9 видеокубов), обновляемые в реальном времени и часто динамической структуры (вылезать за пределы видеостены или предлагать пользователю скроллинг, разумеется, непозволительно).
В этом проекте контрольные панели нам в итоге пришлось реализовать вручную, на чистом HTML/JS, без использования BI-функциональности вендора. Решение оказалось вынужденным, безусловно плохо поддерживаемым. Кстати, именно те наработки дали толчок к созданию нами собственной BI-системы.
Вернемся к видеостене: вся эта красота дополнялась миксом из BI-отчетов, офисных документов, экранов ВКС, ГИС, кусков нашей кастомной функциональности вроде модуля реагирования на инциденты, управления поручениями, дежурной сменой и т.д. Вроде справились и даже начали развивать новое для себя направление – информационно-аналитические системы. Как выяснилось, классический BI-подход к ним далеко не всегда применишь. Как раз об этом будет следующая история.
История 2
Прошли годы, и наконец-то произошел серьезный сдвиг в части требований к BI-платформам. Заказчикам надоело, что BI-решения по сути являются в подавляющем большинстве автономными, оторванными от общей ИТ-инфраструктуры инструментами. Требовались сопряженные между собой НЕмонолитные решения. Никто не хотел «садиться на иглу» одного вендора. Заказчики требовали свободы и потенциальной заменимости одного решения другим.
Рынок осознал, что физически невозможно в одном решении совместить все те функции, которые нужны заказчику, именно с теми возможностями, которые предлагает вендор. В частности, это начали понимать госструктуры, министерства и прочие ведомства. Требовалось что-то, что позволит за приемлемый бюджет и небольшие сроки обеспечить не только визуализацию и анализ данных, но и автоматизацию бизнес-процессов аналитики.
В особенности это коснулось ситуационных центров высших должностных лиц на разных уровнях управления. К ситуационным центрам стали предъявлять всё больше требований. Наличие видеостен и коммутаторов к ним перестало быть достаточным условием. Требовалась серьезная аналитика, которая должна была быть удобной, простой, понятной и, главное – быстрой, поскольку решения в СЦ должны приниматься за секунды. Тогда мы и пришли к выводу, что нужно делать собственную подсистему. Сначала она еще не была отдельным продуктом, не имела названия, но имела четко очерченную функциональность и архитектурные принципы.
Мы провели ряд пилотных проектов в субъектах РФ, шлифуя нашу платформу. Мы объединили BI-функции с функциями автоматизации процессов, не пытаясь охватить все возможные процессы организаций: нашей целью было создание информационно-аналитической системы, задачи которой не в том, чтобы, к примеру, автоматизировать складской учет, а в том, чтобы дать топ-менеджменту и аналитикам инструменты, с помощью которых можно понять, что происходит в организации, что с этим можно сделать, как оценить правильность действий и спрогнозировать, к чему они приведут. И об этом в третьей истории.
Пример дашборда.
Так это выглядит на экране.
История 3
Задача – автоматизация проектов по ремонту сложной, отчасти военной техники и анализ хода исполнения этих проектов. Средняя длительность каждого такого ремонта – 1 год. Использовать MS Project и ему подобные – нельзя. Причем не только по причине импортозамещения, а еще и ввиду того, что объем кастомизации, который требовался заказчику, был слишком велик. В первую очередь это касалось ограничений, валидаций, уникальных бизнес-процессов, да и самой структуры данных.
И снова мы обратились к нашей платформе, добавив к ней еще одну собственную разработку, подсистему управления проектами. Написана она была нами чуть ранее, с нуля, и использовалась в пилотных проектах, но требовала основательной настройки (благо заказчик довольно четко понимал, что именно ему нужно). Отличало эту подсистему то, что благодаря возможностям базовой платформы оказалось на удивление быстро внедрить и растиражировать весь комплекс. От момента постановки задачи до ввода в эксплуатацию прошло 3 месяца. Речь идет не только о самом учете и актуализации планов ремонта, но и об отчетах разного вида, часть из которых, к слову, довольно изощренные.
Например, потребовалось создать так называемую «Производственную диаграмму». Ее цель – мониторить загрузку цехов и выявлять «узкие места». С виду это обычный BI-отчет, в котором сведены в виде дерева и выстроены в единую временную шкалу все активные проекты, каждый из которых – полноценная разворачиваемая диаграмма Ганта. Если кто-то мне подскажет, где найти что-то похожее у «мастодонтов» BI-платформ либо среди OpenSource-компонентов, я пожму ему руку.
Мы проанализировали потребности в визуализации, и с грустью поняли, что нужно писать свой визуализатор. Думаю, ни для кого не секрет, что заказчикам уже давно не интересны стандартные графики и «бублики». Пора признать, что все больше задач требует индивидуального подхода и индивидуальных решений. Безусловно, решения вендоров позволяют наращивать их платформы, но, во-первых, не всегда в нужном объеме, а во-вторых, какими усилиями?
Как быть?
Я считаю, пришло время гибридных решений, которые для простых задач предоставляют понятные и удобные пользовательские интерфейсы, а для более сложных – дают своего рода каркас, или фреймворк, с использованием которого уже реализуется то, что надо, причем без ограничений со стороны вендора. Если только это не архитектурные ограничения (конечно, важность последних неоспорима).
Сделать такую BI-платформу – настоящее искусство, и я не утверждаю, что мы ее уже сделали. Это лишь то, к чему мы стремимся. Если кто-то уже сделал что-то подобное, буду благодарен, если вы поделитесь своим опытом в комментариях к этому посту.
Следующим постом я расскажу об архитектуре нашей платформы и технических подробностях решения.
Альберт Нурутдинов, архитектор «Инфосистемы Джет»
