Skræddersyet software til industrien – hvornår et standardiseret ERP-/produktionsstyringssystem ikke længere er et fornuftigt valg

Et standardsystem til produktionsstyring eller ERP kan være et fornuftigt valg, men kun hvis det faktiske produktionsforløb kan afspejles uden væsentlige forenklinger. Ellers skaber systemet orden i registreringen på bekostning af processtyrbarheden. Det er her, spørgsmålet om funktionskataloget mister sin betydning. I stedet må man vurdere, om virksomheden fortsat kan styre sin egen produktion, kvalitet og vedligehold, eller om arbejdet begynder at blive tilpasset værktøjets begrænsninger. Hvis kritiske beslutninger, undtagelser og blokeringer i praksis primært håndteres uden for systemet, er specialudviklet software til industrien ikke en luksus. Det bliver en måde at genvinde sammenhæng i data, ansvar og den operationelle kontrol.

Ikke al produktion kan reelt passes ind i et standardsystem

Et standardsystem til produktionsstyring eller ERP fungerer godt dér, hvor processen faktisk er gentagelig, ansvarsfordelingen er entydig, og datamodellen ikke forvrænger billedet af virksomheden. Under sådanne forhold skaber standardisering struktur i informationsflowet, begrænser antallet af lokale fortolkninger og gør det muligt at træffe beslutninger på grundlag af en sammenhængende registrering af hændelser. Problemet opstår tidligere end på niveauet for manglende funktioner. Det begynder dér, hvor det faktiske forløb i produktion, kvalitet, vedligehold og planlægning ikke længere kan rummes i systemets logik uden tab for processen.

Det er grænsen mellem fornuftig standardisering og tab af operationel kontrol. Hvis organisationen begynder at omgå sin egen proces for at få data til at “passe i systemet”, holder informationsarkitekturen op med at understøtte produktionen. Den begynder i stedet at forvride den. Nogle regler kan uden problemer ensrettes gennem konfiguration eller procedure, men der findes også teknologiske afhængigheder, kontrolpunkter og ansvarskæder, som ikke må udvandes uden skade for produktkvaliteten, processikkerheden eller sporbarheden i beslutninger. Derfor er diskussionen om “standard eller egen løsning” som regel stillet forkert. Det mere præcise spørgsmål er: Hvilke dele af processen er fælles standard, og hvilke udgør kernen i virksomhedens fordel, en risikokilde eller et område med compliance-forpligtelser og skal derfor afspejles loyalt.

I praksis er det dyreste ikke de manglende moduler, men de omveje, der stille og roligt bliver den daglige arbejdsform. Regneark ved siden af systemet, manuel overførsel af data mellem skift og kontor, operatørnoter, uformel afklaring af undtagelser og parallelle informationsstrømme er ikke blot små gener. Det er et signal om, at modellen for processtyring er ved at slå revner. Derfor bør man ikke måle antallet af funktioner, men antallet af manuelle punkter, hvor data skrives om mellem produktion, kvalitet, vedligehold og planlægning, antallet af kritiske undtagelser, der håndteres uden for systemet, samt andelen af operationelle beslutninger, der træffes på grundlag af data, som ikke kommer direkte fra kilderegistret. Hvis disse indikatorer stiger, skyldes problemet som regel ikke dårlig konfiguration, men en forkert antagelse om, at processen uden omkostninger kan bøjes til værktøjet.

Det ses tydeligt i virksomheder, hvor et ordreforløb ikke kun afhænger af den teknologiske rute, men også af maskinens faktiske tilstand, resultaterne af mellemliggende kontrol, materialegodkendelser, batchen af inputmateriale, indstillingsparametre og beslutninger, der under tidspres træffes af flere funktioner samtidig. Hvis et standardsystem ikke kan fastholde disse sammenhænge i én troværdig datakæde, falder sandheden om processen fra hinanden og ender flere steder. Noget bliver i systemet, noget ved maskinen, noget i kvalitetsdokumentationen og noget i medarbejdernes viden. En sådan situation gør kortlægningen af produktionsprocessen vanskeligere, komplicerer ansvarsfordelingen for dem, der gennemfører implementeringen, og øger projektrisikoen ved integration med automatik samt systemer, der påvirker maskinsikkerheden. Specialudviklet software giver ikke mening, fordi virksomheden ønsker “noget eget”, men når det er nødvendigt at bevare enheden mellem proces, kildedata og beslutninger dér, hvor en forenkling ville medføre et reelt tab af kontrol.

