Этапы внедрения ERP: три подхода и как выбрать подходящий для вашей компании

Автор: Александр Кольцов · Опубликовано 22 октября 2026 года.

Кратко: из каких этапов состоит внедрение ERP

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

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

Содержание

• Сравнение трёх подходов
• Дорожная карта и критерии готовности
• Сроки и бюджет
• Классическое внедрение
• Итерационная разработка с единым запуском
• Запуск стандартного функционала
• Как выбрать подход
• Частые вопросы

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

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

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

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

Три подхода к внедрению ERP

Подход	Основная последовательность	Когда пользователи дают обратную связь	Для каких компаний подходит
Классическое последовательное внедрение	Бизнес-требования → выбор платформы → настройка и разработка → опытная эксплуатация → исправления → промышленный запуск	Основная проверка происходит на этапе приёмки, хотя промежуточные демонстрации тоже полезны	Для компаний со сложными процессами, которым нужны подробные требования и контролируемая приёмка
Итерационная разработка с единым запуском	Первоначальный объём проекта → разработка сквозных процессов небольшими итерациями → общая проверка готовности → промышленный запуск	В течение каждой итерации	Для компаний, которые готовы уточнять требования в процессе, но не могут переходить на новую ERP по частям
Запуск стандартного функционала с последующим развитием	Проверка принципиального соответствия → подготовка данных и пользователей → запуск стандартной системы → адаптация и доработки	Во время подготовки и затем в повседневной работе	Для компаний, которые готовы принять стандартные процессы ERP и не имеют большого количества принципиальных отличий от них

Здесь есть важное различие, которое часто упускают: разрабатывать систему по частям и запускать её по частям — не одно и то же.

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

Какие этапы нужны при любом подходе

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

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

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

Этап	Что должно быть получено	Кто отвечает за выполнение и приёмку	Когда можно переходить дальше
Обследование бизнеса и формирование требований	Согласованные цели, перечень процессов, обязательные требования, ограничения и первоначальные риски	Бизнес-аналитик или функциональный консультант организует работу; владельцы процессов подтверждают требования; куратор проекта со стороны бизнеса определяет приоритеты	У критичных процессов есть ответственные, принципиальные требования понятны, бизнес согласовал ожидаемый результат
Выбор платформы и проектирование решения	Оценка соответствия платформы, список функциональных разрывов, подход к внедрению, первоначальный объём работ, зависимости и порядок приёмки	Руководитель решения оценивает платформу; владельцы процессов проверяют бизнес-сценарии; заказчик утверждает выбор и объём проекта	Для обязательных требований определён способ реализации, по нерешённым вопросам согласованы действия, бизнес принимает предложенный подход
Настройка, разработка и интеграции	Настроенные процессы и согласованные доработки, результаты технических проверок, актуальная документация	Команда внедрения выполняет работы; руководитель решения контролирует связи между частями системы; владельцы процессов проверяют логику работы	Согласованный функционал можно показать и проверить как сквозной процесс; ограничения зафиксированы и понятны
Подготовка и пробная миграция данных	Правила сопоставления данных, подготовленные исходные данные, результат пробного переноса и сверки	Специалист по миграции выполняет перенос; ответственные со стороны бизнеса проверяют полноту и корректность данных	Согласованные проверки пройдены, критичные расхождения устранены, определены ответственные за окончательную миграцию
Пользовательское приёмочное тестирование и обучение	Проверенные бизнес-сценарии, реестр замечаний, инструкции и подготовленные ключевые пользователи	Владельцы процессов принимают результат; ключевые пользователи выполняют сценарии; команда внедрения исправляет ошибки и проводит обучение	Критичные сценарии работают, блокирующие ошибки устранены, по оставшимся замечаниям есть согласованные решения и ответственные
Подготовка переключения и решение о запуске	План окончательной миграции, последовательность переключения систем, уведомления, график поддержки и план действий при проблемах	Руководитель проекта координирует подготовку; технические и бизнес-руководители подтверждают готовность; уполномоченный представитель заказчика разрешает запуск	Ответственные подтвердили готовность, согласованы окно запуска и действия при нештатной ситуации, нет нерешённых проблем, блокирующих основные операции
Промышленный запуск и усиленная поддержка	Работа компании в новой системе, сверенные итоговые данные, оперативная поддержка и управляемый список проблем	Бизнес отвечает за ежедневные операции; команда внедрения и поддержка устраняют проблемы; руководитель проекта организует эскалацию	Основные процессы устойчиво работают в течение согласованного периода, критичные проблемы запуска устранены, по оставшимся вопросам определён порядок решения
Передача в сопровождение и дальнейшее развитие	Принятая документация, распределённая ответственность за поддержку, список известных ограничений и приоритетный перечень улучшений	Руководитель поддержки принимает систему; владельцы процессов определяют приоритеты развития; заказчик подтверждает завершение проекта	Поддержка может решать обычные задачи без постоянного участия проектной команды, бизнес принимает ответственность за работу системы и оставшиеся обязательства

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

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

Что такое критерий перехода между этапами

Это конкретная проверка: можем ли мы обоснованно двигаться дальше?

Нужно понимать, кто принимает решение, на какие результаты он смотрит и какая проблема остановит переход.

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

Как эта дорожная карта работает в трёх подходах

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

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

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

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

От чего зависят сроки и бюджет внедрения ERP

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

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

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

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

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

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

Такие зависимости объясняют график проекта гораздо лучше, чем общее обещание «внедрим ERP за несколько месяцев».

1. Классическое внедрение: описать, разработать, принять и запустить

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

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

Формирование требований и выбор платформы

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

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

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

Настройка, разработка и интеграции

