Lønbehandling er kendetegnet ved at være dansk, og der findes i dag mere end 130 it-systemer på det danske marked, som virksomhederne kan vælge imellem, når de skal have understøttet deres lønbehandling.

Der er dog en meget stor forskel i udbredelsen af de enkelte systemer. Lige fra det meget lille ”hjemmelavede” lønsystem til de store professionelle lønservicebureauer og lønsystemudbydere. Der er ligeledes en stor forskel i den funktionalitet, som tilbydes, lige fra web-indtastning af oplysninger, så der kan udskrives en lønseddel, til større lønsystemer der kan foretage mere avancerede lønberegninger, indberette til eIndkomst, Danmarks Statistik etc. De store lønsystemer tilbyder desuden ofte funktionalitet til personaleadministration og udvikling.

I en opgave som HerbertNathan& Co har gennemført for nylig, har det været nødvendigt at afdække det danske marked for lønservicebureauer og lønsystemer.

Der skelnes typisk mellem lønservicebureauer, som tilbyder at håndtere hele lønbehandlingen, og lønsystemer, som skal installeres lokalt i selve virksomheden. Der er dog også udviklet cloud løsninger, hvor virksomheden anvender et web-baseret lønsystem, som er hosted centralt.

Den største spiller blandt lønservicebureauer er uden tvivl Multidata med hele 8 løsninger; Dataløn, Erhverv, Maxi, Stat, Finans, Lønservice, ERP og EPOS. Blandt andre større lønservicebureauer kan nævnes Danske lønsystemer (Danløn), Visma, PROLØN og IBM’s MLØN.

Blandt lønsystemer, som installeres lokalt i den enkelte virksomhed kan især nævnes Lessor (som også har flere versioner af deres lønsystem), EPOS, KMD Nettoløn som er målrettet virksomheder der anvender SAP, samt andre lønsystemer som er målrettet Microsoft ERP-løsninger (C5, NAV og XAL). Og så er der selvfølgelig lønsystemer, som primært henvender sig til den offentlige sektor, som f.eks. Silkeborg Løn og SLS, eller lønsystemer til banksektoren som f.eks. BEC.

Mens HR-systemet ofte er en del af ERP-pakken, så er lønsystemerne typisk selvstændige systemer, der i større eller mindre grad er integreret med ERP-løsningen. Selvom der er mange spillere på markedet, er der en tydelig koncentration omkring de største lønservicebureauer og lønsystemudbydere, som har specialiseret sig på lønområdet.

Energirige ressource er også ofte kendetegnet som meningsdannere, frontløbere, forandringsagenter og meget andet. I projekter bliver de ofte udpeget via projekt human ressorce synsvinkler, og derefter anvendt mere eller mindre bevidst i projekterne.
Jeg mener, at der er gode resultater ved at anvende disse energi bærere, som det vælges her at kalde dem, aktivt! Mig bekendt findes der kun studier af dette. Dvs. der er begrænsede evidente metoder, der f.eks. målbestemt ud fra en energiskala, kan tildele ressourcer opgaver af en sværhedsgrad, der kombinerer ressourcens viden, indsatsmuligheder og evner med energiniveauet hos ressourcen.
Vi kender det, når vi somme tider møder en person der stormer os med positiv energi for sagen, og forhåbentlig kender vi også denne energirus hos os selv. Vi har intuitivt en fornemmelse af vigtigheden af denne energi og det brændstof det bringer projekter, men ofte kniber det med tiden til at strukturere disse følelser og fornemmelser ind i konkrete vurderinger.

Jeg vurderer, at denne energifaktor udgør halvdelen af et projekts succeschance og derfor opfordres alle de der udpeger ressourcer i et projekt, til, som minimum, at vurdere om projektets ressourcer vil medføre positiv , neutral, eller negativ energi til et projekt. Såfremt der er blot nogle få negative ressourcer skal de være modsvaret af den dobbelte positive energi. I alle projekter er det forholdsvis enkelt at nedbryde, men det kræver mindst dobbelt så mange evner at opbygge og gennemføre. Energi skal derfor være et vigtigt element i ressorceudvælgelsen og styringen. Endelig skal nævnes at en person der måske generelt udstråler kritik, negativitet og pessimisme sagtens kan bringe positiv energi ind i et projekt.
Energi skal der til men det er særdeles vanskeligt at publicere energiniveauer i projekter som tørre fakta. Dermed fastholdes dette styringsredskab pt. i det skjulte, og ofte ustruktureret som følelser, mavefornemmelser og erfaringer. Hermed en opfordring til at få det lidt højere på agendaen f.eks. i forbindelse med projekt vurderinger.

