ERP внедрили. Что дальше?

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

ISBN 978-5-0071-3324-1

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

Введение

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

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

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

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

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

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

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

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

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

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

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

Раньше он звучал так:

Купили ERP — что дальше?

Теперь мне гораздо интереснее другой:

ERP внедрили. Что дальше?

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

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

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

Она нужна для того, чтобы получить возможность двигаться дальше.

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

Она постепенно становится средой, в которой можно исследовать изменения до того, как они произошли в реальном предприятии.

Сначала нужно восстановить причинность прошлого и управляемость настоящего, чтобы получить право серьёзно говорить о вычислимом будущем.

Отсюда и возникает дальняя траектория этого текста. Мы начнём с вещей довольно привычных — Устава проекта, обследования, бизнес-процессов, профессиональных ролей, ERP-объектов. Затем постепенно выяснится, почему этого недостаточно и зачем понадобились бизнес-предметы, состояния, точки передачи, профессиональные модели, доказательный GAP, исполняемые сценарии, цифровая нить и граф.

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

Именно поэтому в названии стоит не «как правильно внедрить ERP», а «ERP внедрили. Что дальше?»

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

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

На этом месте и возникла идея сделать автоконспект собственной монографии.

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

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

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

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

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

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

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

Есть ещё одна оговорка, которую лучше сделать сразу. По ходу текста я иногда буду называть конкретные инструменты, которыми действительно пользовался в работе: Microsoft Word, Microsoft Excel, Vanessa Automation, ChatGPT, отдельные RPA-средства и некоторые другие продукты. Я долго думал, стоит ли вообще оставлять коммерческие названия, но полное их удаление создаёт лишнюю неопределённость: коллега перестаёт понимать, каким именно инструментарием был получен описываемый результат. Поэтому конкретное название будет появляться там, где оно действительно нужно для понимания практического контекста, но это не реклама и не утверждение, что данный продукт является единственно возможным. После первого упоминания мне важнее уже функция инструмента внутри технологии, а не его торговое название.

В итоге этот автоконспект — не история о том, как я придумал ещё одну методологию внедрения ERP. Скорее это попытка показать длинную профессиональную траекторию: от вопроса «Купили ERP — что дальше?», через множество реальных проектов и постепенно сложившуюся технологию, к новому вопросу — «ERP внедрили. Что дальше?»

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

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

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

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

С Устава проекта.

I. Устав проекта, который неожиданно оказался технологией

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

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

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

А ведь специалисты заказчика не являются внешними наблюдателями технологии внедрения. Они находятся внутри неё.

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

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

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

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

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

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

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

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

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

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

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

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

Фраза «обследование закончено» сама по себе не отвечает на главный вопрос: что теперь существует такого, чего раньше не существовало и что следующая команда имеет право использовать как основание своей работы?

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

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

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

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

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

А, вот ты о чём, Семён Семёныч. Получается, наше вечное проектное «ну мы же это сделали» на самом деле ещё ничего не гарантирует.

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

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

Так довольно рано возникает цифровая нить: основание связано с решением, решение — с результатом, результат — с последующими зависимостями, а изменение основания позволяет пройти по этой цепочке вперёд и определить последствия.

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