Мы теряем контроль над сложной ERP. Что делать?

Теперь мы спускаемся с уровня общей памяти к конкретным объектам ERP. Поле, показатель, фрагмент кода или старая доработка технически существуют вполне определённо, однако управлять ими безопасно можно только тогда, когда понятны их происхождение, функция и дальнейшие зависимости. Во второй части вопрос меняется с «что мы помним о системе?» на «можем ли мы доказательно вернуть техническому объекту его бизнес-адрес?».

Глава 4. Что делать со сложной ERP: где заканчивается типовая и начинается своя

У старой кастомизированной ERP есть очень характерный момент, когда технически простая задача неожиданно превращается в исследовательскую. Предприятие готовится к обновлению, пересматривает накопившиеся расширения или просто хочет избавиться от старой доработки, которую уже много лет никто не трогал. Кто-нибудь замечает, что в новой типовой версии появилась похожая возможность, и возникает вполне разумная мысль: зачем продолжать сопровождать собственный механизм, если теперь примерно то же самое умеет сама ERP?

На поверхности вопрос действительно выглядит техническим. Можно сравнить конфигурации, посмотреть изменённые объекты, найти расширение, изучить реквизиты и код. Через некоторое время становится понятно, где именно находится собственная реализация и чем она отличается от текущей типовой версии. Казалось бы, после этого остаётся решить, что удалить, что оставить и что заменить типовым функционалом.

Именно здесь начинается главная ошибка. Техническое отличие показывает, где система изменилась, но почти ничего не говорит о том, зачем предприятие когда-то её изменило. Если эта причинная связь за годы эксплуатации потерялась, команда знает местоположение доработки, но ещё не знает её границу как бизнес-решения. А без этого совершенно похожие функции легко принять за одинаковые, хотя на самом деле они могут удерживать разные процессы, разный экономический смысл и разные зависимости.

Кажется, что типовую и собственную ERP можно разделить одной линией

В начале проекта граница обычно выглядит довольно просто. Есть поставляемая конфигурация ERP, есть требования предприятия, а всё, что пришлось изменить или добавить ради этих требований, воспринимается как собственная часть системы. Пока команда внедрения рядом и история решений свежая, такая картина достаточно хорошо работает. Люди помнят, какие ограничения типового механизма столкнули проект с необходимостью изменения, какие варианты обсуждались и почему в итоге выбрали именно эту конструкцию.

Через несколько лет простота исчезает. Типовая ERP развивается, старые ограничения снимаются, появляются новые возможности, меняются формы, алгоритмы и сценарии. Одновременно развивается и предприятие. Собственные механизмы переписываются, часть решений уходит в расширения, часть переносится в настройки и нормативно-справочную информацию, некоторые правила вообще перестают выглядеть как доработки, потому что технически реализуются штатными средствами системы.

Поэтому через пять или семь лет вопрос «что у нас типовое?» уже не имеет одного технического ответа. В одном месте собственная логика действительно находится в коде. В другом предприятие использует полностью типовой объект, но настроило его под собственную методологию. В третьем типовой механизм появился позже и теперь внешне повторяет старую проектную функцию. В четвёртом собственная доработка давно удалена, но её смысл сохранился в аналитиках, статусах, параметрах и принятом порядке работы.

В этот момент прямой вертикальной границы между «типовым» и «своим» больше нет.

Собственная ERP значительно больше собственного кода

Это принципиально важно. Когда говорят о кастомизированной ERP, чаще всего внимание автоматически смещается в сторону изменённой конфигурации, расширений и программного кода. Для разработчика это естественный взгляд: именно там технически видна разница между поставкой и конкретной информационной базой. Но с точки зрения предприятия собственная система начинается гораздо раньше.

Допустим, организация использует штатный документ ERP без единой программной доработки, но в конкретном процессе утвердила обязательную аналитику, определила особый момент её появления, зафиксировала порядок переноса между документами и построила на ней управленческую отчётность. Технически объект типовой. Управленчески его использование уже является частью собственной архитектуры предприятия.

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