Et af de nye buzzwords er cloud, men har det en reel betydning for ERP? Hvad er benefits og barrierer for cloud, og hvordan vil det påvirke IT-organisationen?

Cloud computing og SaaS (Software as a Service) er bestemt en af de 10 væsentligste trends indenfor ERP. De fleste ERP-leverandører har et bud på mobility og cloud. Med fremkomsten af tablets/smartphones er der et krav om, at ERP-systemet skal kunne tilgås fra alle steder med alle typer udstyr. Det gælder f.eks. sælgerne, som skal have adgang til salgsdata, priser m.v., eller servicemedarbejderne som skal have en mobilenhed til projekt og tidsregistrering, eller virksomhedens samarbejdspartnere som skal have adgang til en portal for selv at trække data eller indtaste direkte i ERP-systemet.

Baggrunden for cloud er blandt andet, at vi lever i en tid med knappe ressourcer og stigende pres på it-budgettet. Der er krav om at reducere omkostninger på drift og vedligehold, kombineret med at der også er behov for større fleksibilitet til at understøtte udvikling og vækst. Samtidig er der sket en teknologisk udvikling, hvor adgangen til Internet/broadband er øget væsentligt, og der findes mobile devices i alle former. Endelig er der sket en kulturel forandring, hvor især de unge har behov for at være on-line hele tiden, og der stilles stigende til brugervenligheden af de nye applikationer, som skal kunne anvendes umiddelbart og intuitivt uden nærmere instruktioner.

Nordisk Råd har i et dokument, som er udgivet i februar 2012 om Cloud Computing, anført deres definition af cloud som følgende: ”Cloud computing er et fælles begreb for pay-per-use IT services, som leveres over Internettet. En Cloud computing leverandør sælger en service, som f.eks. forretnings applikationer eller business intelligence, til en køber som har adgang til denne service gennem en web browser uden at installere eller vedligeholde software på hans eget system. Data gemmes på en server i ”skyen”, dvs. på en server hos leverandørens data center.”

Der kan fremhæves en lang række benefits ved at indføre cloud:

• Reducere omkostninger til drift og vedligehold
• Minimale omkostninger up-front
• On-demand selvbetjening
• Mulighed for hurtigt at skalere op/ned
• Fleksibilitet
• Hurtig implementeringstid
• Løbende udvikling (time-to-market)
• Uafhængighed i forhold til devices og lokation
• Stordriftsfordele
• Grønne besparelser

Men der er også barrierer:

• Lovgivning / datasikkerhed
• Tab af kontrol
• Integration på tværs af flere leverandører
• Sikkerhed

Kun få ERP-systemer leveres full-scale til cloud. Som eksempel på danske ERP-systemer der leveres til cloud kan nævnes e-conomic. SAP har også netop lanceret, at SAP Business One nu kan fås som cloud løsning. Der er tale om systemer, som er målrettet mindre virksomheder, som dels ikke behøves at bekymre sig om installation af software, drift og vedligehold, men dels heller ikke stiller store krav og kan leve med den funktionalitet, som leveres i standardløsningen.

Cloud applikationer leveres også på udvalgte områder til de større virksomheder. Her skal man være opmærksom på, at fremtidens forretningssystem skal bygges af forskellige komponenter, traditionel on-premise ERP-systemer, på forskellige outsourcing niveauer, cloud eller SaaS, og skal kunne tilgås af forskellige devices. På brugersiden vil det være mere brugervenligt – tilpasset forskellige brugeres krav – og tilgængeligt fra alle typer redskaber (PC, iPhone, iPad etc). Men på indersiden i IT-afdelingen bliver det mere komplekst, med mere infrastruktur, flere leverandører, applikationer, funktionalitet og integrationer som skal fungere i fællesskab. Kompleksiteten i den store virksomhed øges med større krav til løsningsarkitektur, problemløsning og monitorering af et kompleks systemlandskab.

