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, которым не нужны системные хранилища данных"? По моему мнению, они нужны.

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

Факт дня: Трамп ввел пошлины в размере 25% на китайские товары.

США: криптовалюта заменит деньги

Факт дня: Глава SEC не считает Bitcoin ценной бумагой.

​Amazon меняет менеджеров на роботы

Тренд дня: Amazon начал ставить роботов на менеджерские позиции.

​Microsoft идет по пути Amazon

Тренд дня: Microsoft работает над технологией автоматизированных магазинов без касс и продавцов.