Set fra et compliance- og driftsmæssigt tilsynsperspektiv er denne sondring helt grundlæggende. Hvis de vigtigste regler og kontrolpunkter kun findes i teamets praksis og ikke håndhæves eller i det mindste er entydigt afspejlet i systemet, bliver ansvarligheden betinget. I nogle brancher vil det først og fremmest være et spørgsmål om kvalitet og mulighed for at genskabe batchforløbet, i andre også et spørgsmål om sektorkrav, sporbarhed, ændringsstyring eller grænserne for ansvar mellem anlæggets bruger, integratoren og softwareleverandøren. Derfor bør beslutningen om at underordne processen systemet eller systemet processen ikke begynde med en funktionspræsentation, men med en ærlig analyse af undtagelserne. Først da bliver det tydeligt, hvilke der skyldes organisatorisk kaos, og hvilke der afspejler reelle teknologiske, informationsmæssige og sikkerhedsmæssige krav.

Omkostningerne vokser dér, hvor systemet ikke ser den reelle risiko

Et system, der ikke passer til behovet, bliver sjældent dyrest i det enkle flow af ordrer eller i de daglige rapporter, men derimod i grænsefladen mellem produktion, kvalitet, vedligehold og processikkerhed. Det er netop her, beslutninger skal træffes hurtigt, dokumenteres og bygge på den fulde kontekst: maskinens aktuelle tilstand, batchparametre, historik over indgreb, status for kvalitetsfrigivelse og gældende blokeringer. Hvis et standardiseret system til produktionsstyring eller ERP kun ser en del af dette billede, er omkostningen ikke begrænset til brugerbesvær. Der opstår operationel variation. Forskellige skift træffer lignende beslutninger på grundlag af forskellige data, undtagelser håndteres skønsmæssigt, og ansvaret flyder ud mellem systemet, proceduren og praksis på gulvet.

Det væsentligste problem opstår, når systemet ikke afspejler den reelle rækkefølge af handlinger, betingelserne for blokering, versionsstyringen af procesparametre eller ansvaret for at godkende en afvigelse. I registreringen kan alt se korrekt ud, selv om udførelsen forløb anderledes. Der opstår et hul mellem hændelsen og dens digitale spor. Det tvinger meget konkrete designbeslutninger frem: om kritiske procesblokeringer skal fungere systemmæssigt eller kun proceduremæssigt; om maskindata er operationel dokumentation eller blot støttemateriale; og om undtagelser skal håndteres gennem et designet beslutningsflow eller overlades til skøn. Hvis anlægget bygger på manuelle tilføjelser, ekstra regneark eller grænseflader, der kræver konstant menneskelig indgriben, skal datatroværdigheden ikke vurderes ud fra, om den endelige rapport kan genereres, men ud fra, om forløbet af én afvigelse, reklamation eller linjestop kan rekonstrueres uden tvist.

En særlig risiko viser sig i anlæg med en omfattende maskinpark, hvor systemet skal fungere sammen med automatiseringen, operatørstationer og kontrol- og måleudstyr. Hvis integrationen med udstyret kun er delvis, indsamlingen af procesdata er inkonsistent, og ændringshistorikken er spredt mellem styring, panel, produktionsdatabase og servicenotater, bliver batchsporing og produktgenealogi betinget. Det samme gælder håndteringen af teknologiske ændringer. En ændring i recept, tolerancegrænse eller omstillingslogik kan være formelt godkendt, men uden sammenhængende versionsstyring og arkivering kan man senere ikke dokumentere, hvilken konfiguration der faktisk var gældende på hændelsestidspunktet. Det er ikke et spørgsmål om systemarkitekturens æstetik, men om reproducerbarhed, fastlæggelse af rodårsager og ansvarsgrænser mellem produktion, vedligehold, kvalitet og integrationsleverandører.

