Демонстрациите на OEE софтуер са репетирани преживявания. Доставчиците представят платформата си в най-добрата ѝ светлина, с предварително заредени чисти данни, идеални производствени сценарии и демонстрационни среди, в които всяка функция работи гладко.
Това, което не показват, е как системата се справя със заплетени реални условия: операторът, който забравя да затвори събитие за престой, PLC, който изпраща двусмислени сигнали за състояние, производствена серия, която обхваща смяна, или отчет, който изисква комбиниране на данни от три различни линии с различни продуктови структури.
Разликата между представянето в демонстрация и в реалния свят е най-честата причина за съжаление у купувачите на OEE софтуер. Производителите, които купуват въз основа на полираните демонстрации, без да тестват гранични случаи, често откриват след внедряване, че системата се справя с техните конкретни производствени сценарии по различен начин от това, което демонстрацията подсказваше.
Начинът да се преодолее тази пропаст е да представите собствените си сценарии по време на демонстрациите, като изискате от доставчиците да покажат как системата им се справя с конкретните гранични случаи и работни потоци, които съществуват във вашето предприятие, а не с идеалните случаи, за които е изградена тяхната демонстрационна среда.
Структурирането на оценката на демонстрациите около фиксиран контролен списък със сценарии прави сравняването на доставчиците по-надеждно.
Ако всеки доставчик демонстрира едни и същи 25 сценария, можете да сравнявате подходите им едно до друго, вместо да сравнявате функцията „управление на престои“ на един доставчик с функцията „анализ на загуби“ на друг доставчик, демонстрирана с различни данни и различни работни процеси.
Контролният списък налага последователност при сравненията, която иначе би изисквала опитни оценители да поддържат ръчно през множество сесии.
Сценарии за събиране на данни: (1) Покажете как промяната на състоянието на машина се улавя без намеса на оператор, демонстрирайте в реално време потока от PLC сигнал към OEE състоянието. (2) Покажете какво се случва, когато PLC сигналът е двусмислен или датчикът се прекъсне за кратко, как системата се справя с пропуски в данните?
(3) Демонстрирайте оператор, който добавя причина за престой 2 часа след събитието, възможна ли е ретроактивна категоризация и има ли одитен запис? (4) Покажете производствен цикъл, който преминава през полунощ, как системата обработва границите между смени? (5) Демонстрирайте смяна на продукт, която отнема 90 минути, проследява ли се смяната отделно от престой поради повреда?
Сценарии за изчисляване на OEE: (6) Покажете OEE за линия, произвеждаща два продукта с различни времена на цикъла в една и съща смяна, как се управляват целите за отделен продукт?
(7) Покажете как планираната поддръжка по време на производствени часове влияе на Наличността (Availability), изключва ли се тя от изчислението на OEE или се показва като планиран престой? (8) Демонстрирайте изчисляването на показателя за качество, откъде идват данните за брак и как се обработва преработката (rework) отделно от отпадъците (scrap)?
(9) Покажете какво се случва, ако OEE резултатът за смяна е 0%, системата обработва ли краените случаи без грешки? (10) Демонстрирайте агрегиране на OEE за три линии с различни графици на смени, как се изчислява многолинейното OEE?
Сценарии за отчитане и използваемост: (11) Покажете Парето на причините за престой за последните 30 дни, може ли да се филтрира по смяна, продукт и категория оборудване? (12) Демонстрирайте създаването на персонализиран отчет, колко време отнема да се създаде нов отчет от нулата без помощта на доставчик?
(13) Покажете мобилното приложение на реално устройство в помещението, нативно приложение ли е или мобилен уеб изглед? (14) Демонстрирайте задействане и получаване на аларма от супервайзор, каква е реалната латентност? (15) Покажете масов експорт на данни за 12 месеца престой, колко време отнема и в какъв формат се получава?
Сценарии за интеграция и администриране: (16) Покажете живо демо на OEE системата, която получава данни от тестов PLC чрез OPC-UA, не симулация, а действителна връзка. (17) Демонстрирайте създаването на конфигурация на нова производствена линия без намеса на доставчика, колко сложна е настройката?
(18) Покажете как се създава нов потребител и му се присвоява конкретна линия и роля. (19) Демонстрирайте конфигурация за Single Sign-On (SSO) с вашия доставчик на идентичност. (20) Покажете как списъкът с кодове за причини за престой се актуализира, когато таксономията се промени.
(21) Покажете системата в действие по време на симулиран мрежов срив, работи ли буферирането на ръба (edge buffering)? (22) Демонстрирайте API-то, направете на живо API повикване пред вас, за да извлечете OEE данните от последните 24 часа. (23) Покажете как изглежда системата след 2 години натрупани данни, има ли деградация на производителността?
(24) Помолете доставчика да ви покаже клиентски тикет от последните 6 месеца и как е бил разрешен. (25) Покажете процеса на ъпгрейд, как се разгръщат новите версии и какъв престой е необходим?
Изпратете контролен списък с 25 сценария до доставчиците една седмица преди демонстрацията и ги помолете да се подготвят да демонстрират всеки от тях. Следете внимателно тяхната реакция, доставчици, които възразяват срещу конкретни сценарии („не можем да покажем това в демо среда“), сигнализират за пропуск в възможностите. Доставчици, които приемат предизвикателството и се явяват подготвени, вдъхват повече увереност в реалното представяне на своята платформа.
По време на демонстрацията оценявайте всеки сценарий по проста скала 0, 2: 0 (не е демонстрирано или функционалността не е налична), 1 (демонстрирано с значителни уговорки или заобиколни решения), 2 (демонстрирано ясно и убедително). Водете бележки за конкретните доказателства за всяка оценка, какво е показал доставчикът, кои ограничения са споменати и какви последващи въпроси възникват.
Това водене на бележки създава запис от оценката на демонстрацията, който може да се сподели с членове на екипа по оценка, които не са успели да присъстват на цялата сесия.
След демонстрацията направете последващо искане за писмен отговор за всички сценарии, които не бяха демонстрирани, помолете доставчика писмено да документира как неговата система се справя с конкретния сценарий.
Писмените отговори за пропуските в демонстрацията създават договорни референтни точки: ако доставчикът твърди писмено, че системата му обработва даден сценарий по определен начин, а това не е така след пускането в продукция, вие имате документация за подвеждането.
Тази документация също така насочва екипа по продажбите на доставчика към точност, а не към оптимизъм, което обикновено подобрява надеждността на техните отговори.
Вход
Блог
