Запуск 1С:ERP, когда не закрывается месяц

Контекст

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

Ситуация до проекта

На старте у компании было две ключевые базы. В 1С:ERP вели производство. В «1С:Бухгалтерии предприятия КОРП» держали основной регламентированный учет. Формально контур существовал. По факту единой управляемой системы не было.

Проблема была не в количестве систем, а в том, что учет перестал «держать период». Месяц не закрывался, ошибки не фиксировались в момент возникновения и тянулись дальше. Из-за накопленных расхождений расчет себестоимости ломался по цепочке, а текущий месяц зависел от проблем прошлых периодов. Чтобы получить управленческую картину, данные приходилось собирать вручную и сверять между системами.

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

Почему «просто перейти на 1С:ERP» не работает

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

• не закрываются периоды,
• не закреплены правила учета,
• есть ошибки в НСИ и производственном контуре,

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

Что пошло не так на старте проекта

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

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

Стало понятно, что простой перенос и настройка обменов задачу не решают.

Как пересобрали проект

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

Что сделали

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

Шаг 1. Определили критичный объем данных для переноса.
Не переносили все подряд. Выделили данные, без которых невозможны закрытие месяца и расчет себестоимости: НСИ, остатки и ключевые цепочки документов.

Шаг 2. Привели в порядок НСИ.
Убрали дубли и несогласованность справочников, разобрали номенклатурные группы и связанные параметры, которые влияют на производственный и финансовый учет.

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

Шаг 4. Пересобрали производственный контур под фактическую логику бизнеса.
Производственный блок не переносили «как есть». Его перестроили так, чтобы цепочка документов, учет выпуска и списаний, взаимосвязи партий и затрат позволяли корректно считать себестоимость.

Шаг 5. Зафиксировали правила закрытия месяца.
Определили, какие операции и проверки обязательны перед закрытием периода, и собрали воспроизводимый порядок закрытия, который можно повторять каждый месяц.

Управленческий эффект

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