Здравствуйте,
Смотреть в любом случае нужно в статистике.
Это то в статистике видно.
Другое дело, в чём мерить "сделала"?
Вот ваш пример в VOGBIT:
Рис.1:
2 смены, по 2 человека по 11 часов.
Сначала делали "большое" изделие (ДГУ 200, 74 н/ч). Начала первая смена, потом продолжила вторая, потом опять первая продолжила, и вторая, наконец, доделала.
Потом делали "маленькое" изделие (ДГУ 500, 32 н/ч). Вторая смена начала, первая доделала.
Смотрим в статистику (рис.2):
По количеству получается, что сдали по одному изделию. Причём вторая смена, получается, сдала "большое" изделие, а первая - "маленькое".
Но по объёму работы видно, что первая смена то тут работала намного больше, чем вторая.
Видно в статистике и то, и другое. И объём работы в н/ч и количество сданных изделий и кто сдал. Но как показывает этот пример, количество сданных изделий сменой в данном случае не показатель. Те, кто сдал, мог просто оказаться последним в цепочке, а делал то, в основном, не он.
| Цитата |
|---|
Михаил Анатольевич написал:
Какая смена превысила плановую трудоемкость, т.е. делала изделие дольше чем запланировано? |
А вот тут ещё интереснее вопрос.
Причём, как мне кажется, он не к программе, в общем-то, а по сути самого процесса больше.
Учёт фактической трудоёмкости наладить, предположим, можно с помощью терминалов цеховых. Опыт есть. Чтобы отмечалось, и в базу падала информация, кто сколько по факту над каким изделием работал.
Это даёт много информации для анализа, но на 100% задачу не решает в такой постановке, потому что:
Берём тот же пример. Делаем "большое" изделие. Первые отметили, что они фактически свои 22 н/ч отработали по нему (всю смену его делали). Потом вторые отметили, что они всю смену делали это же изделие (ещё 22 н/ч фактической трудоёмкости). Потом опять первые всю смену. И вот, наконец вторая смена приходит, и выясняется, что там реально не на треть дня ещё работы, как предполагалось, а на весь день фактически. Они, соответственно, закрывают по факту больше трудоёмкость работы над данным изделием, и дальнейший плановый график "сползает" несколько вправо на время этой задержки.
Но!
Самое интересное.
Да, вторая смена в оконцовке отклонилась от норматива. В итоге. Но кто виноват то в этом?
Это первая смена в самый первый день что-то не так сделала, и в итоге пошла оттуда задержка?
Или у них всё было нормально, но потом вторая смена вчера ночью что-то не доделала, и пошло дальше отставание?
Или это на второй день в первую смену что-то пошло не так, и дальше с этого момента пошло отставание, а до этого было всё нормально?
Или вообще всё было нормально до самого конца почти, и вторая смена сама в конце что-то затянула?
Как тут понять?
Из этого примера явно видно, что только фактических нормо-часов отработанных и сданного количества никак не достаточно, чтобы ответить на вопрос, когда и кто "отстал".
Чисто математически с такими исходными данными задача не решаема.
Тот помимо объёма выполненной работы и количества сданных изделий нужен ещё какой-то показатель - типа насколько процентов от 100 в эту смену в итоге продвинулась общая работа над изделием.
Но это нереально, по моему, такой показатель вводить. Даже если пофантазировать и добавить в программе место, куда его вводить, и аналитику (что само по себе то довольно просто технически), то тут самый главный вопрос - кто будет этот "процент продвижения" в реальной жизни вводить и на основании чего?
Мне в плане реальной практики видится два возможных решения.
В любом случае ставить терминалы и мерить фактические трудозатраты.
Дальше первый вариант - выгружать потом данные через "статистику производства" и находить "отклонения". Где по факту они значительные, т.е. разница фактической трудоёмкости суммарной и изначально запланированной под это задание больше сколки-нибудь процентов или нормо-часов. И когда нашли, с каждым таким случаем разбираться отдельно - кто делал, почему так получилось.
Другой вариант - дробить одну такую "длинную" операцию на цепочку более мелких, которые выполняются друг за другом. И отмечать не всю её (74 н/ч), как одно задание, а как набор последовательных более мелких заданий, идущих друг за другом. Тогда намного точнее можно найти точку "отклонения". И будет его видно ближе к моменту, когда оно возникло, а не в самом конце.
В принципе, современная версия VOGBIT с её функциями "сдвига влево/вправо" и "вставки со сдвигом" + терминалы, которые корректно обрабатывают фактически затраченное время, позволяют вполне сносно с такими "цепочками" заданий, расписанными на несколько дней вперёд, работать. В т.ч. с учётом возникающих отклонений. Намного лучше сейчас дело с этим обстоит, чем пару лет назад.
Но тут нужно будет мониторить постоянно этот процесс и графики подправлять, если что.
В общем, тут дело не в отчёте, как мне кажется, в первую очередь, а в том, как для таких "совместных" операций длинных организовать вообще учёт их выполнения. А отчёт тут один можно придумать. Сравнивать фактически затраченную трудоёмкость с плановой. Только для этого фактическую мерить нужно по ходу дела. Иначе нечего сравнивать будет просто.
Технически решаемо. Ставить терминалы нужно и работу с выдачей заданий и их отметкой организовывать. Дальше будет статистика - будет что анализировать.
