Компания согласовала внедрение за 2 млн рублей, но начала без чёткого технического задания. Infostart оценивает возможный рост бюджета при таком старте в 10–30%. Для исходной сметы риск составляет 200–600 тысяч рублей: 2 000 000 × 0,10–0,30.
Перерасход возникает не в момент оплаты счёта. Сначала отделы добавляют требования, подрядчик переделывает согласованные сценарии, а руководители неделями не принимают решения. Заметить отклонение нужно раньше — пока его ещё можно убрать из первой очереди.
Ваша задача до договора — согласовать результат, границы проекта и порядок изменений. После старта понадобятся наблюдаемые признаки, по которым вы поймёте: проект движется по плану или уже требует пересмотра.
До договора зафиксируйте не функции, а результат
Фраза «внедрить 1С:ERP» не описывает результат. Она не отвечает, какие процессы перейдут в систему, кто будет ими пользоваться и по каким сценариям компания примет работу.
Начните с рабочего цикла. Например: менеджер принимает заказ, склад резервирует товар, бухгалтер получает документы без повторного ввода, руководитель видит задолженность. Такой сценарий можно показать, проверить и принять.
Подрядчик приносит методику и техническую экспертизу. Правила учёта, внутренние согласования и реальные исключения знает заказчик. На это разделение ролей указывает компания «Диалог ИТ» в разборе ошибок внедрения 1С.
Если бизнес не участвует, исполнитель заполняет пробелы своими предположениями. Ошибка обнаруживается поздно: когда пользователи видят настроенную систему и говорят, что работать по предложенной схеме нельзя.
До старта примите пять решений.
| Решение до старта | Кто утверждает | Чем подтвердить |
|---|---|---|
| Какие процессы входят в проект | Руководитель проекта и владельцы процессов | Перечень процессов с начальной и конечной точкой |
| Что входит в первую очередь | Спонсор проекта и рабочий комитет | Список законченных рабочих сценариев |
| Кто принимает решения от каждого отдела | Руководитель соответствующего направления | Имена, полномочия и срок ответа |
| По каким признакам принимают работу | Владелец процесса и подрядчик | Сценарии проверки с ожидаемым результатом |
| Как команда обрабатывает новые требования | Спонсор проекта и подрядчик | Порядок оценки влияния на срок и стоимость |
Если у решения нет владельца и проверяемого результата, оно вернётся поздней правкой. Подрядчик либо заложит запас в оценку, либо выставит дополнительные работы после старта.
Спонсор проекта нужен не для участия в каждой встрече. Он снимает противоречия между отделами и утверждает изменения, которые влияют на деньги или срок. TPL Soft связывает недостаточную вовлечённость руководства с задержками из-за зависших решений.
Рабочий комитет решает вопросы меньшего масштаба: согласует модели процессов, принимает результаты этапов, назначает участников испытаний. Заранее установите срок ответа. Иначе три дня разработки легко сменяются двумя неделями ожидания согласования.
Обследование должно закончиться документами
Серия встреч сама по себе ничего не подтверждает. После обследования у вас должны остаться материалы, по которым можно проверить оценку подрядчика.
«Диалог ИТ» связывает короткое или формальное обследование с перерасходом бюджета и переносом сроков. Infostart отдельно рекомендует провести предварительный аудит ИТ-инфраструктуры, чтобы снять технические риски до внедрения.
Проверьте четыре области: текущие и будущие процессы, качество данных, внешние обмены и инфраструктуру. Пропуск любой области возвращается переделкой на следующем этапе.
| Область обследования | Что выяснить | Какой результат запросить |
|---|---|---|
| Процессы | Кто начинает операцию, кто согласует, где она заканчивается | Модели текущей и будущей работы |
| Данные | Есть ли дубли, противоречия и перегруженные справочники | Правила очистки и ответственные за исправления |
| Интеграции | Какие системы передают данные в 1С и получают их обратно | Перечень обменов, состав данных и владельцы |
| Инфраструктура | Где будет работать база, хватит ли текущей схемы размещения | Заключение по серверу, сети, резервированию и доступу |
| Приёмка | Какие операции должен выполнить пользователь | Набор сценариев с ожидаемыми результатами |
Вывод обследования — не презентация с общими обещаниями. TPL Soft называет результатом этапа концепцию внедрения с оценкой срока и стоимости. После проектирования должны появиться дорожная карта и прототипы основных сценариев.
Концепция связывает потребность бизнеса с составом работ. В ней видно, какие подразделения входят в проект, что меняется в их работе, какие данные переносят и какие интеграции настраивают.
Дорожная карта отвечает на другой вопрос: в какой последовательности команда выдаёт проверяемые результаты. Если подрядчик показывает только календарь встреч и загрузку специалистов, оценку проекта пока не на чем защищать.
Прототип нужен до основной разработки. На нём владелец процесса проверяет будущую работу и замечает неверные допущения. Исправить модель на этой стадии дешевле, чем переделывать настроенную систему и повторно обучать людей.
Выбор продукта тоже должен следовать за обследованием. Сверьте процессы компании с развилкой между конфигурациями 1С, прежде чем закреплять продукт в договоре. Покупка неподходящей конфигурации не исправит разрыв между отделами.
Первая очередь должна завершать рабочий цикл
Попытка сразу охватить финансы, закупки, продажи, склад, производство и кадры перегружает проект. «Диалог ИТ» относит автоматизацию всех процессов без предварительного анализа к причинам роста сложности.
Первая очередь не обязана быть маленькой. Она обязана быть законченной. Пользователь должен пройти рабочий цикл от начала до результата без временной таблицы между двумя отделами.
Для торговой компании таким контуром может стать заказ, резервирование, отгрузка и отражение оплаты. Для производства — заказ на выпуск, потребность в материалах и передача результата на склад. Точный состав зависит от затруднения, ради которого компания начала проект.
Не включайте функцию только потому, что она была в старой системе. Сначала выясните, какую работу она поддерживает, кто пользуется результатом и что произойдёт без неё.
Особенно дорого обходится перенос старых доработок без проверки. «Диалог ИТ» отмечает, что избыточная кастомизация усложняет обновления, сопровождение и дальнейшее развитие системы.
| Кандидат в первую очередь | Условие включения | Когда перенести |
|---|---|---|
| Обязательный ежедневный процесс | Без него нельзя завершить выбранный рабочий цикл | Не переносить: изменить границы всей очереди |
| Обмен с внешней системой | Он нужен для начала или завершения основного процесса | Перенести, если данные можно временно вводить один раз без двойного учёта |
| Управленческий отчёт | Руководитель назвал решение, которое принимает по отчёту | Перенести, если у показателя нет владельца и согласованной формулы |
| Редкий сценарий | Ошибка в нём создаёт правовой или финансовый риск | Перенести, если ручная обработка дешевле настройки первой очереди |
| Доработка из старой системы | Она поддерживает подтверждённое правило бизнеса | Перенести, если сохраняет привычный экран, но не меняет результат |
| Функция без владельца | Назначен человек, который примет результат | Перенести до назначения владельца |
Первая очередь должна закрыть один рабочий цикл, а не взять понемногу из каждого отдела. Иначе компания получает много начатых участков и ни одного процесса, готового к эксплуатации.
Новые идеи не нужно запрещать. Их нужно отделять от уже согласованного результата. Каждое требование получает оценку влияния на срок, стоимость, обучение и соседние процессы.
После оценки у руководителя три варианта: заменить требованием другую работу, перенести его в следующую очередь или расширить бюджет и срок. Нельзя молча добавить работу, сохранив прежнюю дату.
Данные готовит заказчик, а не система
Новая 1С не исправит противоречия в справочниках сама. Дубли контрагентов, разные единицы измерения и несогласованные остатки переходят в новую базу вместе с историей.
«Диалог ИТ» указывает, что команда тратит время на исправление противоречивых данных и дублей вместо развития системы. TPL Soft связывает слабое качество данных с ошибками в отчётах и управленческих решениях.
Назначьте владельца каждого набора данных. Финансовая служба отвечает за правила учёта, отдел продаж — за клиентов и договоры, склад — за номенклатуру и остатки. ИТ-служба может выполнить загрузку, но не решит, какая из двух карточек контрагента верна.
До миграции согласуйте правила очистки. После пробной загрузки сравните исходные и итоговые остатки, задолженность и справочники. Расхождение нельзя переносить на промышленный запуск под обещание «поправим потом».
Отклонение видно по результатам этапов
Проект редко срывается за один день. Сначала исчезают промежуточные результаты: прототип не готов, данные не очищены, владельцы процессов не отвечают. Дата запуска при этом остаётся прежней.
Следите не за числом проведённых встреч, а за тем, что команда передала и приняла. TPL Soft описывает последовательность из обследования, проектирования, настройки, испытаний и промышленного запуска. У каждого этапа есть отдельный результат.
После обследования нужна концепция с оценкой. После проектирования — дорожная карта и прототипы. После настройки — рабочая модель для испытаний. Перед запуском пользователи должны проверить свои сценарии и подготовиться к работе.
| Ранний признак отклонения | Что проверить | Действие заказчика |
|---|---|---|
| Новые требования попадают в работу без оценки | Есть ли запись об изменении границ | Остановить работу по требованию и запросить влияние на срок и стоимость |
| Нет прототипа основного сценария | Был ли он записан как результат проектирования | Не принимать этап до демонстрации и проверки владельцем процесса |
| Решения руководства зависают | Назначены ли спонсор и срок ответа | Вынести вопрос спонсору, зафиксировать влияние задержки |
| Команда исправляет дубли во время испытаний | Выполнен ли план очистки до миграции | Остановить перенос и нормализовать данные |
| Пользователи впервые видят систему перед запуском | Кто участвовал в прототипировании и испытаниях | Перенести запуск до проверки рабочих сценариев |
| Смета выросла без перечня работ | Какие требования добавили после договора | Запросить отдельную оценку каждого изменения |
| Серверную схему выбирают после настройки | Есть ли заключение по инфраструктуре | Вернуть вопрос на уровень проекта и пересчитать связанные расходы |
Таблица нужна для еженедельного контроля. Один признак ещё не доказывает срыв, но требует решения с владельцем и датой.
Не принимайте этап за процент готовности. Формулировка «проектирование выполнено на 90%» не показывает, можно ли начинать настройку. Принять можно концепцию, прототип, испытанную модель или готовность пользователей — то, что можно проверить.
Если обследование требует клиент-серверной схемы, заранее сравните собственный сервер и облачное размещение. Выбор влияет не только на оборудование, но и на доступ, обслуживание и порядок восстановления.
Лицензии, СУБД и сопровождение считайте вместе с инфраструктурой. Отложенный расчёт этих расходов делает исходную смету неполной. Состав затрат разобран в материале о полной стоимости сервера 1С.
Что решить на ближайшей встрече
Не утверждайте следующий этап, пока подрядчик не передал результат предыдущего. Для обследования это концепция и оценка, для проектирования — дорожная карта и прототипы, для настройки — модель, готовая к испытаниям.
Перед подписанием договора проверьте пять пунктов:
- границы первой очереди описаны через законченные рабочие сценарии;
- у каждого процесса и спорного решения есть владелец;
- обследование завершилось концепцией, оценкой и дорожной картой;
- критерии приёмки описывают действия пользователя и ожидаемый результат;
- каждое новое требование получает отдельную оценку срока и стоимости.
Если хотя бы одного пункта нет, не расширяйте проект обещаниями на встрече. Сначала зафиксируйте недостающее решение.
Для сметы в 2 млн рублей оценка риска из материала Infostart составляет 200–600 тысяч рублей. Для другого бюджета используйте формулу бюджет × 0,10–0,30. Это оценка возможного перерасхода при нечётком техническом задании, а не обязательный резерв в договоре.