Ловушка бесконечного внедрения: завод третий год платит программистам за то, чтобы его же 1С просто работала
Один владелец производственного предприятия (завод по выпуску упаковки) в разговоре со мной искренне сокрушался:
«Мы два года дорабатывали программу под себя. Вроде всё настроили. Но вот идёт уже третий год, а внедрение как будто продолжается и продолжается! Постоянно счета от программистов, бухгалтерия регулярно жалуется на сбои, коллектив генерирует новые идеи — мы снова пишем доработки. Когда наконец наступит финал и система начнёт просто работать?»
Со стороны кажется: завод в состоянии перманентного ремонта ИТ-системы. Но если убрать эмоции, откроется жёсткий факт: внедрение на этом заводе давно закончилось. Собственник просто попал в классический организационный капкан, который на рынке называется «петлёй доработок».
Как захлопывается ловушка
Схема всегда одна. Программистам дают карт-бланш: «Перепишите систему так, чтобы людям было удобно». Разработчики перекапывают типовую конфигурацию, создают уникальный код и связывают блоки программы сотнями технических «костылей».
А дальше система живёт своей жизнью:
Программист поставил костыль → фирма «1С» выпустила обновление → обновление снесло костыль → документы заблокировались → бухгалтерия бьёт тревогу → программист ставит тот же костыль заново → директору прилетает счёт.
И так по кругу. Темп задают сами разработчики 1С: у «1С:Бухгалтерии» может выходить по 3–4 обновления в месяц, у ERP — стабильный поток релизов и «горячих» исправлений. Каждый релиз несёт новое: печатные формы, отчёты, правила прослеживаемости, маркировку, налоговые форматы.
Руководитель каждый месяц оплачивает внушительные счета, думая, что развивает систему. На самом деле он платит налог за то, чтобы программа просто работала так же, как вчера.
Финал у этой истории предсказуем
Избыточное переписывание типовой программы вручную всегда заканчивается одним и тем же: бухгалтерия перестаёт работать в системе. Меняются законы, формы деклараций, требования ФНС — объём этих изменений колоссален, и ни один штатный программист не в состоянии вручную поддерживать уникальные модули под каждое новое требование налоговой.
Когда программа окончательно заходит в тупик, бизнес принимает экстренное решение — разделять базы. Производство, склады и снабжение остаются в кастомной ERP, а для сдачи отчётности покупается чистая типовая «1С:Бухгалтерия».
Скрытая чёрная дыра: ловушка выгрузок
Казалось бы, решение найдено? Нет — директора ждёт новая экономическая ловушка. Разделение баз рождает регулярную выгрузку данных из кастомной ERP в чистую Бухгалтерию. И этот процесс превращается в огромную, монотонную ручную работу: где-то поехала аналитика, где-то не сошлись копейки, где-то перепутались субконто.
Автоматизировать саму проверку выгрузки практически невозможно. В итоге бухгалтерия вручную, строчка за строчкой, сверяет две гигантские базы. На это уходят сотни человеко-часов — и директор, сам того не замечая, раздувает штат бухгалтерии и платит зарплаты людям просто за сверку двух своих же программ.
Как вырваться
Решение о масштабах автоматизации нужно принимать осмысленно ещё до начала проекта. Возможностей современных стандартных систем 1С достаточно для закрытия 95% задач любого завода. Если нужны специфические управленческие отчёты — для этого существуют механизмы расширений и внешних обработок: они решают задачу бизнеса, не ломая монолитный код системы.
Простое правило: чем меньше переписан внутренний код вашей программы, тем меньше денег собственник тратит на её ежемесячное обслуживание. Задача руководителя — не переписывать программу под старые привычки персонала, а наводить порядок в процессах через жёсткие регламенты людей.
Проверьте свой проект за 15 минут
Задайте подрядчику три вопроса:
Если на все три ответят «мы всё сделаем в рамках проекта» — это красный флаг. Код они сделают. Регламенты — нет.
Проекты «МЭТРИК» начинаются с методологии, а не с кода: мы берём на себя организационное сопровождение ИТ-проектов, аудит регламентов и наведение порядка в промышленном учёте — чтобы ваши сотрудники и программа работали на общую цель.
«Мы два года дорабатывали программу под себя. Вроде всё настроили. Но вот идёт уже третий год, а внедрение как будто продолжается и продолжается! Постоянно счета от программистов, бухгалтерия регулярно жалуется на сбои, коллектив генерирует новые идеи — мы снова пишем доработки. Когда наконец наступит финал и система начнёт просто работать?»
Со стороны кажется: завод в состоянии перманентного ремонта ИТ-системы. Но если убрать эмоции, откроется жёсткий факт: внедрение на этом заводе давно закончилось. Собственник просто попал в классический организационный капкан, который на рынке называется «петлёй доработок».
Как захлопывается ловушка
Схема всегда одна. Программистам дают карт-бланш: «Перепишите систему так, чтобы людям было удобно». Разработчики перекапывают типовую конфигурацию, создают уникальный код и связывают блоки программы сотнями технических «костылей».
А дальше система живёт своей жизнью:
Программист поставил костыль → фирма «1С» выпустила обновление → обновление снесло костыль → документы заблокировались → бухгалтерия бьёт тревогу → программист ставит тот же костыль заново → директору прилетает счёт.
И так по кругу. Темп задают сами разработчики 1С: у «1С:Бухгалтерии» может выходить по 3–4 обновления в месяц, у ERP — стабильный поток релизов и «горячих» исправлений. Каждый релиз несёт новое: печатные формы, отчёты, правила прослеживаемости, маркировку, налоговые форматы.
Руководитель каждый месяц оплачивает внушительные счета, думая, что развивает систему. На самом деле он платит налог за то, чтобы программа просто работала так же, как вчера.
Финал у этой истории предсказуем
Избыточное переписывание типовой программы вручную всегда заканчивается одним и тем же: бухгалтерия перестаёт работать в системе. Меняются законы, формы деклараций, требования ФНС — объём этих изменений колоссален, и ни один штатный программист не в состоянии вручную поддерживать уникальные модули под каждое новое требование налоговой.
Когда программа окончательно заходит в тупик, бизнес принимает экстренное решение — разделять базы. Производство, склады и снабжение остаются в кастомной ERP, а для сдачи отчётности покупается чистая типовая «1С:Бухгалтерия».
Скрытая чёрная дыра: ловушка выгрузок
Казалось бы, решение найдено? Нет — директора ждёт новая экономическая ловушка. Разделение баз рождает регулярную выгрузку данных из кастомной ERP в чистую Бухгалтерию. И этот процесс превращается в огромную, монотонную ручную работу: где-то поехала аналитика, где-то не сошлись копейки, где-то перепутались субконто.
Автоматизировать саму проверку выгрузки практически невозможно. В итоге бухгалтерия вручную, строчка за строчкой, сверяет две гигантские базы. На это уходят сотни человеко-часов — и директор, сам того не замечая, раздувает штат бухгалтерии и платит зарплаты людям просто за сверку двух своих же программ.
Как вырваться
Решение о масштабах автоматизации нужно принимать осмысленно ещё до начала проекта. Возможностей современных стандартных систем 1С достаточно для закрытия 95% задач любого завода. Если нужны специфические управленческие отчёты — для этого существуют механизмы расширений и внешних обработок: они решают задачу бизнеса, не ломая монолитный код системы.
Простое правило: чем меньше переписан внутренний код вашей программы, тем меньше денег собственник тратит на её ежемесячное обслуживание. Задача руководителя — не переписывать программу под старые привычки персонала, а наводить порядок в процессах через жёсткие регламенты людей.
Проверьте свой проект за 15 минут
Задайте подрядчику три вопроса:
- Справочники — кто отвечает за чистоту карточек и НСИ?
- Кто отвечает за выгрузки — что происходит с данными, если базы разделены?
- Кто написал регламенты — кто, в какой момент и какие данные вводит в систему руками?
Если на все три ответят «мы всё сделаем в рамках проекта» — это красный флаг. Код они сделают. Регламенты — нет.
Проекты «МЭТРИК» начинаются с методологии, а не с кода: мы берём на себя организационное сопровождение ИТ-проектов, аудит регламентов и наведение порядка в промышленном учёте — чтобы ваши сотрудники и программа работали на общую цель.
23.10.2026
