Вопрос от пользователя: «Из любопытства хочу понять, как бы выглядела настройка этого самого «пооперационного планирования», если бы мы решили его использовать. Что нужно было бы указывать?»
Суть проблемы
Даже понимая, что функцию использовать не стоит, технические специалисты и руководители хотят представлять себе ее масштаб и сложность. Это помогает окончательно убедиться в правильности решения не связываться с ней и оценить уровень зрелости, необходимый для подобных систем.
Что может 1С ERP? (в прошлом)
Настройка пооперационного планирования требовала конфигурации множества взаимосвязанных параметров в специальном рабочем месте «Производство – Внутрицеховое управление – Пооперационное планирование» и в справочниках. Это была целая подсистема со своими объектами.
Суть подхода (архитектура устаревшей функции):
- Включение в подразделении: Флажок «Использовать пооперационное планирование» на закладке «Производство по заказам» в карточке подразделения.
- Параметры расчета в РМ:
Момент планирования: Точка отсчета, от которой система начинает размещать операции в будущем.
Горизонт планирования: Насколько далеко вперед (часы, дни) строить расписание.
Нормативное время на регистрацию: Допустимое время опоздания с отметкой начала операции, после которого операция подлежала перепланированию.
Модель планирования: Основной набор правил расчета. - Модели и сценарии планирования: Отдельные справочники, где описывались:
Коэффициенты времени работ для каждого РЦ.
Расценки работ и переналадок для расчета стоимости операций.
Сценарии изменений: Можно было смоделировать увеличение/уменьшение парка оборудования, изменение графика работы для подразделения, вида РЦ или конкретного станка (например, на время ремонта). - Отдельное РМ для диспетчеризации: При использовании планирования диспетчеризация велась не в основном РМ «Выполнение операций», а в специальном РМ «Выполнение операций (MES)».
Преимущества понимания (архитектуры):
- Оценка сложности: Становится ясно, что это не просто «галочка», а целая экосистема настроек.
- Понимание требований к данным: Для работы нужны были не просто нормы, а точные коэффициенты и расценки.
- Осознание уровня детализации: Система оперировала понятиями минутных интервалов и стоимостными показателями, что подразумевало соответствующий уровень учета на производстве.
Решение и рекомендации (для любознательных)
- Изучите как исторический артефакт: Посмотрите на эти настройки (если они доступны в вашей конфигурации) только для расширения кругозора.
- Сравните с современными MES: Понимание этой архитектуры поможет в будущем при выборе или обсуждении современных MES-систем, где подобные (и гораздо более продвинутые) функции реализованы иначе.
- Используйте принципы, а не инструмент: Сами идеи учета доступности РЦ, коэффициентов загрузки и сценариев «что, если» полезны. Их можно применять вручную или с помощью простых отчетов, не включая нерекомендуемый механизм.
- Сфокусируйтесь на качестве НСИ: Даже не включая планирование, стремитесь к тому, чтобы нормы времени и свойства рабочих центров в системе были точными. Это полезно само по себе.
Итог простыми словами
Представьте, что вы нашли старую, сложную швейную машинку с двумя десятками регуляторов настройки натяжения нити, длины стежка и пр. (параметры планирования). Чтобы на ней шить, нужно быть профессиональной швеей (высокий уровень зрелости производства) и долго ее настраивать под каждую ткань (сценарии). Производитель (1С) говорит: «Мы ее больше не производим, запчастей нет, лучше пользуйтесь современной машинкой с тремя кнопками (ручное диспетчирование)». Но изучать ее устройство все равно интересно, чтобы понять эволюцию технологий.
Типичные сценарии использования (в теории):
- Сценарий 1: Моделирование ремонта станка.
Теоретическое действие: В сценарии планирования указывалось, что «РЦ №5» исключается из планирования на 3 дня. При построении расписания система автоматически распределяла бы его нагрузки на другие станки этого вида. - Сценарий 2: Планирование со сменным графиком.
Теоретическое действие: Для «Вида РЦ: Печи» устанавливался график «Круглосуточно», а для «Вида РЦ: Токарные станки» — «Двухсменный». Система учитывала бы это при размещении операций в календарном плане.