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

• Бизнес, который ставит целью извлечь максимальную выгоду от внедряемой автоматизации;
• Подрядчик, цель которого извлечь материальную выгоду от внедрения;
• Собственная команда разработки заказчика, которая стремится к минимизации трудозатрат и ответственности;
• Конечные потребители системы, которые имеют потребность защиты от изменений.

И разность целей зачастую приводит к несостоятельности продукта, «сваренного» в данном котелке противоречивых идей.
В данной статье на наглядном примере рассмотрим негативные процессы, к которым приводит противоречивость целей. Рассматриваемый в нашем кейсе проект – внедрение ERP системы.

Становление проблемы

Обычно первым шагом при внедрении ERP является упорядочивание единиц учета – справочных данных (этап MDM). ERP к справочным данным относится очень капризно. Если для кейсов полу автоматизированного учета достаточно поиска и сравнения по наименованию в EXCEL, то котелок ERP требует однозначных ID. Кроме того, многоразовый ввод справочных данных в различных системах это немалые трудозатраты. Исходя из описания проблемы, мы имеем общую цель – «Создать единую систему справочных данных (MDM) и навести порядок в ведении справочников». Но она сформирована не четко и мы уже на этом этапе сталкиваемся с разногласиями на счет единой цели:

• Бизнес уже считает, сколько человек/часов можно экономить за счет автоматизации справочников;
• Подрядчик уже готовит смету – это достаточно быстрая выгода с минимальными трудозатратами;
• Команда разработки пытается «мапить» объекты систем с разными структурами данных для минимизации доработок и пытается знакомиться с новым «инородным телом» в своем информационном ландшафте
• Бизнес пользователи высказывают все больше «хотелок» с целью оставить, как было и не сломать существующие процессы, обоснования «зачем Вам это нужно» зачастую добиться сложно и в некоторых случаях идут на компромиссы

Краткосрочный результат

И даже в данной ситуации проектная команда отработала на совесть. Прошли проектирование, разработку, тестирование. Практически уложились в сроки и довольно быстро стабилизировались. Бизнес свыкся с новой системой. На этом можно было бы поставить точку – с большей натяжкой проект можно назвать успешным, но мы забыли о главном. А именно, каковой же на самом деле была цель выделения данного этапа?
После внедрения «мастер данных» была автоматизирована передача справочников из единой MDM системы всем возможным потребителям данной информации. ID объектов системы там, где можно были синхронизированы. Там, где нельзя – настроены таблицы перекодировки. Справочники синхронизированы, но пока ими реально никто не пользуется т.к учетные системы еще работают по старым правилам, которые не сильно требовательны к достоверности справочных данных.

Первые плоды

На следующем этапе внедрения системы ERP (начали отдавать документы) случилась беда, у которой достаточно много симптомов и причин их возникновения, но первопричина одна. Я начну с перечисления некоторых «симптомов» и причин их возникновения.

• Из текущих систем невозможно удалить справочные данные, а в ERP решили не тянуть весь объем справочников. Поэтому часть данных осталось без ERP ID. И, как оказалось, справочными данными, которые не имели “связи с ERP» по ошибке активно пользовались, что привело к невозможности обработки множества документов
• Некоторые объекты системы ERP имели «срок жизни». К примеру, в ERP контрагент может быть активным и не активным. На не активного контрагента не возможно создание документа, а они в системах источниках по ошибке создавались
• Возможности ERP оказались гораздо шире возможностей LS (унаследованных систем) и бизнес процессы, которые обещали не использовать пользователи активно начали использовать в связи переходом на новые этапы жизненного цикла системы. Другими словами LS оказались менее гибкими по отношению к ERP.

И таких примеров было достаточно много. А первопричина одна – цель системы.

Определение причины провала

Если смотреть с ретроспективой, то цель этапа MDM было навести порядок в справочных данных предприятия, т.к очень требовательная к данным ERP система не пропустит не один документ с хотя бы в одном разрезе кривыми данными.
Если бы была поставлена именно эта цель, то:

• Бизнес активно бы участвовал в наведении порядка в справочных данных и связанных с их ведением бизнес процессах
• Собственная группа разработки – проектировала бы систему с оглядкой на структуры данных и бизнес процессы ERP
• Бизнес пользователи бы активно консультировались по поводу будущих процессов работы с документами и высказывали конструктивные предложения
• Подрядчик – активно консультировал по работе своей системы, т.к к нему было бы больше обращений со стороны бизнеса и ИТ заказчика

Последствия

В больших проектах мы зачастую сталкиваемся с проблемой коммуникаций. Я уже не помню, как все произошло, но цель определенное время была довольно очевидна и была у всех на виду. На определенном этапе каждый участник команды погружается в работу в рамках своей компетенции и зоны ответственности. При этом все выполняют свои задачи достаточно качественно и эффективно.
После внедрения проекта и «причесывания» массовых и явных проблем команда внедрения столкнулась с периодом застоя. В данный период система стабилизировалась на определенном объеме точечных проблем, которые решаются в лучшем случае «костыльными» разработками, а в худшем – ручным вмешательством в данные системы. И никто не знал, что с этим делать.
Нет, в нашей истории не появился супер-герой, который заставил вернуться к изначальным целям и кардинально изменить подход к некоторым вещам. Максимум что удалось сделать, это рассматривать новые костыли через призму этих целей и стараться заставить людей действовать в ключе « …принято временное решение… также настоятельно рекомендуем пересмотреть подходы к следующим процессам…».

Выводы

1. Цели являются основой системы и к ним нужно относится не менее серьезно чем, к примеру, документации спецификаций интерфейсов.
   Я лично, записываю их в документации по архитектуре и озвучиваю во время презентации своих решений.
2. Каждое решение нужно рассматривать сквозь призму целей и цель каждого участника проекта, по крайней мере, не должна противоречить основополагающим целям проекта.
   Я записываю, каким образом каждое решение реализует проектные цели, каким образом пришли к данному решению и какие были альтернативные решения.
3. Зачастую цели узнать довольно сложно.
   Но там где цель явно не описана я о них догадываюсь и согласовываю их со всеми участниками.

Цель данной статьи – ознакомить читателя с взглядом на не явную и достаточно плохо исследованную проблему крупных IT проектов, а также понять в правильном ли направлении движусь я в своих рассуждениях и выводах.