Специализиран софтуер за индустрията – кога готовата система за управление на производството/ERP престава да бъде разумен избор

Готова система за управление на производството или ERP често е разумен избор, но само ако реалният ход на производството може да бъде отразен без съществени опростявания. В противен случай системата подрежда отчетността за сметка на управляемостта на процеса. Точно тук въпросът за каталога с функции престава да е съществен. Трябва да се прецени дали предприятието ще продължи да управлява собственото си производство, качество и поддръжка, или ще започне да наглася работата си към ограниченията на инструмента. Ако критичните решения, изключенията и блокировките функционират основно извън системата, специализираният софтуер за индустрията не е прищявка. Той се превръща в начин да се възстановят последователността на данните, отговорността и оперативният контрол.

Не всяко производство може коректно да се побере в готова система

Готова система за управление на производството или ERP работи добре там, където процесът е действително повтаряем, отговорностите са ясно определени, а моделът на данните не изкривява реалната картина на предприятието. При такива условия стандартизацията подрежда информационния поток, ограничава броя на локалните тълкувания и позволява решенията да се вземат въз основа на последователен запис на събитията. Проблемът се появява по-рано от нивото на липсващите функции. Той започва там, където реалният ход на производството, качеството, поддръжката и планирането вече не се побира в логиката на системата без загуби за процеса.

Това е границата между разумната стандартизация и загубата на оперативен контрол. Ако организацията започне да заобикаля собствения си процес, само за да „излизат данните в системата“, информационната архитектура престава да служи на производството. Тя започва да го деформира. Част от правилата могат безопасно да се уеднаквят чрез конфигурация или процедура, но има и технологични зависимости, контролни точки и вериги на отговорност, които не бива да се размиват без вреда за качеството на изделието, безопасността на процеса или проследимостта на решенията. Затова спорът „готово или собствено“ обикновено е поставен погрешно. По-точният въпрос е: кои елементи на процеса са общ стандарт и кои представляват същността на предимството на предприятието, източник на риск или област на задължения по съответствие и трябва да бъдат отразени вярно.

На практика най-скъпи не са липсващите модули, а заобиколните решения, които неусетно се превръщат в ежедневен начин на работа. Таблици, водени паралелно със системата, ръчно прехвърляне на данни между смяната и офиса, бележки на операторите, неформално съгласуване на изключения и паралелни информационни потоци не са дребно неудобство. Това е сигнал, че моделът за управление на процеса се пропуква. Тогава си струва да се измерва не броят на функциите, а броят на ръчните точки за прехвърляне на данни между производството, качеството, поддръжката и планирането, броят на критичните изключения, обработвани извън системата, както и делът на оперативните решения, вземани въз основа на данни, които не идват директно от първичния регистър. Ако тези показатели нарастват, проблемът обикновено не е в слабата конфигурация, а в погрешното допускане, че процесът може без разходи да бъде огънат според инструмента.

Това ясно се вижда в предприятия, в които изпълнението на поръчката зависи не само от технологичния маршрут, но и от реалното състояние на машината, резултатите от междинния контрол, допуските за материалите, партидата на зареждания материал, настройващите параметри и решенията, вземани под натиск от времето едновременно от няколко звена. Ако готовата система не е в състояние да поддържа тези зависимости в една надеждна верига от данни, истината за процеса се разпада на няколко места. Част остава в системата, част е при машината, част е в документите по качеството, а част е в знанието на хората. Такова състояние затруднява картографирането на производствения процес, усложнява отговорността на изпълнителите по внедряването и увеличава риска на проекта при интеграция с автоматизацията и със системи, които влияят върху безопасността на машините. Специализираният софтуер има смисъл не когато предприятието просто иска „нещо свое“, а когато трябва да се запази единството на процеса, първичните данни и решенията там, където опростяването би означавало реална загуба на контрол.

От гледна точка на съответствието и оперативния надзор това разграничение е от основно значение. Ако ключовите правила и контролни точки съществуват единствено в практиката на екипа, а не се налагат или поне не са еднозначно отразени в системата, проследимостта на отговорността става условна. В едни отрасли това ще бъде преди всичко проблем на качеството и възстановимостта на хода на партидата, а в други също и въпрос на секторни изисквания, проследимост, управление на промените или граници на отговорност между ползвателя на предприятието, интегратора и доставчика на софтуера. Затова решението дали процесът да се подчинява на системата или системата на процеса трябва да бъде предшествано не от представяне на функции, а от честен анализ на изключенията. Едва тогава се вижда кои от тях са организационен хаос и кои отразяват реални технологични, информационни и свързани с безопасността изисквания.

