← Все статьи

Ошибки внедрения 1С:ERP: НСИ, переход с УПП и цена «перенести как было»

1С:ERP — самая тяжёлая конфигурация в линейке: несколько контуров, единая нормативно-справочная информация, планирование, взаимозависимость подсистем. Здесь ошибка стоит дороже, чем в торговле или бухгалтерии, а исправление обычно означает не «перенастроить галочку», а перезагрузку остатков и повторный запуск.

Отдельный контекст: большинство проектов ERP сегодня — это не внедрение «с нуля», а переход с «1С:УПП», поддержка которой по объявленным срокам завершается. И главная ошибка таких проектов — попытка перенести старую систему «как было».

Почему ERP прощает меньше

  • Единая НСИ. Справочники обслуживают все контуры: ошибка в номенклатуре или плане счетов расходится по производству, закупкам, складу и финансам.
  • Связность. Производство тянет закупки, закупки — финансы, финансы — регламентированный учёт. Локальная правка почти всегда имеет отложенный эффект в другом контуре.
  • Объёмы. Производительность и закрытие периода проверяются на реальных данных, а не на демо-базе.
  • Необратимость части настроек. Например, группа финансового учёта у номенклатуры не меняется после того, как позиция использована в хозяйственной операции.

Ошибка №1: НСИ в конце проекта

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

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

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

Ошибка №2: перенос справочников «один к одному»

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

Что важно понимать до старта:

  • архитектура справочников ERP отличается от УПП — прямой перенос без адаптации почти всегда даёт ошибки;
  • в ERP есть группы финансового и аналитического учёта, которые нельзя «донастроить» после первых операций;
  • чистить данные лучше в приёмнике: в старой системе невозможно учесть все требования новой (шаблоны наименований, свойства, виды номенклатуры, объединение дублей);
  • перенос всей истории хозяйственных операций — самый трудоёмкий вариант с наименьшей ценностью для бизнеса.

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

Ошибка №3: доработки до того, как согласована логика

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

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

Ошибка №4: «учтём всё сразу»

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

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

Ошибка №5: параллельная работа «для подстраховки»

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

Более управляемый вариант — опытная эксплуатация с чётким окном, ответственными и критериями выхода, а не бессрочное параллельное ведение.

Ошибка №6: запуск без проверки объёмов и производительности

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

Ошибки управления, которые ломают ERP-проект

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

Признаки, что проект уже буксует

  • ERP формально запущена, но ключевые отчёты продолжают считать в Excel.
  • Цифры не сходятся, идёт постоянная ручная сверка.
  • Смета растёт без оценок и согласований.
  • Никто не может объяснить, почему справочники и настройки устроены именно так.
  • Демонстраций нет: о ходе работ известно из актов.
  • Ключевые пользователи перестали участвовать во встречах.

Что делать: порядок, который снижает риск

  1. Сформулировать измеримую цель: не «внедрить ERP», а «закрывать месяц за N дней».
  2. Поставить НСИ и учётную политику первым блоком дорожной карты.
  3. Согласовать целевую модель процессов и границы первой очереди до разработки.
  4. Определить уровень переноса: остатки + НСИ, при необходимости плюс открытые заказы и планы.
  5. Нормализовать данные в приёмнике, а не «чистить» в источнике.
  6. Проверить производительность и обмены на объёмах, близких к боевым.
  7. Провести опытную эксплуатацию с критериями выхода, а не бессрочный параллельный учёт.
  8. Принимать результат по сценариям, написанным заказчиком до начала работ.

Планируете переход на 1С:ERP или уже застряли в проекте? Проведём бесплатный 30-минутный аудит и дадим дорожную карту из 3 шагов. Оставить заявку.

Полезно по теме