Det er let at blive fanget af dette års “hype” og de potentielle benefits ved cloud. Mange økonomi/IT-chefer foranlediges til at tro, at de nye web-applikationer kan give omkostningsbesparelser i IT-organisationen, men det er vigtigt at se bagom “reklamerne” og de flotte Powerpoints og foretage en kritisk vurdering af både applikation og leverandør. Hvad nu hvis applikationen ikke opfylder forretningens behov eller leverandøren ikke er på markedet om 2-3 år?  Før man vælger cloud løsning kræver det en kritisk vurdering af både applikation og leverandør.

Business Intelligence (BI) er efterhånden blevet en kompleks størrelse. Tidligere handlede BI om rapportering og informationskuber (slice-and-dice), men i dag er dette billede meget mere komplekst. ERP-leverandørerne anser BI som de største vækstområde og flere af ERP-leverandørerne forventer at op til 50% af deres nye forretning skal komme fra BI (!). Da BI har eksisteret i rigtigt mange år findes da også en underskov af Best-of-breed (BoB) leverandører på området. Flere af disse Bob-leverandører er i de seneste år blevet opkøbt af ERP-leverandørerne med henblik på at lukke hullet, som ERP-systemerne ikke dækker.

Det er svært at definere BI fuldstændigt og fyldestgørende, da der løbende kommer nye funktioner og features og helt nye teknologier til at understøtte disse. Arkitekturmæssigt kan en BI-suite indeholde følgende arkitekturlag, hvor visse af lagene dog kan undværes i en virksomhedsspecifik markitekturmodel:

• Datalaget: Funktioner til import af data fra forskellige datakilder – der kan være tale om relationelle databaser (OLTP), analytiske databaser (OLAP/kuber), HT/XML data (web-data), dokumenter (Office-data fra regneark mv.) og andre typer strukturerede data. Da kilderne kan være mange og der kan være forskellige værktøjer er det meget vigtigt at der er standard adaptere til de gængse databaser.
• Datavarehus: Teknologi til at opbevare data i vilkårlige strukturer, dvs. i relativt fleksible datastrukturer. I datavarehuset gemmes redundante data (importerede og derved duplikerede!) i et fælles format så de er klar til at blive benyttet til rapportering. Det er væsentligt at der med de importerede data medfølger nogle såkaldte ”meta-data”, dvs. data om data, til at holde styr på hvornår data er importeret, hvilken kilde de kommer fra, hvad formålet er med data mv.
• Kubelag: Er et typisk, men dog ikke obligatorisk lag. Kuber benyttes til at udforme analysemodeller i den struktur som man typisk har behov for. Det er umuligt at forudse alle typer af dataudtræk, så i kuberne tilrettelægger man analysedata i nogle grundlæggende strukturer, f.eks. i forskellige dimensioner – det kunne være konteringsdimensionerne fra ERP-systemet, men det kunne også være andre dimensioner. Kuberne giver mulighed for på en enkelt måde at slice og dice i data for at kunne udføre ad hoc analyser på data. I visse tilfælde er kubelaget hierarkisk opbygget ift. datakonsolidering.
• Proceslag: Proceslaget indeholder funktionalitet og procesunderstøttelse til at opfylde specifikke forretningsmæssige krav – de typiske er budgetlægningsprocessen eller regnskabsprocessen, men der er også andre såsom datakvalitetssikringsfunktioner, master data management etc. Budget- og regnskabsprocesser er typisk meget procesdrevne, men understøttet af en stor mængde data typisk fra mange forskellige kilder.
• Semantisk lag: Det semantiske lag er noget relativt nyt indenfor teknologien – det dækker over at kunne danne nogle fælles databegreber på tværs af de mange data og datakilder der analyseres på. Det semantiske lag skal hjælpe slutbrugeren med at have overblik over hvad det er for rapporter de udarbejder og især hvilket indhold de har.
• Præsentationslag: Præsentationslaget er typisk det værktøj man benytter til at præsentere data, hvad enten det er i et dashboard, en papirrapport, en XML-push til en hjemmeside eller i et regneark. Der er mange forskellige værktøjer på markedet for præsentation, og det er vigtigt at BI-teknologien understøtter eksport til de forskellige værktøjer (akkurat som det er vigtigt at kunne importere fra forskellige kilder i Datakilde-laget).
• Sikkerhedslag: Sikkerhedslaget er meget vigtigt og ligger udenom alle de øvrige lag, idet man skal kunne sikre den samme dataintegritet og –sikkerhed som findes i fødesystemerne. Det er også her vigtigt at BI-systemet kan ”nedarve” de forskellige fødesystemers datasikkerhed, men også have sine egne sikkerhedsniveauer.

