Ключови изводи
Вижте видовете работни поръчки, които тези предупреждения трябва да генерират.
В типичен завод системата за OEE наблюдава линията, а CMMS наблюдава актива. И двете виждат "престой", но всяка вижда различна версия на него. OEE страната улавя всяко спиране над определен праг. Страната на поддръжката улавя само тези, които са станали работни поръчки.
Разликата между тези две числа, обикновено 20% до 40% от общото време на престой, е мястото, където живеят малките повтарящи се загуби. Именно в тези малки загуби се крие повечето от постижимото подобрение.
Причината за разликата не е, че един от екипите върши неправилна работа. Причината е, че двете системи нямат общо определение за "това спиране изисква работна поръчка". Решава операторът, решава ръководителят, понякога никой не решава, и правилата се отдалечават линия по линия. Оперативният модел за поддръжка е наборът от явни правила, които превръщат всяко OEE събитие в двоичен резултат: отваря се работна поръчка или не.
Система за OEE без чиста таксономия на класовете загуби е просто агрегиращ таймер. Оперативният модел започва с групиране на всяко спиране в стабилен набор от класове, обикновено седем до десет. Често срещани: смяна (changeover), микропауза (micro-stop), дребна механична повреда, електрическа/сензорна повреда, липса на материал, бракуване поради качество, планирано превишение, иницирано от оператор.
Точният списък е по-малко важен от това да се използва същият списък навсякъде, на всяка смяна, на всяка линия. Материалът за производствените KPI разглежда семействата от KPI, в които тази таксономия се вписва.
Всеки клас се нуждае от правило: при каква продължителност или честота това събитие става работна поръчка? Прагът почти винаги е неверен в първия ден и се настройва във втората до шестата седмица. Важното е, че правилото съществува и е видимо. Примери за типични начални прагове:
Правилата за клъстерни прагове ("3 пъти в 8 часа") обикновено улавят малките повтарящи се загуби, които единичните прагове пропускат. Те са най-високоефективният тип правило за добавяне.
Всеки клас загуба има един назначен собственик, а не отдел. Дребните механични и електрически повреди отиват при мениджъра на поддръжката. Смяната и инициативите от оператора отиват при мениджъра на производство. Липсата на материал отива при планиращия. Бракуванията поради качество отиват при мениджъра по качеството. Собственикът не непременно извършва ремонта, но той или тя носи отговорност за тенденцията и прага. Когато един клас надвиши прага, собственикът реагира пръв.
Най-важното и най-често пропусканото правило. Когато OEE събитие автоматично отвори работна поръчка, две неща трябва да се случат в една и съща минута: техникът по поддръжката да вижда работната поръчка на мобилното си устройство и OEE записа да бъде свързан с работната поръчка, така че затварянето да се синхронизира обратно.
Без тази двупосочна връзка оперативният модел в рамките на тримесечие деградира до "OEE създава шум, CMMS го игнорира". CMMS, пригодена за полева употреба на телефона на техника, е това, което прави възможно това. Статията за системите за управление на работни поръчки разглежда по-задълбочено подвижните части.
Тъй като клъстерните прагове улавят един и същ повред, появяващ се три пъти преди някой да го забележи, малките повтарящи се загуби, които в момента са невидими, започват да се появяват в списъка със задачи на поддръжката с реален път за отстраняване.
Повечето заводи установяват, че само тази категория често представлява голям дял, често 15, 25%, от непланирания престой, след като бъде разкрита. Вижте по-задълбоченото третиране в нашата статия за анализ на основните причини в производството .
Когато всяко релевантно OEE събитие се превръща в работна поръчка, CMMS най-накрая вижда пълната популация на повредите. MTBF и MTTR започват да отразяват реалността вместо подмножество, което операторите или ръководителите са решили да ескалират. Последващият ефект е, че графиците за превантивна поддръжка могат да се настройват спрямо реални данни за повреди, вместо да се базират само на препоръки от доставчици.
Тъй като OEE събитието и работната поръчка споделят идентификатор, мениджърът на производство и мениджърът на поддръжката гледат един и същ ред. Сутрешната среща преминава от "чие число е вярно" към "кой клас загуба се е променил през последната седмица". Тази една промяна е оперативният отключващ елемент, който повечето средномащабни заводи търсят, когато закупуват OEE система, и почти никога не идва само от OEE софтуера.
Честа грешка е пускането на 30 правила за задействане при стартиране. Наполовина са грешни, всички създават шум, екипът по поддръжката деактивира интеграцията през трета седмица. Започнете с пет или шест правила. Добавяйте по едно седмично в зависимост от това какво се пропуска.
Ако работната поръчка се затвори, но OEE събитието остане "отворено" в регистъра на загубите, OEE числата и CMMS числата отново се раздалечават, понякога в рамките на седмици. Затварянето трябва да тече в двете посоки. Тук много сглобени OEE+CMMS стекове се провалят на практика.
Ако клас задейства работна поръчка, но няма назначен собственик, който да наблюдава тенденцията, работната поръчка се изпълнява, загубата се повтаря и нищо не се променя. Назначеният собственик е това, което превръща обема в подобрение.
Посоченият оперативен модел може да бъде имплементиран върху всяка добре инструментирана стек, но практическата причина, поради която средномащабните заводи се затрудняват да го реализират, е, че OEE инструмент и отделен CMMS рядко споделят чиста връзка между събитие и работна поръчка.
Fabrico е създаден около точно тази точка за предаване: всяко OEE събитие живее в същата база данни като работните поръчки, йерархията на активите и таксономията на загубите, така че правилата за задействане и пътищата за затваряне съществуват по подразбиране, а не като персонализирана интеграция.
Ако искате да видите как единен модел изглежда спрямо данните от вашата линия, запазете демо и ние ще го разгледаме заедно.
Не, но проблемът с пътя за затваряне е труден за решаване чисто при двe отделни системи. Заводите със разделени стекове обикновено се нуждаят от междинен слой или ръчна стъпка за сверяване, която ерозира в рамките на тримесечие. Единната платформа премахва този риск.
С пет или шест. Изкушението е да се дефинират всички правила в първия ден; реалността е, че повечето правила се нуждаят от 4, 6 седмици реални данни, преди прагът да е правилен. Малък начален набор, настроен през първото тримесечие, е по-добър от пълен набор, пуснат „студен“.
Оперативно, началникът на завода. Мениджърът на поддръжката и мениджърът на производството всеки притежават класове. Без единствен собственик на ниво завод моделът се разпада: праговете се отклоняват, назначените собственици се въртят без предаване и моделът деградира.
Много малко в началото. Операторът все още регистрира спиранията по същия начин. Промяната е в това, че системата сега решава дали всяко спиране да стане работна поръчка, така че операторът не трябва да взема това решение смяна след смяна. С течение на времето операторът вижда по-малко повтарящи се малки загуби, защото правилата за задействане ги хващат по-рано.
Две числа: дялът от непланирания престой, който има свързана работна поръчка (цел: над 80% в рамките на 90 дни) и подвижният брой работни поръчки, генерирани от правила за клъстерни прагове (трябва да остане ненулев; ако спадне до нула, правилата вече не улавят нищо ново).
Вход
Блог
