Концепт «Такт»

Производственный план связывает материал, оборудование и обещанный срок, а каждое изменение проходит проверку.

Концепт-проект: «Такт» — вымышленная компания. Результатов работы здесь нет: только решения и гипотезы.

О заказчике

• Сценарий: Серийные и заказные металлоизделия на ограниченном участке
• Участники: Планировщик, технолог, кладовщик и мастер смены
• Первая версия: Маршрут заказа, резерв, график участка и фактические события
• Граница: Финансовый учёт и управление всеми цехами не входят в стартовый модуль
• Данные: Оборудование, заказы, сроки и остатки в иллюстрациях являются учебными

Задача

В вымышленном производстве металлоизделий планировщик получает заказ, технолог задаёт операции, склад резервирует материал, а мастер уточняет фактическую готовность станков. Эти данные находятся в разных таблицах. Обещанная клиенту дата не учитывает очередь на узком участке и время переналадки.

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

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

Риски исходного процесса

Остаток ошибочно считается доступным

Разделяем общий остаток, действующий резерв и ожидаемое поступление. Обещанная поставка не становится доступным материалом до подтверждения принятого источника данных.

Станок занят двумя операциями

Черновой план проверяет пересечения, сменный календарь и переналадку. Конфликт виден у конкретной операции, а не скрывается в общем предупреждении.

Изменение даты ломает зависимости

При переносе показываем последующие операции и затронутые заказы. Пользователь подтверждает изменение всего допустимого набора, а не только красивое положение полосы.

План подменяет фактический выпуск

Факт начала и завершения хранится отдельно. Перепланирование не стирает остановку, перерасход или брак; эти события требуют своего решения и доступа.

Решение

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

Планировщик собирает черновой график и проверяет ограничения. Полоса заказа на диаграмме связана с карточкой операции; рядом видны резерв материалов, предыдущий шаг и источник ожидаемого поступления. Перенос показывает затронутые заказы и причину. Подтверждение публикует новую версию плана, а не молча меняет даты для всех сотрудников.

Мастер фиксирует фактическое начало, выпуск и остановку. Если работа уже началась, её нельзя перенести как пустой слот. Расхождения возвращаются планировщику для решения. Учетная система остаётся источником финансового и складского учёта в согласованной границе; модуль планирования не выдаётся за универсальную замену всей ERP.

Как устроен продукт

1. Портфель заказов. Приоритет, срок, версия изделия и причина риска. Предполагаемая дата отделена от подтверждённой. Зачем: Планировщик видит источник ограничения до назначения операции.
2. Маршрут и спецификация. Зависимые операции, группа оборудования, единицы материала и версия состава. Зачем: Позднее изменение рецептуры не применяется незаметно к уже запущенной партии.
3. Материалы и резервы. Остаток, резерв других заказов, дефицит и источник ожидаемого поступления. Зачем: Один и тот же материал не обещается двум заказам.
4. График участка. Операции по оборудованию, рабочие окна, обслуживание и ограничения переналадки. Зачем: Диаграмма служит проверкой исполнимости, а не только календарём.
5. Черновик перепланирования. Различия с опубликованной версией, затронутые заказы и подтверждение изменений. Зачем: Участники понимают, какие сроки уже являются рабочим планом.
6. Фактические события. Начало, остановка, завершение, выпущенное количество и причина отклонения. Зачем: Руководитель может отличить ошибку модели от события в цехе.

Что помогает пройти сценарий

Проверка перед публикацией

План проходит проверку пересечений оборудования, последовательности операций и доступного материала. Ошибки привязаны к заказу; публикация не считается успешной при частичном сохранении.

Сначала влияние, затем перенос

Новая позиция операции создаёт предложение. Планировщик видит последствия для последующих шагов и клиентских дат; работающий участок продолжает читать прежнюю версию до подтверждения.

Резерв с объяснимым источником

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

Ключевые сценарии

Проверить материал

Заказ нельзя считать готовым к запуску только по общему остатку на складе.

На входе: Спецификация требует материал, часть остатка уже зарезервирована; ожидаемая поставка ещё не подтверждена.

1. Выбрать версию спецификации и нормализовать единицы потребности.
2. Вычесть действующие резервы из подтверждённого остатка.
3. Показать дефицит и отдельно ожидаемое поступление.
4. Сохранить решение планировщика и допустимый вариант запуска.

