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

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

Кирилл Ледовский

© Кирилл Ледовский, 2026

ISBN 978-5-0071-1683-1

Создано в интеллектуальной издательской системе Ridero

Введение. Как работающая ERP превращается в систему, которую никто уже не может объяснить

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

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

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

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

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

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

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

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

Часть I. Когда предприятие начинает терять собственную память

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

Глава 1. Что делать со сложной ERP: уволился аналитик ERP

Почему вместе с человеком предприятие теряет часть причинной архитектуры системы, хотя код, ТЗ, задачи и записи совещаний остаются на месте

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

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

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

Передача дел может быть выполнена правильно и всё равно оказаться неполной

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

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

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

Документация хранит результаты решений, но не всегда историю их происхождения

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

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

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

Поэтому проблема находится не между «есть документация» и «нет документации». Она проходит между архивом информации и проверяемой памятью системы.

В голове хорошего аналитика существует то, чего часто нет ни в одном файле

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

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

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

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

Что именно теряет предприятие

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

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

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

Таким образом после ухода человека предприятие может продолжать знать как работает механизм и постепенно переставать знать почему он работает именно так.

Цифровая нить должна заменить человека как единственное место соединения истории

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

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

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

Цифровая нить поэтому является не ещё одним журналом изменений. Её ценность в том, что она удерживает происхождение смысла изменения.

Почему новый аналитик неизбежно создаёт новую версию прошлого

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

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

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

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

Маленький реквизит способен держать на себе большой кусок методологии

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

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

В интерфейсе от всей этой истории остался один реквизит.

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

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

Цифровой мастер и цифровая тень постепенно расходятся

В книге «Цифровая трансформация в интеллектуальное предприятие» полезно различаются ещё два понятия. Цифровой мастер описывает принятую модель нормы — как деятельность и поддерживающая её система должны быть устроены. Цифровая тень отражает фактическое прохождение деятельности: реальные документы, статусы, движения, действия пользователей, логи, изменения и исключения.

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

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

В какой-то момент предприятие начинает жить одновременно с двумя версиями ERP: той, которая действительно работает, и той, которую оно думает, что имеет.

Уход аналитика лишь делает невидимую проблему заметной

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

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

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

Как быстро проверить свою систему

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

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

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

Сложная система должна учиться дольше, чем работает любой отдельный сотрудник

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