alt: Почистване на натрупани над 200 работни поръчки за поддръжка: 30-дневен метод Основни изводи - Натрупване от над 200 работни поръчки почти никога не е проблем с капацитета.
Това е проблем с класификацията: в регистъра има реална работа, „мъртва“ работа, дублирана работа и работа, която изобщо не би трябвало да е работна поръчка, и никой не може да ги различи с един поглед. - 30-дневното разчистване е упражнение по триаж, а не спринт.
Целта не е да се затворят 200 работни поръчки; целта е да се остави регистърът с един статус на ред, един приоритет на ред и реален собственик на ред, така че следващите 30 дни да доведат до действителни ремонти вместо до още триаж.
- Най-голямата категория за изтриване в повечето заводи са „призрачните работни поръчки“: елементи, които са отворени, частично обслужени и изоставени, защото съответният актив е бил променен, изведен от експлоатация или вече е бил поправен от някой друг. Те обикновено са най-голямата единична категория за изтриване в остарял регистър.
- След разчистването правилният размер на регистъра за завод с 100 актива обикновено е 30, 60 отворени елемента, а не нула. Нулата означава, че системата не улавя реалното търсене; над 200 означава, че системата улавя търсенето, но не го отстранява. Защо регистрите (backlogs) се разрастват Натрупването на работни поръчки в поддръжката расте по скучни причини.
Работна поръчка се отваря за „вибрация на мотор на линия 3“, операторът го докладва, техникът сменя лагер, симптомът изчезва, но първоначалната работна поръчка никога не се затваря, защото за затварянето трябва да се отвори CMMS, да се намери правилният ред и да се кликнат три неща.
След седмица друг оператор докладва същия симптом и отваря нова работна поръчка. Сега са две. Умножете по 200 актива и 18 месеца и регистърът става неузнаваем. Вторият източник са дубликати от различни докладващи. Производството отваря „опаковачката на линия 3 е бавна“. Поддръжката отваря „лагер на опаковачката на линия 3“.
Контролът на качеството отваря „увеличени бракове на опаковачката на линия 3“. Всички три са за един и същи актив, възможно е и със същата коренна причина, но стоят като три отделни реда. Без процедура за премахване на дубликатите регистърът се надува, без да отразява повече реална работа.
Третият източник е отсъствието на ясен критерий за затваряне. Работната поръчка е „в процес“ защото някой работи по нея; остава „в процес“ безкрайно, защото никой не е дефинирал какво означава „свършено“ за този тип работна поръчка.
Статусите в жизнения цикъл, от които зависи този метод, са разгледани в статията за work order management systems (система за управление на работни поръчки) (https://www.fabrico.io/blog/work-order-management-systems/). Дни 1, 10: триаж на всеки отворен ред Стъпка 1: Съберете целия регистър в един изглед Целият регистър се експортира в електронна таблица, сортирана по възраст.
Най-старите от над 90 дни са в горната част. Това е единственият етап, в който потребителският интерфейс на CMMS не е основният инструмент, сортирането и масовото редактиране в електронна таблица са по-бързи за триажа и резултатите след това се импортират обратно.
Стъпка 2: Класифицирайте всеки ред в една от пет кошници За всеки ред едно от: - Реална: работа, която все още трябва да се извърши. - Призрачна: работа, която вече е извършена или е остаряла, защото активът е променен или изведен от експлоатация. Призрачните обикновено са най-голямата категория за изтриване в остарял регистър.
- Дубликат: същият проблем като друг отворен ред. Слейте ги. - Неподходящ тип: не би трябвало да бъде работна поръчка. Трябва да бъде в график за превантивна поддръжка (PM), заявка за части или заявка от експлоатацията. Прехвърлете го. - Неясен: нуждае се от обход по цеха преди класификация. Повечето от 30-дневната работа се извършва тук.
Двуметров екип за триаж, един ръководител на поддръжката, един представител на производството, може да обработи 300 реда за седмица, ако не затварят и самите работни поръчки. Устойте на желанието да смесвате триажа с изпълнението; изискват различно мислене.
Стъпка 3: Масово затваряне на призрачните и сливане на дубликатите Призрачните се затварят с код на причина „потвърдено постфактум, вече направено“. Дубликатите се сливат в най-стария ред. Редовете от неподходящ тип се насочват към правилната система (график PM за повтаряща се работа, система за заявки на части за елементи само за части).
В края на ден 10 регистърът трябва да е с 40, 60% по-малък от началния брой, преди да е направен какъвто и да е реален ремонт. Дни 11, 20: приоритизирайте оцелелите Стъпка 4: Присвоете реален приоритет на всеки останал ред Повечето приоритети в CMMS са неправилни.
Те са зададени от първоначалния докладващ, който има контекст само за тази една работна поръчка. Сега, когато регистърът е половината от първоначалния, ръководителят на поддръжката може да пренареди оцелелите помежду им: - P1, безопасност / регулаторно / спиране на производството, поправка през същата седмица.
- P2, значително влияние върху OEE, повтарящо се, в рамките на месеца. - P3, незначително / козметично / единично събитие, да влезе в регистъра за наличен капацитет. Чисто правило: ако заводът има 100 актива, P1 трябва да е под 10 реда.
Ако P1 има 40 реда, „P1“ вече не означава нищо и цялата система за приоритети е колабирала. Пренаредете, докато P1 отговаря на това правило. Стъпка 5: Свържете всеки ред с собственик Всеки останал ред получава именуван собственик, един човек, не отдел. Без това P1 работата стои, защото всички предполагат, че някой друг я има.
Това е втората по сила мярка в метода. Връзката между собствеността и трендовите метрики е разгледана в материала за manufacturing KPIs (https://www.fabrico.io/blog/maintenance-kpis-and-metrics-manufacturing-guide/).
Дни 21, 30: изпразнете P1 и заключете постигнатото Стъпка 6: Изпразнете P1 с един именуван изпълнител всеки ден През последните 10 дни всеки работен ден има един именуван техник отговорен за затварянето на две P1 поръчки. Не „екипът ще затвори“, а един човек, два конкретни ID-та на редове.
Това дава 20 затворени P1 за 10 дни, което обикновено покрива повечето от оцелелия стек P1. Стъпка 7: Въведете постоянни правила, които предотвратяват повторно разрастване Това е, което прави разчистването устойчиво. Три постоянни правила за заключване: - Критерий за затваряне за всеки тип: всеки тип работна поръчка има писмено определение за „свършено“.
Няма тип без такова. - Автоматично затваряне след верификация: когато техник маркира като завършено, супервайзорът верифицира в рамките на 24 часа и редът се затваря автоматично. Няма повече „в процес“ завинаги.
- Откриване на дубликати при отваряне: когато се отваря нова работна поръчка за актив, системата показва евентуални отворени редове за същия актив и пита докладващия дали да потвърди или слее. Връзката с root cause analysis (https://www.fabrico.io/blog/what-is-root-cause-analysis-guide/) идва естествено тук, защото дубликатите сочат към една и съща коренна причина.
Стъпка 8: Задайте целеви размер на регистъра и го наблюдавайте седмично За типичен среден завод с 100 актива здравословният регистър е 30, 60 отворени реда. По-голям от това означава, че търсенето превишава капацитета (или дубликатите отново се появяват). По-малък означава, че системата вече не улавя реалното търсене.
Наблюдавайте броя седмично; трендът е по-важен от абсолютния брой. Съчетайте броя на регистъра с графика за превантивна поддръжка (https://www.fabrico.io/blog/preventive-maintenance-schedule/), за да знае екипът какъв дял от усилията е реактивен спрямо планирания.
Как обикновено изглеждат числата Завод, който започва с 220 отворени работни поръчки, обикновено стига до: - 40 призрачни затворени (потвърдени постфактум) - 25 дубликата слети - 15 реда от неподходящ тип прехвърлени в графика на PM или заявки за части - 10 P1 реда изпразнени в дни 21
30 - ~130 P2/P3 реда останали като новия работен регистър „Реалният“ регистър се оказва много по-малък от броя отворени редове. Заводът не е добавил капацитет. Просто е спрял да си представя, че 220 реда са 220 отделни единици работа.
Как Fabrico пасва Горните стъпки за триаж са независими от инструмента, работят във всяка CMMS, включително електронна таблица.
Това, което се променя, когато CMMS е изградена върху обединена OEE+CMMS основа, е превенцията: правила за прагове на клъстери и свързване на OEE събития (разгледани в статията за work order management systems (https://www.fabrico.io/blog/work-order-management-systems/)) улавят повтарящите се причини, които създават дубликати първоначално. Fabrico (https://www.fabrico.io/) е изградена за този работен поток.
За да видите как изглежда разчистването спрямо вашите живи данни, запишете демо (https://www.fabrico.io/demo/). Често задавани въпроси Какво ако нашият регистър е над 500 реда? Увеличете екипа за триаж. Методът е същият, но фазата от ден 1 до 10 се нуждае от повече хора.
Регистър от 500 реда с двама триажиращи отнема ~3 седмици за триаж; с четирима влиза в 10 дни. Не позволявайте методът да се разтегне над 60+ дни, свежестта на контекста намалява. Наистина ли призрачните работни поръчки са най-голямата категория за изтриване?
Да, в заводи, които не са правили разчистване през последните 18+ месеца, призрачните обикновено са най-голямата единична категория за изтриване. Колкото по-дълъг е интервалът от последното разчистване, толкова по-голям е дялът на призраците. Заводите с тримесечен ритъм на разчистване го поддържат нисък.
А какво да кажем за отворените задачи от превантивната поддръжка (PM), броят им ли влизa в регистъра? Отворените PM задачи са отделна популация. Те имат свои срокове и собствен критерий за успех (процент завършване в срок). Смесването им с реактивния регистър замъглява картината и на двете. Дръжте ги отделно, дори ако са в същата CMMS.
Трябва ли да публикуваме броя на регистъра за по-широкия екип? Да, но внимателно. Числото може да падне драматично в първите 30 дни и да изглежда като чудо. После се стабилизира в диапазона 30, 60 и изглежда, че нищо не се случва. Съпоставяйте броя с тренда на редовете P1 поотделно, което е по-смисленият сигнал.
Коя е най-честата причина за връщане назад? Премълчаването на откриването на дубликати. Ако докладващият не бъде подканен да потвърди или слее при всяко ново отваряне, дубликатите се появяват отново в рамките на тримесечие и регистърът се надува пак. Правилото за откриване на дубликати е най-ниско по инженерни разходи и с най-голяма възвращаемост във времето.
Вход
Блог
