Технология внедрения ERP-систем

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

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

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

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

Технологии создания автоматизированных систем управления производством в настоящее время развиваются. Если еще лет 10 назад мы ориентировались на серию 34-х ГОСТов, то сейчас мало кто про них вспоминает. Возможно, лет через 10 мало кто вспомнит и про технологии, которые применяются сейчас.

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

Не выполнив очередную операцию (итерацию-этап), нельзя в точности знать, что и как мы будем делать на следующей операции. Почему происходит именно так – покажем чуть ниже. Основная причина – исследовательский характер работы обеих сторон (Заказчика и Исполнителя) на ERP-проекте. Исследование – это не процесс создания материального товара, где заранее точно известен результат и способы его получения.

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

При этом изначально известны, как правило, только несколько основных целей и некоторый небольшой объем исходных данных.

А сейчас покажем, какие логические шаги (этапы) лучше всего выполнить при создании ERP-системы. Наши цели:

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

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

С чего можно начать?

Отметим, что очень редко система автоматизации создается сразу на все бизнес-процессы и запускается сразу тоже по всем процессам.

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

Например, сначала запустить оперативный учет, а потом – диспетчеризацию производства.

Рассмотрим плюсы и минусы такого подхода.

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

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

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

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

Плюсы в большинстве случаев на практике перевешивают минусы.

Семь раз отмерь – один раз отрежь?

Следующая рекомендация: попробуем усовершенствовать классическую «каскадную» модель работы.

В каскадной модели декларируется «системный подход»: сначала составлялась исчерпывающая проектная документация, продумывалась вся система в целом, затем выполнялись настройки – и только затем пользователей допускали «пощупать» систему в ходе опытной эксплуатации.

В каком направлении надо двигаться?

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

Что удивительно – этот очевидный подход для многих отраслей (например, для строительства), в ИТ-технологиях, оказывается, не самый оптимальный. Как это ни странно…

Представим себе, что заказчик нарисовал набросок дома, после чего привозятся стройматериалы, и начинается немедленно строительство. Каменщики втыкают кирпичи, клиент сразу смотрит, что получается, критикует, каменщик кладет кирпич на другое место… По ходу строительство клиент «созревает», где у него должно быть окно, а где – балкон… Бред?

Очевидно, что так строить дома нельзя. Может получиться вот что :)

Но применима ли данная логика к процессу создания ERP-системы? Попробуем разобраться. Для начала – исходные предпосылки:

Читать далее>>>

Частые вопросы

Что такое проектная технология внедрения 1С:ERP и почему она строится итерациями?

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

• Почему не ГОСТ 34: нормативы тридцатилетней давности создавались под разработку заказного ПО с нуля; современная технология опирается на адаптацию готовой ERP-системы под цели бизнеса.
• Исследовательский характер: ERP не создаётся как типовой материальный предмет по готовому неизменному чертежу — на каждом шаге команда уточняет требования и находит оптимальные способы их закрытия.
• Минимизация рисков: не выполнив очередную итерацию и не получив обратную связь в живой программе, нельзя достоверно спроектировать следующий шаг.

Из каких этапов состоит внедрение 1С:ERP и почему его ведут очередями?

Систему почти никогда не запускают одним днём по всем бизнес-процессам сразу — внедрение делят на функциональные очереди или пилотные подразделения.

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

Какие риски возникают при внедрении по очередям и как их нивелируют?

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

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

Чем современная методология внедрения 1С:ERP отличается от каскадной модели?

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

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

Почему сроки и бюджет проекта внедрения нельзя зафиксировать в самом начале?

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

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

эксперт Николай Лисин заместитель директора, главный методолог и эксперт по автоматизации производства, ИТРП

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

Опубликовано: 11 октября 2026

эксперт Александр Вепринцев Директор ИТРП

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

Опубликовано: 11 октября 2026