Omkostningen ved en sådan mismatch ses sjældent i implementeringsbudgettet. Den viser sig senere som diagnostiske stop, mere manuelt arbejde, reklamationer, uenighed om årsagen til en hændelse og tab af muligheden for entydigt at rekonstruere procesforløbet. Derfor er det ikke nok at spørge, om systemet “understøtter produktionen”, når en løsning skal vurderes. Man skal undersøge, hvor mange grænseflader der kræver manuel korrektion, hvor mange kritiske parametre der ikke versionsstyres automatisk eller arkiveres konsistent, og hvor lang tid det tager at rekonstruere en enkelt operationel hændelse. Hvis svaret er: lang tid, inkonsistent og med brug af flere uafhængige kilder, handler problemet ikke om brugerkomfort, men om styrbarheden af risikoen. Det er netop her, en egen løsning eller i det mindste et dedikeret lag oven på standardsystemet kan være berettiget: ikke for at rapportere fortiden bedre, men for at understøtte sikre operationelle beslutninger i det øjeblik, hvor anlægget arbejder under tidspres og ansvar. Dedikeret software til industrien er ofte relevant i netop sådanne situationer.

Set fra et compliance-perspektiv betyder det også noget mere. Der, hvor software påvirker beslutningsforløb med betydning for kvalitet, sporbarhed eller risikoanalyse, bør omfanget af kritiske funktioner tage udgangspunkt i den faktiske risikoanalyse og ikke i et katalog over standardmoduler. Det gælder især integration med maskiner, håndtering af undtagelsestilstande og de steder, hvor systemet skal håndhæve en bestemt rækkefølge af handlinger eller blokere overgangen til næste trin. I sådanne områder er det værd at skille registreringsfunktioner fra de funktioner, der bliver en del af den operationelle styring og kræver en mere robust designmæssig begrundelse, også i forhold til maskinsikkerhed og integratorens ansvar.

Først beslutningsdesign, derefter kode

En fornuftig beslutning om systemudvikling i et anlæg begynder ikke med en funktionsliste, men med et kort over de operationelle beslutninger, som softwaren skal understøtte eller håndhæve. Man skal fastlægge, hvem der træffer beslutningen, på grundlag af hvilke data, inden for hvilken tid og med hvilken konsekvens for produktion, kvalitet, sporbarhed eller processikkerhed. Først på den baggrund bliver det tydeligt, om et standardiseret system til produktionsstyring eller ERP dækker problemets kerne, eller blot bringer orden i registreringen efterfølgende. Hvis det kritiske ikke er selve registreringen af hændelsen, men blokeringen af opstarten af den næste operation, betingelsen for batchfrigivelse, bekræftelsen af at maskinindstillingerne er korrekte eller håndteringen af en afvigelse, er spørgsmålet ikke “om systemet har det”, men “om det kan håndhæve den rigtige beslutning på det rigtige tidspunkt”.

Denne måde at tænke på skaber også struktur i arkitekturdesignet. I praksis er det oftest en hybridmodel, der fungerer bedst. Et standardiseret ERP- eller produktionsstyringssystem bør blive dér, hvor processen er fælles, gentagelig og godt beskrevet af en moden datamodel: i planlægning, produktionsafregning, lagerstyring samt grundlæggende registrering af ordrer og partier. Et dedikeret lag giver mening, når det overtager logik, der er kritisk for den konkrete fabrik: integration med maskiner, validering af hændelser fra flere kilder, håndtering af undtagelser, godkendelsesforløb, auditspor samt kobling af beslutninger til et bestemt parti, en bestemt maskine og den ansvarlige person. Forudsætningen for succes er dog, at ansvarsgrænserne fastlægges på forhånd. Teamet skal afklare, hvad der hører til den teknologiske proces og derfor ligger hos automatik eller styring, hvad der er ERP’ets eller produktionsstyringssystemets domæne, hvad integrationslaget skal håndtere, og hvad der fortsat skal forblive i de organisatoriske procedurer.