На выходе: Заказ имеет объяснимое состояние обеспеченности; ожидаемая поставка не показана как фактический остаток.

Если что-то пошло не так: Если источник остатков недоступен или версия устарела, интерфейс сообщает дату данных и не подтверждает новый резерв молча.

Критерий приёмки: Два параллельных заказа не получают один и тот же доступный остаток. Повтор подтверждения не создаёт дополнительный резерв.

Перенести операцию

Срочный заказ меняет график участка, поэтому нужно показать влияние на зависимые операции.

На входе: Один станок занят, следующая операция зависит от окончания текущей; мастер ещё работает по опубликованной версии.

1. Создать черновую версию и предложить новое окно.
2. Проверить пересечение, переналадку и зависимые операции.
3. Показать затронутые сроки и зафиксировать причину.
4. Подтвердить актуальную версию целиком.

На выходе: Черновик публикуется только после разрешения конфликтов; мастер получает одну подтверждённую версию.

Если что-то пошло не так: Если коллега уже опубликовал новый план, устаревшее подтверждение отклоняется с сохранением черновика для сравнения.

Критерий приёмки: Утверждённый график не содержит пересечения станка и нарушенной зависимости. Старая версия остаётся в истории.

Зафиксировать остановку

Факт из цеха должен изменить ожидания, сохраняя уже выполненную работу.

На входе: Операция начата; мастер обнаружил неисправность и частично выпущенную партию.

1. Записать время остановки, причину и подтверждённый выпуск.
2. Сохранить событие с уникальным идентификатором.
3. Отметить оборудование недоступным на согласованный период.
4. Передать планировщику новые ограничения без стирания факта.

На выходе: Выполненная часть и остановка сохранены; оставшаяся работа становится основанием для пересмотра графика.

Если что-то пошло не так: При повторной доставке события выпуск не увеличивается второй раз. Коррекция факта требует отдельного действия с автором и причиной.

Критерий приёмки: История показывает исходный факт и коррекцию. Перепланирование не превращает остановленную операцию в никогда не начатую.

Роли пользователей

Планировщик

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

Можно ли выполнить заказ при текущих ограничениях?

Мастер смены

Получает подтверждённую очередь и фиксирует производственные события.

По какой версии работать и что делать при остановке?

Технолог и склад

Поддерживают спецификации, маршруты и подтверждённые остатки.

Какой материал зарезервирован для конкретной версии изделия?

Как устроено технически

Предметная модель

Вариант реализации использует PostgreSQL для заказов, версий спецификаций, операций и резервов. Единицы измерения согласуются при импорте; неизвестная единица блокирует расчёт, а не превращается в нулевую потребность.

Версии и конкурирующие изменения

Подтверждение сверяет версию плана. Резервы и публикация операций сохраняются в согласованной транзакции; устаревший черновик отправляется на пересчёт, не перезаписывая новую работу коллеги.

Обмен с учётной системой

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

Рабочее место и эксплуатация

Интерфейс мастера отделён от редактора плана. Журнал показывает действия и ошибки обмена. Резервную копию проверяем восстановлением; автоматический расчёт не обещает математически оптимальный график.

Что входит в разработку

• Обследование одного участка и источников данных
• Модель маршрута, версий изделия и единиц измерения
• Заказы и потребность материалов
• Резерв с проверкой конкурирующих изменений
• График оборудования и сменный календарь
• Публикация и сравнение версий плана
• Рабочее место фиксации фактических событий
• Одна интеграция с учётной системой
• Параллельная проверка до выдачи производственных заданий

План реализации

1. Модель участка: описываем оборудование, календарь, маршруты, единицы измерения и правила резерва материалов.
2. Прототип плана: проверяем нехватку материала, перенос зависимости и конфликт станка на демонстрационном заказе.
3. Вертикальный срез: связываем один заказ со спецификацией, резервом и очередью операций.
4. Параллельная проверка: сравниваем предложенный график с текущим процессом без автоматической выдачи заданий в цех.
5. Пилот участка: вводим подтверждение версии, сбор фактов и регламент разбора расхождений; затем определяем следующий модуль.

Что замеряем после запуска

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

Стек

React, TypeScript, PostgreSQL, API учётной системы.

Все кейсы · Услуга · Калькулятор стоимости

Визуализация продукта

Изображения созданы с помощью ИИ для демонстрационного проекта. Организации, люди и параметры вымышлены; это не скриншоты работающего клиентского продукта.