Hvordan organiserer man samarbejdet mellem integratoren, softwarehuset og vedligeholdsafdelingen i ét projekt?

Hvorfor emnet er vigtigt i dag

Samarbejdet mellem integratoren, softwarehuset og vedligeholdsafdelingen er ikke længere blot et spørgsmål om organisatorisk bekvemmelighed. I praksis er det i dag afgørende for, om projektet kan sættes i drift uden tvister om omfanget, om en ændring i softwaren ikke forsinker den tekniske overtagelse, og om anlægget efter implementeringen kan vedligeholde løsningen sikkert. Jo mere af proceslogikken der flyttes til softwarelaget, og jo mindre der bliver tilbage i standardfunktionerne i styringer og udstyr, desto vigtigere bliver grænserne for ansvar. Hvis de ikke fastlægges fra starten, stiger projektomkostningerne som regel ikke lineært, men gennem rettelser udført det forkerte sted: integratoren retter grænseflader, softwarehuset bygger forretningslogikken om, og vedligeholdsafdelingen afdækker først til sidst driftskrav, som ingen tidligere har fået skrevet ned.

Det er også et budgetspørgsmål og ikke kun et teknisk emne. I mange projekter bliver spørgsmålet om samarbejdet mellem parterne meget hurtigt til et spørgsmål om, hvad dedikeret software til industrien egentlig er i investeringsbudgettet: en del af investeringen, en driftsomkostning eller en kombination af begge. Hvis løsningens arkitektur forudsætter, at nøglefunktioner for proces, rapportering, recepter, batchsporing eller integration med fabrikkens systemer udvikles uden for automationsstandardens normale omfang, skal det afklares før bestillingen og ikke efter den første prototype. Det praktiske kriterium er enkelt: Hvis fraværet af én beslutningsejer for grænsen mellem automation, applikation og drift betyder, at krav, test og ændringsomkostninger ikke kan placeres entydigt, er projektet allerede kommet ind i en zone med forhøjet risiko og kræver en justering af samarbejdsmodellen.

Det ses lettest i et eksempel med modernisering af en linje, hvor integratoren har ansvaret for styring og idriftsættelse, softwarehuset for applikationslaget og dataudvekslingen, og vedligeholdsafdelingen efterfølgende skal overtage systemet til kontinuerlig drift. Hvis vedligeholdsafdelingen først bliver inddraget ved overtagelsen, dukker der typisk problemer op, som ikke er “fejl”, men manglende beslutninger: ingen procedure for gendannelse efter nedbrud, ingen krav til servicekonti, uafklarede opdateringsvinduer, en uforudset afhængighed af en ekstern leverandør eller utilstrækkelig observerbarhed af fejl. Så handler tvisten ikke længere om kodekvalitet eller om styretavlen er korrekt udført, men om hvem der skal bære omkostningen ved at tilpasse systemet til fabrikkens faktiske forhold. Her hænger emnet naturligt sammen med skjulte projekt- og complianceomkostninger, fordi forsinket overtagelse eller sene ændringer i sikkerhedsfunktioner, teknisk dokumentation eller validering ofte netop skyldes et dårligt organiseret samarbejde og ikke en enkelt udførelsesfejl.

Compliance-aspektet opstår, når arbejdsdelingen påvirker produktets egenskaber, sikkerhedsrelaterede funktioner, dokumentationen eller måden, løsningen tages i brug på. Ikke enhver integration mellem applikation og maskine udløser de samme forpligtelser, men allerede uklarhed om, hvem der har ansvaret for funktionsbeskrivelsen, ændringsstyringen og dokumentationens fuldstændighed, er et advarselssignal. Det gælder især projekter, der gennemføres i egen virksomhed, moderniseringer udført i etaper samt løsninger bygget til eget brug, hvor grænsen mellem “vedligeholdsarbejde” og fremstilling eller væsentlig ombygning kan have juridisk betydning. Derfor skal beslutningen om samarbejdsmodel ikke træffes, når den første konflikt opstår, men når omfanget defineres: hvem beskriver de operationelle krav, hvem godkender arkitekturen, hvem har ansvaret for test på tværs af lagene, og hvem overtager systemet efter idriftsættelse med reel evne til at vedligeholde det.

Hvor omkostninger eller risiko oftest vokser

