Создадим новый план, в котором передвинем "длинную" позицию в самый верх по приоритетам. Сделать этом можно внутри системы, зайдя в раздел Симулятор -> План заказов: Скопируем план, в нем передвинем самую длинную позицию наверх (присвоим высший приоритет): После этого верхняя часть плана будет выглядеть так: Моделирование с новым вариантом плана сразу сократит время почти на месяц: Анализ диаграммы Ганта показывает, что для ресурса "слесарь" нужна вторая смена: Из графика очередей на сборочном центре следует, что с 6 по 16 единственной причиной простоя сборки является недостаток слесарей: При этом, в том же подразделении существует совершенно незагруженная другая профессия - также "слесарь":
Для объединения двух профессий (слесарей с разными кодами) есть основание, так как не бывает такой организации работ, чтобы загрузка у рабочих одной категории отличалась в десятки раз. Получается, это – ошибка. Нужна новая, исправленная модель данных. При ее подготовке обращаем внимание также на замечания (комментарии) в тексте, касающиеся численности шлифовщиков на длинной операции - шлифовка ДСЕ "Шток". Уточнение позволило выявить, что на самом деле длинные операции шлифовки "Штока" выполняют двое рабочих - в две смены.
Моделирование при тех же правилах дает результат на 200 часов меньше:
Помня, что существенное влияние на скорость прохождения плана имеет размер партий, ограничим партии четырьмя часами, для этого создадим соответствующее правило: Результат - сокращение еще на почти 200 часов: Последнее существенное сокращение возникает при изменении приоритетов плана - перемещении одной из трудоемких позиций вперед. План при этом такой: plan1 -1.xlsx При этом достигается загрузка персонала, превышающаяя 80% - т.е. дальнейшего сокращения времени исполнения плана добиться трудно: Итоговое сокращение времени прохождения плана составило:
Замечание. Из теории расписаний и сути имитационного моделирования известно, что не существует способов доказательства существования лучшего решения, кроме как его построения. Т.е. мы не беремся утверждать, что найденный способ прохождения плана САМЫЙ лучший, но он принадлежит к числу очень хороших решений. И мы утверждаем, что прирост качества решений (сокращение времени) при данной структуре (план, персонал, ресурсы) будет несущественным по сравнению с найденным в примере.
Дальнейшее сокращение циклов будет связано не со снижением длительности всего плана, а со снижением времени прохождения отдельных заказов и партий. Из графиков набора трудоемкости следует, что часть заказов "стоит", несмотря на то, что заказы считаются запущенными, что влечет за собой увеличение длительности прохождения плана. Возможны два пути. Во-первых, проанализировать простои и запускать все планы "руками" так, чтобы простоев не было. Это особенно просто, если ограничение стоит на первых операциях. Второй путь - ограничить количество заказов, одновременно находящихся в обработке. При этом понятно, что чем меньше число одновременно находящихся в обработке заказов (при не увеличивающемся сроке для всего плана), тем меньше цикл для отдельного заказа. В результате процедуры половинного деления найдено минимальное количество заказов в обработке, не увеличивающее общую длительность прохождения плана (мало того, она еще и сократилась - совсем чуть-чуть). Это правило: При этом достигается следующий результат: Одновременно сокращаются сроки прохождения большинства заказов, что видно в сравнении на ленточной диаграмме: Отсортировав отчет о заказах по длительности, мы увидим, что все заказы стали длительностью менее месяца: Сравните с предыдущим отчетом о заказах - там все опоздавшие имеют длительность более месяца, т.к. стартуют одновременно.
Дополнительно BFG IS имеет еще одно средство для сокращения составляющей полного цикла исполнения плана - цикла прохождения партий, за счет "придерживания" запуска партий с тем, чтобы минимизировать пустое пролеживание. Рассмотрим загрузку оборудования в последней сессии расчетов, и выберем оборудование с максимальными ожиданиями ресурсов: В динамике очереди меняются, как показано на графике: Перед этим РЦ максимально скапливается очередь на более 140 часов из-за отсутствия рабочего. Понятно, что можно без ущерба для общего времени запускать часть работ позднее. Установим ограничение на длину очереди в этом РЦ и промоделируем с включенным ограничением. В результате получим: В сравнении с предыдущим расчетом общая длительность не поменялась, но изменилось прохождение заказов - какие-то пошли быстрее, какие-то - медленнее: При этом цель – сокращение цикла прохождения заказов (сокращение очередей перед самым "заваленным" станком) – достигнута: Максимальная физическая очередь сократилась до менее 40 часов, т.е. цикл прохождения партий через этот РЦ сократился почти на 100 часов.