6 этапов грамотного внедрения BI-системы

Данные – важнейший ресурс для принятия обоснованных управленческих решений. Именно поэтому на фоне общего сокращения экономики рынок продуктов для бизнес-анализа переживает бум. Мы хотим поделиться опытом внедрения систем Business Intelligence (BI-систем). Это экспертиза, которую мы накопили за годы работы с сотнями компаний как уровня Leroy Merlin или «Транзас», так и с молодыми проектами, которым важно оптимизировать ресурсы, чтобы выжить в турбулентном пространстве российской экономики. Мы покажем, как поэтапно проходит грамотное внедрение систем такого класса, и обоснуем, для чего нужен каждый этап.

Что такое BI-система, и как она работает

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

Умелое использование данных для него – гарантия прочности здания. Ошибаться нельзя: высотка не должна обрушиться и похоронить под обломками людские жизни. Так и в бизнесе. Чтобы принимать взвешенные стратегические решения, развивать предприятие и вовремя противостоять рискам, собственник должен ежедневно анализировать терабайты информации (что практически невозможно) или автоматизировать этот процесс.

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

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

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

Этап №1. Определение и анализ требований

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

Правильным методом здесь будет идти сверху вниз – если автоматизировать существующую отчетность, двигаясь от специалистов нижнего уровня, руководителей и аналитиков в сторону высшего руководства, то на финише может оказаться, что работа была бесполезной, потому что топ-менеджерам нужны другие цифры. Продвигаясь сверху вниз, мы получаем правильную картинку: финансовый директор знает, что он должен видеть в P&L, дальше его запрос адаптируется на уровень региональных и местных управленцев, а они, в свою очередь, четко понимают, какие цифры нужны на их уровне. Так мы спускаемся на уровень транзакций до самого низа.

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

Дерево отчетов на примере сети магазина одежды

Дерево отчетов

Увеличить изображение

Этап №2. Организация данных

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

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

Этап №3. Выбор стека технологий

Тема безграничная. Кратко опишем, что важно сделать на этом этапе: определить источники данных и уточнить, есть ли в них необходимая информация и показатели. Очень часто приходится дорабатывать учетные системы, чтобы показатели заводились. Когда пул источников собран, можно переходить к учетным системам, веб-ресурсам и внутренним системам компании, чтобы покомпонентно спроектировать архитектуру и прописать роль источников для трансформации данных. Любые сведения в BI-систему поступают в сыром виде, и на этом этапе только от нас зависит, насколько точные и удобные для восприятия данные менеджеры получат на выходе.

Этап №4. Проектирование интерфейсов

Сотрудники, которые пользуются системой, ценят удобный и приятный глазу интерфейс возможно так же глубоко, как и возможности, которые решение дает. Поэтому на проектах часто вводится этап прототипирования, когда мы отрисовываем формы интерфейса. Причем, если внедряем систему SAP, то UX и UI стараемся делать в интерфейсе этой системы, если Qlik, то рисуем в интерфейсе этой платформы. Благодаря такому этапу клиент понимает, какие графики лучше использовать для визуализации тех или иных показателей, какие цвета подобрать, как удобнее расположить фильтр и т.д. После этапа трансформации данных этот прототип достаточно будет наполнить. В остальном он полностью соответствует ожиданиям бизнес-пользователей.

Этап №5. Тестирование системы

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

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

Отдельная тема – внедрение системы на динамически меняющийся источник данных, или когда мы внедряем решение на данных Excel, но этап загрузки данных необходимо перенести на вновь внедренный источник, в котором могло поменяться все от структуры хранилища до самих сведений. Здесь внедрение и тестирование будет идти по иным правилам.

Этап №6. Обучение команды

Обучение команды

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