Uden en sådan opdeling ender man i dyr improvisation. Den samme betingelse bliver ofte skrevet ind flere steder, undtagelser afgøres manuelt, og efter nogle måneder kan ingen længere entydigt pege på, hvilket system der er ansvarligt for den beslutning, der enten blokerer eller frigiver processen. Et godt dedikeret projekt handler derfor ikke om at kopiere en færdig løsning i mindre skala. Dets opgave er at lukke et konkret beslutningsmæssigt hul. Derfor bør man allerede i projektfasen udarbejde en liste over kritiske beslutninger, som i dag ikke har systemmæssig støtte eller håndhævelse, og derefter holde dem op mod antallet af procesundtagelser, som løsningen skal kunne håndtere fra første idriftsættelse. Det er vigtigere end en omfattende specifikation af skærmbilleder.

Et praktisk eksempel er enkelt. Et standardsystem kan sagtens afregne produktion, materialeforbrug og lagerindleveringer korrekt, men uden at omfatte de særlige kvalitetsblokeringer, der er knyttet til betinget frigivelse af et parti. Et parti kan være formelt produceret og bogført, men bør alligevel ikke gå videre til næste trin uden bekræftelse af bestemte testresultater, status for omstilling af linjen eller afhjælpning af en afvigelse fra den foregående operation. Hvis en sådan betingelse i dag håndteres via telefon, regneark eller underskrift på en udskrift, er det ikke et spørgsmål om procesæstetik, men et hul i styringen af ansvar. I en sådan situation er en ombygning af hele ERP- eller produktionsstyringssystemet som regel ikke berettiget. Det er nok med et dedikeret lag, som henter data fra maskiner og kildesystemer, kontrollerer hændelsernes fuldstændighed, starter det rette godkendelsesforløb og sender en entydig partistatus videre til det overordnede system. Standarden forbliver standard, mens den kritiske logik placeres dér, hvor den faktisk kan styres og vedligeholdes.

Hvis fabrikken endnu ikke har omkostningsdata, behøver man ikke gætte sig frem. Det er nok at begynde at måle, hvor meget tid man hver måned bruger på manuelle omveje, ekstra afstemninger, partikorrektioner og verifikation af afvigelser mellem systemet og den faktiske procestilstand. Et sådant grundlag gør det muligt at skelne mellem et berettiget dedikeret lag og et projekt, der udvikles for en sikkerheds skyld. Det gør det også lettere at fordele rollerne rigtigt på forretningssiden. Omfanget af den logik, der skrives ind i systemet, bør ikke afgøres alene af IT-afdelingen eller integratoren, men i fællesskab af produktion, kvalitet, samarbejdet mellem integrator, software house og vedligeholdsafdeling, de ansvarlige for digitalisering samt, hvor det er relevant, maskinsikkerhed og operationel compliance.

Set fra et projektansvarsperspektiv har det også en yderligere konsekvens. Jo tættere softwaren kommer på procesovergange, blokering af operationer, korrektheden af handlingssekvenser eller data, der kommer direkte fra maskinen, desto mindre kan den betragtes som et neutralt IT-tillæg. På dette niveau er der behov for eksplicitte designforudsætninger, en beskrivelse af grænserne for drift og vedligehold, regler for ændringsstyring samt et dokumenterbart spor af, hvem der har godkendt den kritiske logik, og på hvilket grundlag. Derfor bør man, før den første linje kode skrives, ikke kun godkende de funktionelle krav, men først og fremmest selve beslutningsdesignet: hvad systemet skal håndhæve, hvad det ikke må tillade, og på hvilket punkt mennesket fortsat er den sidste ansvarlige instans.

Compliance er resultatet af et godt projekt, ikke pynt efter implementeringen

