I næsten enhver voksende virksomheds liv kommer der et tidspunkt, hvor de systemer og processer, der har tjent den siden starten, bliver utilstrækkelige. Virksomheder i den tidlige fase har en tendens til at vokse op med grundlæggende og billige softwaresystemer og en stor afhængighed af indsatsen og evnerne hos nogle få centrale administrative medarbejdere. Men på et tidspunkt kan softwaren ikke følge med forretningen, og de betroede medarbejdere bliver overbeskattede, hvilket forårsager et kapacitetsgab, hvor virksomheden skal tage skridt til at opfylde forretningsbehov. Hvis der ikke træffes foranstaltninger for at forbedre processer, vil denne kapacitetskløft udvides og hindre virksomhedens evne til at vokse og konkurrere.
For de fleste virksomheder på dette centrale omdrejningspunkt er der valgt at implementere robust Enterprise Resource Planning (ERP) software, som integrerer alle områder af virksomheden og hjælper med at overvinde det førnævnte kapacitetsgab. Dette er en enorm konsekvensbeslutning i en virksomheds liv og skal gribes an med et uafbrudt fokus på risikostyring. Selvom ERP måske ikke er sexet, er det af største vigtighed for virksomheder i vækst og bør ikke ignoreres.
Som mangeårig økonomicontroller og for nyligt general manager for en virksomhed, har jeg arbejdet på adskillige implementeringer ved at bruge tre forskellige softwarepakker på både helsystem- og modulniveau. Det er klart, at moderne virksomheder har brug for ERP, og jeg går bestemt ind for at udnytte det. Det er dog af afgørende betydning, at ledere er fokuseret på præcis udførelse gennem hele processen. Da ethvert resultat af et softwareimplementeringsprojekt vil påvirke virksomheden fremover, giver denne artikel virksomhedsledere fordelene og risiciene ved ERP samt en detaljeret trin-for-trin implementeringsvejledning.
ERP refererer til et sæt af systemer, der binder alle virksomhedens forretningsprocesser sammen og muliggør strømmen af data mellem processer og funktioner. Det hjælper med at standardisere, strømline og integrere processer på tværs af HR, økonomi, distribution, forsyningskæde – ved at integrere en virksomheds forskellige facetter i ét omfattende system. Den underliggende software bruger en integreret platform og fælles datadefinitioner. I dag leverer ERP-systemer endda business intelligence, salgsstyrkeautomatisering og marketingautomatisering. Faktisk er de fleste e-handelswebsteder nu tæt knyttet til en form for ERP-backend. En effektiv ERP-implementering kræver ikke kun den rigtige software, men også grundig dokumentation, buy-in fra nøgleinteressenter, kommunikation med leverandører og medarbejdertræning.
Selvom der ikke er en standard tidsramme for en ERP-implementering, kan det tage alt mellem seks måneder og to år. Påvirkninger på tidslinjen varierer fra virksomhed til virksomhed, men kan omfatte virksomhedsstørrelse, overførsel af data fra ældre systemer og kompleksiteten af det system, der installeres. I modsætning til mange strategiske beslutninger, som senere kan drejes væk fra, er det usædvanligt for en virksomhed at gennemgå mere end én ERP-implementering.
ERP kan levere alt fra øget produktivitet og datasikkerhed til skalerbarhed og omkostningsbesparelser, med de vigtigste grunde angivet nedenfor. Når forretningsprocesser og data er automatiserede og centraliserede, vil medarbejderne opleve, at de har mindre manuelt arbejde, får nemmere rapporteringsmuligheder og proaktivt kan styre overordnede operationer med langt færre afbrydelser.
En bemærkelsesværdig softwareimplementering, som jeg ledede, var tilføjelsen af et bolt-on kreditor (AP) automatiseringsmodul i et Oracle-miljø. Modulet var adskilt fra ERP-systemet, men brugte de samme databaser og var fuldt integreret. Jeg var den nye controller for en 500 millioner dollars gruppe af virksomheder, og det eksisterende system var arkaisk. Jeg var chokeret over at opdage, at kreditorteamet blandede bogstaveligt papir omkring 20 forskellige kontorer, tjekkede for godkendelsesinitialer på papir, foretog 100 % af betalingerne på fysiske checks og fik mig så til at underskrive hver check. Papirfakturaer blev også opbevaret i arkivbokse i syv år eller mere.
Overordnet set var det en ren implementering:Vi identificerede en klar mulighed for at forbedre, besluttede os for aggressivt at forfølge den med den bedst tilgængelige softwareløsning og lagde derefter det tidlige grundlag for at styre risiko ved at dokumentere vores processer grundigt og ved at søge ledelsens buy-in. Resultaterne omfattede drastisk reducerede transaktionsomkostninger og en forbedret evne til at undersøge arten af udgifter. Jeg vil gerne understrege, at buy-in var vigtigt. Selvom jeg var ny i organisationen og følte, at regnskabsteamet skulle bestemme deres egen politik, fik CFO'en mig med rette til at sælge de administrerende direktører for hver enkelt virksomhed i forbindelse med implementeringen. Vi udførte med støtte fra de fleste vigtige virksomhedsledere, især dem, der ikke var samlokaliseret med regnskabsteamet. Til sidst blev denne AP-software, som i 2014 kun var i anvendelsesområde for USA og Canada (65 % af den samlede forretning), senere udvidet globalt på tværs af virksomheden.
Lad os nu dykke ned i trinene i ERP-implementering.
Som tidligere nævnt er en virksomhed nogle gange på et klart vendepunkt, hvor det er indlysende, at ERP er nødvendigt:
Imidlertid er ERP-implementering en grundlæggende risikabel indsats. En fuldstændig fiasko kan lamme en virksomhed i en længere periode, mens en delvis fiasko kan skabe ineffektivitet, der er svære at afhjælpe. Den bedste måde, jeg kan forklare omfanget af ERP-beslutningen på, er, at det næsten helt sikkert vil være et fast inventar for virksomheden. Den monetære investering er typisk ret høj, selvom den kan variere, generelt på linje med de største anlægsudgifter, som en virksomhed har foretaget til dato. For en lille virksomhed, der flytter ud af Excel-regneark og implementerer Microsoft Dynamics GP, er det måske $100.000. For en større virksomhed kan det koste flere millioner dollars. Derudover er det en stor investering fra medarbejderne i form af følelsesmæssig belastning og udgifter til ekstra indsats.
Tænk i forhold til risikostyring og identificer nøgternt, hvad du håber at få ud af en ERP-implementering. Mål det i forhold til omkostningerne ved en mislykket implementering. Det er muligt, at det rigtige svar er at holde fast i dine nuværende processer og udskyde implementeringen af ERP. Der er tidspunkter, hvor lavere teknologi giver mening, og gevinsten forbundet med ny software ikke retfærdiggør omkostningerne. For eksempel valgte jeg engang i stedet at bruge en freelance programmør baseret internationalt til at automatisere en eksisterende, kedelig udgiftsbehandlingsmetode. Heldigvis gav denne indsats kun et engangsgebyr på 50 USD, inklusive et tip på 20 USD – i stedet for en langvarig og dyr systemopgradering.
Hvis du beslutter dig for en ERP-implementering, anbefaler jeg, at du besvarer følgende spørgsmål skriftligt:
Tag disse svar og brug dem til eksplicit at udforme målene for implementeringsprojektet. Der vil være tidspunkter i løbet af processen, hvor du får at vide, at en antagelse skal ændres, eller at der skal indgås et kompromis. Ved at have et klart overblik over projektets krav, vil du være meget mindre tilbøjelig til at indgå et kompromis, der forårsager betydelig skade.
Når du klart har formuleret, hvorfor du implementerer ERP, og du har fundet ud af, at det er de iboende risici værd, er det afgørende, at du vælger det rigtige ERP-værktøj, og at du implementerer det med succes. Så mange som 75 % af ERP-implementeringerne opfylder ikke deres mål fuldt ud, og vi vil gøre alt, hvad vi kan for at forbedre chancerne for succes ved at bruge bedste praksis.
Når du har besluttet dig for at forfølge ERP, er den vigtigste opgave at sikre, at dine forretningsprocesser er veldokumenterede, og at de er samlet ét sted. Dette inkluderer de åbenlyse store processer som indkøb-til-betal og ordre-til-kontant, men bør også dække selv de mest detaljerede tilbagevendende aktiviteter såsom medarbejder onboarding eller godkendelse af timecards. Du skal gøre dette, før du tager andre skridt, fordi enhver udokumenteret proces bliver en antagelse, og enhver antagelse indebærer risiko. Derudover giver denne dokumentation ledelse et klart overblik over projektets omfang, kompleksitet og minimumskrav.
Et nøgleelement i dit dokumentationsprojekt er den eksplicitte identifikation af informationsinteressenterne på hvert trin i hver forretningsproces. Implementeringer mislykkes på de laveste niveauer af virksomheder, når processer ikke oversættes fuldt ud, eller når det udøvende ledelsesteam ikke overvejer downstream-effekter. Jeg har set denne type fiasko utallige gange. I min seneste implementering understregede kundeserviceteamet, at der var et centralt kundepræferencefelt i det gamle system, som var afgørende for at kunne levere vores sædvanlige høje serviceniveau. IT-projektlederen antog dog fejlagtigt, at feltet var uvæsentligt, hvilket droppede kravet. Dette førte direkte til adskillige kundeserviceproblemer ved at fjerne nøglefunktionalitet fra kvalitetssikringsprocessen.
De fleste virksomheder i den tidlige fase har ikke tilstrækkelig dokumentation, og det er tilrådeligt at søge ekstern hjælp fra professionelle CPA'er eller konsulenter for at få disse oplysninger samlet. Det er sandsynligt, at dit interne team mangler tid og evner til at gøre det, især da slanke og agile private virksomheder ser øvelsen som modsætning til agility.
Derudover skal du tydeligt præcisere alt, hvad virksomheden gør, fordi du vil videregive disse oplysninger til din værditilvækste forhandler (VAR), som styrer den tekniske side af implementeringen og hjælper dig med at tilpasse din software. Jo flere oplysninger du kan give en VAR, jo bedre arbejde vil de gøre. Hvis du ikke giver en VAR meget information, vil de lave antagelser for at udfylde hullet i viden. Disse antagelser kan være baseret på deres egne erfaringer eller på en kort samtale med en medarbejder, der ikke har hele billedet. VAR'er har stramme tidslinjer, og det er bydende nødvendigt for dem, at de får ressourcer ind og ud af job. Og da de fleste virksomheder typisk kun implementerer ERP én gang, er de ikke nødvendigvis motiveret af gentagne forretninger.
Tænk på risikoen sådan her:En VAR, der kun forstår 30 % af din virksomhed, vil sandsynligvis levere en løsning, der opfylder 30 % af dine behov. Gennem udarbejdelse af fuldstændig og nøjagtig dokumentation, før du afslutter kontrakten med en VAR, minimerer du denne risiko. Dette sker på flere vigtige måder:
I en af mine mere uheldige oplevelser undlod forretningsteamet at specificere implementeringskrav til en tæt forbundet ERP/eCommerce-løsning. Vi modtog en hjemmeside, der stort set var ubrugelig for vores kunder. VAR's antagelse var, at udseendet og følelsen af vores kundevendte side ikke betød noget, så længe det var tæt knyttet til ERP-systemet. På forretningsniveau så vi først siden to uger efter, at den skulle gå live. For at korrigere for dette brugte vi måneder på forbedringsarbejde og titusindvis af dollars i ekstra omkostninger. Lad aldrig VAR antage.
At vælge den rigtige softwarepakke er afgørende for ERP-succes, men det er en af de mere belastende dele af processen. Det er ikke let at lave research, fordi det er i VARs bedste interesse at holde tingene uigennemsigtige. Derfor anbefaler jeg at gøre din robuste procesdokumentation til en kortfattet beskrivelse af de specifikke krav og bede VAR'ere om at tale specifikt til disse krav i deres præsentationer. Igen, jo mere specifik du er, jo mere specifik vil VAR være.
Jeg foreslår også at spørge VAR'er, hvilke andre lignende virksomheder bruger den software, de sælger, og hvilke VAR'er har arbejdet med. Du bør lytte efter indikationer på, at VAR forstår din virksomhed og har arbejdet med lignende krav før. Hvis VAR fortæller dig, at en forskellig virksomhed ligner hinanden, så vær skeptisk.
En anden vigtig overvejelse er, om der er noget ikke-standardiseret ved din forretningsmodel, som vil nødvendiggøre systemtilpasning. Hvis ja, er den ikke-standardfunktion virkelig nødvendig? En masse suboptimale processer og praksisser har en tendens til at tage fat i de tidlige år af små til mellemstore virksomheder. Tænk på tilpasning i dit ERP-system som indbygget risiko og omkostning. Det er fordi, med hver opgradering af det større system, vil der sandsynligvis være behov for engangsopdateringer i den tilpassede del af softwaren. Brug denne implementering som et øjeblik til at gentænke, forbedre og forenkle eksisterende processer.
Du kan spare dig selv for mange smerter og utilfredshed ved at forhandle kontrakten godt. Fordi du har investeret i dokumentationsprojektet, kan du tydeligt formulere, hvordan "succesfuld afslutning" ser ud. Jeg anbefaler stærkt, at du udtrykkeligt definerer, hvordan succes ser ud i kontrakten, i det mindste som et tillæg – hvis den tilføjer 50 sider med flere rutediagrammer og diagrammer, så må det være. Typisk ønsker VAR at holde de kontraktmæssige krav så vage som muligt, og de vil fakturere dig på timebasis. De ønsker også at være dem, der erklærer færdiggørelsen af processen og opkræver gerne ekstra gebyrer for at udføre det arbejde, der skulle have været udført fra starten. Prøv at undgå VAR's standardaftale, og få din egen advokat involveret. Et optimalt resultat fra din side ville være en kontrakt med fast pris, hvor den endelige afskrivning hviler på dig. Men hvis en VAR er ufleksibel på vilkår, så prøv at finde en anden udbyder af den samme software, der er mere modtagelig for forhandling.
På dette tidspunkt bør der dannes et nøgleprojektteam til at hjælpe med udrulningen af softwaren. Teamet bør omfatte en executive sponsor og en intern projektleder. Den udøvende sponsor bør være meget senior, bør opretholde overblik og ansvar på højt niveau for projektmålene, og bør formulere den overordnede strategi, som det daglige team skal udføre. Den interne projektleder bør være en person med demonstrerede projektledelsesevner. Projektledelse kan være vanskelig, fordi teammedlemmer generelt er hentet fra en række funktionelle områder. Projektlederen mangler typisk traditionel tilsynsmyndighed over nogen af de personer, de leder. En effektiv projektleder er i stand til at overvinde denne udfordring og leverer op til projektets mål. En person, der er certificeret som Project Management Professional (PMP) af Project Management Institute, besidder sandsynligvis de nødvendige færdigheder.
Selv over den udøvende sponsorniveau skal der være en forpligtelse til implementeringen fra de højeste rækker i organisationen. Hvis en præsident eller CEO er ligeglad med projektet eller endda mærkbart uengageret, signalerer det til andre i organisationen, at modstand kan være acceptabel og kan skabe risiko.
For eksempel, i en finansinspektørstilling, jeg havde, pressede jeg på for implementeringen af automatiserede kreditorer og opnåede intern konsensusgodkendelse for det. Da vi udrullede softwaren og viste mellemledere, hvordan man godkender fakturaer, nægtede flere at deltage. Den administrerende direktør afviste at involvere sig og give vejledning til disse uforsonlige ledere, og resultatet var, at godkendelse blev uddelegeret til ikke-ledelsesmedarbejdere, som næsten helt sikkert manglede viden eller perspektiv til tilstrækkeligt at vurdere de udgifter, der skulle betales.
Den udøvende sponsor og projektleder skal have klare mål og tidsplaner for at styre. Du bør sigte efter den langsomste tid på året i en sæsonbestemt virksomhed og få den første startdato til at falde i begyndelsen af den periode. Det overordnede projekt vil med stor sandsynlighed løbe længere end oprindelige forventninger, og du ønsker ikke at blive fanget ved at skulle starte på et dårligt tidspunkt af dit år.
Det sidste tidspunkt, hvor du kan minimere risikoen, er i tidsrummet lige før start. Tre afgørende aktiviteter finder sted på dette tidspunkt (test, træning og dataversion). Sørg for, at hver især får tilstrækkelig opmærksomhed.
Forbindelserne mellem moduler og systemer skal testes grundigt for at sikre, at data oprettes og overføres efter hensigten. Når der f.eks. genereres en faktura til en kunde på vilkår, vil du gerne sikre dig, at Debitormodulet bevirker, at de korrekte posteringer foretages i Hovedbogsmodulet. Det er umagen værd at køre parallelle transaktioner i det gamle system såvel som i den nye ERP-løsning for at sikre, at tilsvarende funktionalitet er på plads. Vær grundig med testning, og gennemgå resultaterne i detaljer. Hvis en del af systemet ikke fungerer som planlagt, skal du ikke forpligte dig til at gå live.
Et klassisk tilfælde af en fejlbehæftet ERP var Hershey, som gik live med en SAP-løsning og to andre bolt-on-systemer, begyndende i 1996. VAR anbefalede en 48-måneders proces, men Hershey insisterede på at gå live om 30 måneder for at fuldføre overgangen inden Y2K. Implementering af ét ERP-system er kompliceret nok, men at inkludere en separat forsyningskædeløsning og en separat CRM-løsning på én gang var også et tegn på hybris. Hershey tog beslutningen om at ofre testtid for at nå deres uvedkommende deadline. Deres implementering var en katastrofe; Hershey var ude af stand til at opfylde kundeordrer i deres højsæson og mistede 100 millioner dollars i salg i 1999 som et resultat.
Noget træning vil foregå samtidig med testning, da en nøglebruger eller to fra hvert funktionsområde generelt vil deltage. Det er dog en fejl at stole på, at disse testere er undervisere for andre arbejdere i deres områder. Der skal gennemføres et veltilrettelagt træningsprogram med tilstrækkelig tid til at give alle teammedlemmer mulighed for at lære. Forstå, at forskellige mennesker vil have forskellige læringsstile. Typisk lærer folk bedst, når de kan relatere det nye system til gamle processer. Ofte er aktiviteterne det samme med et andet navn.
Hav ikke blind tro på, at folk er veluddannede nok. Oftere end ikke, første gang, at VAR fortæller dig, at virksomheden er klar til at gå live, er den det ikke. Bliv heller ikke overrasket, hvis et mere robust system kræver flere klik og tid på opgaven end de gamle systemer. Processer kan tage længere tid og kan kræve, at flere mennesker udfører dem på daglig basis. Det ville være fantastisk, hvis du kunne være sikker på, at du altid købte lønomkostningsbesparelser med ERP, men nogle gange gør du det ikke. Du handler faktisk med noget højere lønomkostninger for forbedrede muligheder og/eller interne kontroller. For mange virksomheder er det en handel, der er umagen værd, men forvent, at dette er en mulighed.
Der er en proces, der sker mod slutningen af hver ERP-implementering, kaldet datakonvertering, som lyder relativt ligetil og godartet. Det er dog normalt meget mere problematisk end forventet, og det er en almindelig årsag til forsinkelser og problemer efter lanceringen. Datakonvertering er stort set manuelt og kedeligt arbejde, og det kræver normalt arbejde fra funktionelle ressourcer, som er mest bekendt med dataens karakter. Små fejl kan skabe store problemer, når først data er migreret, så det er bedst at sikre, at du har en robust tilgang til kvalitetssikring.
I en implementering stolede vi på, at det interne it-team tog detaljerede lagerdata fra det gamle system og kortlagde det korrekt til tilsvarende felter i den nyligt implementerede ERP-løsning. Efterhånden som data blev manipuleret i et regneark, blev elementer af det forkert justeret mellem rækker, og helt forkerte attributter blev tildelt tusindvis af specifikke lagervarer. Dette forårsagede ineffektivitet i den daglige opfyldelse, da lagerbeholdningen blev bestilt, og et igangværende manuel oprydningsprojekt, der tog seks måneder at fuldføre.
En vigtig del af datakonvertering er datarensning. Ældre systemer har en måde at akkumulere ubrugelige data over tid, som ikke er værd at bringe ind i det nye systemmiljø. Nogle eksempler på dette er uudfyldte pristilbud og information om forældede produkter.
Den anden nøgledel af processen er dataoversættelse. Der er nøgleoplysninger i det gamle system, som skal kortlægges til tilsvarende felter i det nye system. Mange gange er den out-of-the-box justering af de to systemer ikke perfekt eller enkel. Et godt ERP-system vil have brugerdefinerede felter, der giver mulighed for nødvendig datafangst og migrering.
Da opstrøms dele af processen tager længere tid end forventet, bliver den samlede proces normalt forsinket. I de fleste implementeringer er der en fristelse til at komprimere aktiviteterne i de senere stadier. VAR, som typisk har brug for sine folk til at gå videre til deres næste projekt, vil ofte tilføje pres for at haste. Giv ikke efter for denne fristelse og/eller pres. Du bør starte med den mentalitet, at tidsrammen for test, træning og datakonvertering ikke kan forkortes af nogen grund, og at den kan forlænges, hvis det er nødvendigt.
Underforstået betyder det, at go-live-datoen frit kan forlænges efter behov. Den planlagte startdato bør heller aldrig være bundet til nogen anden nøgledato, såsom slutningen af et kvartal eller regnskabsår. At gøre det er en stor risiko. Det bedste, en CFO eller anden executive leder kan gøre for at minimere risikoen i en ERP-implementering, er at opretholde disciplin over tidslinjen og sikre, at start kun sker, når der er en masse komfort, at folk og software er klar.
Når det er tid til at gå live, er det bedst at kommunikere til hele organisationen, at alle skal være maksimalt fleksible og tilgængelige. Jeg anbefaler at lade alle involverede vide, at de skal være til rådighed for at arbejde meget overarbejde de første dage, inklusive den første weekend. Uanset hvor god forberedelsen er, vil der være nogle uventede udfordringer.
I min seneste implementering (for en erhvervet forretningsenhed i en større virksomhed) opdagede vi midt i lanceringen, at varemængder kun kunne gå til to decimaler på grund af en global systemindstilling, der var blevet indstillet 20 år tidligere. Dette tvang os til at ændre vores prissætning og måleenhedsstruktur med det samme, fordi vi indså, at vi ikke nøjagtigt kunne sælge eller spore en ounce (0,0625 pund) af vores bulkprodukt. Dette var en lille detalje, der satte os flere dage tilbage.
Du bør prioritere den nøjagtige og øjeblikkelige indlæsning af din begyndelsesbalance på skæringsdatoen. There are many ways this can be challenging, because of the detail required to accurately and completely track the assets and liabilities in subsidiary ledgers. Inventory and accounts receivable tend to be the riskiest accounts.
Data uploads should be reviewed in granular detail because errors at this stage can be very difficult and time-consuming to correct.
Once you’re operating in the new ERP system, an enhanced ongoing support capability needs to be maintained at least for the first couple of months. It is appropriate to hold regular calls, where outstanding issues are discussed and updated.
While there are many benefits to be gained from using an ERP system, its implementation is admittedly risky. However, by employing best practices and by managing the process well, the risks can be minimized. The takeaway from this post should not be a collection of reasons not to implement ERP, but rather, some ideas for improving the chances of success.
According to authors Howard Smith and Peter Fingar, “Not all process-integration problems are technical and not all about IT. Integrating computer systems is not the same as integrating the business.”