Onlayn kitobni bepul oʻqish  Мы теряем контроль над сложной ERP. Что делать?

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

Оглавление

Введение. Как работающая 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.

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

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

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

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

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

Глава 2. Что делать со сложной ERP: знания есть, а системы никто не понимает

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

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

Когда архив растёт, а объяснимость падает

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

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

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

Документы отвечают на свои вопросы, но не на вопрос системы целиком

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

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

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