Как ИТ-директору загубить BI-проект

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

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

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

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

В такой ситуации слишком много неопределенностей, поэтому рекомендую разделать проект на 3 очереди:

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

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

2. Возглавить проект. Как ни странно звучит, но ИТ-директору не стоит брать на себя руководство проектом. Вообще, BI по-русски — это система управленческой отчетности, и создается она для финансово-экономических служб и топ-менеджмента. Часто встречаю ИТ-директоров, которые берут тайм-аут для того, чтобы собрать требования с финансистов, коммерсантов, маркетологов и других служб, но еще не встречал ни одного, кто бы потом выдал ТЗ. Как правило, внедрение BI бесконечно откладывается.

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

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

Чтобы избежать подобной ситуации, нужно в рамках пилота (или тестовой задачи) предложить больше чем просто табличный отчет. Во-первых, это визуализация данных (так называемые дашборды, или информационные панели), а во-вторых, отображение в них не просто абсолютных данных, а KPI хотя бы в виде «светофоров» по отклонениям (% выполнения плана, доли, рейтинги и т.д.). В итоге это позволит уместить «портянки» в 100 колонок и 500 строк на один экран, дающий наглядные ответы на вопросы.

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

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

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

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

На самом деле, проектных рисков гораздо больше, и в статье не затронута тема взаимоотношений заказчика и подрядчика, так как это отдельная песня. Причем сразу хочу пояснить: основная мысль публикации заключается не в том, что проекты по созданию аналитических систем надо отдавать на подряд. При наличии профильных специалистов (готовности брать их в штат) можно сделать и своими силами, только главное — перестать подходить к созданию системы бизнес-аналитики, как традиционному ИТ-проекту поставки софта и его внедрения. Бизнес-аналитика — это в первую очередь бизнес-задача, и уже во-вторую техническая. Пока не поменяется отношение, многие компании будут продолжать покупать дорогой софт и использовать его на 10%.