Kommunerne i gang med kæmpe SAP-opgave: KMD's Opus indtager Aalborg
Der blæser SAP-vinde over danske kommuner, efter at KMD valgte at flytte de centrale it-systemer til kommunerne over på én, samlet SAP-platform, der har fået navnet Opus.
Aalborg Kommune er blandt de rigtig mange kommuner, der i disse år migrerer fra et kludetæppe af forskellige systemer og Excel-ark til én, samlet løsning. Det er en ordentlig mundfuld, forklarer projektleder Ane Elsnab om Opus-projektet, der begyndte i 2007 og varer nogle år endnu.
Hvad går projektet ud på?
»Vi skifter gradvist de kommunale administrationssystemer over til KMD's Opus suite. Det drejer sig om systemer til økonomi, løn, HR, projekt- og resursestyring, indkøb og ledelsesinformation. Det er en større omgang. Nogle af områderne, der indgår i Opus, har vi ikke et egentligt system til i dag. Så kører det måske bare i et regneark og nogle Word dokumenter.«
Hvad er målet med projektet?
»Vi har en række målsætninger og visioner. Det skal først og fremmest give mere tid til kerneydelsen på kommunernes institutioner. En børnehaveleder bruger for eksempel i dag meget tid på at slå op i forskellige systemer, der ikke hænger sammen. Nu kan de få en personaliseret indgang, hvor de kan se alle nødvendige informationer om personale, økonomi og sig selv. De kan købe ind via systemet og trække nøgletal ud i stedet for at skulle logge på alle mulige steder og selv sammenstille data.
Visionen er også at få digitaliseret flere arbejdsgange i kommunen. Der er stadig områder, hvor det foregår på blanket-maner.«
Hvad er din rolle i projektet?
»Jeg er overordnet projektleder for leverancen. Så jeg holder øje med, om KMD leverer det, vi har aftalt, i den rigtige kvalitet. Jeg skal også sørge for, at vi i kommunen træffer alle de beslutninger, der er nødvendige, i tide. Der er rigtig mange beslutninger undervejs om arbejdsgange og workflow.
Det foregår i tæt samarbejde med en række faglige projektledere på hvert område, og kommunens ledelse, der træffer de strategiske beslutninger undervejs.
Vi har sat de første dele af systemet i drift i januar på økonomiområdet. Det store ryk kommer i løbet af 2010, så vi har implementeret det meste inden 2011.
Projektet har krævet et rigtig stort forarbejde, hvor vi startede med at sende opgaven i EU-udbud i 2007. Siden KMD vandt ordren, har vi kørt en meget lang afklaringsfase sammen med KMD, hvor vi gik dybere ned i kravspecifikationen.«
Hvilken teknologi indgår i projektet?
»Opus er bygget på en SAP-platform. Så har vi et meget stort samspil med mange andre systemer, vi har i kommunen. Vi har blandt andet en del Navision-systemer, og mange fagsystemer fra KMD og andre leverandører.
Det har været rimeligt gnidningsfrit at integrere. Vi forsøger at holde os tæt op ad KMD's snitflader. Kontonummerstrukturen i Opus er dog ret forskellig fra den i andre systemer, så det har givet en lille krølle.«
Hvilke udfordringer eller problemer er I stødt på?
»Der har været mange udfordringer i sådan et projekt. Vi har døjet noget med brugerstyringen hele efteråret. Vi har mange tusinde brugere, der skal oprettes i systemet. Men måden, man håndterer brugere på i Opus, er rigtig besværlig. En bruger, der skal have bred adgang, skal oprettes op til fire gange og tildeles rettigheder fire gange.
Vi er gået i drift med 2.000 brugere, og mange af dem måtte vi oprette flere gange. Det er et stort issue. KMD er ved at udvikle en bedre brugerstyring, men vi har ikke besluttet, om vi skal købe det til.
Vi har også oplevet, at der var funktionalitet, som ikke lige blev opfyldt på den måde, vi regnede med. Det har også været en udfordring, at dele af Opus ikke kunne tages i brug fra starten af, fordi det ikke er færdigt. Så må vi fortsætte med nogle af de gamle systemer, indtil det er klar.
Fordi Opus er en løsning, der er ens for alle kommuner, har der også været områder, hvor det ikke har passet til vores workflow. Så skal vi måske ændre vores måde at gøre tingene på, så det passer til systemet. Det har vi heller ikke noget imod, for vi er meget fokuseret på, om vi kan gøre det nemmere og smartere. Hvis systemet kan hjælpe os til det, så er det fint.
Men vi kan ikke ændre det hele fra dag ét. Det er en stor implementering, så vi må tage det i etaper og kan ikke få alle effektiviseringerne fra starten af.
Har I nogle gode råd, I kan give videre?
»Det er de klassiske projekt-dyder.
Man skal have en god kravspecifikation og en god kontrakt med leverandøren. Det er rigtig svært at lave et detaljeret udbud til så stort et system, så vi brugte i høj grad use-cases, hvor vi beskrev de arbejdsgange, der skal understøttes af systemet. Så i stedet for at prøve at skrive 2.000 specifikke krav, siger use-casen egentligt meget mere om detailkravene, sammen med visioner og målsætninger, som systemet skal understøtte.
En god kontrakt er kendetegnet ved, at man aldrig skal have den frem for at diskutere, om der stod det ene eller det andet. Her er det også vigtigt med et godt samarbejde med leverandøren. Begge parter skal have en vilje til samarbejdet, og begge parter må udvise fleksibilitet.
Helt klassisk handler det også om at få topledelsens opbakning. Så kommer man betydeligt nemmere igennem. Vores topledelse interesserer sig meget for det, fordi det også handler om ledelsesinformation. Det skal give overblik til dem og til politikerne.«
Kommentarer (2)
Når systemet er en KMD-tilpasset version kan det vel give problemer med at opgradere til en nyere version af SAP?
Så er kommunen tvangsindlagt til at vente på at KMD kommer med en ny udgave af Opus?
@Andreas
Jeg er ret sikker på at svaret på dine spørgsmål er "Ja" og "Ja" (men det var måske også retoriske spørgsmål ;-).
Det er et ofte set problem med standardsystemer at de skal tilpasses i en mindre eller større grad for at passe til en organisation.
Det er derfor der er så mange konsulentfirmaer, som lever af at levere implementeringsprojekter til dette.
Også selv om onkel Larry siger "don't change our software" (ja, jeg er tidligere Oracle ansat :-).
Det er egentligt ligegyldigt hvor det kommer fra (Oracle, SAP, Concorde, Pro:Mis, ES4 - you name it)
Min erfaring er at netop tilpasningerne ofte udskyder opgraderingen af det underliggende standardsystem til ud over sidste holdbarhedsdato (= "end of support").
Når man så endelig får taget sig sammen/bliver tvunget til en opgradering, så er den så omfattende, at omkostningerne kan være større end den initielle implementering.
Og det bliver ikke billigere at tage mindre skridt.