Flere af de væsentligste leverandører arbejder intenst med at opbygge systemporteføljen indenfor BI, så vi vil sikkert se mange flere funktionaliteter og muligvis også flere lag i modellen i den kommende tid.

Mange undrer sig nok hvorfor ERP-systemerne ikke alene kan benyttes til virksomhedens budgettering. Alle virksomheder har budgetteringen som en meget høj prioritet i forhold til at styre virksomheden, og ERP-systemer dækker jo efterhånden så mange andre funktioner. Budgettering stiller dog særlige krav til funktionalitet, procesunderstøttelse, fleksibilitet, sikkerhed og teknologi, i forhold til mange andre typer systemer, herunder altså også ERP-systemer, og derfor er det nødvendigt at have målrettede budgetsystemer.

En række undersøgelser og analyser af virksomhedernes budgetlægning viser, at langt de fleste budgetter den dag i dag registreres, behandles og rapporteres helt eller delvist i Excel regneark, hvilket gør Microsoft til den største aktør på markedet for budgetsystemer. Regneark alene som værktøj til at understøtte budgetprocessen i større, eller for den sags skyld bare mellemstore virksomheder, er dog noget usikkert og uden processtøtte, og der er derfor, over en årrække, fremkommet en lang række Best-of-Breed (BoB) budgetsystemer, som sikrer funktionel, procesmæssig samt sikkerhedsmæssig understøttelse af budgetprocessen.

Stort set samtlige ERP-systemer har fra helt fra de tidligere dage indeholdt funktionalitet til budgettering, men denne funktionalitet har været begrænset i forhold til virksomhedernes behov, hvorfor disse i høj grad har anvendt regneark til at kompensere for manglende funktionalitet. Desuden har processerne samt teknologien for budgetlægning rent funktionelt aldrig helt passet ind i rammerne af et ERP-system.

Der findes en række målrettede budgetsystemer og markedet er langt inde i en konsolideringsproces, hvor de ”bedste” BoB systemer er opkøbt af de store ERP-leverandører i erkendelsen af, at de ikke kan rumme denne funktionalitet på samme funktionsmæssige platform som ERP-systemerne. Det betyder, at budgetsystemerne nu i større eller mindre grad er en integreret del af ERP-leverandørernes stadigt stigende løsningsportefølje. Situationen i markedet for budgetsystemer kan sammenlignes med ERP-markedet i almindelighed – få store leverandører (ERP-leverandørerne), nogle nicheleverandører samt en række BoB leverandører.

Udbredelsen af målrettede budgetsystemer i virksomhederne er stigende og udgør ifølge de væsentligste leverandører et stort vækstpotentiale, hvilket peger på, at der i mange virksomheder er plads til forbedring på dette område.

Der er ikke en bestemt type virksomhed, som har behov for velfungerende budgetsystemer, og i første omgang er behovet ikke strategisk. Flere virksomheder udtrykker behov for bedre styring, både i forhold til realisering, men også i forhold til rapportering, målstyring, planlægning og budgettering. Det er derfor at leverandørerne har fokus på dette område.

Konsulentmarkedet er endnu noget begrænset eller fragmenteret, i første omgang fordi budgetsystemerne er bygget til at blive forvaltet af forretningsbrugerne og ikke af IT-teknikere. Det er dog sandsynligt at de væsentligste leverandører får opbygget et konsulent- og partnernetværk, hvis de skal udnytte det potentiale der er i markedet lige nu. Til gengæld vil det være svært at finde tilstrækkeligt med ressourcer i den nærmeste fremtid.

