Когда пора задуматься о внедерении BI-системы?

В этой статье хочу поделиться личными наблюдениями вот за каким процессом. Как компании проходят путь от пункта «Нам достаточно стандартных отчетов в корпоративной учетной системе » до «Подготовка отчетности требует много времени и ресурсов. Пора все автоматизировать!». Надеюсь, что ниже изложенное поможет кому-то избежать некоторых ошибок и правильно выбрать решение Business Intelligence (BI-платформу).

Стадия первая. Прелюдия.

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

Стадия вторая. Возбуждение.

Затем у руководителей растут аппетиты (растет компания, растет количество управленцев, приходят руководители с новым взглядом на бизнес и т.д.), и они начинают запрашивать все больше разовых (ad-hoc) отчетов, чтобы взглянуть на бизнес под разными углами. С ростом компании таких отчетов все больше, часть из них переходит в разряд регулярных, и у специалистов от бизнеса возникают проблемы с подготовкой всего этого многообразия в срок. В поисках спасения они начинают требовать от ИТ взять часть работы на себя, а именно, просят различные выгрузки из базы учетной системы (УС) и все чаще обращаются с требованиями разработать в УС новые отчеты.

Стадия третья. Зачатие (Эмбрион).

После всех этих процессов в компании начинает образовываться направление, именуемое бизнесом «аналитики». Так, в компании может появиться SQL-разработчик (с этого я начал путь) и специалист/ты, владеющие Excel и прочими программами из пакета Office. Развитие на этой стадии может проходить по-разному. Я лично видел, что со временем количество аналитиков может стать довольно большим (каждое подразделение обзаводится 1-2 специалистами или же в компании образуется отдельное подразделение). Я, кстати, мог оказаться и в этой роли, но мне повезло, что в университете меня не учили Excel’ю и на первом собеседовании тетенька из отдела HR сказала «ай-ай-ай». Мои уверения её в том, что я быстро (за пару недель) освою сей продукт, скорее всего, породили в ней мысль: «Явно передо мной самоуверенный болван, ибо у нас тут другие тетеньки годами работают на компутере и все еще боятся этого зверя, а этот наглый шкет такое заявляет». Лично мне быстро наскучило создавать разные выгрузки, и я начал интересоваться, а что же есть подходящего на рынке. Но в 2006 году я еще даже не знал термина BI, поэтому поиски были недолгими. Остановился я в результате на технологии OLAP.

Стадия четвертая. Избавление ИТ от ad-hoc или рождение OLAP. Начало проекта BI.

Как мне кажется, OLAP — уже довольно распространенная вещь, и с высокой долей вероятности в компании появляются люди, работавшие с OLAP-кубами как пользователи или разработчики. Они-то и сеят мысль о том, что внедрение кубов станет избавлением от многих проблем и облегчит жизнь большого количества сотрудников. Или же этот человек имел опыт с некой BI-системой. Поскольку сейчас речь скорее не о самых крупных компаниях, то людей, предлагающих что-то из SAP Business Objects, IBM Cognos, Oracle BI перестанут слушать, когда увидят ценник. В крупных же компаниях уже давно что-нибудь да есть, как минимум Microsoft BI (SQL Analysis Services и Reporting Services). «Как минимум» здесь не пренебрежение, просто это довольно распространенные решения, так как поставляются в комплекте в сервером БД, что часто приводит к выбору именно этой платформы.

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

Ошибка первая. Спонтанный выбор системы.

Как это бывает? Поскольку тем самым человеком может быть либо лицо высокопоставленное, либо весьма про-активный специалист от ИТ, отдающий предпочтение некому продукту, на выбор системы не отводится никакого времени, а просто покупается то, что пролоббировали эти люди. Это может привести к тому, что выбранный продукт не очень-то приживется в компании и, решив одни проблемы, заменит их другими.
Думаю, что перед выбором следуют ответить хотя бы на следующие несколько вопросов (подробнее я писал об этом в прошлой статье):
Для кого предназначена система (кто основной потребитель)?
Какие предпочтения в компании в способах доставки данных до потребителя?
С какими объемами данных придется иметь дело?
Сколько компания готова за все это заплатить и тратить на дальнейшее развитие и обслуживание?

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

