С помощью инструмента Калькулятор мы получили оценку необходимого количества оборудования и персонала. Для моделирования в режиме Симулятора нужно подготовить необходимые изменения, позволяющие применить полученные оценки. Зайдем в соответствующий раздел, в котором можно заводить новое количество оборудования:
Здесь создадим изменение (добавим один станок в РЦ В), сохраним изменение под именем + 1B: Теперь у нас в распоряжении будет:
Из сравнения полученной расчетной потребности в "человекочасах" (персонале):
и количества рабочих центров, на которых персонал должен работать, получается, что для РЦ А и РЦ B требуется трехсменный режим работы. Поэтому перед тем, как менять количество персонала, необходимо удостовериться, что среди доступных, созданных ранее в Конструкторе расписаний, есть трехсменный режим. Для этого перейти в Конструктор расписаний:
Среди режимов работы находим похожий по названию - "трехсменная пятидневка". Выбираем этот режим и проверяем его смены: Выбранный режим содержит три смены, закрывающих целые сутки. Если бы трехсменного режима не было среди готовых, его пришлось бы создать по описанной процедуре.
Создадим изменение по персоналу на основе выбранного режима. Будем делать это внутри системы. Зайдем в изменения по профессиям Симулятора: Скопируем имеющееся ранее созданное изменение: Содержательно переименуем и выберем новый режим по умолчанию: Подтвердим предупреждение о том, что ранее созданные исключения будут в новом изменении потеряны, и расставим персонал по сменам в соответствии с оценками. Для этого входим в расписание режима и редактируем расстановку по каждой категории рабочих (через троеточия справа): В результате суммарно по сменам рабочие расставятся так: Здесь в первую и вторую смену - все профессии, в третью - операторы-наладчики А и B по одному человеку. Для профессии оператор-наладчик В выход посменно неравномерный - в первую и вторую смену по два человека, в третью - один, поскольку на два станка нужно в сутки 5 "человекосмен". Запускаем моделирование со сделанными изменениями и ранее найденным (см.) правилом по партионности: В результате моделирования с подключением созданных изменений по количеству оборудования и персоналу получим общее время исполнения плана более 800 часов, что значительно меньше предыдущего расчета, но не укладывается в месяц: Во вкладке Анализ заказов - Отчет находим одну из причин того, что не уложились в месяц, а именно, старты второго и третьего заказов плана заморожены: Поскольку наша цель - уложиться в "средний" месяц, то, чтобы не менять план, просто запустим его с более поздней даты, установив ее вручную (тем самым заказы, которые должны стартовать в конкретную дату при запуске "по плану", начнут выполняться сразу): В результате получена новая длительность исполнения плана: Отчет о прохождении говорит, что мы опаздываем : Поиск причин показывает, что главная причина опоздания в том, что сборочный центр в первые дни не работает, в результате чего последние работы по сборке выполняются в следующем месяце: (Для вывода диаграммы без персонала нужно выбрать соответствующий фильтр.)
Для исправления ситуации вновь изменим правило партионности. Сборка может стоять из-за некомплектности - но в данном случает входящие изготавливаются мелкими партиями, и не конкурируют за ресурсы. Другая возможная причина простоя сбоорки - крупные партии на сборку. Дадим возможность производить сборку как только готов комплект входящих, и для этого изменим партионность на сборочных операциях, поставив по 1 на каждое наименование ДСЕ сборки: и сохраним изменение.
Запустим моделирование с ними: В результате получаем сроки, "почти" укладывающиеся в месяц: Опоздание от целевого значения 1 месяц составляет 1 день. При этом работа сборки начинается как мы захотели:
Определим возможные причины опоздания. Посмотрим, чем плотно занят сборочный центр в кон6це работы над планом и чем менее плотно он занят в начале работы над планом. На диаграмме Ганта имеем для сборочного центра и график очередей для сборочного центра Расписание раюоты сборочного центра показывает, что в начале работы он собирает только изделия Q, и наоборот, в конце - только изделия P/ Возможно, причина опоздания заключается в структуре и очередности заказов? Смотрим план: Вместо этого плана создадим новый, с теми же изделиями и суммарными количествами. Для возможности маневра очередностью внутри заказа раздробим заказы, и поменяем очередность: (Здесь можно забрать план с измененной структурой). Моделирование прохождения этого плана с теми же настройками дает искомое значение - меньше месяца: Заметим, что простое разделение исходного плана без изменения порядка не меняет сроков. Для проверки возьмем этот план и промоделируем с ним. Результат в этом случае будет совпадать с результатом для исходного плана.
Таким образом, задача достижения цели - уложиться в месяц - выполнена. Но в арсенале BFG IS Симулятор есть еще одно средство управления очередями, которое позволяет (до определенных пределов), не меняя сроков, уменьшить очереди перед станками, тем самым влияя на размеры НЗП в производстве (завалы) и уменьшая степень организационного беспорядка. Сначала посмотрим на динамику очереди перед самым загруженным станком - центром предварительной обработки В, в последнем, удовлетворившем по срокам, моделировании: Видим, что очередь имеется сразу и только уменьшается - это следствие того, что с предыдущих операций работы приходят быстрее, чем этот, самый загруженный центр, может их "переварить" (обработать). Рано пришедшие партии только увеличивают очередь и создают беспорядок у рабочего центра. Для минимизации очереди "придержим" запуски. Для этого войдем в окно управления запуском партий: Создадим изменение по длине очереди (как это сделать - см.): Запустим моделирование по предыдущему сценарию, но добавим еще и сформированную настройку: В результате срок исполнения плана почти не изменился: Но самое главное, на что мы сейчас были нацелены - уменьшилась очередь там, где мы ее ограничили (в пересчет на 2 станка в РЦ - до 100 с заданного ограничения 50), и ограничение отразилось на всех связанных маршрутом обработки РЦ - появилась составляющая "ожидание запуска партий", фактически означающая, что физической очереди пока нет: График набора трудоемкости, естественно, немного изменился в сравнении с предыдущим: