Når vi rådgiver vores kunder i forbindelse med anskaffelse af standardforretningssystemer er et væsentligt element, hvordan implementeringen skal tilgås. Der tales f.eks. om vandfaldsmodel, faseopdeling, leverancemodel, agil fremgangsmåde, Scrum, prototyping og sprints. Jeg vil her se på de forskellige metoder og principper der bliver bragt til torvs og hvordan de passer i forhold til implementering af standardforretningssystemer.

Vandfaldsmodellen er velkendt. Den stammer fra softwareudvikling og består af en sekvens af faser, hvor fremdrift sker fra den ene fase til den næste, f.eks. fra krav til design. Som udgangspunkt er der intet tilbageløb i vandfaldsmodellen og dette er netop dens akilleshæl, idet det forudgående arbejde skal være korrekt for at det følgende arbejde kan blive korrekt. F.eks. skal forretningskravene være korrekt og fuldt specificeret for at det efterfølgende arbejde bliver korrekt. Dette er meget sjældent muligt – brugerne forstår endnu ikke systemet og dets muligheder, systemet kan understøtte det samme forretningsbehov, men på en anden måde. Vi ser således heller ingen leverandører der foreslår brug af vandfaldsmodellen i dens rendyrkede form. Men vi oplever mange leverandører der foreslår en faseopdelt fremgangsmåde til implementering af standardforretningssystemer. Det kan give god mening at opdele et projekt i logiske faser af opgaver. Fremgangsmåde skal ikke forveksles med vandfaldsmodellen selv om det kan ligne ved første øjekast. Men arbejdet indenfor faserne foreslås gennemført på en anden måde end de ”rene principper” fra vandfaldsmodellen.

Mange leverandører af forretningssystemer har opbygget en leverancemodel for implementering af netop deres forretningssystem. F.eks. har SAP ASAP (AcceleratedSAP), Microsoft har SureStep, Oracle har AIM (Application Implementation Methodology), Infor har Infor Deployment Method og IFS har IFS Implementation Methodology. Herudover har nogle implementeringspartnere bygget deres egen leverancemodel – nogle gange baseret på systemleverandørens leverancemodel. Modellerne er typisk baseret på erfaringer med leverandørens gennemførte projekter og er forfinet over tid. Ofte er leverancemodellerne baseret på en fasebaseret tilgang til implementeringen og en specifikation af hvilke leverancer der skal gennemføres i de forskellige faser. Leverancemodellerne kan være et stærkt værktøj for at sikre en god tilgang til implementeringen og at det er de rigtige leverancer der bliver arbejdet på. Men det er også vigtigt at være opmærksom på at det er rammeværktøjer og den succesfulde anvendelse handler om at vælge de relevante leverancer og den rette tilgang i forhold til projektet og kunden. Det er også vigtigt at få klarlagt, hvordan samarbejdet mellem kunde og leverandør reelt kommer til at foregå. Dvs. hvordan bliver kunden involveret? Benyttes der agile elementer? Afholdes der interviews eller workshops? Hvem har ansvaret for skrivearbejdet? Hvad med review og godkendelse?

En agil fremgangsmåde associeres typisk med en inkremental og iterativ fremgangsmåde, hvor alle elementer af en delopgave løses og leveres, f.eks. kravspecifikation, design, konfiguration, test og idriftsættelse. Fremgangsmåde er født ud af softwareudviklingen, hvor det Agile Manifest blev beskrevet i 2001 af en række softwareudviklere (www.agilemanifesto.org). Dette manifest beskriver en række principper for software-udvikling, dvs. omkring interaktion mellem kunde og leverandør (mellem bruger og softwareudvikler), kørende software fremfor dokumentation, samarbejde og proaktivitet mht. ændringer.

Disse agile principper giver rigtig god mening også ved implementering af standardsystemer. Det stemmer også med de ønsker vi oplever hos kunderne, nemlig omkring interaktion, samarbejde, kørende software (dog som supplement til dokumentation og ikke i stedet for dokumentation). Det er også her vi ser prototyping komme ind i billedet og egentlig blot som et begreb for, at der i samarbejdet mellem kunde og leverandør bliver lavet en konfigurering af standardsystemet som benyttes i dialogen mellem kunde og leverandør indenfor et givent forretningsområde. Men ved implementering af standardsystemet kan den agile fremgangsmåden sjældent anvendes efter alle beskrevne principper, der er således sjældent muligt at dele hele implementeringen op i inkrementer der alle gøres fuldt færdige og tages i brug. Typisk implementeres et standardforretningssystem i forholdsvis store område – f.eks. en samlet løsning for finans, lager og service. Men det aftalte scope for projektet kan sagtens deles op i inkrementer der leder frem til en samlet afsluttende test, f.eks. accepttest, hvorefter systemet tages i brug.

Scrum høres ofte nævnt når der tales om agile metoder. Scrum stammer også fra software-udvikling og er en specifik metode baseret på de agile principper. Et af grundprincipperne i Scrum anvendelse af en ’product backlog’ som er en prioriteret liste over krav, features og andre opgaver for ”produktet”. Der arbejdes i små teams og i sprints (dvs. perioder af typisk 2-3 uger). I et sprint skal de prioriterede opgaver gøres færdig og tages i brug. Centrale roller i scrum er ’product owner’ der prioriterer opgaverne og en ’scrum master’ der skal sørge for gennemførelse af sprints.

Vi ser jævnligt at leverandørernes metoder har hentet inspiration fra Scrum mht. brugen af sprints. Det betyder at nogle leverandører foreslår at hele implementering opdelt in delopgaver af samme varighed, hvilket kan være en god fremgangsmåde. Men succesen kommer ikke alene fra en opdeling i sprints, det er er naturligvis også vigtigt at det er de rigtige leverancer der bliver produceret og her kan leverancemodellen hjælpe til. Brugen af en ’product backlog’ hænger dog oftest dårligt sammen med implementering af et standardforretningssystem. Der er ikke en ”produktejer”, men flere repræsentanter fra forretningen, hvad der måske nok kunne løses. Desuden er der ikke fri prioritering af krav. Når f.eks. et ERP-system skal implementeres er der typisk et fast scope for omfanget af implementeringen. Selv om der kan være lidt fleksibilitet i prioriteringen kan det ikke sammenlignes med en ’product backlog’ hvor der løbende prioriteres og vælges ud fra.

I forhold til de forskellige muligheder for at tilgå implementering af et standardforretningssystem er den vigtigste beslutning at vælge en fremgangsmåde der passer både til det aktuelle projekt og til kunden, og ikke mindst at leverandøren har den nødvendige erfaring i eksekveringen.