MDM против зоопарка ERP и локальных таблиц
Почему большинство провалов BI-проектов - это на самом деле провалы мастер-данных, а не аналитики и не инструментов.
Когда BI-проект не даёт ожидаемого результата, первый импульс - поменять инструмент. Купить другую платформу, нанять другого аналитика, заказать другой дашборд. Я видел этот цикл несколько раз подряд в одной компании.
Проблема почти никогда не в инструменте. Проблема в том, что одни и те же данные в разных системах называются по-разному, считаются по-разному и не имеют ни одного общего ключа. Грязные мастер-данные ломают любой BI, каким бы хорошим ни был инструмент.
Что такое мастер-данные и почему они важнее дашборда
Мастер-данные - это справочники, которые связывают всё остальное. Контрагенты, продукты, склады, сотрудники, статьи затрат. Если в ERP поставщик называется "ООО Ромашка", в таблице закупок - "Ромашка", а в бухгалтерии - "Ромашка ООО (осн.)", то с аналитической точки зрения это три разных объекта.
Никакой BI-инструмент не исправит это автоматически. Он честно сложит три строки там, где должна быть одна.
Мастер-данные (MDM, master data management) - это дисциплина, которая отвечает на вопрос: кто является источником правды для каждого справочника, как туда попадают изменения и как другие системы получают актуальную версию.
Как выглядит типичный зоопарк
В компании с несколькими системами картина обычно такая:
- ERP содержит "официальный" справочник контрагентов, но заводить туда записи неудобно, поэтому часть операций ведётся в обход.
- CRM ведёт собственную базу клиентов, которая с ERP не синхронизируется или синхронизируется раз в сутки.
- Отдел продаж держит "живой" прайс в Excel, потому что в ERP обновление занимает три дня.
- Склад пользуется своими кодами номенклатуры, которые не совпадают с кодами производителя и кодами в финансовой системе.
Когда аналитик пытается собрать сквозной отчёт - например, маржу по продукту с учётом логистики - он тратит 80% времени на согласование этих расхождений. А результат всё равно приходится объяснять на совещании с оговорками.
Почему Excel-таблицы становятся частью архитектуры
Локальные таблицы появляются не потому что люди ленятся пользоваться системой. Они появляются потому что система не даёт нужного им гибкости в нужный момент. Таблица - это быстрый способ закрыть реальную потребность.
Проблема не в самом факте таблицы. Проблема в том, что через полгода эта таблица становится источником данных для других таблиц, потом для отчётов, потом для решений. И когда кто-то уходит из компании, вместе с ним уходит понимание того, как эта таблица устроена.
Таблицы не надо запрещать. Надо понять, какую реальную потребность они закрывают - и создать для этого управляемый процесс.
Что даёт нормальный MDM
Когда справочники централизованы и управляемы:
- любой отчёт считается по одним и тем же объектам, независимо от источника;
- изменения в справочниках распространяются по всем системам предсказуемо;
- можно сравнивать данные за разные периоды, не тратя время на "выравнивание";
- новые системы подключаются к готовому справочнику, а не создают свои копии;
- аналитик работает с данными, а не с их уборкой.
MDM не требует отдельного дорогого продукта на старте. Часто достаточно определить владельца каждого справочника, описать процесс изменений и создать одну таблицу, которой все доверяют.
Практический тест
Прежде чем покупать следующий BI-инструмент или заказывать очередной дашборд, я предлагаю ответить на несколько вопросов:
- Кто в компании отвечает за справочник контрагентов? За справочник продуктов?
- Если один и тот же поставщик добавлен в две разные системы - как это обнаруживается?
- Когда аналитик строит отчёт по продажам, из какой системы берётся список продуктов?
- Если данные в двух отчётах расходятся - есть ли понятный регламент, какому из них доверять?
Если на эти вопросы нет чётких ответов, то дело не в дашборде. Дело в том, что данные ещё не готовы быть источником для аналитики.