Разходът нараства там, където системата не вижда реалния риск

Несъответствието на системата струва най-скъпо не при простия поток на поръчките или в дневните отчети, а на границата между производството, качеството, поддръжката и безопасността на процеса. Именно там решението трябва да се вземе бързо, да бъде документирано и да се основава на пълния контекст: текущото състояние на машината, параметрите на партидата, историята на намесите, статуса на освобождаване от качеството и действащите блокировки. Ако готовата система MES или ERP вижда само част от тази картина, цената не се изчерпва с неудобство за потребителя. Появява се оперативна вариативност. Различни смени вземат сходни решения въз основа на различни данни, изключенията се обработват по преценка, а отговорността се размива между системата, процедурата и практиката в цеха.

Най-същественият проблем започва тогава, когато системата не отразява реалната последователност на действията, условията за блокиране, версионирането на технологичните параметри или отговорността за одобряване на отклонение. В записа всичко може да изглежда правилно, докато изпълнението е протекло по друг начин. Възниква разрив между събитието и неговата цифрова следа. Това налага съвсем конкретни проектни решения: дали критичните блокировки на процеса да действат системно, или само процедурно; дали данните от машините са оперативно доказателство, или помощен материал; и дали изключенията да се обработват чрез проектиран поток на решенията, или да се оставят на преценка. Ако предприятието разчита на ръчни дописвания, допълнителни таблици или интерфейси, изискващи постоянна човешка намеса, надеждността на данните трябва да се оценява не по това дали може да се генерира финален отчет, а по това дали без спор може да се възстанови ходът на едно несъответствие, рекламация или спиране на линия.

Особен риск се проявява в предприятия с развит машинен парк, където системата трябва да работи съвместно с автоматиката, операторските работни места и контролнo-измервателните устройства. Ако интеграцията с устройствата е частична, събирането на процесни данни е непоследователно, а историята на промените е разпръсната между контролера, панела, производствената база и сервизните бележки, проследимостта на партидата и генеалогията на изделието стават условни. По сходен начин изглежда и управлението на технологичната промяна. Промяна в рецептурата, прага на толеранс или логиката на пренастройване може формално да е одобрена, но без последователно версиониране и архивиране по-късно не може да се докаже коя конфигурация действително е била в сила в момента на събитието. Това не е въпрос на естетика на системната архитектура, а на възпроизводимост, установяване на първопричините и границите на отговорност между производството, поддръжката, качеството и доставчиците на интеграция.

Цената на подобно несъответствие рядко се вижда в бюджета за внедряване. Тя се проявява по-късно като диагностични престои, увеличаване на ръчната работа, рекламации, спорове за причината за събитието и загуба на възможността еднозначно да се възстанови протичането на процеса. Затова при оценка на решението не е достатъчно да се пита дали системата „обслужва производството“. Трябва да се провери колко интерфейса изискват ръчна корекция, колко критични параметъра не се версионират автоматично или не се архивират по последователен начин и колко време отнема реконструкцията на единичен оперативен инцидент. Ако отговорът е: дълго, непоследователно и с участието на няколко независими източника, проблемът не е в удобството за потребителя, а в управляемостта на риска. Именно тук собственото решение или поне специализираният слой върху готовата система често е оправдан: не за да отчита по-добре миналото, а за да подпомага безопасни оперативни решения в момента, когато предприятието работи под натиск на време и отговорност.

От гледна точка на съответствието това означава и още нещо. Там, където софтуерът влияе върху хода на решения, имащи значение за качеството, проследимостта или безопасността на процеса, обхватът на критичните функции трябва да произтича от реалния анализ на риска, а не от каталога със стандартни модули. Това се отнася особено за интеграцията с машини, обработката на извънредни състояния и местата, в които системата трябва да налага определена последователност на действията или да блокира преминаването към следващия етап. В такива области е добре да се разграничат отчетните функции от онези, които се превръщат в елемент на оперативния контрол и изискват по-солидна проектна обосновка, включително и в контекста на безопасността на машините и отговорността на интегратора.

