Повечето средно големи производствени предприятия използват между три и пет отделни софтуерни инструмента, за да управляват това, което би трябвало да бъде единна свързана функция за оперативна аналитична информация.
Инструмент за мониторинг на OEE, който проследява производствените показатели.
CMMS, която управлява поръчки за работа по поддръжка.
Вижте как Fabrico обединява OEE и поддръжката в една платформа.
Поискайте демоИнструмент за дигитален контрол, който обработва документация за съответствие.
Слой от електронна таблица, свързващ трите - защото никой от тях не общува помежду си директно.
Разходите за интеграция на този фрагментиран стек – разходи за лицензи, време за съгласуване на данни, дублиране на въвеждането на данни и времеви интервал между системите – постоянно струват повече от унифицираната платформа, която би го заменила.
Това ръководство е за производители, които вече са стигнали до заключението, че консолидацията има смисъл и се нуждаят от практическа рамка за осъществяването ѝ.
Важно е да се разбере как е изграден фрагментираният стек, преди да се планира как да се замени.
Почти никой умишлено не е избрал архитектура с три инструмента.
То еволюира.
Инструментът за обща ефективност на оборудването (OEE) се появи първи, защото един производствен мениджър се нуждаеше от видимост на линията и намери бърз и достъпен инструмент за мониторинг, който реши непосредствения проблем.
CMMS се класира на второ място, защото мениджърът по поддръжката се нуждаеше от структура на работните поръчки и намери платформа, която решаваше този непосредствен проблем, независимо от инструмента за OEE, който производственият екип вече използваше.
Инструментът за инспекция се класира на трето място, защото се появи изискване за качество или съответствие, а съществуващите инструменти не го удовлетвориха.
Всеки инструмент беше рационален отговор на специфична болезнена точка в определен момент.
Кумулативният резултат, три инструмента без вградена връзка, три лицензионни разходи, три взаимоотношения с доставчици и три среди за данни, които разказват три различни частични истории за едно и също производствено ниво, никога не е бил целта.
Това беше резултат от решаването на проблеми в последователност без единна архитектурна визия.
Осъзнаването на това е важно, защото означава, че консолидацията не е свързана с признаване, че предишните решения са били грешни.
Става въпрос за признаването, че сборът от индивидуално рационални решения е създал колективно ирационална архитектура – и коригирането ѝ с предимството на ретроспекцията.
Преди да оцените каквато и да е заместваща платформа, направете честен одит на това, колко всъщност струва текущият стек.
Този одит има четири компонента.
Избройте всички софтуерни инструменти, които се използват в момента за наблюдение на производствените показатели, управление на поддръжката, документиране на съответствието и всякаква свързана инфраструктура за отчитане.
Включете годишните разходи за лицензи, разходите на потребител и всички допълнителни модули.
Включете разходите за електронни таблици и инструменти за бизнес разузнаване, ако съществуват специални лицензи за отчетния слой, свързващ основните инструменти.
Повечето производители са изненадани от това колко голямо е това число, когато всички компоненти са изброени заедно, а не са оценени като отделни пера в отделни ведомствени бюджети.
Оценете годишните разходи за поддържане на връзките между инструментите в текущия стек.
Това включва времето, прекарано от ИТ отдела в поддръжка на API интеграции, процедури за експортиране и импортиране на данни и процеси на синхронизация между системите.
Това включва времето, прекарано от екипа по поддръжката за въвеждане на дублирани данни, въвеждане на една и съща информация за повреда както в инструмента OEE, така и в CMMS, тъй като нито една от системите не споделя автоматично данни с другата.
Това включва времето, прекарано от ръководството в изграждането на ръчни междусистемни отчети, тъй като никоя отделна система не предоставя консолидирания поглед, от който се нуждае ръководството.
За повечето средно големи производители, тези разходи за поддръжка на интеграцията – които рядко се появяват като отделен бюджет – са еквивалентни на 30% до 60% от комбинираните разходи за директен лиценз, когато са калкулирани напълно.
Това е най-трудният за количествено определяне компонент, но обикновено е и най-големият.
Разликата в действието е времето между откриването на събитие, свързано с производствените показатели, в инструмента за OEE и генерирането на структуриран отговор за поддръжка в CMMS.
В един фрагментиран стек тази празнина се запълва от човешка координация – ръководител забелязва предупреждение в инструмента OEE, решава, че то изисква реакция по поддръжката, съобщава това решение на екипа по поддръжката и изчаква създаването на работна поръчка в CMMS.
Този процес отнема между 15 минути и няколко часа, в зависимост от сериозността на сигнала и комуникационните практики на съоръжението.
Оценете разходите за липса на действия, като използвате тази формула:
Средна продължителност на прекъсването на действието в минути × Средна стойност на производството на минута × Брой производствени събития на месец, които би трябвало да задействат реакция по поддръжката.
За производител, който преживява 40 значителни производствени събития месечно със среден 30-минутен интервал в действие на производствена линия с цена от 300 долара на час:
40 × 30 минути × ($300 ÷ 60 минути) = $6 000 на месец възстановима производствена стойност, загубена само поради липсата на действия.
Фрагментираните стекове произвеждат фрагментирани данни.
Записите за производствените показатели на инструмента OEE и записите за поддръжка на CMMS не споделят идентификатори на активи, формати на времеви марки или рамки за категоризация на загубите – което означава, че междусистемният анализ изисква ръчно съгласуване.
Записите от инспекциите на инструмента за документиране на съответствието не са свързани с работните поръчки за поддръжка на CMMS, което означава, че демонстрирането на връзката между констатацията от инспекцията и нейните коригиращи действия изисква ръчно сглобяване.
Оценете разходите за качество на данните като седмичните часове, които вашият екип прекарва в изграждане на междусистемни отчети и пакети с документация за съответствие, умножени по пълните почасови разходи за хората, извършващи тази работа.
За мениджър по поддръжката, който прекарва 4 часа седмично в ръчно отчитане между системите при такса от 45 долара на час при пълно натоварване, годишните разходи за качество на данните са 9 360 долара – за един човек, за една повтаряща се задача.
| Компонент на разходите | Вашата оценка |
|---|---|
| Директни разходи за лиценз (всички инструменти взети заедно) | $ |
| Поддръжка на интеграцията (ИТ + ръчно въвеждане на данни) | $ |
| Цена на пропуските в действието (загуба на производствена стойност поради забавяне на координацията) | $ |
| Разходи за качество на данните (ръчно отчитане и сглобяване на съответствие) | $ |
| Обща годишна цена на стека | $ |
Тази обща сума – не индивидуалните лицензионни такси – е числото, което трябва да се сравни с общата цена на притежание на унифицирана платформа.
Сравнението почти винаги води до различно заключение от сравнението само на лицензионната такса.
Не всеки инструмент в текущия стек трябва да бъде заменен от платформата за консолидация.
Някои инструменти решават проблеми, за които една унифицирана производствена платформа наистина не е предназначена – печатни MIS системи, ERP финансови модули, специализирани платформи за управление на калибрирането.
Определянето на това, което платформата за консолидация трябва да предоставя – и какво остава в стека, защото изпълнява функция извън обхвата на консолидацията – предотвратява често срещаната грешка да се опитва да се консолидира всичко и да се стигне до платформа, която не прави нищо особено добре.
Обхватът на консолидацията за повечето средно големи производители обхваща четири функции:
Мониторинг на производствените показатели в реално време, проследяване на OEE в рамките на системата „Шест големи загуби“, свързано със сигнали от машината, а не зависимо от наблюдението на оператора.
Управление на изпълнението на поддръжката, работни поръчки, планиране на профилактика, управление на резервни части и проследяване на съответствието, предоставяни чрез мобилна среда за изпълнение на място.
Документация за съответствие, автоматизирано записване на всяко действие по поддръжката с указание на потребителя, времеви печат, версия на стандартната оперативна процедура (SOP) и попълване на контролен списък, достатъчна за задоволяване на изискванията на ISO 9001, IATF 16949, GMP или одит за безопасност на храните без ръчно сглобяване.
Интеграция на планирането на производството и поддръжката, среда за планиране, където ограниченията за поддръжка са видими заедно с изискванията за производствени поръчки, така че конфликтите се разрешават, преди производството да ги открие.
Какво обикновено остава извън обхвата на консолидацията:
Финансови модули на ERP, снабдяване, задължения към доставчици, финансово отчитане.
Специализирани системи за управление на качеството за управление на CAPA и контрол на документите отвъд съответствието с изискванията за поддръжка.
Специално разработени инструменти за управление на прекъсвания и спирания за големи планирани програми за прекъсвания.
Специализирани системи за управление на калибрирането за операции с голям парк от калибрирани инструменти.
Изричното дефиниране на този обхват – преди оценката на която и да е платформа – предотвратява разширяването на обхвата по време на оценката и предотвратява разочарованието, когато консолидираната платформа не замести нещо, което никога не е била предназначена да замести.
Критериите за оценка на консолидационна платформа са различни от критериите за подмяна на точково решение.
Точковото решение, заместващо инструмента, трябва да прави едно нещо по-добро от инструмента, който замества.
Една платформа за консолидация трябва да изпълнява четири задачи адекватно – и в идеалния случай да ги изпълнява по-добре свързани помежду си, отколкото четирите отделни инструмента, постигнати поотделно.
Оценката на консолидацията задава различен въпрос от оценката на точковото решение.
Не „кой инструмент за OEE е най-добър?“ или „коя CMMS е най-добра?“
Но „коя платформа извършва достатъчно добре мониторинга на OEE, изпълнението на CMMS, документирането за съответствие и интеграцията на графика, така че вградената връзка между тях да осигурява по-голяма оперативна стойност от четири отделни най-добри инструмента?“
Отговорът на този въпрос зависи от две неща.
Първо: Каква част от стойността в текущия стек идва от дълбочината на отделните инструменти като най-добри в класа си спрямо връзката между тях?
Ако основната стойност на настоящия инструмент за обща ефективност на оборудването (OEE) е дълбочината на анализа на шпинделите, специфични за CNC машини – и тази дълбочина е от решаващо значение за програмата за подобряване на операцията – платформата за консолидация трябва да съответства на тази дълбочина или на възможностите за консолидация за свързаност.
Ако основната стойност на настоящия инструмент за OEE е основната видимост на линията, която предоставя всяка платформа, свързана с машина, платформата за консолидация трябва да съответства на достъпна базова линия, а не на специализирана дълбочина - и стойността на вградената свързаност към CMMS почти сигурно е по-голяма от предимството на дълбочината на самостоятелния инструмент за OEE.
Второ: Какво е реалистичното качество на интеграция на текущия стек спрямо качеството на вградената връзка на консолидационната платформа?
API интеграциите между отделни инструменти никога не са толкова безпроблемни, колкото нативната интеграция в рамките на една платформа.
Закъснението на данните, сривовете при синхронизация и разходите за поддръжка на интеграцията са структурни реалности на фрагментирания стек, а не грешки, които трябва да бъдат поправени.
Оценете вградената свързаност на платформата за консолидация спрямо реалистичното качество на интеграция на текущия стек, а не спрямо теоретична идеална интеграция, която не съществува на практика.
След като бъде избрана платформа за консолидация, миграцията трябва да следва поетапна последователност, която минимизира оперативните прекъсвания, като същевременно максимизира ранното предоставяне на стойност.
Фаза 1: Пилотен обект, активи с най-висок приоритет (Месец 1)
Изберете един обект – в идеалния случай този с най-високи разходи за непланирани престои или най-острия проблем с липсата на действия.
В рамките на този обект свържете 5-10-те производствени актива с най-висока критичност към новата платформа.
Старите инструменти да се изпълняват паралелно за този сайт в продължение на 30 дни, така че по време на прехода да не се прекъсват никакви дейности по поддръжка.
Измерете три показателя в края на Фаза 1: надеждност на свързаността на машината, процент на внедряване от техниците и поне едно потвърдено задействане на задействане на PM, базирано на състояние, от машинен сигнал.
Ако и трите са потвърдени, започва Фаза 2. Ако не, нерешените въпроси се решават преди разширяване на обхвата.
Фаза 2: Пълно покритие на обекта (месеци 2-4)
Разширете свързаността на машините към всички производствени активи на пилотния обект, включително наследено оборудване чрез IoT шлюз и ръчни станции чрез компютърно зрение, където е приложимо.
Мигрирайте графиците за профилактика от текущата CMMS, валидирани спрямо действителната история на повреди, вместо да мигрирате безкритично от календарни интервали.
Конфигурирайте работните процеси за документиране на съответствие, за да отговаряте на специфичните рамки за одит, приложими за съоръжението.
Деактивирайте стария инструмент за OEE, CMMS и инструмента за инспекция за този обект, след като новата платформа бъде потвърдена като работеща.
Фаза 3: Допълнителни обекти (от 4-ти месец нататък)
Всеки допълнителен обект следва същата последователност като пилотния проект, но по-бърз, тъй като методологията за свързване, подходът за валидиране на графика за профилактично управление и конфигурацията за съответствие вече са установени от Фаза 1 и 2.
Времето за внедряване на обект обикновено намалява с всеки следващ обект, тъй като екипът по внедряване все повече се запознава с методологията.
Определете показателите за успех преди началото на консолидацията, а не след като резултатите са известни.
Показателите, които най-пряко отразяват консолидационната стойност, са:
Намаляване на пропастта в действията, средното време между събитие, свързано с производствената ефективност, и структурирана реакция по поддръжката. Измерете това преди и след консолидацията. Значителното намаление потвърждава, че вградената свързаност предоставя обещаната стойност.
Време за междусистемно отчитане, седмичните часове, прекарани преди това в изграждане на ръчни междусистемни отчети. След консолидиране това време би трябвало да намалее до почти нула за отчетите, генерирани от консолидираната платформа.
Време за сглобяване на документацията за съответствие, часовете, прекарани в подготовка на записи за поддръжка за одити. След консолидирането, генерирането на отчети при поискване трябва да замени ръчното сглобяване.
Процент на внедряване от техници, процентът на техниците по поддръжка, които активно използват мобилното приложение в рамките на 30 дни след пускането му в експлоатация. Под 70% показва проблем с внедряването, който трябва да бъде решен, преди разширяването му към допълнителни обекти.
Намаляване на разходите за лицензи и интеграция, разликата в преките разходи между общите годишни разходи на фрагментирания стек и общите годишни разходи на консолидираната платформа.
Използвайте този контролен списък, за да потвърдите, че решението за консолидация е готово за изпълнение.
Одитът е завършен: Общата цена на стека – лицензи, поддръжка на интеграцията, пропуски в действията, качество на данните – е изчислена и сравнена с общата цена на притежание на консолидираната платформа.
Определен обхват: Съгласувани са четирите функции, които платформата за консолидация трябва да изпълнява. Инструментите, които остават извън обхвата на консолидацията, са идентифицирани.
Платформа, оценена спрямо критериите за консолидация: Оценката попита дали вградената свързаност между OEE, CMMS и функциите за съответствие осигурява по-голяма стойност от текущия фрагментиран стек, а не само дали някоя отделна функция съответства на текущото точково решение.
Дефиниране на пилотен обект и показатели за успех: Пилотният обект е идентифициран. Критериите за пускане в експлоатация – надеждност на свързаност, степен на приемане, потвърждение на задействане въз основа на условия – се определят преди началото на внедряването.
Съществува план за извеждане от експлоатация на остарели инструменти: Последователността и времето за извеждане от експлоатация на всеки остарял инструмент, включително сроковете за предизвестие на договора и изискванията за експортиране на данни, се документират преди началото на проекта за консолидация.
Колко време отнема пълната консолидация на един производствен обект?
30-дневен пилотен проект за първоначално пускане в експлоатация и 3-4 месеца за пълно внедряване на един обект, включително свързване на машините за целия парк от активи, извеждане от експлоатация на наследени инструменти и конфигуриране за съответствие.
Какво се случва с историческите ни данни от наследените инструменти?
Наистина полезните исторически данни – йерархии на активите, графици за планиране на проекта, висококачествени записи на работни поръчки – мигрират към новата платформа по време на фазата на конфигуриране.
Нискокачествените исторически записи, минимално жизнеспособни записи за съответствие без аналитична стойност, обикновено се изключват след одит на качеството на данните.
Можем ли да консолидираме постепенно, а не наведнъж?
Да. Поетапният подход в това ръководство е умишлено разработен за постепенна консолидация, първо пилотен обект, след това пълен обект, а след това допълнителни обекти последователно.
Опитът за едновременна консолидация на всички обекти увеличава риска, без да ускорява значително предоставянето на стойност.
Ами ако един от нашите стари инструменти има възможности, на които платформата за консолидация не отговаря напълно?
Това е най-важният въпрос за оценка на консолидацията.
Ако разликата в капацитета е във функция, която е от основно значение за обхвата на консолидацията, дълбочина на мониторинг на OEE, йерархия на управление на активите в CMMS, пътека за одит на съответствието, разликата трябва да бъде отстранена, преди да се продължи с консолидацията.
Ако разликата в капацитета е във функция извън обхвата на консолидацията, специализирано управление на калибрирането, дълбочина на планиране на обратния цикъл, този инструмент може законно да остане в стека, наред с консолидираната платформа.
Ако текущият ви одит на стека доведе до общи разходи, които са значително по-високи от очакваните – и оценката на платформата за консолидация потвърди, че вградената свързаност осигурява по-голяма стойност от текущата ви архитектура за интеграция – най-полезната следваща стъпка е оценка на осъществимостта на свързаността на активите на вашия пилотен сайт. Тази оценка определя дали е постижима свързаност на машините, преди да се ангажира каквато и да е пълна инвестиция.
Вижте OEE & CMMS на живо за 15 минути.
Заявете демо
Вход
Блог
