Как не превратить внедрение ERP в бесконечную доработку

Кому и зачем это читать

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

Она поможет:

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

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

Границы проекта нужно описывать через процессы и результат

Фраза «автоматизировать производство» ничего не говорит ни о сроке, ни о цене, ни о составе работ. За ней могут скрываться простой выпуск по заказу или многоэтапный маршрут с операциями, полуфабрикатами, контролем ресурсов и планированием загрузки. Это разные по трудоёмкости задачи.

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

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

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

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

Готовность нельзя оценивать по проценту в отчёте

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

Удобная единица контроля - отдельный бизнес-процесс. У него должны быть:

• согласованные требования;
• контрольный пример с исходными данными;
• проверка результата;
• приёмка в связке с соседними процессами;
• ответственный со стороны бизнеса и команды внедрения.

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

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

Ожидание решений обходится дороже сложной настройки

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

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

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

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

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

Запуск требует минимального рабочего контура, а не всех пожеланий

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

Для первого рабочего дня важнее другое:

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

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

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

Первый закрытый период показывает, состоялся ли запуск

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

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

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

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

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

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

В одном рабочем пространстве стоит хранить:

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

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

Что сделать

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