I projekter, der gennemføres i fællesskab af integrator, softwarehus og vedligeholdsafdeling, stiger omkostningerne sjældent på grund af én stor fejl. De vokser som regel i grænsefladen mellem ansvarsområderne, altså dér hvor ingen har det fulde ansvar for at få sagen helt i mål. Det dyreste er ikke de tekniske fejl i sig selv, men beslutninger, der udskydes eller træffes uden en tydelig ejer: manglende enighed om kommunikationsarkitekturen, uafklarede grænser mellem styrelogik og applikationslag, ingen fastlagt metode for test efter ændringer samt overdragelse af systemet til drift uden reel vedligeholdelsesevne. I praksis betyder det rettelser efter idriftsættelse, tvister om kontraktens omfang og en forskydning af ansvaret for nedetid til den fase, hvor enhver ændring er dyrest. Et enkelt kriterium til at vurdere situationen er at spørge, om der for hver kritisk funktion kan peges på én part med ansvar for kravet, én for udførelsen og én for overtagelsen. Hvis svaret er “det kommer an på”, er projektet allerede belastet af organisatorisk risiko.

Det andet tabsområde opstår, når projekteringsbeslutninger træffes uden involvering af vedligehold, eller omvendt: når vedligehold dikterer løsninger, der er servicevenlige, men ikke hænger sammen med systemarkitekturen. Integratoren ser typisk projektet gennem opstart og samspil med udstyr, softwarehuset til industrien gennem forretningslogik og grænseflader, og vedligehold gennem tilgængelighed, diagnostik og tiden til at genetablere driften. Hvis disse perspektiver ikke mødes allerede i kravfasen, vender de senere tilbage som ændringsomkostninger: ekstra signaler, ombygning af rettigheder, manglende registrering af hændelser, der er nødvendige for diagnostik, manglende mulighed for at gennemføre opdateringer sikkert eller fravær af en procedure for håndtering af fejl. Det er her, emnet naturligt glider over i rollen som teknisk projektleder, fordi problemet ikke længere er en enkelt teknisk beslutning, men styring af afhængigheder, tidsfrister for afklaringer og ansvar for eskalering.

Et typisk praktisk eksempel er en implementering, hvor det overordnede applikationslag skal styre ordrer, recepter og rapportering, mens integratoren har ansvaret for PLC, drev og maskinsekvensen. Hvis ansvarsgrænsen kun beskrives funktionelt, uden angivelse af mellemtilstande, fejlbetingelser og adfærd ved tab af kommunikation, vil hver part opbygge sine egne “sikre” antagelser. Softwarehuset vil antage, at manglende bekræftelse betyder, at kommandoen skal sendes igen, integratoren vil lægge til grund, at kommandoen kun gives én gang, og vedligehold får et anlæg, som ikke kan diagnosticeres under stilstand. Konsekvensen er forudsigelig: lang idriftsættelse, tvetydige fejl, rettelser i grænsefladerne og spændinger omkring spørgsmålet om, hvem der har ansvaret for et ikke-planlagt stop. Ved vurderingen af en sådan situation bør man ikke kun måle afleveringsfristen, men også antallet af ændringer i grænseflader efter projektgodkendelse, antallet af fejl, der først opdages på anlægget, samt den tid, der kræves for at genskabe årsagen til en fejl. Hvis disse indikatorer stiger trods fremdrift i arbejdet, ligger problemet som regel i organiseringen af samarbejdet og ikke i den enkelte leverandørs effektivitet.

En særskilt risikokilde er at betragte test og dokumentation som et biprodukt af idriftsættelsen. Der, hvor systemet påvirker maskinens funktion, operatørens adgang, diagnostik, procesparametre eller sikkerhedsrelaterede funktioner, er en sen ændring ikke blot en almindelig programmeringsrettelse. Den kan kræve en ny vurdering af projektforudsætningerne, opdatering af den tekniske dokumentation, gentagelse af dele af afprøvningen og i bestemte faktiske situationer også en fornyet analyse af forpligtelserne på brugerens side eller hos den part, der indfører ændringen. Det kan ikke afgøres abstrakt og ens for alle projekter, men den praktiske regel er enkel: jo mere en ændring påvirker systemets adfærd i normale og unormale tilstande, desto mindre bør den håndteres “på løbende aftaler”. Her begynder også området med de typiske fejl, man møder ved opbygning og modernisering af maskiner: manglende spærringer mod fejlagtig konfiguration, manglende tvungen rækkefølge af handlinger og manglende mekanismer, der forebygger fejl fra operatør eller service. Hvis sådanne sikringer ikke er skrevet ind i omfanget fra starten, vender de senere tilbage som omkostninger, stilstand eller en tvist om ansvar.

