Основни изводи
Кратък отговор: Стандартизирането на поддръжката в множество обекти означава да се направи начинът, по който всеки завод създава работни поръчки, именува активи, кодира престои и измерва представянето, достатъчно консистентен, за да може да се сравнява и обобщава, като в същото време се позволява на всеки обект да изпълнява локално.
Практическият път е обща йерархия на активите, споделени работни потоци и кодове за причини, стандартизирани работни инструкции и сравними OEE и KPI за поддръжка, идеално на една платформа с конфигурация на ниво обект, вместо различен инструмент за всеки завод.
Целта не е твърда унификация, а сравнимост: възможността да се правят бенчмаркове между обекти, да се споделя това, което работи, и да се управлява мрежата като едно цяло. Това ръководство обяснява как да се стигне до там.
При производители с множество заводи поддръжката обикновено расте от обект до обект. Всеки завод възприема свои собствени инструменти, начин на именуване на активите, категории престой и собствени навици, често като смес от локален CMMS и електронни таблици.
Резултатът е, че всеки обект е остров: не можете да сравните представянето на поддръжката на един завод с друго, не можете да получите обобщен поглед за цялата мрежа и практика, която работи прекрасно на един обект, никога не се разпространява, защото никой не може да я види.
Когато ръководството пита „кои обекти имат затруднения и защо?“ или „подобрява ли се поддръжката ни в цялата мрежа?“, честният отговор често е, че данните не са достатъчно съвместими, за да се каже.
Тази фрагментация е скъпа: скрива ниската ефективност, пречи на бенчмаркинга, блокира споделянето на добри практики и прави почти невъзможно последователното изпълнение на инициативи на ниво мрежа — от нов стандарт за превантивна поддръжка до фокус върху OEE.
Стандартизирането на поддръжката между обектите е работата да превърнете колекция от острови в сравнима, управляемa мрежа.
Важно е да сме точни за целта, защото „стандартизирай“ често се тълкува като „направи всеки обект идентичен.“ Това не е нито постижимо, нито желателно — заводите се различават по оборудване, продукти, мащаб и местни ограничения.
Истинската цел е сравнимост: да се направят основните данни и процеси достатъчно консистентни, за да можете да сравнявате обектите, да обобщавате поглед върху мрежата и да пренасяте практики между заводите, като все пак се позволява локалното изпълнение да се различава там, където трябва.
Конкретно, стандартизацията означава общ начин за структуриране на активите, споделен набор от кодове за престой и причини за повреди, последователни работни потоци и статуси за работни поръчки, стандартизирани работни инструкции за общи задачи и сравними KPI (поддръжка и OEE), изчислявани по един и същ начин навсякъде.
Това не означава налагане на идентични графици, щатно разписание или локални процедури на заводи, които по същество се различават.
Принципът е да се стандартизират методът и метриките, като се остави гъвкавост в локалното изпълнение, така че една работна поръчка или стойност OEE да означава едно и също навсякъде, въпреки че ежедневната реалност на всеки обект е своя.
Стандартизацията почива на три основи, които трябва да са последователни между обектите.
Обща йерархия на активите: всеки завод структурира и именува оборудването по един и същ начин (обект, зона, линия, машина, компонент), така че типът актив да означава едно и също навсякъде и данните да могат да се агрегира. Без това нищо друго не се подрежда.
Последователни кодове за причини: споделена таксономия на причините за престой и повреди, така че когато един обект запише причина и друг запише „същата“ причина, те действително да са сравними; това позволява да се бенчмаркват типовете загуби в мрежата.
Споделени работни потоци за поръчки: един и същ жизнен цикъл и статуси за начина, по който работата се заявява, приоритизира, възлага, изпълнява и затваря, така че работната поръчка да е един и същ обект във всеки завод.
Тези три — йерархията на активите, кодовете за причини и работният поток за поръчки — са гръбнакът на стандартизацията за множество обекти. Съгласувате ли ги, останалото (KPI, бенчмаркинг, споделяне на добри практики) става възможно; оставите ли ги фрагментирани, всяко по-високо ниво сравнение стъпва на пясък.
Установяването им обикновено е най-трудната и най-ценната част от работата, защото изисква съгласие между обекти, които години наред са правили нещата по свой начин.
Отгоре на основите от данни, стандартизирайте метода.
Работни инструкции за общи, повтарящи се задачи трябва да са последователни между обектите, така че конкретна превантивна поддръжка или ремонт да се изпълнява по един и същ правилен начин навсякъде, независимо кой завод или техник го прави — това е многообектното приложение на standard work, и зависи от разликата между работна поръчка и работна инструкция: работната поръчка маршрутизира задачата, стандартизираната работна инструкция гарантира, че е изпълнена правилно.
KPI трябва да се дефинират и изчисляват идентично навсякъде: метриките за поддръжка и OEE, изчислени по един и същ начин, с едни и същи дефиниции за планирано време, престой и годна продукция, така че число от един завод да е директно сравнимо с друго.
Ако обектите изчисляват OEE по различен начин, сравнението в мрежата е безсмислено. Стандартизацията на работните инструкции повишава и изравнява качеството на изпълнение; стандартизацията на KPI прави представянето сравнимо.
Заедно те позволяват на мрежата да се учи сама: да идентифицира кои обекти изпълняват дадена задача най-добре и да разпространява този метод, и кои обекти действително превъзхождат по метриките и защо.
Печалбата от стандартизацията са сравнимите метрики, затова си струва това да се третира като самостоятелна цел.
Когато всеки обект улавя престой със същите кодове за причини срещу обща йерархия на активите и изчислява OEE и KPI за поддръжка по един и същ начин, най-накрая можете да правите нещата, които управлението на множество обекти трябва да позволява: да класирате обекти и линии по представяне, да видите къде са най-големите загуби в мрежата, да бенчмарквате заводи едни спрямо други справедливо и да получите истински корпоративен поглед.
Можете да забележите, че наличността на един обект дърпа назад мрежата и да разкриете защо; можете да видите, че вид загуба доминира във всички заводи и да стартирате координиран ремонт; можете да идентифицирате най-добре представящия се обект за даден процес и да изследвате какво прави различно.
Нищо от това не е възможно, когато всеки завод измерва по различен начин. Сравнимите метрики също държат стандартизацията честна: те показват дали стандартните процеси действително се следват и дали работят.
Дисциплината да дефинирате метриките веднъж централно и да ги прилагате навсякъде е това, което превръща набора от отделни заводи в мрежа, която всъщност можете да управлявате и подобрявате като цяло.
Стандартизацията е много по-лесна на една платформа с конфигурация на ниво обект, отколкото чрез мозайка от различни локални инструменти.
Ако всеки завод използва собствен CMMS, налагането на обща йерархия на активите, споделени кодове за причини, последователни работни потоци и идентични дефиниции на KPI означава постоянна ръчна сверка и интеграция, и има склонност отново да се раздалечава с времето.
Една обща платформа, използвана във всички обекти, с възможност за конфигуриране на локални специфики, вгражда стандарта по дизайн: моделът на активите, кодовете за причини, работните потоци и изчисленията на KPI се дефинират веднъж и се прилагат навсякъде, докато всеки обект може да адаптира графици, щат и местни процедури в рамките на тази структура.
Това е практическият механизъм, който прави стандартизацията в множество обекти устойчива, а не еднократно почистване, което постепенно ерозира. Също така доставя автоматично обобщен, в реално време поглед върху мрежата, защото всички данни вече живеят в една последователна система.
Изборът не е непременно „платформа или нищо“ — интеграция на съществуващи инструменти е възможна — но за повечето производители, които преследват истинска крос-обектна консистентност, обща платформа с локална конфигурация е по-малко усилие и по-устойчив път от опита да се хармонизира набор от независими системи.
Fabrico е подходящ за стандартизация в множество обекти, защото поставя поддръжката и OEE на една платформа с последователен модел на активите, кодове за причини и работни потоци за поръчки, които се прилагат във всички обекти, като същевременно позволява на всеки завод да конфигурира своите локални специфики.
Защото всеки обект улавя престой и качество по един и същ начин срещу жив OEE, метриките са сравними по конструкция, така че можете да бенчмарквате заводи, да обобщавате мрежов изглед и да разпространявате успешните практики, вместо да сверявате мозайка от локални инструменти.
Резервирайте демонстрация, за да видите как изглежда стандартизирана поддръжка и сравним OEE в множество обекти, или сравнете опциите в нашия преглед най-добър CMMS софтуер.
Означава да се направят основните процеси и данни — йерархия на активите, кодове за причини, работни потоци за поръчки, работни инструкции и дефиниции на KPI — достатъчно консистентни между заводите, за да могат да се сравняват и обобщават, като все пак се позволява локалното изпълнение да се различава. Целта е сравнимост, не да се прави всеки обект идентичен.
Обща йерархия на активите (така че оборудването да е структурирано и именувано еднакво), последователни кодове за престой и повреди (така че причините да са сравними) и споделени работни потоци за поръчки (така че работната поръчка да означава едно и също навсякъде). Тези три са гръбнакът, който прави възможни сравними KPI и бенчмаркинг.
Не. Заводите се различават по оборудване, продукти и мащаб, затова налагането на идентични графици и процедури не е постижимо и не е разумно. Стандартизирайте метода (работни инструкции, процеси) и метриките (KPI, изчислени еднакво), но оставете гъвкавост в локалното изпълнение. Целта е сравнимост, не униформност.
Обикновено да. Една платформа с конфигурация на ниво обект вгради общия модел на активите, кодовете за причини, работните потоци и дефинициите на KPI по дизайн и предотвратява тяхното разминаване, докато все пак позволява на всеки обект да се адаптира локално. Хармонизирането на мозайка от различни локални инструменти изисква постоянна ръчна сверка и има склонност отново да се фрагментира.
Дефинирайте OEE и неговите входни данни — планирано време за производство, престой, производителност и годна продукция — идентично във всички обекти и улавяйте престой със същите кодове за причини срещу обща йерархия на активите. Когато всеки завод изчислява OEE по един и същ начин, числата са директно сравними и можете да бенчмарквате и да обобщавате истински мрежов изглед.
Вход
Блог
