Почему ERP-проекты не укладываются в сроки

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

 

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

ERP-проект может выглядеть почти завершенным: основные функции разработаны, интеграции запускаются, пользователи прошли обучение. Но дата промышленного старта снова сдвигается. Руководство видит десятки закрытых задач и не понимает, почему оставшиеся 10–15% работы требуют еще нескольких месяцев.

По прогнозу Gartner, к 2027 году более 70% недавно реализованных ERP-инициатив не достигнут в полном объеме первоначальных целей бизнес-кейса. Речь идет не только о соблюдении сроков, поэтому этот показатель нельзя напрямую трактовать как долю просроченных проектов. Однако задержка — один из самых заметных симптомов того же расхождения между планом и реальной сложностью трансформации.

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

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

 

Планируют функции, а запуск зависит от решений

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

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

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

 

Срок запуска 1С:ERP определяет не только готовность системы, но и готовность данных

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

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

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

 

Функциональное тестирование создает ложное чувство готовности

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

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

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

 

На сроки влияет не объем изменений, а скорость решений по ним

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

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

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

 

Приемка — это работа, а не подпись в конце

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

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

 

Как составить график, который выдержит реальность

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

Что изменить в управлении?

Как это влияет на срок?

Планировать решения как результаты

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

Вынести данные в отдельный поток

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

Считать готовность по критическим сценариям

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

Ограничить время на решение по изменениям

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

Резервировать мощность бизнеса

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

Разделить техническую и промышленную готовность

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

 

Скорость внедрения 1С:ERP зависит от готовности всей компании участвовать в проекте.

Внедрение 1С:ERP выходит за сроки, когда компания пытается управлять организационным изменением календарем разработки. Код в таком проекте — только часть результата. Остальное создают руководители процессов, владельцы данных, ключевые пользователи и те, кто принимает решение о запуске.

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

 

ссылка на публикацию companies.rbc.ru