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