Leverantörens ansvar vid testning

Det är hög tid att vi styr upp roller och ansvar vid testning och godkännande av ett nytt affärssystem. Allt oftare ser vi resultatet av ett bristande testarbete och där kund och leverantör i efterhand bråkar om ”varför driftstarten gick dåligt”. Som vanligt finns det minst två sidor av saken och det är sällan enbart den ena parten som har rätt i sin kritik. Snarare handlar det om att båda parter inte uppfyllt det åtagande som legat på respektive part, eller som BORDE legat på respektive part.

Inledningen till denna blogg handlar om att varna och inspirera kunderna till att ställa väsentligt högre krav på leverantören inför testerna jämfört med vad vi ser idag. Det finns fallgropar i dagens avtal som de flesta kunder inte kan överblicka, och en av fallgroparna handlar just om acceptanskontroll.

I samtliga implementeringar delas införandet in i ett flertal faser och där det vid någon tidpunkt infaller en sk acceptanskontrollperiod. Syftet med denna period handlar (enligt de flesta standardavtal) om att kunden ska genomföra en kontroll för att verifiera att systemet uppfyller de krav som fastställts under upphandlingen och ingår som en del i avtalet. Det framgår också i de flesta standardavtal att det är kunden som ansvarar för att genomföra dessa tester och därefter avlämna ett godkännande eller reklamation av identifierade fel och brister som leverantören ska åtgärda innan ett godkännande lämnas. På pappret verkar detta vara en lämplig modell.

Problemet är att vi väldigt ofta ser exempel på kunder som drabbas av ett flertal utmaningar under acceptanskontrollen och där det råder otydlighet om hur dessa problem ska hanteras då de inte helt finns beskrivna i avtalet. Exempel på problem:

• Det visar sig att testmiljön är uppsatt på ett bristfälligt sätt och där testerna ofta får avbrytas pga att uppsättningen inte återspeglar den uppsättning som tillämpats i den miljö där parterna arbetat under implementeringen.
• Det visar sig att testdata är bristfällig och där förarbetet är så bristande att arbetsflöden inte helt går att genomföra och där enbart enkla flöden går att testa och där stor del av tiden ska ägnas åt att registrera in grunddata.
• Det visar sig att flöden från försystem till huvudbok (eller andra sammanhängande moduler) ej kan genomföras pga att uppsättning skett per modul och där det saknats ansvar för någon att säkra flöden hela vägen från källa till slutdestination.
• Det visar sig att kunden faktiskt saknar tillräcklig kompetens för att kunna genomföra testerna på ett fullgott sätt antingen pga bristande utbildning eller pga bristande uppsättning.
• Det visar sig att systemets uppsättning mer speglar dagens ”AS-IS” men att kundens förväntan var att systemet mer skulle spegla morgondagens ”TO-BE”.

Listan kan göras lång när det gäller problem vi stöter på, och som sedan lett fram till en väldigt besvärlig driftsättning med en lång period av konvalescens för att nå ett friskt tillstånd hos kunden.

Allt detta går att undvika om parterna redan under avtalsfasen är tydliga med ansvarsrollerna under implementeringen och vilka förutsättningar som ska vara uppfyllda innan acceptanstester kan inledas. Det finns flera situationer där kund har en avtalad rätt att vägra inleda testerna då systemet helt enkelt inte håller måttet för att inleda testerna. En av de viktigare parametrarna är att kunden ska kräva av leverantörer att genomföra sk ”egentester” av hela systemet och lämna ett testprotokoll till kunden innan det går över till kunden att inleda sin acceptanskontroll period.

Detta innebär att det vilar ett stort ansvar på leverantören att säkerställa systemets kvalitet innan testerna genomförs. Detta förutsätter dock att det finns framtaget både testdata och testscenario som leverantören ska använda sig av under testerna. Det var dock enbart ett exempel av många andra som bör läggas in i avtalet för att tidigt markera vem som har ansvar för vad. Testerna är implementeringens allra viktigaste fas och bör få den prioritet och omfattning i tid som krävs för att säkerställa en lyckad driftstart. Och märk väl att det spelar ingen roll om implementeringen sker agilt eller via en traditionell vattenfallsmodell.