Технология проекта внедрения MDM-системы
Автор статьи: Валерий Немцов, менеджер продукта интеграции компании "Константа"
Сегодня я расскажу о том, как проходит процесс внедрения. Разберем, на какие шаги раскладывается задача.
ШАГ 1. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ
Формирование требований – это основа основ. Оно поможет прийти к единому пониманию о том, что мы будем делать и как, понять границы и договориться с бизнесом, что попадает в проект.
Определить цель и критерий завершенности рассматриваемого этапа
Например, мы решили начинать с номенклатуры, или с клиентов. Цель – определить границы данных, которые мы централизуем (домены, справочники, сегменты).
Пример критерия завершенности: УТ и ERP подключены к MDM и получают централизованную информацию (Контрагентов и Номенклатуру готовой продукции) только из MDM. Остальным пользователям доступ на заведение данных в эти дочерние системы закрыт.
Определить домены данных для централизации
Домены данных – это крупные области данных, которые мы далее будем рассматривать.
С точки зрения определения того, что мы будем включать, я бы вам рекомендовал смотреть на ближайший пул проектов (горизонт – год), и в работу брать именно те домены данных, которые будут касаться этих проектов. Делать эту задачу только для ИТ тяжеловато. Чтобы результаты проекта жили, обязательно должен быть спрос со стороны бизнеса и бизнес-потребитель.
Сформировать перечень систем, подключаемых к MDM в рамках проекта
Здесь в первую очередь необходимо посмотреть на текущий ИТ ландшафт:
o определить точки входа НСИ,
o понять, какие системы сейчас каскадом подключены к каким-то первоначальным системам, в которые заводится информация,
o понять, как мы будем выстраивать интеграционные потоки. Будет ли это все по модели звезды? Или у нас где-то будет звезда, а дальше от нее будут запускаться каскады.
Надо сначала понять, кто у нас сейчас является потребителем и в каких частях ИТ ландшафта, и уже исходя из этого определять перечень систем, который мы возьмем в MDM проект.
Сформировать модель данных
Глядя на домены данных, которые мы определили вторым пунктом, надо понять, какие справочники, регистры будут входить в модель данных, которую мы собираемся централизовывать.
Когда мы говорим про номенклатуру или контрагентов, это не во всех ИС они могут быть реализованы как один справочник (например, в ИС может быть справочник клиентов и поставщиков). При этом с точки зрения здравого смысла надо забрать те данные, которые повторно использованы в других системах и их логично вести централизованно. А по тем, которые не подлежат централизации, договариваться, что их в рамках бизнес-процесса будут дополнять в системах-получателях.
Таким образом мы сможем получить сбалансированную по качеству MDM систему. У нас туда будет введена та информация, которая является общеупотребимой, а лишний мусор не попадет. К тому же это будет та система, к которой можно относительно легко и недорого подключать другие ИС в рамках стратегии развития ИТ ландшафта.
Выделить источники данных для начального заполнения и обогащения
После того как мы определились, какие данные собираемся централизовывать, нам надо подумать, из каких систем мы можем взять данные для начального заполнения.
Например, в системе «А» у нас максимально широкий перечень номенклатуры, но оттуда мы можем взять только 20 реквизитов из 50 нужных. Остальные 30 у нас есть в смежных системах «В», «C» и «D», из которых мы и будем их забирать. Осталось только продумать план миграции.
Определить целевую схему процессов согласования данных
Почему это важно? Потому что это, по сути, лицо проекта, которое взаимодействует потом с бизнесом.
У нас с вами есть две стороны:
- Функциональные пользователи, у которых в принципе может формироваться потребность о том, чтобы была заведена какая-то карточка номенклатуры или новые точки доставки.
- Команда экспертов по НСИ, которая заведует самим качеством данных. Им нужно иметь набор данных, чтобы по заявке от пользователя легко вводить их в систему и вычленять по ним дубли.
С точки зрения процесса взаимодействия с MDM это может быть вход через web-форму или интеграция с другой системой. Надо смотреть на конкретный кейс и выбирать наиболее удобную для пользователей схему. Ну и естественно там будут вопросы, связанные с оповещением бизнес пользователей о статусах заявок. Это очень важный аспект, потому что по нему потом будет также даваться оценка со стороны бизнеса – а как нам вообще с MDM системой живется?
ШАГ 2. РАЗРАБОТКА
Макет MDM
На этом шаге у нас должен появиться макет MDM системы, который соответствует тем требованиям, которые мы собрали на предыдущем шаге. Он будет явно включать и реквизитный состав, и определенные формы взаимодействия с пользователями.
Интеграции
Появление MDM системы в принципе увеличивает количество интеграционных потоков. Причем на текущий момент уже все привыкли, что интеграции – это нормально. Главное – уметь их хорошо готовить.
Механизмы ограничения доступа пользователей в базах-подписчиках
Даже если мы имеем хороший квалифицированный персонал из бизнеса, мы все равно имеем дело с человеческим фактором.
Например, мы оповещаем людей, что подключили системы «А» и «В» к MDM системе, и с сегодняшнего дня точки доставки вводить не надо. Все отлично ровно до того момента, пока люди от этом помнят.
Как только что-то потребовалось быстро получить или внести какую-то точку доставки, люди могут по старой памяти сделать это по старой схеме. Локально они свою проблему решат, а вот вы с точки зрение MDMпроекта получите определенное приключение. Вам потом эти данные надо мигрировать в основную MDMсистему, дальше понять, надо ли это объединять с какой-то другой карточкой, и если не надо, то раздать в другие системы, а если не надо, уже решать этот инцидент отдельно. Ограничение доступа пользователей в базах-подписчиках решает эту проблему.
Инструменты переноса данных
Один из шагов – это перенос данных из других систем. Из плана запуска нам становится понятно, из каких систем мы будем забирать первоначальные данные. Для этого могут быть использованы отдельные механизмы: разовые инструменты выгрузки и загрузки данных через различные форматы, либо интеграционные потоки, которые временно будут включены через корпоративную шину данных.
Инструменты нормализации
Как бы мы хорошо не думали про нашу текущую ИС, скорее всего, в ней есть какие-то отклонения по ведению НСИ. Номенклатуру продублировали, случайно во время запуска каких-то систем создался пул лишних точек доставки и т.д.
К инструментам нормализации мы обычно относим инструменты проверки полноты заполнения реквизитного состава по централизуемым данным, механизмы их обогащения, а также инструменты анализа дублей.
Рекомендую всем подходить к вопросам нормализации со здравым смыслом, потому что в гонке за качеством можно потратить очень много денег, а основная задача здесь – получить хороший результат с относительно понятными затратами.
ШАГ 3. ПОДГОТОВКА К ЗАПУСКУ
Здесь у нас получается, что уже в наличии есть готовая система, готовые данные к переносу и остается:
- Обучение пользователей
- Начальное заполнение данных
- Обогащение/нормализация
Желательно Шаг 3 располагать максимально близко к Шагу 4. Хочется минимизировать то время, когда у нас данные в MDM попали и при этом параллельно еще что-то может завестись в старых системах.
ШАГ 4. ЗАПУСК
- Подключение систем подписчиков
- Ограничение прав на прямое редактирование ЦНСИ в подписчиках
- Поддержка запуска и мониторинг
После того как произошел запуск (подключение технической части), надо убедиться, чтобы пользователи не испытывают сложностей с их текущими сейчас бизнес процессами. Например, вопросы могут быть и с точки зрения редактирования данных. Кто-то что-то пропустил и хочет поменять, и надо уже в MDM систему создавать заявку на изменения, или еще что-то.
ПОДВЕДЕМ ИТОГ
1. На выходе из проекта надо иметь НСИ хорошего качества
2. Думайте о людях (кто пользуется MDM с двух сторон – эксперты и обычные пользователи)
