Det er langt fra kun i det offentlige, at den ene store it-implementering efter den anden bliver forsinket og dyrere end forventet. Vi hører bare ikke så ofte om de mange private virksomheder, der står tilbage med blødende hjerte efter en stor it-operation.
Alt, alt for mange virksomheder efterlades med gigantiske ekstraregninger og ufuldstændige processer efter langvarigt besøg af professionelle leverandører og konsulenter.
Og spørgsmålet er, om leverandøren kan kræve 50 procent ekstra for en ERP-implementering på grund af 'uforudset hovsa' undervejs, samtidig med at projektet er forsinket? Men det er virkelighed, og det er grænseløst uforskammet.
Efter 25 år med næsen dybt begravet i program- og projektimplementering stikker jeg nu snuden frem. For danske virksomheder accepterer alt for store mængder sjusk og humbug i forbindelse med it-implementeringer.
Når en virksomhed implementerer for eksempel et ERP-system, er det ofte 20-30 år gamle edb-systemer, der skiftes ud.
Derfor er der næppe nogen i virksomheden, som har forudsætningerne for at drive et så stort forandringsprojekt, som det uvægerligt er. Virksomheden lægger naturligt nok opgaven i hænderne på professionelle leverandører og konsulenter. Og alt burde være godt.
Men så dukker der noget hovsa op. Det gør der ofte i store projekter.
Hvis man ikke har taget de rette forholdsregler i den afgørende indledende fase af projektet, er det vanskeligt at begrænse hovsa, som lynhurtigt tager føringen over projektet.
Fakturaen risikerer at blive 40-50 procent dyrere i forhold til den oprindelige aftale, og projektet bliver forsinket i op til adskillige måneder med det kaos, det medfører i organisationen.
Start rette sted
Fejlscoping fra leverandørernes side er med mine øjne den allerstørste trussel mod virksomheder, som skal i gang med store, komplekse implementeringer. Når man starter projektet det forkerte sted, slutter man sandsynligvis langt fra mål.
I store forandringsprojekter skal alle eksisterende processer dokumenteres - ikke kun 90 procent af dem.
Kunden glemmer måske at fortælle noget i overleveringen, og hvis leverandøren ikke gør sig den ulejlighed at udarbejde en as-is-analyse - det vil sige et komplet billede af, hvordan alle processer er i dag, inden man begynder at scope de nye processer - er det vanskeligt at levere en løsning, som dækker alt det, kunden har behov for.
Der mangler nogle mellemregninger, hvis man udelukkende fokuserer på to-be - det vil sige det, kunden fortæller de har behov for - og dermed glemmer den grundige as-is.
As-is-analysen skaber transparens og kommer hovsa-hændelserne i forkøbet. Budgettet bliver lidt højere fra start, men til gengæld sparer man ekstraregningen i den anden ende og minimerer risikoen for forsinkelse.
Med as-is- og to-be-analyser får kunderne det, de ønsker - og de får det til tiden.
Stil krav
Kunderne er uden skyld. De køber en service og forventer professionel rådgivning og eksekvering på højeste niveau.
Men kunderne kan også blive mere opmærksomme på at stille krav til leverandørerne, hvilket vil bidrage til et bedre slutresultat:
- Leverandøren kommer med den bedst egnede it-løsning, men måske ikke de bedst egnede forretningskonsulenter. Derfor kan man spare sig selv for mange frustrationer og ekstraudgifter ved at få en ekstern rådgiver med om bord, som ikke er en del af leverandørteamet. Denne rådgiver holder snor i projektets udvikling fra start til slut og overvåger og forhandler budgetter.
- Scoping er ikke kun relevant i ERP-projekter men i alle typer projekter. Insistér altid på, at de eksisterende processer er dækket helt af, inden leverandøren kommer med forslag til, hvordan processerne skal se ud fremover. Først derefter kan I sammen udfærdige den korrekte kravspecifikation.
- Forlang at blive involveret i projektet fra start, så virksomheden er 100 pct. med i tilblivelsen af det nye system. Det er ofte virksomhedens rygrad, der udskiftes i forbindelse med systemskifte, og as-is og to-be lykkes ikke uden virksomhedens involvering.
- Forlang også, at Change Management og uddannelse tænkes ind allerede fra dag ét i projektet - og at dette er synligt for alle.
- Insister på transparens i projektet. Det opnår man blandt andet ved at kræve leverancerne delt op i bidder, så fejl og uhensigtsmæssigheder fanges i tide. Agilitet og SCRUM sikrer, at man hele tiden er på rette spor og nemt kan foretage små ændringer undervejs, hvis projektet drejer lidt mere til højre eller venstre end forventet. Med transparens kommer man bedre fra start og kan følge udviklingen af projektet tæt.
Er dette ny viden? Og er ovenstående nye metoder? På ingen måde.
Men omfanget af sjusk og dårlig rådgivning er efterhånden så omfattende, at kunderne skal være vanvittigt godt klædt på til at stille leverandøren de rette spørgsmål.
Selvom det burde være omvendt.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os noget tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
