Доказателство за концепция (POC) за софтуер за OEE има една цел: да намали риска системата, която купувате, да не работи така, както доставчикът е обещал във вашата конкретна производствена среда.
Добре проектирано POC отговаря на трите въпроса, на които отговорите на RFP и демонстрациите не могат: Събира ли софтуерът данни точно от вашите конкретни машини и PLC? Изчислява ли OEE по начин, който съвпада с разбирането на вашия производствен екип за производителността? И могат ли операторите ви да го използват без интензивна постоянна поддръжка?
Най-честата грешка при POC е да се направи твърде широк. Производителите, които се опитват да пилотират софтуер за OEE на множество линии, множество смени и различни типове продукти в рамките на 30 дни, в крайна сметка получават неубедителни резултати, твърде много променливи, твърде много настройване и недостатъчно време да се достигне стабилно качество на данните.
Фокусиран POC върху 1, 3 производствени линии, обхващащ 2, 3 седмици стабилно производство след 1-седмичен период за настройка, дава по-надеждни доказателства от разпростиращ се пилот, който никога не достига стабилно състояние.
Определете обхвата на POC писмено преди да започне. Документът за обхват трябва да уточнява: кои линии са в обхвата кой метод за събиране на данни ще се използва (интеграция с PLC, дооборудване със сензори или ръчно резервно събиране на данни) какъв производствен обем и продуктова смес се очаква през периода на POC
кои ERP и CMMS интеграции ще бъдат активни по време на POC (ако има такива) и каква поддръжка от доставчика е обещана за периода на POC. Доставчик, който не се ангажира с писмен документ за обхвата преди започване на POC, вероятно ще пренапише обхвата след приключването му.
Измерването на POC трябва да обхваща четири измерения: точност на събирането на данни, надеждност на изчисляването на OEE, приемане от страна на операторите и производителност на системата. Точността на събирането на данни е най-важна: сравнете показанията на OEE платформата с вашите съществуващи източници на данни (броячи за производство, сменни журнали, SCADA система) за същите смени.
Разлика от повече от 2, 3% в броя на произведените единици или повече от 5 минути на смяна в продължителността на престоя подсказва проблем в конфигурацията на събирането на данни, който ще подкопае доверието в OEE данните след пълното внедряване.
Надеждността на изчисляването на OEE се оценява чрез сверяване на OEE резултатите на платформата с ръчни изчисления, използващи същите сурови данни. Изберете 5, 10 смени от целия POC период, извлечете суровите данни, изчислете OEE ръчно и сравнете с резултата на платформата.
Разликите трябва да могат да се обяснят с документирани избори в методологията на изчисляване (как се третира планираният престой, как се класифицират микропрестоите), необясними несъответствия сигнализират за проблем в логиката на изчисленията на платформата, който ще доведе до продължителни проблеми с доверието сред производствените мениджъри, които познават добре линиите си.
Измерването на приемането от страна на операторите по време на 30-дневен POC се фокусира върху спазването на категоризацията на престоите: какъв процент от събитията на престой бяха категоризирани от операторите (в сравнение с оставените като "некатегоризирани"), и колко време след събитията отне категоризирането?
Цел от над 80% категоризация в рамките на 2 часа от събитието е разумен ориентир за POC. Под тази стойност системата ще произвежда Парето анализ, доминиран от "некатегоризирани" престои, което обезсмисля основната цел на софтуера.
Ако процентите на категоризация са ниски по време на POC, диагностицирайте дали причината е сложността на операторския интерфейс, недостатъчното обучение или неправилният списък с причини за престой, и тествайте дали доставчикът може да отстрани основната причина през POC периода.
Решението "да/не" относно POC на OEE софтуер трябва да се базира на предварително дефинирани критерии, договорени преди старта на POC-а, а не на пост-хок оценка дали взаимоотношенията с доставчика изглеждат положителни.
Дефинирайте критериите за "да" като измерими прагове: точност на събирането на данни в рамките на ±3% от реалните стойности за над 90% от смените процент на категоризиране на престои от операторите над 75% поне един успешно завършен трансфер на данни за ERP интеграция (ако е в обхвата)
нулеви случаи на загуба на данни по време на нормално производство и наличност на системата (uptime) над 99%.
Решението "не" също трябва да бъде ясно формулирано. Ако точността на събирането на данни се проваля в повече от 20% от смените, или ако системата изисква повече от 2 часа седмично подкрепа от доставчика, за да поддържа стабилна работа, или ако операторите активно избягват използването на системата въпреки обучението
това са сигнали, че платформата има фундаментален проблем с пригодността към вашата среда, който едва ли ще бъде решен чрез по-дълго внедряване.
Между чисто "да" и категорично "не", повечето POC-ове дават резултат "да с условия", системата работи приемливо, но има конкретни проблеми, които трябва да бъдат решени преди пълно разгръщане. Документирайте тези условия изрично в заключителния доклад от POC-а: кои проблеми бяха идентифицирани, какво доставчикът се е ангажирал да направи по тях и до коя дата.
Прехвърлянето на тези условия в договорни ангажименти в договора за покупка превръща условното "да" в защитено решение, ако условията не бъдат изпълнени, имате основания за корективни мерки или за изход. Без тази документация, условните проблеми обикновено продължават след покупката, защото у доставчика изчезва спешността да ги разреши след подписването на договора.
Вход
Блог