Поясню суть вопроса. В некоторых системах можно довольно просто поделить функции следующим образом: ИТ отвечает за разработку моделей данных, а уже аналитики занимаются dashboard’ами, отчетными формами — тем, что видят конечные бизнес-пользователи. Зачем это? Требования к внешнему виду отчетов меняются зачастую чаще всего. Плюс, один и тот же по сути отчет (набор данных) может существовать в нескольких вариациях для разных заказчиков. В добавок, в оформлении все-таки важна эстетика, до которой не всегда есть дело на которую не хватает времени у ИТ, их дело — чтобы все это работало. Это особенно важно, если у вас хорошие разработчики с БОЛЬШОЙ зарплатой.
Дабы избежать проблему, терапию надо начинать своевременно. Хорошо, если на 2-ой-3-й стадиях ИТ систематизирует потребности, отвечая на первый вопрос и подталкивает бизнес к вопросу о внедрении BI. На этих стадиях заказчики полны энтузиазма и готовы обсуждать разные варианты, а главное — сформулировать свои требования, что, по моему мнению, является основной задачей бизнес-пользователей в этом проекте (опять же см. предыдущую статью).

Ошибка вторая. DWH или его отсутствие.

Бывает, что перед внедрением собственно системы подготовки автоматизированной отчетности, никто не озаботился тем, что все-таки было бы неплохо иметь хранилище данных (DWH). В результате, это приводит к тому, что OLAP или отчеты обращаются к большому числу источников данных, различным витринам, которые сформировались на 3-ей стадии. Из этого рождается хаос. Развивать и поддерживать систему после этого становится крайне затруднительно, и может оказаться так, что все придется строить заново.
Выбору системы для DWH тоже нужно уделить отдельное время, но зачастую это та же СУБД, на которой работает учетная система (УС). Такой подход вполне оправдан, так как в компании уже есть специалисты по продукту и может получиться экономия на лицензиях. Конечно, это не относится к случаю, когда в УС копится очень много данных (большое количество транзакций и СУБД выбиралась именно для этого) и лучше поискать другую СУБД, более подходящую для задач аналитики (есть механизмы колоночного хранения, размещение таблиц в оперативной памяти и т.п.).
Еще возможен вариант интеграции учетной системы с неким BI инструментом (видел предложения 1С + QlikView, от некоторых интеграторов), но тут я не совсем в курсе как всё устроено. Буду рад, если кто-то напишет об этом в комментариях или в личку.

Ошибка третья. Игнорирование того факта, что проект уже давно надо было начать.

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

Итог.
В заключение хотел бы сказать, что хорошо, когда вы можете потратить время на встречи с интеграторами для ознакомления с различными системами, но такое я видел только в очень крупной компании, в которой стоимость проекта DWH+BI оценивалась в сотни тысяч долларов. Тут была и заинтересованность менеджмента (ответственность за бюджет), и интерес внедренцев (крупный заказ). И тянулось все это год. В компаниях небольших такое просто невозможно. К сожалению, я не встречал интеграторов (возможно, плохо искал), предоставляющих широкую экспертизу. Обычно они концентрируются на 1-2 продуктах. Сам лично общался с 10 компаниями-интеграторами примерно с таким раскладом:2 занимаются Microsoft BI, 2 — QlikView/ Qlik Sense, 3 — Cognos BI, 1 -Tableau, 1 — Cognos и Microsoft, 1 — QlikView/ Qlik Sense и Tableau.

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

Найти решение у бизнес-партнера QlikTech (QlikView) в России.

Форум разработчиков QlikView и Qlik Sense. Получите ответы на все вопросы по QlikView и Qlik Sense!

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий

56 queries in 0,200 seconds