Korrekt scoping er en særdeles vigtig disciplin der kræver en vis indsats, men er en nødvendighed for at et projekt kan få ordentlige livsbetingelser. Projektets omfang skal defineres så præcist at man altid ved om en konkret aktuel problemstilling har indflydelse på projektet eller om dette er projektet uvedkommende. Dette sker f.eks. ved at definere projektets scope ud fra følgende synsvinkler:

-          Projektets person-ressourcer, Organisation og geografi

-          Processer / arbejdsgange

-          Integrationer internt i projektet og med projektets omverden

-          Infrastruktur og teknologier

-          Projektets forventede indsats (tid)

-          Kalendertiden afsat til projektet

-          Data der skal konverteres og nummersystemer

Er der ikke afdækket disse elementer i et projekt, så vær på vagt!

 Hvordan kan man bedømme om et projekt er på rette vej. Ofte går det jo nemt i starten, alle mener det går fint, og først et stykke henne i projektet går det galt.   En af de første ting man skal bedømme et projekt på er projektets formål!

Det skal helst kunne udtrykkes kort og tydelig forklare hvad der er meningen med projektet og deri også indeholde hvorfor projektet har sin eksistensberettigelse.

Her er et eksempel:

”Formålet med rejsekortet

 Formålet med rejsekortet er, at det skal samle landets forskellige takstområder, billetsystemer og rabatordninger i ét fælles system, som skal gøre det mere enkelt for kunderne at bruge den kollektive trafik. Selve rejsekortbilletten er et elektronisk chipkort, som kan bruges i både bus, tog og metro. Kunden kan således bruge det samme chipkort til at rejse rundt i hele landet, og prisen for rejsen udregnes uafhængigt af, hvilket trafikselskab kunden rejser med, så længe rejsen foregår med trafikselskaber, som deltager i rejsekorttakst-samarbejdet.”