Първо проектът на решенията, после кодът

Разумното решение за развитието на системата в предприятието не започва със списък от функции, а с карта на оперативните решения, които софтуерът трябва да подпомага или да налага. Трябва да се установи кой взема решението, въз основа на какви данни, в какъв срок и с какъв ефект за производството, качеството, проследимостта или безопасността на процеса. Едва на този фон става ясно дали готовата система MES или ERP обхваща същината на проблема, или само подрежда отчетността след факта. Ако критичното не е самото регистриране на събитието, а блокирането на старта на следващата операция, условието за освобождаване на партидата, потвърждението за съответствие на настройките на машината или обработката на отклонение, въпросът не е „дали системата го има“, а „дали може да наложи правилното решение в правилния момент“.

Такъв начин на мислене внася ред и в проектирането на архитектурата. На практика най-често работи хибридният модел. Стандартният ERP или система за управление на производственото изпълнение трябва да остане там, където процесът е общ, повтаряем и добре описан от зрял модел на данните: при планирането, отчитането на производството, складовото стопанство и базовата регистрация на поръчки и партиди. Специализиран слой има смисъл тогава, когато поема логика, критична за конкретния завод: интеграция с машини, валидиране на събития от няколко източника, обработка на изключения, маршрути за одобрение, одитна следа и обвързване на решенията с конкретна партида, машина и отговорно лице. Условието за успех обаче е предварително да се определят границите на отговорност. Екипът трябва да реши какво принадлежи към технологичния процес и остава от страната на автоматиката или управлението, какво е в домейна на ERP или системата за управление на производственото изпълнение, какво реализира интеграционният слой и какво все още трябва да остане в организационните процедури.

Без такова разделение се стига до скъпа импровизация. Едно и също условие се записва на няколко места, изключенията се решават ръчно, а след няколко месеца никой не може еднозначно да посочи коя система отговаря за решението, което блокира или освобождава процеса. Затова добрият специализиран проект не се състои в копиране на готово решение в по-малък мащаб. Неговата задача е да затвори конкретна празнина в логиката на вземане на решения. Ето защо още на етапа на проекта си струва да се изготви списък на критичните решения, които днес нямат системна поддръжка или принудително прилагане, а след това да се съпоставят с броя на процесните изключения, които решението трябва да обслужва още от първото пускане. Това е по-важно от подробна спецификация на екраните.

Практическият пример е прост. Готовата система може коректно да отчита производството, разхода на материали и складовите постъпления, но да не обхваща специфични качествени блокировки, свързани с условното освобождаване на партида. Партидата може формално да е произведена и осчетоводена, но въпреки това да не бива да преминава към следващия етап без потвърждение на определени резултати от изпитвания, състоянието на пренастройката на линията или отстраняване на отклонение от предходната операция. Ако такова условие днес се следи по телефон, в таблица или с подпис върху разпечатка, това не е въпрос на естетика на процеса, а празнина в управлението на отговорността. В такава ситуация преизграждането на целия ERP или система за управление на производственото изпълнение обикновено не е обосновано. Достатъчен е специализиран слой, който събира данни от машините и изходните системи, проверява пълнотата на събитията, задейства правилния маршрут за одобрение и предава към надстоящата система еднозначен статус на партидата. Стандартът си остава стандарт, а критичната логика се записва там, където може реално да се управлява и поддържа.

Ако заводът все още няма данни за разходите, не е нужно те да се предполагат. Достатъчно е да започне да се измерва колко време месечно отнемат ръчните заобиколни действия, допълнителните съгласувания, корекциите по партиди и проверката на разминаванията между системата и реалното състояние на процеса. Такъв материал позволява да се разграничи обоснованият специализиран слой от проект, писан за всеки случай. Той улеснява и правилното разпределение на ролите от страна на бизнеса. За обхвата на логиката, записана в системата, не бива да решава единствено ИТ отделът или само интеграторът, а съвместно производството, качеството, поддръжката, отговорните за дигитализацията, както и там, където това е важно, сътрудничеството между интегратора, software house-а и отдела по поддръжка, безопасността на машините и оперативното съответствие.

