Перед ИТ-директорами и руководителями проектов крупных промышленных предприятий часто встает непростая дилемма. С одной стороны, есть мощная, но функционально сложная и требовательная к ресурсам 1С:ERP Управление предприятием. С другой стороны — легкая, быстродействующая и визуально привлекательная 1С:Управление нашей фирмой (УНФ). Соблазн использовать УНФ на уровне отдельных цехов, связав их в единую сеть через распределенные информационные базы (РИБ), крайне велик. Особенно когда кажется, что ERP работает медленно, а запуск планирования производства занимает слишком много времени.
В этой статье мы подробно проанализируем реальный кейс крупного машиностроительного предприятия (два завода, 2000 производственных рабочих, изделия до 10 уровней вложенности, до 8000 полуфабрикатов в одном изделии, объем выпуска — 80 000 полуфабрикатов в месяц с общим документооборотом более 560 000 транзакций). Мы разберем по шагам, почему попытка уйти от ERP в сторону распределенной структуры на УНФ является технологическим тупиком, какие подводные камни скрывает децентрализованная архитектура и как правильно оптимизировать 1С:ERP для стабильной работы.
---
Для начала зафиксируем ключевые параметры и бизнес-требования рассматриваемого производства, которые определяют выбор ИТ-архитектуры:
---
Идея развернуть в каждом из 23 цехов отдельную базу 1С:УНФ, сделать их «организациями», настроить распределенную информационную базу (РИБ) и обмениваться заказами и накладными кажется привлекательной. Приверженцы этого подхода аргументируют его тем, что базы будут легкими, интерфейс на местах не будет зависеть от общей загрузки сервера, а доработки под «хотелки» отдельных цехов можно делать быстро и безболезненно. Однако детальный технический анализ выявляет критические риски этой схемы.
1. Полное отсутствие поддержки ГОЗ (275-ФЗ) в 1С:УНФ.
Это самый главный юридический и методологический барьер. В 1С:УНФ штатно отсутствует механизм сквозного обособления запасов под «Назначения» (контракты ГОЗ) на всех уровнях спецификации. В ней нет инструментов для формирования специализированной отчетности по Постановлению Правительства РФ № 543/47 (Отчет об исполнении контрактов ГОЗ). Попытка «дописать» этот функционал силами собственных разработчиков приведет к фактическому переписыванию ядра конфигурации. Затраты на такую разработку и ее последующую поддержку многократно превысят стоимость внедрения типовой 1С:ERP.
2. Невозможность автоматического расчета сквозной себестоимости.
Для того чтобы рассчитать себестоимость готового изделия на 10-м уровне вложенности, системе необходимо последовательно рассчитать себестоимость полуфабрикатов на предыдущих 9 уровнях, которые производились в разных цехах (разных базах УНФ). При использовании РИБ расчет превратится в бесконечный цикл обменов:
В распределенной системе оперативно получить реальную себестоимость переделов практически невозможно. Стандартные механизмы платформы 1С требуют, чтобы процедура закрытия месяца и окончательного расчета партий выполнялась строго в едином информационном пространстве.
3. Проблема транзакционных блокировок и производительности УНФ.
Тестовые испытания показывают, что проведение месячного объема документов в УНФ может занимать до 4 суток. Это связано с тем, что архитектура регистров УНФ оптимизирована под малый и средний бизнес (до 30-50 пользователей). При попытке провести сотни тысяч документов система неизбежно столкнется с жесткими транзакционными блокировками СУБД на таблицах итогов регистров накопления, таких как РегистрНакопления.Запасы и РегистрНакопления.ВыработкаОрганизации.
4. Лавинообразный рост коллизий при обменах в РИБ.
При интенсивности документооборота в 560 000 документов в месяц таблицы регистрации изменений в РИБ будут перегружены. Любая задержка связи или сбой синхронизации приведут к тому, что цех-потребитель не сможет принять полуфабрикат по системе, так как в его локальной базе еще физически не зарегистрирован документ выпуска от цеха-отправителя. Начнется хаос в оперативном учете на местах.
---
Почему же на практике возникает ощущение, что 1С:ERP «тормозит»? Как правило, это связано не с ограничениями платформы 1С:Предприятие 8.3 или производительностью сервера, а с ошибками методологии проектирования и избыточной детализацией процессов.
Рассмотрим, какие шаги необходимо предпринять, чтобы запустить крупное производство в единой базе 1С:ERP с высокой производительностью.
Часто на машиностроительных заводах пытаются запустить детальное пооперационное планирование до конкретного рабочего центра (станка) непосредственно из ERP-системы. При спецификациях в 10 уровней вложенности и 8000 полуфабрикатов алгоритмы расчета графика производства вынуждены перебирать миллионы комбинаций связей, что и приводит к многочасовым зависаниям («планированию в течение половины рабочего дня»).
Для решения этой проблемы мы рекомендуем применить двухуровневую модель управления:
В отличие от УНФ, в 1С:ERP механизмы поддержки 275-ФЗ встроены в ядро системы. Для ведения раздельного учета используется аналитика Назначение, которая связывается с направлением деятельности (конкретным госконтрактом).
При планировании заказа под ГОЗ система автоматически формирует потребность в материалах с признаком обособления. Это гарантирует, что закупленный под данный контракт металл или болт не будет случайно списан на другое изделие. Схема движения документов выглядит следующим образом:
// Пример логики распределения запасов под ГОЗ (схематично)
ЗаказНаПроизводство.Назначение = НаправлениеДеятельностиГОЗ;
ЗаказМатериаловВПроизводство.Обеспечение = КоличественноОбособленно;
Такая сквозная аналитика позволяет в любой момент сформировать регламентированный отчет для военного представительства без ручного сбора данных из сторонних баз.
Если предприятие до сих пор использует ERP редакции 2.4, настоятельно рекомендуется рассмотреть переход на редакцию 2.5. В ней разработчики фирмы «1С» кардинально переработали архитектуру производственного учета и партионного расчета:
Если стоит задача ограничить видимость данных для сотрудников конкретного цеха (чтобы цех А видел только свои склады и свои документы), не нужно создавать физически разные базы данных. В 1С:ERP этот функционал реализуется через стандартный механизм RLS (Row-Level Security).
Мы настраиваем группы доступа по подразделениям и складам. Для пользователя из Цеха 1 интерфейс системы будет выглядеть простым и лаконичным, содержащим только его документы, в то время как вся информация будет консолидироваться в единой высокопроизводительной базе данных под управлением MS SQL или PostgreSQL.
---
Для наглядности сопоставим два анализируемых подхода по ключевым критериям внедрения:
| Критерий сравнения | Распределенная схема на 1С:УНФ (РИБ) | Единая база 1С:ERP |
|---|---|---|
| Поддержка ГОЗ (275-ФЗ) | Отсутствует. Требуется колоссальная ручная доработка ядра системы. | Поддерживается в типовом функционале через механизмы обособления запасов. |
| Расчет себестоимости | Невозможен по сквозной схеме переделов. Ограничен только прямыми затратами в рамках одной базы. | Полный расчет сквозной фактической себестоимости по всем 10 уровням вложенности. |
| Сложные спецификации | Нет механизмов автоматического сквозного разузлования на всю глубину производства. | Поддерживается автоматическое формирование дерева спецификаций и цепочки зависимых заказов. |
| Производительность | Быстрая работа локально, но критические блокировки при закрытии месяца и проведении больших пакетов документов. | Требует мощного сервера и оптимизации методологии, но стабильно переваривает миллионные объемы транзакций. |
| Поддержка и обновления | Крайне сложная. Поддержка синхронизации 23 измененных баз в РИБ превратится в постоянный кошмар. | Стандартное обновление единой базы. Простая поддержка конфигурации. |
---
Попытка внедрить распределенную систему на базе 1С:УНФ для крупного машиностроительного завода с госконтрактами — это заведомо тупиковый путь, который приведет к потере контроля над себестоимостью, невозможности сдать отчетность по ГОЗ и постоянным сбоям синхронизации данных между цехами.
Единственным жизнеспособным решением является развертывание 1С:ERP в рамках единой информационной базы. Если система работает медленно, необходимо направить ресурсы не на программирование обменов в УНФ, а на оптимизацию настроек ERP: