Это пятая статья практической серии о том, что должно быть определено до того, как неопределённость превратится в код, сроки и обязательства.
Мировоззренческая основа серии – «Автоматизировать бардак нельзя навести порядок: где у ИТ должно быть право вето».
Практическая серия:
«Проект уже запущен, а проблему ещё не нашли» – диагностика инициативы.
«Проект признали успешным. А бизнесу стало легче?» – ценность и проверка результата.
«Риск был у всех. Ответственность оказалась у одного» – полномочия и карта решений.
«Мы производим гвозди по ГОСТу: как идеально выполнить неправильное ТЗ» – непринятые решения в бизнес-процессе.
Здесь продолжаем ту же логику на следующем уровне – в данных.
TL;DR
Корпоративную НСИ не всегда можно «сначала почистить», потому что иногда единого корпоративного объекта данных ещё нет. Разные системы могут содержать разные, но обоснованные части одного объекта. Тогда задача проекта – не выбрать самую удобную базу, а определить, где возникает каждый значимый факт, кто отвечает за его смысл, какой источник считается авторитетным и кто завершает спор. Эту неопределённость удобно разбирать через карту источников и ответственности за данные.
Когда локально правы все
В прошлой статье мы разбирали ситуацию, когда системе уже нужен однозначный алгоритм, а бизнес ещё не принял решение, по какому правилу должен работать процесс. С данными возникает похожая проблема, только заметить её бывает сложнее. Правило процесса приходится хотя бы сформулировать словами, а данные уже лежат в системах, имеют коды, наименования и единицы измерения и выглядят как готовые факты. Очень легко решить, что осталось только найти правильный источник.
На одном из других проектов – уже в другой компании, с другой командой и другими действующими лицами – такая граница прошла через данные. Я руководил проектом со стороны интегратора. Мы автоматизировали производственный учёт в распределённой компании с несколькими филиалами, в том числе производственными. Новая ERP должна была получить единую номенклатуру, а существующие системы – стать источниками для миграции и последующих обменов.
Ещё до старта было понятно, что источников много. Непонятно было другое – насколько сильно их локальные представления разойдутся, когда придётся собрать их в одну корпоративную модель. В одних филиалах фактически единственным справочником была бухгалтерская база. Для учёта её хватало, но технические характеристики нередко были зашиты прямо в полное наименование – сокращениями, условными обозначениями, размерами и специальными символами. В других филиалах подробная информация, включая характеристики и чертежи, находилась в локальных производственных системах. Где-то основным источником была система конструкторского подразделения, где-то часть необходимых данных продолжала жить в Excel.
Всего вокруг будущей ERP было около десятка систем и массивов данных. Точное количество и состав намеренно не раскрываю: сочетание деталей сделало бы компанию слишком узнаваемой.
На обследовании мы собрали существующие справочники, разобрались, какие функциональные группы отвечают за разные части информации, построили схему интеграций и карту миграции. Потом показали результат спонсору, руководителю проекта заказчика и нескольким линейным руководителям. На одном слайде новая ERP стояла в центре окружения из существующих систем, на другом было видно, откуда предполагается получать разные части номенклатуры.
Первая реакция была спокойной:
«Надо подумать».
Это важная деталь. До проекта компания с этой проблемой жила. Бухгалтерия вела учёт, производство производило, конструкторы работали со своими данными, филиалы использовали привычные системы. Если противоречия и возникали, они оставались внутри локальных контуров и не воспринимались как единая корпоративная проблема. Общая ERP впервые заставляла эти контуры договориться между собой.
Хороший пример – единицы измерения. Один из шумоизоляционных материалов закупался в погонных метрах, но ширина рулона могла отличаться. Значит, одинаковое количество погонных метров соответствовало разной площади материала. Для закупки длина была естественной характеристикой, для производства могла быть важнее площадь.
Технически серьёзная ERP без труда хранит несколько единиц измерения и коэффициенты пересчёта. Проблема не в функциональности ERP: кто-то должен сначала установить корпоративную модель – какая единица базовая, какие дополнительные допустимы, как учитывать ширину конкретного исполнения, где брать её достоверное значение и кто отвечает за правильность правила пересчёта.
Если бы локальные трактовки просто перенесли в общую ERP без такого правила, одинаковое числовое значение остатка в погонных метрах перестало бы означать одинаковое физическое количество материала по площади. До проекта эта проблема оставалась локальной: подразделения работали каждое в своей системе. Ошибки ещё не произошло – но возможность встроить её прямо в новую корпоративную модель уже появилась.
После этого привычная формула «перед загрузкой надо почистить НСИ» перестаёт быть достаточной. Что именно чистить? Какое значение удалить как неправильное?
Перед нами были не несколько испорченных копий одного готового справочника. Были разные способы описывать один и тот же бизнес-объект под задачи разных функций.
Иногда перед внедрением ERP действительно нужно очистить НСИ. Но иногда сначала надо создать то корпоративное представление, которое потом вообще имеет смысл очищать.
Почему два привычных ответа не работают
У такой ситуации есть две естественные реакции. Бизнес говорит: справочники уже существуют и используются годами, значит задача проекта – собрать их, привести к единому виду и загрузить. ИТ отвечает: сначала определитесь с дублями, атрибутами и единицами измерения, а потом будем проектировать миграцию.
Обе стороны исходят из одного предположения: где-то уже существует правильная корпоративная номенклатура, до которой нужно только добраться.
Бизнес здесь вполне рационален. Номенклатура уже участвует в закупках, производстве, складских движениях и учёте, поэтому неожиданное заявление проекта «у вас нет правильных данных» легко воспринимается как попытка ИТ усложнить задачу. Но и ИТ не придумывает проблему: миграцию нельзя проектировать как копирование записей, если один и тот же атрибут разные функции трактуют по-разному.
Сложность начинается с фразы «пусть бизнес решит». Кто именно? В нашей проектной команде было несколько функциональных групп – финансы, закупки и склад, производство и другие. Каждая хорошо понимала свою часть объекта. Проблема появлялась на границах между ними.
Здесь полезно жёстко разделить две работы, которые часто объединяют словами «очистить НСИ».
Первая – качество данных: технические дубли, форматы, заполненность, нормализация наименований, проверка уже установленных ограничений. Эту работу не нужно откладывать, пока компания построит идеальный Data Governance. Она может идти параллельно с проектированием.
Вторая – корпоративный смысл данных: какая единица является базовой, какой классификатор принят компанией, чьё значение имеет приоритет, кто вправе менять правило. Здесь уже недостаточно исправить запись.
Поэтому отсутствие решения по одному спорному атрибуту не означает «остановить всю миграцию». Остановить имеет смысл только ту часть реализации, где проекту пришлось бы самостоятельно превратить ещё не принятое корпоративное правило в код или правило загрузки.
То же относится к модели данных. Правильную data model строить нужно. Но сама модель не решает, какая единица базовая и чья классификация корпоративная. Она точно фиксирует принятые решения, но не может сделать их корпоративными вместо компании.
В предыдущей статье похожая проблема возникала с процессом: разработчик мог превратить непринятое бизнес-правило в работающий алгоритм. С данными вместо условия в коде появляется приоритет источников, правило преобразования или очередность загрузки.
Бизнес не обязан заранее знать архитектуру корпоративных данных. ИТ не обязано угадывать её вместо бизнеса. Задача проекта – обнаружить место, где локально работающие правила перестают складываться в корпоративное, показать последствия и довести вопрос до полномочного решения.
Карта источников и ответственности
В том проекте эта работа была распределена между схемой интеграций, картой миграции, материалами обследования и распределением функциональной ответственности. Сегодня я бы собрал её в один компактный рабочий формат – карту источников и ответственности за данные.
Она нужна не для описания всего информационного хозяйства компании, а для значимых атрибутов конкретного бизнес-объекта.
Атрибут или группа данных | Где возникает | Кто отвечает за смысл | Авторитетный источник | Кто использует | Кто решает конфликт | Статус |
|---|---|---|---|---|---|---|
Конструкторские характеристики | Конструкторское подразделение | Конструкторское подразделение | Система конструкторов | Производство, ERP | Не требуется | Источник определён |
Производственные параметры | Производство | Производство | Производственная система | ERP, планирование | Не требуется | Источник определён |
Учётные реквизиты | Финансы | Финансы | Бухгалтерская система | ERP, отчётность | Не требуется | Источник определён |
Единицы измерения | Несколько функций | Несколько функций | Не определён однозначно | Производство, склад, финансы | Владелец данных | Конфликт, владелец решения известен |
Первоисточник – место, где факт возникает. Авторитетный источник – источник, чьё значение компания договорилась использовать как нормативное для конкретного атрибута. Они могут совпадать – и в простых случаях совпадают. Но это не обязательно: в другой модели факт может возникать в одной системе, а право подтвердить его корпоративное значение принадлежать другой функции. Ради таких случаев колонки и разведены.
Я не предлагаю здесь собственную альтернативу Data Governance или MDM. В качестве общей профессиональной рамки использую DAMA-DMBOK, но для статьи беру только те понятия, которые нужны для разбора конкретной проектной ситуации.
В официальном описании ревизии DAMA-DMBOK2 2024 отдельно отмечено уточнение роли Data Owner: это бизнес-роль, отвечающая за решения внутри своего домена данных. На странице DAMA What is Data Management? Data Governance связывается с ответственностью, политиками и правами принятия решений. Именно этот смысл мне здесь нужен: у содержательного решения о данных должен быть не только эксперт, но и полномочный владелец.
При этом владелец данных и Data Steward – не обязательно одна роль. IBM в материале What Is Data Stewardship? описывает stewardship как практическую работу по обеспечению качества и доступности данных. В задачи steward могут входить метаданные, справочные данные (reference data), контроль качества и прослеживаемость происхождения и движения данных (data lineage). То есть право установить правило и повседневная работа по его применению могут быть разделены.
С термином System of Record стоит быть аккуратнее. IBM в материале System of Record vs. Source of Truth называет SOR авторитетным источником данных для определённого бизнес-домена или процесса и отдельно отличает его от Source of Truth, который может объединять данные из нескольких доменов. Поэтому дальше я не использую System of Record как универсальный синоним «источника истины». Для нашего прикладного разговора точнее выражение «авторитетный источник» для конкретного атрибута или группы данных.
Golden Record использую именно в MDM-контексте. Informatica в обзоре What Is Master Data Management? описывает MDM как создание master record, также называемой golden record, – согласованного представления ключевой сущности. Для нашего кейса важен практический вывод: место, где факт возник, авторитетный источник конкретного атрибута и итоговое корпоративное представление объекта не обязаны находиться в одной системе.
Самая интересная строка карты – не та, где быстро найден очередной «мастер». Гораздо полезнее бывает честная запись:
Авторитетный источник не определён. Требуется решение владельца данных.
При этом владелец не заменяет функциональных экспертов. Решение может готовиться совместно с конструкторами, производством, финансами и другими заинтересованными функциями. Его полномочие нужно для того, чтобы межфункциональный спор закончился корпоративным правилом.
Именно так происходило у нас. Функциональные группы определяли свои наборы атрибутов и показывали, где находится достоверная информация. По спорным реквизитам заказчик определил владельца данных. Когда стало понятно, что конфликты между подразделениями и филиалами будут возникать регулярно, появилась отдельная служба НСИ с арбитражной функцией. Она не стала «знать всю номенклатуру лучше всех» и не заменила функциональную экспертизу, но у компании появилась постоянная точка, где спор можно довести до решения.
Если владельца данных пока нет
На реальном проекте легко услышать: «Всё правильно, но никакого владельца данных у нас нет и неизвестно, когда появится. Что теперь – ждать организационной реформы?»
Не обязательно.
Если решение требуется сейчас, проектная команда может подготовить временный вариант: описать правило, показать последствия и вынести его на утверждение спонсору, проектному комитету или другому органу, который вправе принять соответствующий риск. Важно только не выдавать этот компромисс за окончательное корпоративное правило.
У временного решения должны быть как минимум четыре признака: понятно, кто его утвердил; какой риск принят; когда или при каком событии правило пересматривается; можно ли после окончательного решения восстановить исходные значения и выполнить преобразование заново.
Для миграции последнее особенно важно. После преобразования «источник А сказал X, источник Б – Y, а загрузили Z» не должно остаться только Z без возможности понять его происхождение.
Так проект продолжает двигаться, но временный технический выбор не маскируется под корпоративное правило.
Не пятая новая таблица
На пятой статье серии есть риск превратить весь подход в фабрику реестров: диагностический паспорт, карточка проверки выгоды, карта решений, реестр непринятых решений процесса, теперь ещё карта источников.
Это не пять конкурирующих методологий. Это разные срезы одной логики:
Этап | Артефакт | Что должно стать видимым |
|---|---|---|
Диагностика | Диагностический паспорт | Что мы вообще пытаемся изменить и чего ещё не знаем |
Ценность | Карточка проверки выгоды | Почему изменение должно дать эффект |
Ответственность | Карта решений | Какой выбор требуется и кто вправе его сделать |
Процесс | Реестр непринятых решений | Где отсутствует правило работы |
Данные | Карта источников и ответственности | Где отсутствует авторитетный источник или корпоративное правило |
Отдельные документы для этого не обязательны. Если карта данных обнаружила «авторитетный источник единицы измерения не определён», этот вопрос вполне может сразу стать записью в общей карте решений с владельцем, вариантами и сроком.
Артефакты можно объединять. Логику – нельзя.
Ценность не в количестве таблиц, а в способности отличить уже принятое решение от того, которое проектная команда только по привычке приняла за решённое.
Три варианта реализации
Когда источники и нерешённые конфликты стали видны, у заказчика оставалось три практических пути: сохранить исходную идею и интегрировать ERP примерно с десятком существующих источников; загрузить доступные данные и перенести значительную часть валидации внутрь новой ERP; либо выделить корпоративную НСИ в отдельный контур.
Ни один вариант сам по себе не отвечал на вопрос, кто определяет правильное корпоративное значение. При прямых интеграциях правило могло незаметно поселиться в коде обмена, при ручной валидации – превратиться в ежедневный спор пользователей, а MDM вполне способна собрать в одном месте хорошо централизованные противоречия.
Для заказчика это была далеко не бесплатная развилка. Вместо решения задачи внутри ERP появлялся отдельный проект, дополнительные затраты и новая организационная функция. Поэтому то самое «надо подумать» и прозвучало, а к вопросу пришлось возвращаться на нескольких встречах.
В итоге заказчик выбрал отдельный контур НСИ. Проект MDM стартовал немного раньше ERP, а затем оба шли параллельно с таким лагом, чтобы к моменту, когда ERP понадобятся корпоративные справочники, централизованный контур уже работал.
Это не означает «много источников – внедряйте MDM». В другой компании правильным решением могут оказаться несколько прямых интеграций, вывод одной локальной системы или даже ограниченная ручная валидация. Сравнение таких вариантов по стоимости, срокам, сложности, обратимости и остаточному риску – уже отдельная задача, к которой мы вернёмся дальше в серии.
После появления MDM локальные системы тоже не стали одинаковыми. Одни превратились в потребителей централизованных данных, другие выводились из эксплуатации вместе с переносом функций в ERP, третьи сохранились как специализированные первоисточники и продолжили обмениваться данными с центральным контуром.
MDM оказалась способом технически реализовать уже принятое решение о корпоративных данных, а не способом принять это решение вместо компании.
Когда карта превращается в бюрократию
Карту легко испортить желанием сделать её полной. Если в компании десятки тысяч номенклатурных позиций и сотни атрибутов, можно месяцами строить каталог, назначать владельцев и описывать происхождение каждого поля. Часть документа устареет раньше, чем его закончат.
Карта нужна там, где происхождение или смысл данных влияют на решение проекта. Если источник очевиден, правило уже установлено и расхождение ни на что существенное не влияет, отдельная управленческая процедура проекту не нужна.
Столь же вредно превращать владельца данных в универсального согласующего. Исправление опечатки по уже принятому правилу не требует его решения. Он нужен там, где меняется корпоративный смысл факта или граница полномочий между функциями.
Не спасает и формальное назначение владельца без полномочий. Если он умеет только собрать следующую встречу и попросить стороны договориться, у проекта появился новый участник, но решение не появилось.
Служба НСИ тоже не должна становиться универсальным экспертом. Администрирование справочника не даёт знания технологии производства или конструкторской документации. Её полезная роль – организовать работу с правилами и довести межфункциональный конфликт до полномочного решения.
Наконец, карта не заменяет архитектуру. Запись «конструкторская система – авторитетный источник чертежа» ничего не говорит о способе интеграции, периодичности обмена и отказоустойчивости. И наоборот, красивая стрелка между системами не делает передаваемое значение корпоративным.
Есть ещё одна цена централизации, которую нельзя прятать за словом governance. Как только появляется отдельная функция НСИ, появляются и новые процедуры: кому-то нужно создавать и изменять элементы, подтверждать спорные значения, ждать решения там, где раньше локальное подразделение справлялось самостоятельно. Плохая централизация легко превращает управление данными в очередь согласований.
Поэтому задача службы НСИ – не собрать у себя максимум решений. Всё, что однозначно решается внутри функциональной области по установленным правилам, должно оставаться там. Центр нужен прежде всего для действительно межфункциональных конфликтов.
Что можно сделать завтра
Возьмите один объект, от которого действительно зависит ваш проект: номенклатуру, контрагента, оборудование, сотрудника, договор. Лучше тот, вокруг которого уже возник спор при миграции или интеграции.
Не начинайте со списка информационных систем. Идите от самого факта:
объект → атрибут → бизнес-смысл → функциональная экспертиза → место возникновения → авторитетный источник → потребители.
Для каждого значимого атрибута достаточно ответить на несколько вопросов:
Где этот факт возникает?
Одинаково ли его понимают разные функции?
Существует ли корпоративное правило или проектная команда сейчас собирается его изобрести?
Что изменится в процессах или расчётах при разных вариантах?
Кто вправе установить корпоративное значение, если ответы расходятся?
После этого у строки карты должен появиться один из четырёх статусов:
Источник определён – можно проектировать обмен.
Правило совместного использования определено – источников несколько, но понятно, как они работают вместе; логику можно фиксировать.
Конфликт, владелец решения известен – вопрос можно эскалировать предметно.
Не определено – нет ни корпоративного правила, ни полномочного владельца; эту часть реализации пока нельзя фиксировать как окончательную.
Если завтра вам скажут: «Просто возьмите это поле из ERP, там оно вроде правильное», полезный встречный вопрос звучит так:
Кто решил, что именно для этого атрибута ERP является авторитетным источником?
Если ответа нет, проблема находится не в интеграции.
Что происходит с картой после проекта
Карта не должна становиться фотографией обследования, которую положили в архив после запуска. Но и обновлять её по календарю ради самого обновления нет смысла.
Пересмотр нужен тогда, когда меняется предмет решения: появляется новый существенный атрибут или источник, выводится система, меняется процесс, перераспределяется ответственность или принимается новое корпоративное правило.
При этом карта совсем не обязана жить отдельным Excel-файлом. После проекта её логика может быть перенесена в каталог данных, реестр решений, документацию интеграций или другой корпоративный инструмент. Важно не место хранения, а возможность ответить на два вопроса: где сейчас зафиксировано действующее правило и кто отвечает за его пересмотр.
Источник истины – не свойство системы
В нашем проекте в итоге появились централизованный контур НСИ, отдельный проект MDM и служба НСИ. Но главный результат был не в новой системе.
Система может хранить значение, быть местом его возникновения или распространять его другим потребителям. Право считать значение корпоративным появляется после принятого правила ответственности.
В предыдущей статье такой границей была развилка процесса: пока компания не решила, как должна работать, ИТ не должно незаметно превращать свой вариант в бизнес-алгоритм. С данными происходит то же самое. Пока компания не решила, какой факт признаёт корпоративным и на каком основании, ИТ не должно делать этот выбор очередностью загрузки или приоритетом интеграции.
После этого можно и нужно заниматься техническим качеством: удалять дубли, нормализовать наименования, проверять обязательные реквизиты, настраивать контроли. Но если корпоративного правила ещё нет, идеальная очистка его не создаст.
Она лишь сделает неопределённость аккуратнее.
Поэтому вместо вопроса «где находится источник истины?» я бы чаще задавал другой:
Кто имеет право утверждать конкретный факт об этом объекте и на каком основании?
Когда ответ появился, остаётся следующая проблема: выбрать способ реализации среди нескольких работоспособных вариантов, каждый из которых имеет собственную цену, срок, сложность и остаточный риск.
Дальше – как выбирать, когда правильного варианта нет
В этой истории я сознательно почти не разбирал один вопрос: почему заказчик в итоге выбрал отдельный контур НСИ, а не интеграцию ERP примерно с десятком существующих источников или ручную валидацию данных. Все три варианта были реализуемы. У каждого были своя цена, сроки, архитектурные последствия и риски – и ни один нельзя было доказать как единственно правильный.
Именно об этом будет следующая статья. Что делать, когда проект уже достаточно хорошо понимает проблему, ценность, ответственность, процесс и данные, но перед компанией всё равно лежат несколько несовершенных решений? Разберём, как сравнивать варианты по критериям, стоимости, обратимости и остаточному риску, как фиксировать сознательный компромисс и почему фраза «архитектура рекомендует вариант А» ещё не означает, что компания выбрала вариант А.
