Внедрение систем бизнес-аналитики: автоматизируем системный беспорядок

С чем реально сталкиваются консультанты, которые внедряют BI-решения, в проектах? Об основных проблемах взаимодействия рассказала изданию vc.ru бизнес-эксперт департамента BI ГК «КОРУС Консалтинг» Мария Перцева.

Сейчас многие предприятия делают ставку на современные информационно-аналитические технологии. Это и традиционный BI, и углубленная аналитика (data mining), и использование искусственного интеллекта, машинного обучения. Компаниям нужны информационные системы, которые должны выявлять закономерности, мониторить достижение поставленных целей, строить прогнозы, моделировать сценарии и помогать выбирать оптимальные решения.

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

Но давайте посмотрим на то, с чем реально сталкиваются консультанты, которые внедряют BI-решения, в реальных проектах.

Проблема целей

Ожидания: «Информационная система сделает наш бизнес более эффективным».

Реальность: cама по себе информационная система не представляет собой бизнес-ценности.

Ценность может представлять решение задачи, предлагаемое данной информационной системой. А идентификация задач должна исходить из стратегических целей предприятия. Зачастую идея внедрения на предприятии «модного» технологического продукта продиктована не столько насущными потребностями бизнеса, сколько желанием быть в тренде или выполнить личные KPI менеджеров. Сотрудники, которым поручено («спущено сверху») ведение проекта, часто не знают или не понимают реальных целей, которые перед ними ставятся, а сложность коммуникаций с топ-менеджментом иногда не позволят транслировать видение целей проекта сверху вниз. Иногда ситуация доходит до абсурда: «Давайте соберем хоть что-то и представим хоть в каком-то виде, а для отчёта перед советом директоров давайте покажем аналитику на Google карте, чтобы было красиво». К сожалению, часто в проектах внедрения традиционных BI-систем критерии успешности проекта подменяются, и вместо получения реально полезной информации, конечный пользователь получает набор красивых, но абсолютно не функциональных картинок.

Проблема данных

Ожидания: «У нас есть данные. Много данных. Большие данные. Давайте их анализировать».

Реальность: качество и полнота данных оставляет желать лучшего. Информация из разных источников не согласована и представлена в разной детализации. Данные из некоторых источников должны поступать, но по разным причинам не поступают.

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

• Отсутствие данных или задержка в их появлении. В сети предприятий общепита данные чеков из некоторых точек приходят с большой задержкой (или не приходят вовсе) из-за проблемы отсутствия устойчивых каналов связи между конечной точкой и головным офисом. Для того, чтобы избавиться от «провала по выручке» в оперативной аналитической отчетности, заказчик вынужден эмулировать данные для таких точек на основе статистики. Подобная эмуляция не позволяет оперативно выявить реальные аномалии с выручкой и приводит к нестыковкам между детализированными данными и сводными агрегированными отчетами.
• Непрозрачность данных, поступающих от обособленных подразделений, франчайзи и партнеров: есть только агрегированные отчеты, нет детальных транзакционных данных, нельзя оценить адекватность данных и проанализировать причины изменений тех или иных показателей.
• Данные из «чёрного ящика»: невозможность получить детализированные данные, потому что «они находятся в системе, которую создали 10 лет назад, и всё, что из неё можно получить – это три отчета в Excel в строго определенных разрезах» (пример утрирован, но, думаю, такая ситуация многим знакома).
• Отсутствие единых справочников: есть детализированные данные из разных источников (например, sell in из внутренней ERP в разрезе SKU и sell out в разрезе тех же SKU, получаемый от торговых сетей, при этом наименования SKU не сходятся). Проблема решаема, но требует дополнительных трудозатрат по ведению маппинга справочных данных из разных источников.

Проблема методологии

Ожидания: «Пусть система нам посчитает» или «Пусть интегратор расскажет нам, как это считать».

Реальность: для того, чтобы «система посчитала», нужна методология.

С методологией всё сложно. С одной стороны, действительно, есть устоявшиеся наборы показателей, применимые как для конкретной отрасли, так и кросс-отраслевые (набор показателей финансовой эффективности или аналитика эффективности использования кадров). Интегратор, имеющий опыт аналогичных внедрений, может поделиться с заказчиком своей экспертизой: какие показатели смотрят обычно, в каких разрезах их стоит представить, в каком порядке. С другой стороны, для определения состава показателей очень важны и целеполагание заказчика, и отраслевая специфика, поэтому при разработке системы показателей для BI недостаточно одного только опыта интегратора. Ведь все компании разные, и система аналитических показателей для каждого конкретного клиента уникальна!

