Ключови изводи
OEE пилотът има за цел да отговори на един въпрос: ще работи ли това тук? Много пилоти се провалят не защото софтуерът е лош, а защото никой не е дефинирал как изглежда успехът. Определете това предварително и пилотът ще ви даде ясен „да“ или „не“.
Решете предварително какво трябва да докаже пилотът: автоматичното улавяне на точни данни, откриването на загуби, които екипът не е виждал, или постигането на измеримо подобрение на линията. Запишете тези критерии за успех преди пускането в експлоатация, за да е резултатът факт, а не спор.
Изберете една линия, която представя реалните ви условия, идеално такава с реални загуби за откриване, а не най-добре или най-зле представящата се. Представителен пилот ще ви покаже какво ще осигури по-широкото внедряване.
Запишете настоящото представяне на линията преди пилота, за да можете да покажете промяната. Задайте ясен срок, достатъчно дълъг за улавяне на реални модели, но достатъчно кратък, за да запазите инерцията. Безкраен пилот се размива; ограничен такъв дава вердикт.
Пилотът ще успее или пропадне в зависимост от това дали операторите и супервайзорите се ангажират. Включете ги при настройката, обяснете за какво са данните и изяснете, че това е инструмент за откриване на загуби, а не за контрол на хората. Приемането е разликата между богати данни от пилота и екран, който се игнорира.
Завод провежда OEE пилот на една представителна линия, задава четириседмичен прозорец, определя базовата наличност и дефинира успеха като улавяне на микроспирания, които екипът в момента не може да види, и предприемане на действия по най-честото от тях. До втората седмица автоматичното улавяне разкрива повтарящо се кратко спиране, което никой не е регистрирал; отстраняването му повишава производителността на линията. Успехът беше очевиден, защото бе дефиниран в първия ден.
Пилотът е най-сигурният начин да докажете, че OEE в реално време ще се изплати, преди да поемете ангажимент за целия завод. Ясните критерии превръщат изпитанието в доказателство. Резервирайте демонстрация на Fabrico, за да определите обхвата на фокусиран OEE пилот на една от вашите линии.
Правилният дизайн на пилота за производствен софтуер решава дали разгръщането ще бъде успешно.
Достатъчно дълго, за да улови реалните производствени модели, обикновено няколко седмици, но с ясни граници, за да остане фокусиран. Безкраен пилот губи инерция и никога не дава вердикт.
Липса на дефинирани критерии за успех и слабо приемане от екипа. Ако никой не е съгласувал какво означава успехът, или екипът не се ангажира, дори добрите данни водят доникъде.
Пилотните внедрявания на софтуер за OEE без предварително определени критерии за успех почти винаги завършват с двусмислени изводи.
Доставчикът е доволен, защото нищо катастрофално не се е провалило; ИТ екипът е скептичен, защото интеграцията отне повече време от очакваното; ръководителят на производството е предпазливо положителен, защото данните изглеждат приблизително коректни; а директорът на завода не е сигурен дали числата оправдават покупката.
Без предварително споразумение как изглежда успехът преди старта на пилота, всеки заинтересован преценява пилота през призмата на собствените си притеснения, и обсъждането след пилота се превръща в дебат дали тези притеснения са били адекватно адресирани, вместо в обективна оценка дали критерии са били изпълнени.
Предварително определените критерии за успех променят дискусията след пилота от субективна в обективна. Когато екипът за оценка се съгласи преди пилота, че „успехът изисква точност на събиране на данни над 95% за поне 80% от наблюдаваните смени“, обсъждането след пилота е дали този праг е достигнат, а не дали точност от 93% е достатъчно добра.
Тази конкретика е неудобна за доставчиците, които предпочитат по-неясни критерии, което само по себе си е показателно: доставчиците, които се противопоставят на специфични критерии за успех, имат по-малко увереност в способността си да ги постигнат в сравнение с тези, които конструктивно участват в дефинирането на измерими прагове.
Процесът по дефиниране на критериите за успех също принуждава към организационно съгласуване преди старта на пилота. Различните заинтересовани страни имат различни представи за успех, ИТ иска съответствие със стандартите за сигурност; експлоатацията иска точност на данните; финансовият отдел иска доказателства за възвръщаемост на инвестицията (ROI); а директорът на завода иска приемане от страна на операторите.
Ясното изясняване на тези различни определения преди пилота и уеднаквяването им в общ документ с критерии гарантира, че пилотът ще генерира доказателства по всички измерения, важни за заинтересованите страни, а не само по тези, които ръководителят на екипа за оценка счита за най-важни.
Категория 1, Точност на събиране на данни: Определете приемливата разлика между показанията на платформата OEE и съществуващите ви източници на данни (броячи на производство, смянови дневници) за брой произведени единици, продължителност на престой и брой на отхвърлените изделия.
Разумен начален праг е ±3% за брой произведени единици и ±5 минути на смяна за продължителност на престой. Уточнете за колко смени трябва да е изпълнен този праг (например 85% от смените през пилотния период) и какво се счита за неуспех при събиране на данни, който изисква разследване.
Категория 2, Приемане от операторите: Определете минималния процент на категоризация на събитията с престой (процент от събитията с престой, категоризирани от операторите в рамките на определено време), който показва, че интерфейсът за оператори е функционален. Практически начален праг е ≥75% категоризации в рамките на 2 часа.
Уточнете и приемливия обем на обучение: ако операторите изискват повече от 4 часа първоначално обучение, за да използват системата правилно, това е сигнал за проблем с използваемостта, който следва да се документира като неизпълнение на критерия, дори ако нивата на категоризация са постигнати.
Категория 3, Надеждност на интеграцията: Ако интеграция с ERP или CMMS влиза в обхвата на пилота, определете необходимия процент на успешен пренос на данни. Минимално приемлив е 99% от потвържденията на производствените поръчки да се прехвърлят правилно в рамките на определеното SLA (например в рамките на 15 минути след края на смяната).
Уточнете как се откриват и докладват грешки при интеграцията и какъв е ангажиментът за време за реакция на доставчика при такива грешки.
Категория 4, Производителност на системата: Определете максимално приемливото забавяне, за да се появят производствените данни в таблото за OEE след реално събитие (максимум 2 минути е типично), както и минималната наличност на системата по време на планираните производствени часове (минимум 99.5%). Уточнете как се измерва престоят, от системата за мониторинг на доставчика или от независимо верифицирани времеви марки, за да се избегнат спорове относно изпълнението на критериите.
Категория 5, Удобство при използване на отчети и анализи: Определете конкретни отчети, които трябва да бъдат генерирани успешно по време на пилота без съдействието на доставчика, например 30‑дневно Парето на престоите по оборудване, седмично спрямо седмица тенденция на OEE по линия и сравнение на представянето по смени.
Ако екипът за оценка не може да генерира тези отчети самостоятелно до трета седмица от пилота, това показва проблем с използваемостта или с конфигурацията, който трябва да бъде разрешен преди пълно внедряване.
Категория 6, Доказателства за възвръщаемост (ROI): За пилоти с достатъчна продължителност определете какви подобрения в производствените показатели се очаква да бъдат видими в данните OEE в резултат на получената мониторингова видимост.
Този критерий е по‑труден за строго специфициране в 30‑дневен пилот (каузалната атрибуция е трудна), но дори качествените доказателства, конкретни подобрителни действия, предприети въз основа на прозренията от OEE, които не биха били взети без данните, могат да бъдат документирани и включени в препоръката за продължаване или прекратяване.
Процесът по одобряване (sign‑off) за решението go/no‑go на OEE пилот трябва да включва същите заинтересовани страни, които са определили критериите за успех, а не само ръководителя на екипа за оценка.
Насрочете срещата за преглед след пилота преди старта на пилота и изискайте от всеки заинтересован да представи писмена оценка на критериите във своята област (ИТ оценява критериите за сигурност и интеграция; операции оценяват точността на данните и приемането от операторите; финанси оценяват разходите и доказателствата за възвръщаемост).
Това предварително задължаване да се представят писмени оценки предотвратява присъствието на заинтересованите страни на прегледната среща без да са извършили оценъчната работа.
Дневният ред на пост‑пилотната среща трябва да обхваща: резултати от оценката на критериите (go/no‑go за всеки критерий и доказателствена база); отворени въпроси (критерии, които не са напълно изпълнени, с ангажименти от доставчика и срокове за разрешаване); оценка на представянето на доставчика (качество на внедряване, бързина на реакция и качество на поддръжката по време на пилота); и препоръка.
Препоръката трябва да бъде една от трите възможни: go (всички критерии изпълнени, продължава се към пълно внедряване); go with conditions (повечето критерии изпълнени, конкретни въпроси изискват договорно уреждане преди поемане на ангажимент за пълно внедряване); или no‑go (критични критерии провалени, необходима е смяна на доставчика или фундаментално преразглеждане на изискванията).
Документирайте пост‑пилотното решение и доказателствената база в писмен доклад с изводите от пилота, който се споделя със всички заинтересовани страни и се съхранява в документацията на проекта.
Тази документация защитава екипа за оценка, ако внедряването срещне проблеми по‑късно, тя демонстрира, че решението е взето въз основа на обективни критерии и документирани доказателства, а не на отношения с доставчика или непълна оценка.
Освен това дава на доставчика ясни указания за това какво трябва да се подобри преди или по време на пълното внедряване, което повишава вероятността пълното внедряване да бъде успешно.
Вход
Блог
