Разработване от служители в производството е практиката оператори на производствената площадка, техници и ръководители на линии да изграждат собствени безкодови или нискокодови приложения за решаване на производствени проблеми, без да чакат отдел ИТ да напише код. Въоръжени с инструменти за плъзгане и пускане, бази данни във вид на електронни таблици и мобилни конструктори на формуляри, хората, най-близо до машините, вече могат да превърнат начертано решение на клипборд в работещ дигитален инструмент за един следобед. Тази скорост е наистина мощна, но също така тихичко създава нов клас негъвкав софтуер, който управлява вашата фабрика без надзор. Тази статия ви дава балансиран поглед и към двете страни, за да можете да уловите предимствата, без да наследите блато от крехки, недокументирани приложения.
В продължение на десетилетия всеки дигитален инструмент на производствения под трябваше да премине през централен ИТ или автоматизационен екип. Натрупването на заявки беше голямо, събирането на изисквания беше бавно и когато инструментът най-накрая се пуснеше, процесът, който трябваше да поддържа, често вече беше променен. Безкодовите платформи разчупиха този тесен гръбнак. Планировчик на поддръжката, който разбира истинската причина за забавянето на нарядите за работа, вече може да създаде точно формуляра, който техниците наистина ще използват.
Типичната първа вълна от плътно разработени от служители приложения се съсредоточава около няколко силно триещи се области:
Това са точно работните потоци, които формалните системи често оставят непокрити, и затова операторите посегнат към инструмент за изграждане. Когато е направено добре, това е пряко продължение на култура на автономна поддръжка: хората, които притежават процеса, също притежават инструментите, които го поддържат.
Най-силният аргумент за разработването от служители е, че то скъсява разстоянието между проблема и решението. Когато човекът, който усеща болката, също изгражда поправката, изискванията са точни от първия път и усвояването е почти автоматично, защото никой не е наложил инструмента отгоре.
Има и компаундиращ ефект върху непрекъснатото подобрение. Добре управляван PDCA цикъл или DMAIC проект често заседават на етапа „контрол“ или „действие“, защото няма евтин начин да се закотви новият стандарт. Един бърз безкодови проверъчен списък може да стане този механизъм за контрол в същата седмица, в която подобрението е договорено, вместо месеци по-късно.
Помислете за линия, която работи една смяна, 8 часа на ден, 20 дни в месеца. Операторите в момента отбелязват микропрестои на хартия и приблизително 40 процента от кратките спирания никога не се записват, защото записването ги прекъсва при възстановяване. Да предположим, че линията има средно 45 минути неизписани микропрестои на смяна.
Един супервизор създава безкодово приложение за запис с натискане: две докосвания, за да се запише причина за спиране. Задържането на кратките спирания скача от 60% на 95%. Това разкрива допълнителни 35% от 45 минути, или около 16 допълнителни минути видим престой на смяна. За месеца това са 16 минути по 20 смени, което прави 320 минути, или приблизително 5,3 часа предварително невидими загуби, които сега могат да бъдат отчетени.
Тези ново видими данни подават директно към честен показател за Обща ефективност на оборудването (OEE) и към правилен анализ на Парето на причините за спиранията. Приложението, създадено от служителя, не поправи машината, но направи най-големите загуби невъзможни за игнориране. Проблемът: тези 5,3 часа инсайт сега живеят в личното приложение на един супервизор, под един акаунт, без резервно копие и без собственик, ако той напусне.
Всяко неглижирано приложение е малка отговорност, която расте с употребата. Рисковете не са хипотетични и обикновено излизат наяве в най-неподходящия момент.
Това е класическо тенево ИТ: софтуер, който задвижва реални операции, но стои извън всякакъв инвентар, преглед или жизнен цикъл. Полезен ментален модел е кривата тип „ваничка“. Приложенията, създадени от служители, са евтини за раждане, но носят нарастващ риск от провал с течение на времето, ако не се поддържат, и за разлика от машина, никой не е насрочил тяхната поддръжка.
Целта не е да се забрани разработването от служители. Забраната просто ще го закара под повърхността. Целта е лека предпазна рамка, която позволява на полезните инструменти да процъфтяват и принуждава крехките да излязат на светло. Практичен подход:
Ако се третира по този начин, разработването от служители става слой за бързо прототипиране, който открива какво хората имат нужда, докато трайният, фабрично-обхватен запис живее на място с отговорност.
Най-здравословният модел, който наблюдаваме, е: приложения, създадени от служители, за хаотичните периферии и управлявана система на запис за всичко, което трябва да бъде доверено, сравнено или одитирано. Fabrico е изграден да бъде тази система на запис. Тя предоставя мониторинг в реално време на OEE и производство, така че престои и микропрестои да се улавят последователно във всяка линия с един общ речник, а не десет частни електронни таблици. Нейният готов за полева употреба CMMS покрива наряди за работа, активи, превантивно планиране и резервни части, давайки на проверъчните списъци и формулярите за заявки, които операторите харесват, постоянно, притежавано място вместо личен вход.
Защото Fabrico използва компютърно зрение, за да чете машини без PLC, екипите могат да дигитализират по-старо оборудване без проект за персонализирана интеграция, което често е точно пропускът, който приложение, създадено от служител, се опитваше да закърпи. И като платформа, изработена в ЕС с местонахождение на данните в ЕС, тя адресира притесненията за сигурност и юрисдикция, които безплатните потребителски инструменти тихомълком създават. С други думи, Fabrico е основата за данни в реално време около която вашите служители-разработчици могат да изграждат, така че тяхната скорост да се превърне в последователна картина, вместо в фрагментация. Можете да видите как улавя данни от производствения под в прегледа на OEE и мониторинг на производството.
Не задължително. Разработването от служители се превръща в теневи ИТ само когато приложенията оперират извън всякакъв регистър, преглед или структура на собственост. Санкционираното разработване от служители, със прост инвентар на приложения и нива на риск, ви дава предимството на скоростта без неконтролирания риск. Разликата е в управлението, не в самия инструмент.
Отнасяйте това като територия с висок риск. Записите за качество и съответствие изискват валидация, неизменяеми одитни следи и проследимост, които повечето безкодови инструменти не налагат по подразбиране. По-безопасно е да позволите на служителските приложения да прототипират работния поток, а след това всичко, свързано със спецификации, контролен план или проследимост за клиента, да се мигрира към управлявана система на запис.
Стандартизирайте терминологията преди да стандартизирате инструментите. Ако всички използват едни и същи кодове за причини за престой, имена на активи и категории дефекти, дори независимо изградени приложения ще генерират сравними данни. Сдвоете тази споделена таксономия с централизирана платформа в реално време, която става едното място, където всичко се обобщава, и фрагментацията до голяма степен се решава сама.
Готови ли сте да дадете на своя производствен под управлявана, в реално време база за данни, около която служителите-разработчици да строят, вместо да работят около нея? Запишете демо на Fabrico и вижте как OEE в реално време и готовият за полева употреба CMMS превръщат разпръснатите приложения на операторите в една достоверна картина на вашия завод.
Вход
Блог
