Данные – важнейший ресурс для принятия обоснованных управленческих решений. Именно поэтому на фоне общего сокращения экономики рынок продуктов для бизнес-анализа переживает бум. Мы хотим поделиться опытом внедрения систем 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 (power bi, tableau) не обладают развитым функционалом коннекта к сложным источникам (например, личные кабинеты web-сервисов с доступом через API, REST-клиент, POST-запросы). В этих случаях требуется предварительная выгрузка данных из операционных систем, применение к ним ETL-процедур, загрузка в хранилище с СУБД, и только потом коннект к средству визуализации (BI-системы класса in-memory).
Можете прокомментировать в этом ключе, почему для "системы класса in-memory, которым не нужны системные хранилища данных"? По моему мнению, они нужны.