Sådan griber man emnet an i praksis

I praksis bør samarbejdet mellem integrator, softwarehus og vedligeholdsafdeling ikke organiseres omkring virksomhederne, men omkring ansvarsgrænserne for konkrete tekniske beslutninger. Det afgør, hvem der har ansvaret for styrelogikken, hvem der har ansvaret for applikationslaget og kommunikationen, og hvem der har ansvaret for servicevilkår, backup, gendannelse efter fejl og sikker implementering af ændringer på anlægget. Hvis disse grænser kun er beskrevet overordnet, begynder projektet at køre på antagelser: integratoren forudsætter, at driftskravene leveres af virksomheden, softwarehuset antager, at proceslogikken allerede er fastlagt, og vedligehold får et system, som ikke kan vedligeholdes effektivt uden kodeforfatteren. Konsekvensen er ikke kun organisatorisk. Omkostningerne ved idriftsættelsen stiger, fejlretning tager længere tid, og i tilfælde af en tvist bliver det vanskeligere at fastslå, om problemet skyldes en implementeringsfejl, ufuldstændige forudsætninger eller en ukontrolleret ændring efter overtagelsen.

Derfor bør den første beslutning ikke være valg af værktøj eller tidsplan for workshops, men at fastlægge en fælles ansvarsmodel for hele løsningens livscyklus. For en leder er det praktiske kriterium enkelt: Hver funktion, der påvirker maskinens eller linjens drift, skal have en udpeget ejer i projektets fire tilstande — projektering, idriftsættelse, overtagelse og vedligehold. Hvis man for en given funktion ikke entydigt kan svare på, hvem der godkender kravet, hvem der gennemfører ændringen, hvem der tester konsekvenserne, og hvem der bærer ansvaret for at genskabe funktionen efter en fejl, så er omfanget ikke klar til udførelse. Her opstår rollen som teknisk projektleder helt naturligt: ikke som personen “for tidsplaner”, men som ejer af beslutningsstrukturen mellem fagområder og leverandører.

De fleste problemer opstår i grænsefladen mellem styring og specialudviklet software. Et typisk eksempel er en applikation, der ændrer måden, recepter vælges på, parameteriserer arbejdssekvensen eller påvirker operatørens rettigheder. For et softwarehus til industrien kan det ligne en almindelig funktionsændring, men for integratoren og vedligeholdelsen er det et indgreb i anlæggets adfærd, diagnostik og omstillingsprocedurer. Hvis det ikke før implementeringen er aftalt, hvor ansvaret for interfacet slutter, og hvor ansvaret for proceslogikken begynder, kan en rettelse udført “i produktionen” kræve nye test, opdatering af instruktioner og i nogle tilfælde en ombygning af serviceprocedurerne. Det er netop her, emnet også bliver et budgetspørgsmål: Omkostningen ved specialudviklet software til industrien skyldes ikke kun selve kodningen, men også hvor meget ansvar projektet flytter over i validering, dokumentation og den efterfølgende vedligeholdelse.

For at undgå dette bør projektets status vurderes ud fra verificerbare leverancer og ikke ud fra leverandørernes erklæringer. Et minimumssæt er en aftalt liste over grænseflader, en beskrivelse af versionsstyring, en procedure for anmeldelse og godkendelse af ændringer, scenarier for accepttest samt en vedligeholdelsesplan efter idriftsættelse. Her fungerer en kort beslutningsscreening godt:

• om ændringen påvirker proceslogikken, driftsparametrene eller operatørens adfærd,
• om den kan genskabes, testes og rulles tilbage uden medvirken fra løsningens ophavsmand,
• om dokumentationen efter implementeringen gør det muligt for virksomheden at vedligeholde systemet uden viden, der kun findes gemt i leverandørens mailboks.

Hvis svaret på et af disse spørgsmål er “nej”, skal projektets omfang præciseres nærmere i stedet for at arbejdet forceres. Først på dette trin giver det mening at forholde sig til de formelle krav: ikke for at føje generelle forbehold til kontrakten, men for at kontrollere, om ændringernes karakter allerede påvirker dokumentationskrav, acceptkrav eller vurderingen af ansvaret på brugerens side. Det er særligt vigtigt dér, hvor virksomheden selv er med til at udvikle løsningen, videreudvikler den med egne ressourcer eller bygger dele af systemet til internt brug. I så fald er samarbejdet mellem de tre parter ikke længere kun et spørgsmål om projektorganisation, men også om virksomhedens juridiske forpligtelser.

