В предыдущих 2 статьях (статья 1, статья 2) я рассказал, как с помощью 5 артефактов полностью описать ERP систему будь то 1С или SAP, на русском или китайском языке.

Бизнес‑процессы
Функции
Инструкции
Объекты метаданных
Требования

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

Проект
Топик
Слой
Проектный документ
Организация
Графическая схема
Backlog
Заказчики

Полученные данные можно крутить‑вертеть, модифицировать новыми требованиями и все равно модель будет стоять на прочном фундаменте и не позволять аналитикам запутаться. Если вы не прочитали эти статьи — настоятельно рекомендую ознакомиться с ними — так будет более понятна проблематика этой. Как и следовало ожидать — это были не просто теоретическое рассуждение — это методологическая основа, заложенная в мой авторский программный продукт ERP‑tools. Ввиду глубоким недовольством MS office вся работа команды от аналитика/разработчика до руководителя проекта была перенесена в единую программу с 3 мощными подсистемами.

На самом деле я люблю Excel, но в него слишком легко добавлять колонки исходя из конкретного случая, а когда разрабатываешь Методологию — приходится все стандартизировать. Центральное ядро «Функциональное моделирование» прошло множество циклов потребность‑реализация‑анализ и уже к окончанию первого пилотного проекта перехода с SAP на ERP УХ его удалось привести к сбалансированности — к вот именно этой картинке.

А проекты с его применением

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

Получен файлоархив проектных документов значительного объема — под тысячу страниц текстов, картинок, которые совсем не востребованы теми, кто управляет проектом после начала промышленной эксплуатации
Нарисованные UML, BPMN диаграммы представлены в виде png картинок, то есть непригодны для будущей модификации
В момент ОПЭ продолжалась модификация решения без редактирования «Функциональных моделей» и с каждым месяцем полученный красивый файл становится все менее надежным источником
Текущая разработка плохо организована и часто идет не по ТЗ, а по сообщениям в чатах
Обновление вендора становится проблемой, так как непонятно — что сломается из доделок проекта

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

Реальный кейс

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

Пример документации не очень успешного проекта

Внедрение произошло в январе 2026 года и ни один месяц до сих пор на закрыт, и заказчик всерьез обсуждает вопрос «отступить» обратно в 1С БП 3.0 На просьбу предоставить инструкции пользователям федеральный интегратор предоставил архив видеозаписей встреч аналитиков с бизнесом и посоветовал посмотреть и все подробности оформления увидеть там. Как я писал в 1 статье — инструкции являются самым узким местом — практически никто их не делает. Что же в итоге дал федеральный интегратор своему клиенту? Вот такую таблицу с его процессами. Здесь и далее все картинки переработаны ИИ чтобы убрать действительные клиентские данные, но сохранив их суть. Названия колонок не изменены. Но события и процессы довольно стандартные.

Уже на этом этапе возникает вопрос: это действительно результат применения единой методологии или рабочая таблица, созданная случайным образом для этого проекта? Выделено 3 вида Бизнес‑процесса

Глобальный процесс
Бизнес‑процесс
Процесс

И отдельно

Операция в ERP

При этом глобальных процессов — 11 штук и их примеры

Проработка условий на оказание услуг ГОЗ
Выполнение работ по договору оказания услуг/выполнению работ ГОЗ
Завершение работ по договору оказания услуг/выполнению работ ГОЗ

Бизнес‑процессов — 65 единиц и их примеры

Перевод ориентировочной стоимости работ в фиксированную цену
Закрытие работ по услуге
Потребность по доходным договорам
Коммерческое предложение по доходным договорам
Договор и счет по доходным договорам

Первые три это некое действие, напоминающее Процесс, последние 2 — просто название объектов системы. Почему закрытие работ по услуге отдельно от открытия — непонятно. Какая граница разделяет Глобальный процесс от обычного?

Просто Процессов — 270 единиц

Передает информацию о потребности в выдаче средств
Формирует перечень заявок на выдачу средств для согласования
Запускает процесс согласования
Согласуют служебную записку и заявки на оплату ОХР/ОПР в Excel

И примерно 80 строк уникальных действий в ERP

Загрузка поступлений из банка, Ввод Поступления безналичных денежных средств, Ввод счет‑фактуры выданной (аванс)
Ввод карточки ресурсной спецификации
Заполнение карточки ресурсной спецификации, Ввод номенклатуры, Ввод Видов работ сотрудников

Правда действий больше, но как поступить — если на 1 Процесс в Excel есть только 1 ячейка? Правильно — 2 действия поместить в одну ячейку через запятую. Наличие в ячейках формул говорит о том, что это не выгрузка из специальной базы (например, СППР).

Все действия по фильтру «спец» (так я пытался найти все упоминания Ресурсных Спецификаций)

Ввод карточки ресурсной спецификации
Заполнение карточки ресурсной спецификации, Ввод номенклатуры, Ввод Видов работ сотрудников
Корректировка ресурсной спецификации

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

Целых 80 действий в ERP, а всего таблица содержит — солидных 700 строк? О чем 620 строк (точнее 279 без указания действий ERP )? — Аналитики провели большую работу и зачем‑то описали бизнес‑процессы, не покрываемые ERP системой и нарисовали 50 диаграмм последовательности в формате png. Уверен что для этого в штате есть специальный Технический писатель. Почему бы не передать заказчику исходные файлы?

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

Что можно сделать по нашей проектной методологии

Провести анализ задействованных объектов метаданных текущей системы. Пользователи даже без инструкций что‑то делают. Это полезно и не отнимет времени на интервью
На основании практики прошлых проектов составим перечень функций системы — реальных действий пользователей в ERP. Все что за ее рамками мы либо проигнорируем, либо укажем непосредственное событие как основание для функции: Получили факс (внешнее событие) — Создание Заказа клиента (функция системы).
Быстро упакуем полученный массив функций. В среднем мы регистрируем от 500 до 700 функций на производственных предприятиях (против 80) и упаковываем их в примерно 100 бизнес‑процессов по примерно 10 функциональным разделам: Продажи, производство, закупки и так далее
Только на этом этапе обратимся к бизнесу и уточним — какие процессы у них вызывают вопросы и по их функциям составим подробные визуальные инструкции с пошаговым выполнением и обязательно обучим сотрудников. Тут мы выявим функции, которые вообще не выполняются и, допустим, остались в Excel. Очевиден большой методический провал в учете затрат и их распределении для корректного расчета себестоимости. Все‑таки придется пересматривать видео встреч, чтобы не отвлекать пользователей.
По документам интегратора складывалось впечатление, что внедрение было без доработок. Но это не так — просто доработки делала другая компания. И на этом этапе нужно выявить модификации объектов метаданных — это просто. Достаточно посмотреть на новые объекты, новые реквизиты. По каждому из них сформировать требование — это даст картину — что именно дорабатывалось. С модификацией бизнес‑логики чуть сложнее, но все точечные изменения также нужно сформулировать в качестве Требований. В любом случае в таблице нет никаких столбов, где говорится о наличии доработки. Если бы таблица интегратора была стандартной (по их Методологии) — то колонка бы сушествовала и была бы не заполнена с комментарием «вне рамок проекта». Еще одно доказательство, что методология отсутствует и перед нами обычная рабочая таблица руководителя проекта.

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

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

Будем держать вас в курсе проекта, а если вы хотите провести аудит вашего проекта и быстро сформировать его ОКИС (операционная карта информационной системы) — обращайтесь. Будем рады помочь

Разбор неудачного проекта внедрения ERP