Дальше команда готовит ERP под согласованные требования.

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

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

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

Опытная эксплуатация и приёмка

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

Здесь я бы обязательно разделял ошибки и новые либо изменившиеся требования.

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

Когда всё это складывается в один список без разделения, контролировать стоимость и ответственность становится сложнее.

Исправления и промышленный запуск

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

После этого бизнес принимает решение: можем ли мы использовать ERP как основной рабочий инструмент?

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

Когда я выбираю этот подход

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

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

Главный недостаток — расстояние между моментом формирования требований и моментом получения готовой программы.

Можно получить систему, которая очень хорошо соответствует тому, что вы написали, но при этом плохо соответствует тому, что вы ожидали получить.

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

Реальный пример: требования остались прежними, а бизнес изменился

Я участвовал в выборе ERP для автоматизации FMCG-холдинга — компании, работающей с товарами повседневного спроса.

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

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

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

Дальше началась разработка по нашим требованиям.

Примерно через восемь–десять месяцев систему передали с перечнем реализованных изменений. Но к этому моменту компания уже заметно изменилась.

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

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

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

Для меня вывод из этого проекта такой: утверждение требований не останавливает развитие компании.

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

2. Итерационное внедрение: разрабатывать сквозными процессами, запускать целиком

Второй подход строится на небольших итерациях.

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

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

Сначала — работающий сквозной процесс

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

Это понятная последовательность: вот товар у поставщика, вот он приехал к вам, вот вы приняли его и разместили на складе. Теперь вы видите количество и стоимость этого запаса в системе.

На одной демонстрации объединяется работа нескольких подразделений.

Закупки проверяют заказ поставщику. Склад проверяет приёмку и размещение. Финансы смотрят, как формируется и отражается стоимость.

Люди видят один связанный процесс, а не набор отдельных экранов.

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

Это примеры сценариев, которые я бы использовал для демонстрации и проверки. Конкретная последовательность действий зависит от компании и выбранной ERP.

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

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

Затем — проверка, уточнение и развитие

Пользователи получают возможность реагировать на конкретную работающую систему.

Они видят, что удобно, что непонятно и о каких требованиях раньше даже не думали.

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

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

После итераций — один промышленный запуск

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

Мы разрабатываем и проверяем систему частями, а запускаем её целиком.

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

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

После общего промышленного запуска начинается период усиленной поддержки.

Когда я выбираю этот подход

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

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

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

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

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

3. Внедрение стандартного функционала: начать работать и затем улучшать

Третий подход начинается с другой установки.

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

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

Сначала нужно проверить принципиальное соответствие

Я бы начал с разделения привычек и обязательных требований.

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

Этот подход работает, когда стандартная система позволяет выполнять основные операции компании.

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

Подготовить данные и пользователей

Миграция становится одной из первых практических задач: данные должны оказаться в новой системе.

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

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

Запустить систему и организовать привыкание

Компания начинает работать в ERP и фиксирует то, что её не устраивает.

Здесь обучение, поддержка и адаптация становятся центральной частью внедрения.

И возникает интересная вещь: часть первоначальных требований может исчезнуть.

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

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

От каких требований клиенты отказываются после знакомства с системой

Таких примеров много.

Один небольшой, но показательный случай связан с терминологией. Клиент говорил: нам обязательно нужно, чтобы клиенты назывались лидами. Название «клиент» нам не нравится, мы привыкли к слову «лид».

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

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

Похожая история бывает с документами.

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

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

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

Ещё один пример — автоматическое проведение всех инвойсов.

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

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

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

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

Когда я выбираю этот подход

Я рекомендую его, когда компания готова адаптироваться и доверяет стандартным процессам ERP настолько, чтобы попробовать работать по ним.

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

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

Принципиальные требования тоже должны быть закрыты до запуска.

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

Как я выбираю между этими подходами

Мой первый вопрос: что компания не может позволить себе нарушить?

Второй: насколько она готова меняться?

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

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

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

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

Перед рекомендацией я бы задал пять конкретных вопросов:

1. Какие процессы нельзя менять по операционным или обязательным требованиям, а какие можно адаптировать к стандартной ERP?
2. Могут ли владельцы процессов и ключевые пользователи регулярно участвовать в демонстрациях, тестировании и согласовании решений?
3. Можно ли начать работу на стандартном функционале или до запуска обязательно должны быть готовы конкретные доработки и интеграции?
4. Пригодны ли исходные данные для переноса и кто отвечает за их исправление и проверку?
5. Можно ли переключать операции постепенно или связанные процессы требуют одного согласованного запуска?

Ответы должны влиять на план проекта.

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

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

Я бы также заранее определял, когда заканчивается усиленная поддержка.

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

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

Небольшие вопросы, которые могут остановить запуск

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

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

Каждый из этих вопросов может сделать промышленный запуск невозможным.

Часто проблема связана именно с историческими данными и с тем, что бизнес должен делать с ними после переноса.

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

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

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

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

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

Обсудите подход до того, как зафиксируете план проекта

В ERPixel мы рекомендуем разные подходы в зависимости от ограничений клиента и его готовности к изменениям.

Нам не нужно, чтобы каждое внедрение проходило по одной и той же схеме.

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

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

Чтобы связать проект ERP с задачами бизнеса, прочитайте материал «Автоматизация бизнес-процессов: с чего начать».

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

Частые вопросы об этапах внедрения ERP

Сколько этапов во внедрении ERP?

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

Чем итерационная разработка отличается от поэтапного запуска ERP?

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

Можно ли запустить стандартную ERP без миграции и обучения?

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

Сколько времени занимает внедрение ERP?

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

Кто принимает решение о промышленном запуске ERP?

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