Hvad man skal være opmærksom på ved implementering

De fleste problemer opstår ikke, når teamet mangler kompetencer, men når projektets parter arbejder korrekt inden for deres egne grænser, uden at nogen styrer kontaktfladen mellem dem. I et projekt, hvor integratoren har ansvar for eksekveringslaget og forbindelserne til automatiseringen, softwarehuset for applikationslogikken og vedligeholdelsen for virksomhedens driftssikkerhed, ender en forkert organiseret implementering næsten altid med, at risikoen skubbes videre til idriftsættelsesfasen. Det er netop dér, det viser sig, om projektbeslutningerne er truffet med hele løsningens livscyklus for øje, eller kun for at den enkelte leverandør kunne lukke sit eget scope. For projektet betyder det som regel én af tre ting: dyre rettelser efter opstart, en tvist om ansvaret for fejl eller forsinket overtagelse, fordi systemet kun fungerer under laboratorieforhold og ikke i den virkelige proces.

Den væsentligste faldgrube er, at implementering ofte behandles som en teknisk fase, selv om det i praksis er tidspunktet, hvor de organisatoriske beslutninger bliver prøvet af. Hvis integratoren kan foretage ændringer i styringen uden fuldt kendskab til konsekvenserne på applikationssiden, softwarehuset udvikler funktioner uden bekræftelse af begrænsninger i udstyr og industrinetværk, og vedligeholdelsen først bliver inddraget ved overtagelsen, så ligger problemet ikke i kommunikationen, men i en fejlbehæftet ansvarsfordeling. Det praktiske vurderingskriterium er enkelt: Før arbejdet går i gang på anlægget, skal hver part kunne angive, hvilke ændringer den kan udføre selvstændigt, hvilke der kræver fælles godkendelse, og hvem der træffer beslutning om at standse arbejdet, hvis der opstår risiko for processen, sikkerheden eller muligheden for at genskabe konfigurationen. Hvis svaret afhænger af “løbende aftaler”, er implementeringen endnu ikke tilstrækkeligt forberedt, selv om tidsplanen formelt set ser korrekt ud.

Et typisk eksempel er en tilsyneladende mindre ændring: en justering af en stations arbejdssekvens, som fra softwarehusets synspunkt er en korrektion af logikken, men som for integratoren betyder andre reaktionstider i udstyret, og for vedligeholdelsen påvirker diagnostik og procedurer efter fejl. Hvis en sådan ændring bringes ud på anlægget uden en fælles gennemgang af konsekvenserne, er det efter opstart vanskeligt at fastslå, om problemets kilde er koden, PLC-konfigurationen, drevparametrene eller operatørens betjening. Så vokser omkostningen ikke kun på grund af selve rettelsen, men også på grund af stilstandstid, ekstra test og involvering af personer, som tidligere ikke behøvede at deltage i analysen. Derfor bør man ikke kun måle tidspunktet for idriftsættelsen, men også antallet af implementeringsændringer uden fuld godkendelsesproces, tiden til at gendanne den forrige version samt andelen af fejl, der først opdages efter, at systemet er overdraget til drift. Det giver et reelt billede af, om samarbejdet mellem de tre parter er styret, eller blot holdes kørende ad hoc.

På dette trin opstår der helt naturligt også en grænse mellem en almindelig implementering og en situation, hvor virksomheden begynder at medudvikle løsningen på en måde, der påvirker dens formelle forpligtelser. Hvis afdelingen for vedligehold ikke blot afgiver bemærkninger, men selv ændrer logikken, udvælger komponenter til systemet eller overtager en del af konstruktionsbeslutningerne, handler det ikke længere kun om organiseringen af samarbejdet, men også om maskiner, der fremstilles til eget brug. Det kan ikke afgøres med én regel, der gælder for alle projekter; det afgørende er omfanget af indgrebet, virksomhedens grad af selvstændighed, og hvem der reelt former løsningens egenskaber. Det samme gælder for risikoanalysen: Hvis ændringen påvirker procesfunktionen, operatørens adfærd, betingelserne for serviceindgreb eller sekvensen af nødtilstande, er det ikke længere kun et spørgsmål om “skal det implementeres”, men også om “skal risikoen vurderes på ny, og skal forudsætningerne for godkendelse opdateres”. I praksis er det netop her, man tydeligst ser rollen for den projektansvarlige: ikke som mellemled for statusopdateringer, men som ejer af beslutningen om, hvornår den bekvemme forenkling ophører, og det tekniske og juridiske ansvar begynder.