Поэтому выражение «у нас почти типовая ERP» само по себе мало что объясняет. Оно может означать небольшое количество изменённого кода, но ничего не говорит о количестве собственных управленческих решений, которые живут внутри типовых механизмов.

Похожая функция может решать совсем другую задачу

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

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

Потом выходит новая версия ERP, в которой типовой механизм тоже активно использует направления деятельности. Название аналитики совпадает. На форме существует похожее поле. Появились штатные механизмы заполнения и использования. Возникает ощущение, что проблема решена производителем конфигурации и собственный механизм можно убрать.

Но совпадение названия ничего не доказывает. Типовой механизм может определять аналитику позже. Он может использовать её в другом хозяйственном контексте. Она может влиять на другой набор регистров и показателей. Она может не поддерживать именно ту раннюю точку ввода, из-за которой предприятие когда-то вообще начало доработку. Даже если результат в большинстве обычных сценариев выглядит одинаково, один важный сценарий способен принципиально отличаться.

Поэтому сильный аналитик в такой ситуации задаёт не вопрос «есть ли теперь это поле в типовой ERP?». Его интересует другое: какую задачу предприятия решала старая конструкция и закрывает ли новая типовая возможность именно эту задачу целиком?

Это уже совсем другой уровень сравнения.

Сравнивать нужно не объекты, а две причинные цепочки

Старое собственное решение имеет историю происхождения. Когда-то существовала проблема или ограничение. На её основе сформулировали требование. Затем приняли методологическое или процессное решение, определили экономический смысл, выбрали параметры и аналитику, после чего перевели всё это в техническую реализацию ERP. Наконец, конструкцию проверили и применили в реальной работе.

У новой типовой возможности существует своя цепочка. Она тоже что-то решает, опирается на определённые параметры и реализует определённое поведение. Но её происхождение другое: она создавалась как универсальный механизм продукта, а не как ответ на конкретную историю конкретного предприятия.

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

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

Граница между типовой и собственной ERP проходит зигзагом

Удобнее всего увидеть это, если разложить систему на несколько смысловых слоёв. На предметно-процессном уровне предприятие определяет собственную деятельность: процессы, процедуры, операции, роли и правила выполнения. На экономическом и учётном уровне оно решает, что означают хозяйственные факты, как они оцениваются, по каким аналитикам разделяются и в какие результаты превращаются. На нормативно-параметрическом уровне эти решения получают параметры, статусы, справочники, обязательность и точки ввода. Только после этого они материализуются в прикладной архитектуре ERP.

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

Поэтому реальная граница никогда не похожа на аккуратную вертикальную линию. Она проходит через все уровни системы и постоянно меняется вместе с развитием конфигурации и предприятия.

Через несколько лет происхождение решений стирается

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

Но обычно история распадается. Исходное ТЗ лежит в одной папке. Несколько последующих изменений — в задачах сопровождения. Одна важная оговорка осталась только в протоколе совещания. Код пережил рефакторинг. Часть механизма перенесли в расширение. Настройки несколько раз менялись непосредственно в информационной базе. А сотрудники, которые помнили первоначальную причину решения, давно занимаются другими проектами или вообще ушли из компании.

Техническая реализация остаётся, а её происхождение постепенно становится гипотезой.

Именно поэтому старая кастомизированная ERP так часто вызывает страх. Команда видит механизм, который выглядит избыточным, но не может доказать, что он действительно больше ничего не защищает. Любая попытка его убрать начинает сопровождаться вопросами: а вдруг это используется при закрытии месяца, а вдруг на этом держится интеграция, а вдруг какая-то аналитика попадает отсюда в отчёт, а вдруг существует редкий сценарий, который просто никто сейчас не вспомнил?

Этот страх нельзя убрать призывом «лучше документировать код». Код способен показать технические зависимости, но он не восстановит сам по себе причину, почему зависимость когда-то считалась необходимой.