Частые ошибки при внедрении

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

  • Не разбираться в типах платформ. Существуют системы класса in-memory, которым не нужны системные хранилища данных; и платформы, которые требуют двухкомпонентную архитектуру, то есть отдельное хранилище и отдельный BI-инструмент для визуализации.
  • Работать крупными мазками. Этапы загрузки, трансформации и последующей загрузки данных в приложение всегда стоит максимально детализировать и разбивать на более короткие отрезки. Многие в одном скрипте загружают, трансформируют данные, и делают последующую выгрузку. С гигантскими кусками кода не справится ни подрядчик, ни клиент. Но если код разбит на маленькие кусочки, определить, что вышло из строя, будет легко. Это сэкономит время и деньги на последующую поддержку.
  • Сразу автоматизировать. Нельзя сразу отдавать в разработку отчеты от бизнес-пользователей. Возможно, они не видели других, более удобных форматов. Может быть, раньше они сталкивались с техническими ограничениями и не могли представить анализ по-другому. Простая разработка не решает задач бизнеса – нужно глубже погружаться в отрасль и процессы в компании, выяснять, в чем заключаются проблемы и целенаправленно с ними работать.

Сколько это стоит и от чего зависит

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

Чем помогут консультанты

Часто консультанты самостоятельно выполняют весь объем работ и минимально привлекают сотрудников клиента. Но случается, что объем работ собственных сотрудников соизмерим с объемом работ интегратора. В зависимости от задач и финансовых возможностей клиента, компания-консультант может участвовать в проекте в нескольких форматах.

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

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

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

Выводы

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

Иллюстрации и фото: архив автора

Комментарии
Аналитик, Ростов-на-Дону

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

Вице-президент, зам. гендиректора, Воронеж

С трудом начинаю понимать статьи многих молодых людей. Всю жизнь система отчетности строилась только после шагов: бизнес модель; показатели BSC, показатели KPI и далее в привязке к KPI сами формы отчетности. А иначе ..(??). Что касается программной реализации, то это и не такой сложной вопрос. За основу берется одна из изучаемых в ВУЗЕ СУБД. И один из ИНТЕГРАТОРОВ, которые затягивают в СУБД данные из различных специализированных пакетов применяемых в организации. Практически все сотрудники современных компаний хорошо владеют простыми приемами позволяющие формировать свои запросы и отчеты. И система начнет функционировать и саморазвиваться с первого дня установки.

Директор по производству, Украина

Автор пишет в своей статье: "Чтобы построить высотку, директор строительной компании должен знать о проекте все до последнего шурупа: ...".

Нынче "совсем страх потеряли". Запросто пишут о том, о чем не имеют ни малейшего представления.

Менеджер, Москва

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

Нач. отдела, зам. руководителя, Москва

Андрей, Вы пишете, что

  • Не разбираться в типах платформ. Существуют системы класса in-memory, которым не нужны системные хранилища данных; и платформы, которые требуют двухкомпонентную архитектуру, то есть отдельное хранилище и отдельный BI-инструмент для визуализации.

Но ведь системы класса in-memory (power bi, tableau) не обладают развитым функционалом коннекта к сложным источникам (например, личные кабинеты web-сервисов с доступом через API, REST-клиент, POST-запросы). В этих случаях требуется предварительная выгрузка данных из операционных систем, применение к ним ETL-процедур, загрузка в хранилище с СУБД, и только потом коннект к средству визуализации (BI-системы класса in-memory).

Можете прокомментировать в этом ключе, почему для "системы класса in-memory, которым не нужны системные хранилища данных"? По моему мнению, они нужны.

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Вакансии (1555)
Все вакансии
Дискуссии
Все дискуссии
Цифры и факты
​ЕС вводит новые санкции

Тренд дня: 28 стран ЕС одобрили новые санкции за разработку химоружия.

«Роснефть» займется ледоколами

Цифра дня: Ледокол «Лидер» построит судоверфь «Роснефти» за 100 млрд.

«Яндексу» угрожают штрафы

Факт дня: Штраф грозит за выдачу ссылок на заблокированные сайты.

​Платить долги можно после закрытия бизнеса

Тренд дня: МЭР хочет разрешить выплачивать задолженность компаний и после их ликвидации.