От гледна точка на проектната отговорност това има още една последица. Колкото по-близо софтуерът навлиза в условията за преминаване на процеса, блокировките на операции, коректността на последователността от действия или данните, идващи директно от машината, толкова по-малко може да се разглежда като неутрална ИТ добавка. В такъв обхват са необходими ясни проектни допускания, описание на границите на действие и поддръжка, правила за управление на промяната и проверима следа кой и на какво основание е одобрил критичната логика. Затова преди да бъде написан първият ред код си струва да се одобрят не само функционалните изисквания, а преди всичко проектът на решенията: какво системата трябва да налага, какво не трябва да позволява да се прави и в кой момент човекът остава последната инстанция на отговорност.

Съответствието е резултат от добър проект, а не украса след внедряването

В индустриалното предприятие софтуерът не е неутрално допълнение към процеса, а част от начина, по който той се изпълнява. Той може да определя последователността на действията, да блокира преминаването към следващия етап, да налага пълнота на данните, да насочва по маршрута за одобрение и да предопределя дали след дадено събитие може да се възстанови ходът на решенията и отговорността. Поради това съответствието не започва с добавяне на формални изисквания в края на внедряването. То започва от проекта, в който съзнателно се определя кои решения системата взема сама, кои само подпомага, кои данни приема за обвързващи и кой е собственик на правилата, изключенията и промените.

Ако този ред не бъде изграден още на етапа на архитектурата на решението, по-късното позоваване на изискванията за качество, безопасност на процеса или задълженията за документиране се превръща в привидно действие. Това е особено важно, когато системата влияе върху решения, съществени за качеството на изделието, безопасността на процеса или взаимодействието с машини и оборудване. В такъв обхват изискванията за съответствие трябва да се разбират оперативно: като необходимост от последователност в работата, проследимост на отговорностите, контрол на промените и пригодност на решението за реалното му приложение. Не става дума само за това дадена функция да е налична, а да може да се докаже защо работи точно по този начин, кой е одобрил нейната логика и как се оценяват последиците от нейната промяна.

Най-много проблеми обикновено се проявяват не при пускането, а след няколко месеца експлоатация. Предприятието добавя нов производствен вариант, променя критериите за приемане, свързва още една работна станция или прехвърля част от отговорността от оператора към системата. Ако предварително не е определено кои класове решения и записи трябва да оставят одитна следа, бързо възниква спор чия промяна е повлияла на качеството, престоя или неправилната реакция на системата. Именно тогава се вижда разликата между решение, което просто работи, и решение, което може да се управлява. При второто предварително е ясно кои елементи на логиката изискват формален път за одобрение, кой контролира референтните данни, кой поддържа интеграцията с автоматиката и дали проектната документация е достатъчна за одит, поддръжка и безопасно поемане на системата от друг изпълнител.

• кои решения системата взема или съвместно формира в областта на качеството, безопасността и взаимодействието с машината,
• кои събития, промени и одобрения трябва да оставят възпроизводима следа,
• кой е собственик на бизнес правилата, данните и изключенията и кой одобрява тяхната промяна.

Едва след такова подреждане има смисъл проектът да се съпоставя с правните и нормативните изисквания, приложими за конкретното предприятие, изделие, бранш и начина на интеграция с машини или оборудване. В полските и европейските реалности въпросът не е само дали решението работи, а дали организацията може да докаже защо работи по този начин, на какво основание са одобрени правилата и как се управлява промяната, без да се отслабва проследимостта на отговорностите. Обхватът на този анализ винаги зависи от приложението: по един начин се оценява система за отчетност, по друг — логика, която влияе върху хода на процеса, и по съвсем различен — интеграция, която се допира до функционирането на машината, оценката на риска или обхвата на отговорност на интегратора.

Изводът е прост. Специализираният софтуер е оправдан тогава, когато подрежда отговорностите и ограничава риска точно там, където готова система за управление на производството или ERP би изисквала скъпи компромиси в логиката на процеса, контрола на промените или възпроизводимостта на действията. Следователно не става дума за изграждане на всичко от нулата, а за такова разделяне между стандарта и критичната логика, че системата да подпомага реалния процес в предприятието, вместо да го опростява за сметка на качеството, безопасността и проследимостта на отговорностите.