Обновление превращается в археологию не из-за количества доработок

Большое количество собственных изменений, безусловно, усложняет обновление. Но количество кода — не самая тяжёлая проблема. Гораздо хуже, когда у кода нет бизнес-адреса.

Если команда знает, что определённое расширение реализует конкретное правило процесса, связано с определённой экономической моделью, использует такие-то аналитики и подтверждено такими-то сценариями, даже сложную доработку можно исследовать достаточно рационально. Понятно, что с чем сравнивать и какой результат должен сохраниться.

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

Отсюда следует ещё один важный вывод. Сложность обновления определяется не только количеством отклонений от типовой системы, но и качеством памяти об этих отклонениях.

Типовая система может полностью догнать старую доработку — и это хороший результат

Вторая крайность тоже вредна. Иногда команда настолько привыкла считать собственный механизм уникальным, что продолжает сопровождать его даже тогда, когда типовая ERP давно решила ту же задачу лучше и глубже. Возникает историческая привязанность: «это наше, мы этим пользуемся много лет, значит удалять опасно».

Такой подход превращает ERP в музей прошлых проектных решений. Каждое обновление становится дороже, собственный код продолжает расходиться с развивающейся типовой конфигурацией, а предприятие тратит ресурсы на сопровождение того, что больше не создаёт уникальной ценности.

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

В таком случае удаление собственной реализации — не потеря проектного наследия, а нормальное развитие архитектуры.

После сравнения возможны три совершенно разных вывода

Первый вариант — современная типовая возможность полностью покрывает исходное требование, включая ключевые сценарии и зависимости. Тогда собственную реализацию действительно можно выводить из эксплуатации, предварительно подтвердив переход испытаниями и обновив принятую модель системы.

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

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

Во всех трёх случаях решение принимается не по внешнему сходству интерфейса и не по количеству совпадающих объектов метаданных. Оно принимается по покрытию смысла.

Цифровая нить превращает сравнение в инженерную задачу

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

С такой историей обновление выглядит совершенно иначе. Аналитик видит новую типовую возможность и не начинает с предположения «похоже на наше». Он поднимает исходную цепочку собственного решения и последовательно проверяет покрытие. Что из старой потребности закрывается? Что стало неактуальным из-за изменения самого бизнеса? Что типовая ERP теперь делает штатно? Что всё ещё остаётся специфическим? Какие сценарии нужно подтвердить до переключения?

В этом режиме предприятие перестаёт бояться собственной системы. Оно может менять её, потому что понимает не только текущее устройство, но и происхождение важных решений.

Где же всё-таки заканчивается типовая и начинается своя

После всего сказанного ответ становится несколько неожиданным. Типовая ERP заканчивается не в точке первого изменённого программного модуля. И собственная ERP начинается не там, где разработчик написал первую строку корпоративного кода.

Граница определяется тем, какие решения предприятие приняло само и какие части своей деятельности оно материализовало с помощью системы.

Иногда такое решение потребует собственного расширения. Иногда — особой настройки типового механизма. Иногда — собственного состава НСИ или аналитик. Иногда весь технический маршрут окажется стандартным, а уникальным будет только правило, определяющее момент и условия его применения. Но во всех этих случаях существует собственная архитектура предприятия, потому что существует собственная норма деятельности.

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

Сравнение конфигураций отвечает только на половину вопроса

Сравнение конфигураций остаётся необходимым техническим инструментом. Оно показывает, какие объекты отличаются, где изменился код, какие реквизиты добавлены и какой технический объём нужно исследовать. Без этого невозможно качественно сопровождать сложную ERP.

Но оно отвечает только на вопрос «чем наша система отличается от типовой сегодня?». Для управления развитием предприятия нужен ещё один ответ: «почему она вообще стала другой?»

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

Именно поэтому настоящая граница между типовой и собственной ERP — это не граница кода. Это граница происхождения решений.