(kilde: Rigsrevisionen: ”Notat til Statsrevisorerne om orientering om Rigsrevisionens undersøgelse af rejsekortprojektet”

Det ser ikke godt ud. For langt, indeholder løsningselementer og inkluderer forudsætninger.  Spændende hvordan dette projekt vil forløbe.

 Et andet eksempel:

”Formålet med projektet er at implementere et nyt system der understøtter virksomhedens strategi om udvikling og ekspansion”.

Formålet er kort. Det er udtrykt omvendt at det gamle system ikke længere kan opfylde formålet. Der ser ikke ud til af være tale om et optimeringsprojekt, men blot om en systemudskiftning der kan understøtte virksomhedens strategi. Formålsbeskrivelsen vurderes til at være i orden.

 Prøv at gå din organisations aktuelle projekter igennem, og opstil projektformålene samlet. Kniber det med en præcis formålsbeskrivelse jf. ovenstående, er det et advarselssignal på at noget kan være galt.

I et ERP-projekt, som er afsluttet for nylig, har HerbertNathan & Co medvirket til at gennemføre en årsagsanalyse på fejl, som blev fundet i implementeringsforløbet og efter go-live. Formålet med opgaven var at finde ud af, hvor og hvornår fejl opstår, og hvordan det kunne være forhindret.

Implementering af standard ERP-system indeholder normalt mindre fejl, end hvis man udvikler et system fra bunden. Dette skyldes bl.a., at funktionalitet i standard ERP-systemer anvendes af mange andre virksomheder, og derfor er blevet gennemtestet flere gange. Samtidig må det forventes, at især de større ERP-leverandører er mere professionelle og tester funktionalitet grundigt, inden systemet frigives på markedet. Fejl findes typisk de steder, hvor virksomheden selv har lavet tilpasninger (enhancements), eller hvor der er udviklet integration til andre systemer. Det anbefales derfor også, at der i testforløbet for implementering af et nyt ERP-system fokuseres på disse områder, i stedet for at teste standardfunktionalitet.

I test anvender man normalt ”V-modellen” til at beskrive, hvornår i projektforløbet, der gennemføres test, og på hvilket niveau test er relevant at gennemføre. Man kan således tale om forskellige test-faser, som f.eks. komponenttest, integrationstest, brugertest og overtagelsestest. Afhængig af projektet kan der også gennemføres andre typer tests, som f.eks. performancetest og brugervenlighedstest (usability-test). Generelt kan man sige, at jo før fejlen findes, jo billigere er det at rette. Når først systemet er gået i drift, kan selv små fejl være problematiske, fordi de er sværere at rette, og det udstilles overfor brugere og måske endda eksterne leverandører eller kunder.

I den årsagsanalyse som HerbertNathan & Co var med til at gennemføre, blev det vurderet i hvilken fase fejlen blev fundet. Samtidig blev angivet en kode for årsag til fejl. Eksempler på dette er:

• Specifikationen er uklar eller fejlbehæftet
• Standarder for programmering er ikke fulgt
• Forkert opsætning af parametre
• Dårlig planlægning af test, mangler i testmiljøer, uerfarne testressourcer etc.

Endvidere blev det for hver fejl vurderet, hvilke forbedringstiltag der kunne have været gjort, som havde forhindret, at fejlen opstod. Eksempler på dette er:

• Projektet bemandes med erfarne ressourcer
• Kvalitetssikring af designbeslutninger
• Planlægning og prioritering af test
• Etablering af testdata og testmiljøer m.v.

Ingen systemer er fejlfrie, og det kan ikke svare sig at teste 100%, med mindre man skal sende en rumraket til månen, og selv i de tilfælde har der jo som bekendt været fejl. Men man kan godt lære af egne og andres erfaringer, så antallet af fejl minimeres.

Problemet ved dette skifte er at IT overtager styringen og ansvaret for gennemførelse af de forandringer enhver ERP systemimplementering medfører. Dermed mistes forankringen hos opgavestilleren (forretningen) og dermed den naturlige interesse for at sikre at behovene bliver opfyldt i henhold til det forventede.  Nu er det ikke sådan at IT ikke kan varetage forretningens interesser, men IT’s kompetencer er typisk – ikke altid – ikke centreret omkring arbejdsprocesserne i forretningen, men derimod omkring data som processeres og integreres i forretningen.

Konsekvenserne ved ansvars- og interesseskiftene er at business casen får svært ved at blive indfriet, samt at projekterne fortaber sig i teknikaliteter og kontraktstyring fremfor fremdrift og indfrielse af gevinster. Så det enkle svar til denne blogs retoriske spørgmål er Nej, man skal så vidt muligt sørge for at implementeringen styres af forretningen. Dog skal IT deltage i projektet, da deres kompetencer også er nødvendige, men som medspillere og ikke ledere af projektet.

Hvad er god kvalitet i ERP-projekter?  Mange projekter er bundet op på implementering til en fast dead-line og indenfor et godkendt budget. Ofte er det kvaliteten af løsningen, som bliver ofret, når der ikke længere er tid og økonomi til at udvikle og teste løsningen færdig, eller sikre at alle er uddannet tilstrækkeligt.

ATP har netop vundet guld i SAP’s QA Award 2011 med Feriekontoprojektet, hvor HerbertNathan & Co har haft ansvaret for kvalitetssikring. Projektet har efterlevet følgende 10 principper, som af SAP er kendetegnende for god kvalitet:

1. Forstå såvel forretnings mål som de tekniske krav
2. Bliv enige om hvad der kan leveres indenfor den fastlagte tidsramme, og hvordan der sikres levering til tiden
3. Arbejd sammen med alle interessenter for at opnå projektets mål
4. Bliv fra starten enige om projektroller og ansvar
5. Alloker de rigtige ressourcer til projektet, med det rigtige ansvar, kompetencer og erfaringer
6. Gennemfør projektet professionelt ud fra en fastlagt metodologi
7. Identificer risici og styr dem
8. Udarbejd og styr projektet ud fra en kvalitetsplan
9. Sikr at projekt teamet forstår hvor der med fordel kan anvendes ERP standard funktionalitet
10. Foretag brugeruddannelse og forandringsstyring som en del af ERP projektet

Ved at følge de 10 ovenstående principper er det muligt at levere en løsning, som ikke alene er en projektmæssig succes, men som også leverer signifikante benefits til forretningen. Det at opnå ekstraordinære resultater er ikke et spørgsmål om held, men derimod et resultat af et nøje planlagt projektforløb, hvor kvalitetsstyring står højt på agendaen.