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

Мы изучили судебные споры по 1С:ERP-проектам и выявили причины, из-за которых код готов, бюджет потрачен, а промышленный запуск снова откладывается.

 

В последнее время заказчики все чаще задают нам один и тот же вопрос:

Можете ли вы гарантировать сроки промышленного запуска системы 1С:ERP?

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

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

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

Там уже нельзя ограничиться формулировками «система не подошла» или «заказчик постоянно менял требования». Каждой стороне приходится объяснять:

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

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

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

 

Сценарий 1. Проект начинает двигаться к постоянно меняющейся цели

Потому что каждое отдельное изменение выглядит небольшим.

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

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

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

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

И вот здесь возникает первая развилка.

Либо компания признает, что проект изменился, и пересматривает его стоимость, сроки и объем первой очереди.

Либо новое требование просто добавляется к прежнему плану.

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

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

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

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

Что делает проектная технология

Управление изменениями — это не запрет бизнесу развиваться и не бюрократия ради оформления документов.

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

Каждое существенное изменение должно получить ответы на четыре вопроса:

1.  Что именно изменится в результате проекта?

2.  Как это повлияет на бюджет?

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

4.  Что будет исключено из первой очереди, если дату запуска необходимо сохранить?

Если добавляется что-то новое, необходимо либо увеличить срок и бюджет, либо перенести часть прежнего объема в следующую очередь.

Иначе первая промышленная версия постоянно отдаляется.

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

 

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

Представим, что в 1С:ERP можно оформить заказ клиента, создать закупку и сформировать отгрузку. Формально функциональность существует.

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

Работает ли система?

Технически — да.

Готово ли предприятие перейти на нее?

Нет.

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

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

Но даже экспертам бывает трудно ответить на более широкий вопрос:

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

Потому что этот вопрос относится не только к программе.

Он касается данных, сотрудников, регламентов, интеграций, ответственности и организационной готовности.

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

Заказ клиента должен привести к резервированию товара, закупке или производству, отгрузке, отражению в учете, оплате и управленческой отчетности.

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

Что делает проектная технология

Принимать нужно не экран программы и не отдельный документ.

Принимать необходимо бизнес-сценарий целиком.

До начала опытной эксплуатации проектная команда должна определить:

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

Так технология проекта переводит спор «работает — не работает» в измеримую плоскость.

Вместо общего впечатления появляются согласованные критерии готовности.

 

Сценарий 3. Работы выполнены, но оплатить их невозможно

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

Но технически он почти всегда выполняется частями.

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

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

Что делает проектная технология

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

Не просто на календарные периоды — «первый этап», «второй этап», — а на законченные результаты:

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

Для каждого результата заранее устанавливаются:

• содержание;
• стоимость;
• критерии готовности;
• порядок проверки;
• срок направления замечаний;
• последствия остановки проекта.

Это защищает не только исполнителя.

Заказчик также понимает, за что именно платит и какой результат должен получить на каждом шаге.

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

 

Сценарий 4. Компания покупает 1С:ERP, но еще не готова реализовать принятое решение

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

С точки зрения бизнеса это может быть вполне разумным решением.

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

Почему особенно рискуют быстрорастущие компании

В быстрорастущем бизнесе решения устаревают быстрее.

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

Старая архитектурная идея перестала соответствовать новой стратегии.

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

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

Что делает проектная технология

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

Нужно ответить не только на вопрос «подходит ли нам продукт», но и на другие вопросы:

• Утверждена ли целевая архитектура?
• Какие системы будут выведены из эксплуатации?
• Какие процессы действительно перейдут в 1С:ERP?
• Кто со стороны бизнеса принимает решения?
• Выделены ли ключевые пользователи?
• Готова ли компания финансировать не только лицензии, но и весь проект?
• Какие изменения бизнеса ожидаются в период внедрения?
• Какие события могут привести к пересмотру проекта?

Это не гарантирует, что стратегия не изменится.

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

 

Сценарий 5. Проектом управляют как набором задач для разработчиков

Можно закрыть 90% задач и при этом не иметь возможности запустить систему

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

Без этих десяти процентов весь результат не имеет практической ценности

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

Можно ли назвать проект завершенным

Формально система существует

Фактически она не встроена в управление предприятием

Внедрение 1С:ERP можно сравнить  с имплантацией новой нервной системы в живой организм. 1С:ERP не просто регистрирует уже совершившиеся операции. Она связывает действия подразделений и влияет на будущие решения компании.

Именно поэтому проект нельзя свести к программированию.

Что делает проектная технология

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

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

 

Что происходит, когда хотя бы один контур выпадает

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

 

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

И здесь особенно важен опыт проектной команды.

Не только знание конкретной ERP системы. Не только умение программировать или описывать процессы.

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

 

Можно ли гарантировать срок и бюджет ERP-проекта

Заказчики часто задают и этот вопрос.

Честный ответ: нельзя гарантировать отсутствие изменений и сложностей.

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

Но можно гарантировать другое — управляемость реакции на эти изменения.

Именно это отличает проектную технологию от обычного выполнения заявок.

Гарантия бюджета и срока возникает не из обещания «все предусмотреть». Все предусмотреть невозможно.

Она возникает из дисциплины:

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

 

Почему проектные риски не исчезают сами

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

Можно ли считать его почти готовым к полету?

С 1С:ERP происходит то же самое.

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

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

 

Главный вывод

Зачем вообще анализировать судебные споры по внедрениям

Не для того, чтобы определить, кто чаще оказывается прав — заказчик или исполнитель.

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

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

В этот момент особенно ясно проявляется, что стороны не смогли согласовать или удержать:

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

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

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

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

Но знание бизнеса и умение управлять программой его изменения — разные компетенции.

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

Тогда 1С:ERP перестает быть бесконечной стройкой.

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

 

 

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