I en industrivirksomhed er software ikke et neutralt supplement til processen, men en del af den måde, processen udføres på. Det kan fastlægge rækkefølgen af aktiviteter, blokere overgangen til næste trin, håndhæve datakomplethed, styre godkendelsesforløbet og være afgørende for, om man efter en hændelse kan genskabe beslutningsforløbet og ansvarsplaceringen. Derfor begynder compliance ikke med, at man tilføjer formelle krav til sidst i implementeringen. Den begynder i designet, hvor man bevidst fastlægger, hvilke beslutninger systemet træffer selv, hvilke det kun understøtter, hvilke data det anser for bindende, og hvem der ejer reglerne, undtagelserne og ændringerne.

Hvis denne struktur ikke etableres allerede i løsningsarkitekturen, bliver senere henvisninger til kvalitetskrav, processikkerhed eller dokumentationsforpligtelser i praksis kun tilsyneladende handlinger. Det er særligt vigtigt, når systemet påvirker beslutninger, der er væsentlige for produktkvaliteten, processikkerheden eller samspillet med maskiner og udstyr. Inden for dette område skal krav til overensstemmelse forstås operationelt: som behovet for ensartet drift, sporbarhed, ændringskontrol og at løsningen passer til den faktiske anvendelse. Det handler ikke kun om, at en funktion er tilgængelig, men om at man kan dokumentere, hvorfor den fungerer netop sådan, hvem der har godkendt dens logik, og hvordan konsekvenserne af ændringer vurderes.

De fleste problemer viser sig som regel ikke ved idriftsættelsen, men først efter nogle måneders drift. Virksomheden tilføjer en ny produktionsvariant, ændrer acceptkriterierne, kobler endnu en station på eller flytter en del af ansvaret fra operatøren til systemet. Hvis man ikke på forhånd har fastlagt, hvilke typer beslutninger og registreringer der skal efterlade et auditerbart spor, opstår der hurtigt uenighed om, hvis ændring der påvirkede kvaliteten, forårsagede stilstand eller udløste en forkert reaktion i systemet. Det er først dér, forskellen mellem en løsning, der fungerer, og en løsning, der kan styres, bliver tydelig. I sidstnævnte tilfælde er det på forhånd klart, hvilke dele af logikken der kræver en formel godkendelsesproces, hvem der har ansvaret for referencedata, hvem der vedligeholder integrationen med automatikken, og om projektdokumentationen er tilstrækkelig til audit, drift og sikker overdragelse af systemet til en anden leverandør.

• hvilke beslutninger systemet træffer eller er med til at forme inden for kvalitet, sikkerhed og samspil med maskinen,
• hvilke hændelser, ændringer og godkendelser der skal efterlade et reproducerbart spor,
• hvem der ejer forretningsreglerne, data og undtagelserne, og hvem der godkender ændringer i dem.

Først efter en sådan afklaring giver det mening at holde projektet op mod de juridiske og normative krav, der gælder for den konkrete virksomhed, produktet, branchen og måden, det integreres med maskiner eller udstyr på. I en polsk og europæisk kontekst er spørgsmålet ikke kun, om løsningen virker, men også om organisationen kan dokumentere, hvorfor den virker på denne måde, på hvilket grundlag reglerne er godkendt, og hvordan ændringer håndteres uden at svække sporbarheden. Omfanget af denne analyse afhænger altid af anvendelsen: et rapporteringssystem vurderes på én måde, logik der påvirker procesforløbet på en anden, og integration, der berører maskinens funktion, risikovurdering eller integratorens ansvarsområde, på en tredje.

Konklusionen er enkel. Dedikeret software til industrien er berettiget, når det skaber klarhed om ansvar og reducerer risikoen præcis dér, hvor et standardiseret system til produktionsstyring eller ERP ellers ville kræve dyre kompromiser i proceslogikken, ændringsstyringen eller sporbarheden af handlinger. Det handler altså ikke om at bygge alt fra bunden, men om at adskille standardfunktioner og kritisk logik på en måde, så systemet understøtter virksomhedens reelle proces i stedet for at forenkle den på bekostning af kvalitet, sikkerhed og sporbarhed.