Например, набор финансовых показателей, которые нужны конкретному заказчику зависит от его стратегических целей. Если цель – увеличение продаж, то в качестве главных показателей на дашборд стоит выводить абсолютный прирост продаж и удельный прирост продаж на сотрудника. Если цель – повышение эффективности и снижение затрат, то, в первую очередь, нужны показатели прибыльности каждого продукта и доля затрат на единицу продаж, и дальше уже всё дерево аналитики вырастает из этого «корня». Для акционеров и инвесторов – EBITDA, а для компании, перед которой стоит задача экспансии на рынок – выручка. Для формирования состава показателей крайне важно, чтобы заказчик чётко сформулировал свои цели.

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

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

Не проще дела обстоят с углубленной аналитикой и предиктивными решениями. От заказчика здесь требуется четкое определение прогнозируемых объектов и понятий, формализация требований. Также заказчику нужно поделиться с консультантами своими внутренними знаниями об устройстве бизнеса (от чего это может зависеть? как это должно влиять? данные о каких факторах есть у нас в наличии?). Определение и формализация задачи - это всегда совместная работа. А дальше уже - работа интегратора – проверить гипотезы, выявить значимые и отбросить незначимые факторы, подобрать адекватные модели и бороться за качество решения.

И что делать?

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

• Работать с целеполаганием. Привлекать к обсуждению и формулировке целей проекта топ-менеджмент, увязывать задачи проекта со стратегическими целями компании, налаживать коммуникацию внутри организации.
• Выделять заинтересованных бизнес-экспертов к работе над проектом. Обсуждать методологию, не бояться изменять устоявшиеся алгоритмы расчета, особенно, если они уже никому не понятны. Завязывать показатели с целями управления. И обязательно – документировать.
• Обеспечить надежное хранение данных. Необходимо обязательно включать в ИТ-стратегию предприятия меры по созданию, актуализации и развитию корпоративного хранилища данных (КХД). КХД - это цифровое «сердце» организации. И, скорее всего, у заказчика оно уже есть (а, может быть, и не одно!). Важно задаться вопросом, отвечают ли возможности данного хранилища текущим потребностям и потребностям ближайшего будущего. Возможно, путь по развитию бизнес-аналитики и выходу на новый уровень управления стоит начать с проекта глобального обновления КХД, как бы скучно это ни звучало.
• Создать эффективные процессы сбора данных. Например, внедрить механизмы сбора данных от партнёров, ввода данных сотрудниками на рабочих местах. В этом могут помочь такие инструменты, как мобильные приложения для «полевых» сотрудников, удобные формы ввода и согласования данных, workflow с напоминаниями и контролем.
• Автоматизировать сбор данных с устройств, датчиков, счетчиков. Как пример - IoT на производстве для мониторинга работоспособности и предотвращения сбоев. Или снятие данных со счетчика посетителей магазина - для оценки конверсии.
• Обеспечить технологические процедуры обмена данными: веб-сервисы, шины и т.п.
• Контролировать согласованность собираемых данных - здесь могут быть полезными аналитические приложения, отражающие нестыковки в данных. Резкие отличия от средних или допустимых значений, отсутствие связанных записей - такие ошибки можно отследить, например, с помощью ежедневного мониторинга данных в BI-системе.
• Наладить постоянную работу по сохранению и улучшению качества данных. Для организаций, владеющих большим количеством данных, актуальна задача Data Management, решаемая с использованием соответствующих инструментов. Примеры задач: унификация данных, устранение дубликатов, заполнение пропущенных данных (это особенно актуально для ведения больших клиентских баз), выявление связей между данными, реализация контроля и подсказок при вводе данных, отслеживание и предотвращение несанкционированных изменений в данных. Для решения данной задачи важно не только внедрить технологические инструменты, но и выстроить в организации соответствующие бизнес-процессы, и в обязательном порядке – назначить ответственных владельцев данных.

…Аналитика нужна срочно, а хранилище и методология – это очень долго

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

Источник: vc.ru