I livet för nästan alla växande företag kommer det en tidpunkt då systemen och processerna som tjänat det sedan starten blir otillräckliga. Tidiga företag tenderar att växa upp med grundläggande och billiga mjukvarusystem och ett starkt beroende av ansträngningar och förmågor hos några få viktiga administrativa medarbetare. Men någon gång kan programvaran inte hålla jämna steg med verksamheten, och de betrodda anställda blir överbeskattade, vilket orsakar en kapacitetsklyfta där företaget måste vidta åtgärder för att möta affärsbehoven. Om åtgärder inte vidtas för att förbättra processer kommer denna kompetensgapet att utökas och hindra företagets förmåga att växa och konkurrera.
För de flesta företag vid denna viktiga brytpunkt görs ett val att implementera robust programvara för Enterprise Resource Planning (ERP), som integrerar alla delar av verksamheten och hjälper till att övervinna ovannämnda kapacitetsklyfta. Detta är ett enormt följdbeslut i ett företags liv och måste närma sig med ett oavbrutet fokus på riskhantering. Även om ERP kanske inte är sexigt, är det av yttersta vikt för växande företag och bör inte ignoreras.
Som en långvarig ekonomiansvarig och, på senare tid, chef för ett företag, har jag arbetat med flera implementeringar, med tre olika mjukvarupaket på både helsystems- och modulnivå. Det är tydligt att moderna företag behöver ERP, och jag är definitivt för att utnyttja det. Det är dock av yttersta vikt att ledare är fokuserade på exakt utförande under hela processen. Eftersom varje resultat av ett programvaruimplementeringsprojekt kommer att påverka verksamheten framöver, ger den här artikeln företagsledare fördelarna och riskerna med ERP samt en detaljerad steg-för-steg implementeringsguide.
ERP hänvisar till en uppsättning system som binder samman alla affärsprocesser i företaget och möjliggör flödet av data mellan processer och funktioner. Det hjälper till att standardisera, effektivisera och integrera processer över HR, ekonomi, distribution, försörjningskedja – och integrera ett företags olika aspekter i ett heltäckande system. Den underliggande mjukvaran använder en integrerad plattform och gemensamma datadefinitioner. Idag tillhandahåller ERP-system till och med affärsinformation, automatisering av säljkåren och automatisering av marknadsföring. Faktum är att de flesta e-handelswebbplatser nu är tätt kopplade till någon form av ERP-backend. En effektiv ERP-implementering kräver inte bara rätt programvara utan också noggrann dokumentation, inköp från nyckelintressenter, kommunikation med leverantörer och utbildning av anställda.
Även om det inte finns en standardtidsram för en ERP-implementering, kan det ta allt mellan sex månader och två år. Påverkan på tidslinjen varierar beroende på företag men kan inkludera företagsstorlek, överföring av data från äldre system och komplexiteten i systemet som installeras. Till skillnad från många strategiska beslut som senare kan svängas bort från, är det ovanligt att ett företag går igenom mer än en ERP-implementering.
ERP kan ge allt från ökad produktivitet och datasäkerhet till skalbarhet och kostnadsbesparingar, med de viktigaste skälen som anges nedan. När affärsprocesser och data är automatiserade och centraliserade kommer anställda att upptäcka att de har mindre manuellt arbete, får enklare rapporteringsmöjligheter och kan proaktivt hantera övergripande verksamhet med mycket färre störningar.
En anmärkningsvärd mjukvaruimplementering som jag ledde var tillägget av en bolt-on leverantörsreskontra (AP) automationsmodul i en Oracle-miljö. Modulen var skild från affärssystemet men använde samma databaser och var helt integrerad. Jag var den nya kontrollanten för en företagsgrupp på 500 miljoner dollar, och det befintliga systemet var ålderdomligt. Jag blev chockad när jag upptäckte att leverantörsreskontrateamet blandade bokstavligt papper runt 20 olika kontor, letade efter godkännandeinitialer på papper, gjorde 100 % av betalningarna på fysiska checkar och lät mig sedan signera varje check för hand. Pappersfakturor förvarades också i kartonger i sju år eller mer.
Sammantaget var det en ren implementering:Vi identifierade en tydlig möjlighet att förbättra, bestämde oss för att aggressivt driva den med den bästa tillgängliga mjukvarulösningen och lade sedan den tidiga grunden för att hantera risker genom att dokumentera våra processer noggrant och genom att söka ledningens buy-in. Resultaten inkluderade drastiskt minskade transaktionskostnader och en förbättrad förmåga att undersöka utgifternas karaktär. Jag vill betona att buy-in var viktigt. Även om jag var ny i organisationen och kände att redovisningsteamet borde bestämma sin egen policy, fick CFO mig med rätta att sälja de allmänna cheferna för varje ingående verksamhet vid implementeringen. Vi utförde med stöd av de flesta nyckelföretagsledare, särskilt de som inte var samlokaliserade med redovisningsteamet. Så småningom utökades den AP-mjukvaran, som 2014 endast var tillgänglig för USA och Kanada (65 % av den totala verksamheten), globalt över hela företaget.
Låt oss nu dyka in i stegen för ERP-implementering.
Som tidigare nämnts, ibland är ett företag vid en tydlig brytpunkt där det är uppenbart att ERP är nödvändigt:
Emellertid är ERP-implementering en i grunden riskabel strävan. Ett fullständigt misslyckande kan lamslå ett företag under en längre tid medan ett partiellt misslyckande kan skapa ineffektivitet som är svåra att åtgärda. Det bästa sättet jag kan förklara hur enormt ERP-beslutet är är att det nästan säkert kommer att bli en permanent fixtur för företaget. Den monetära investeringen är vanligtvis ganska hög, även om den kan variera, i allmänhet i linje med de största investeringarna som ett företag har gjort hittills. För ett litet företag som flyttar från Excel-kalkylblad och implementerar Microsoft Dynamics GP, kanske det är $100 000. För ett större företag kan det kosta flera miljoner dollar. Dessutom är det en stor investering från de anställda, i form av känslomässiga avgifter och utgifter för extra ansträngning.
Tänk i termer av riskhantering och identifiera nyktert vad du hoppas få ut av en ERP-implementering. Mät det mot kostnaden för en misslyckad implementering. Det är möjligt att det rätta svaret är att hålla fast vid dina nuvarande processer och att skjuta upp implementeringen av ERP. Det finns tillfällen då lägre teknik är vettigt, och vinsten förknippad med ny programvara motiverar inte kostnaden. Till exempel valde jag en gång istället att använda en frilansande programmerare baserad internationellt för att automatisera en befintlig, tråkig kostnadshanteringsmetod. Lyckligtvis gav detta försök bara en engångsavgift på 50 USD, inklusive ett tips på 20 USD – istället för en lång och dyr systemuppgradering.
Om du bestämmer dig för en ERP-implementering rekommenderar jag att du svarar på följande frågor skriftligen:
Ta dessa svar och använd dem för att uttryckligen skapa målen för implementeringsprojektet. Det kommer att finnas tillfällen under processen då du får veta att ett antagande måste ändras eller att en kompromiss måste göras. Genom att ha en klar bild av projektets krav är det mycket mindre troligt att du gör en kompromiss som orsakar betydande skada.
När du tydligt har formulerat varför du implementerar ERP, och du har bestämt att det är värt de inneboende riskerna att göra det, är det avgörande att du väljer rätt ERP-verktyg och att du implementerar det framgångsrikt. Så många som 75 % av ERP-implementeringarna lyckas inte helt uppfylla sina mål, och vi kommer att göra allt vi kan för att förbättra chanserna att lyckas genom att använda bästa praxis.
När du väl har bestämt dig för att satsa på ERP är den viktigaste uppgiften att se till att dina affärsprocesser är väldokumenterade och att de är sammanställda på ett ställe. Detta inkluderar de uppenbara stora processerna som köp-att-betala och order-till-kontanter, men bör också täcka även de mest detaljerade återkommande aktiviteterna såsom introduktion av anställda eller godkännande av tidkort. Du måste göra detta innan du tar några andra steg eftersom varje odokumenterad process blir ett antagande och varje antagande medför risker. Dessutom ger denna dokumentation ledarskap en tydlig bild av projektets omfattning, komplexitet och minimikrav.
En nyckelkomponent i ditt dokumentationsprojekt är den explicita identifieringen av informationsintressenterna vid varje steg i varje affärsprocess. Implementeringar misslyckas på de lägsta nivåerna av företag när processer inte översätts helt eller när den verkställande ledningsgruppen inte överväger nedströmseffekter. Jag har sett den här typen av misslyckanden otaliga gånger. I min senaste implementering betonade kundtjänstteamet att det fanns ett nyckelfält för kundpreferenser i det äldre systemet som var avgörande för att kunna tillhandahålla vår sedvanliga höga servicenivå. IT-projektledaren antog dock felaktigt att fältet var oväsentligt, vilket släppte kravet. Detta ledde direkt till flera kundserviceproblem genom att ta bort nyckelfunktioner från kvalitetssäkringsprocessen.
De flesta företag i tidiga skeden har inte tillräcklig dokumentation, och det är tillrådligt att söka hjälp utifrån från professionella CPA:er eller konsulter för att få ihop denna information. Det är troligt att ditt interna team saknar tid och förmåga att göra det, särskilt eftersom smala och smidiga privata företag ser övningen som motsats till smidighet.
Dessutom måste du tydligt beskriva allt som företaget gör eftersom du kommer att skicka den informationen till din värdeadderande återförsäljare (VAR), som hanterar den tekniska sidan av implementeringen och hjälper dig att anpassa din programvara. Ju mer information du kan ge en VAR, desto bättre jobb kommer de att göra. Om du inte ger en VAR mycket information, kommer de att göra antaganden för att fylla kunskapsluckan. Dessa antaganden kan baseras på deras egna erfarenheter eller på ett kort samtal med en anställd som inte har hela bilden. VARs har snäva tidslinjer och det är absolut nödvändigt för dem att de får resurser in och ut från jobb. Och eftersom de flesta företag vanligtvis bara implementerar ERP en gång, är de inte nödvändigtvis motiverade av återkommande affärer.
Tänk på risken så här:en VAR som bara förstår 30 % av din verksamhet kommer sannolikt att leverera en lösning som uppfyller 30 % av dina behov. Genom att ta fram fullständig och korrekt dokumentation innan du slutför kontraktet med en VAR, minimerar du denna risk. Detta sker på flera viktiga sätt:
I en av mina mer olyckliga erfarenheter misslyckades affärsteamet med att specificera implementeringskrav för en tätt länkad ERP/e-handelslösning. Vi fick en hemsida som i princip var oanvändbar för våra kunder. VAR:s antagande var att utseendet och känslan på vår kundvända webbplats inte spelade någon roll så länge den var tätt kopplad till affärssystemet. På affärsnivå såg vi inte webbplatsen förrän två veckor efter att den skulle släppas. För att korrigera detta ägnade vi månader åt förbättringsarbete och tiotusentals dollar i extra kostnader. Låt aldrig VAR anta.
Att välja rätt mjukvarupaket är avgörande för ERP-framgång, men det är ändå en av de mer besvärliga delarna av processen. Det är inte lätt att forska eftersom det är i VARs bästa intresse att hålla saker ogenomskinliga. Därför rekommenderar jag att du gör din robusta processdokumentation till en kortfattad beskrivning av de specifika kraven och ber VAR:er att tala specifikt om dessa krav i sina presentationer. Återigen, ju mer specifik du är, desto mer specifik blir VAR.
Jag föreslår också att du frågar VAR:er vilka andra liknande företag som använder programvaran som de säljer, och vilka VAR har arbetat med. Du bör lyssna efter indikationer på att VAR förstår din verksamhet och har arbetat med liknande krav tidigare. Om VAR säger dig att en annan verksamhet är liknande, var skeptisk.
En annan viktig faktor är om det finns något icke-standardiserat med din affärsmodell som kommer att kräva systemanpassning. Om så är fallet, är den icke-standardiserade funktionen verkligen nödvändig? Många suboptimala processer och metoder tenderar att få fäste under de första åren av små till medelstora företag. Tänk på anpassning i ditt affärssystem som inbyggd risk och kostnad. Det beror på att det med varje uppgradering av det större systemet sannolikt kommer att behövas engångsuppdateringar i den anpassade delen av programvaran. Använd den här implementeringen som ett ögonblick för att tänka om, förbättra och förenkla befintliga processer.
Du kan bespara dig själv mycket smärta och missnöje genom att förhandla kontraktet väl. Eftersom du investerade i dokumentationsprojektet kan du tydligt formulera hur "lyckat slutförande" ser ut. Jag rekommenderar starkt att du uttryckligen definierar hur framgång ser ut i kontraktet, åtminstone som ett tillägg – om det lägger till 50 sidor med flera flödesscheman och diagram, så är det så. Vanligtvis vill VAR hålla de avtalade kraven så vaga som möjligt och de vill fakturera dig på timbasis. De vill också vara de som deklarerar att processen är avslutad och tar gärna ut ytterligare avgifter för att göra det arbete som skulle ha gjorts från början. Försök att undvika VAR:s standardavtal och få ditt eget biträde inblandat. Ett optimalt resultat från din sida skulle vara ett kontrakt med fast pris, med den slutliga avskrivningen på dig. Men om en VAR är oflexibel på villkor, försök att hitta en annan leverantör av samma programvara som är mer mottaglig för förhandlingar.
Vid denna tidpunkt bör en nyckelprojektgrupp bildas för att hjälpa till med utrullningen av programvaran. Teamet bör inkludera en verkställande sponsor och en intern projektledare. Den verkställande sponsorn bör vara mycket senior, bör upprätthålla översikt och ansvar för projektmålen på hög nivå och bör formulera den övergripande strategin för det dagliga laget att genomföra. Den interna projektledaren bör vara en person med visad projektledningsförmåga. Projektledning kan vara svårt eftersom teammedlemmar i allmänhet hämtas från ett antal funktionella områden. Projektledaren saknar vanligtvis traditionell tillsynsbefogenhet över någon av de personer de leder. En effektiv projektledare kan övervinna denna utmaning och levererar på målen för projektet. En person som är certifierad som Project Management Professional (PMP) av Project Management Institute har sannolikt de nödvändiga färdigheterna.
Även över den verkställande sponsorns nivå måste det finnas ett engagemang för genomförandet från de högsta led i organisationen. Om en vd eller VD är likgiltig för projektet eller till och med märkbart oengagerad signalerar det till andra i organisationen att motstånd kan vara acceptabelt och kan skapa risker.
Till exempel, i en ekonomistyrningsposition jag hade, drev jag på för implementeringen av automatiserade leverantörsskulder och fick internt konsensus för det. När vi rullade ut mjukvaran och visade mellanchefer hur man godkänner fakturor, vägrade flera att delta. VD:n avböjde att engagera sig och ge vägledning till dessa oförsonliga chefer, och resultatet blev att godkännande delegerades till icke-ledande anställda, som med största sannolikhet saknade kunskap eller perspektiv för att adekvat utvärdera de utgifter som skulle betalas.
Den verkställande sponsorn och projektledaren behöver ha tydliga mål och tidslinjer att hantera. Du bör sikta på den långsammaste tiden på året i en säsongsbetonad verksamhet och få det första startdatumet att falla i början av den perioden. Det övergripande projektet kommer med stor sannolikhet att pågå längre än de ursprungliga förväntningarna, och du vill inte åka med att behöva starta vid en dålig tid på året.
Den sista tiden då du kan minimera risken är under tidsperioden strax före start. Tre viktiga aktiviteter sker vid denna tidpunkt (testning, utbildning och dataversion). Se till att alla får tillräcklig uppmärksamhet.
Kopplingarna mellan moduler och system måste testas utförligt för att säkerställa att data skapas och överförs som avsett. När till exempel en faktura genereras till en kund på villkor vill du försäkra dig om att modulen Kundreskontra gör att korrekta posteringar görs i modulen Huvudbok. Det lönar sig att köra parallella transaktioner i det äldre systemet, såväl som i den nya ERP-lösningen, för att säkerställa att motsvarande funktionalitet finns på plats. Var noggrann med tester och granska resultaten i detalj. Om någon del av systemet inte fungerar som planerat, förbind dig inte att gå live.
Ett klassiskt fall av ett misslyckat affärssystem var Hershey, som gick live med en SAP-lösning, och två andra bult-on system, med början 1996. VAR rekommenderade en 48-månaders process, men Hershey insisterade på att gå live om 30 månader, för att slutföra övergången före Y2K. Att implementera ett ERP-system är tillräckligt komplicerat, men att inkludera en separat supply chain-lösning och en separat CRM-lösning på en gång var också ett tecken på hybris. Hershey fattade beslutet att offra testtid för att nå sin dåliga deadline. Deras genomförande var en katastrof; Hershey kunde inte uppfylla kundorder under sin högsäsong och förlorade 100 miljoner USD i försäljning 1999 som ett resultat.
Viss utbildning kommer att ske samtidigt med testning, eftersom en nyckelanvändare eller två från varje funktionsområde i allmänhet kommer att delta. Det är dock ett misstag att lita på att dessa testare är utbildare för andra arbetare i deras områden. Ett välplanerat utbildningsprogram måste genomföras, med tillräckligt med tid för att alla teammedlemmar ska kunna lära sig. Förstå att olika människor kommer att ha olika inlärningsstilar. Människor lär sig vanligtvis bäst när de kan relatera det nya systemet till gamla processer. Ofta är aktiviteterna samma sak med ett annat namn.
Ha inte blind tro på att människor är tillräckligt vältränade. Oftare än inte, första gången som VAR säger till dig att företaget är redo att gå live, är det inte det. Bli inte heller förvånad om ett mer robust system kräver fler klick och tid på uppgiften än de äldre systemen. Processer kan ta längre tid och kan kräva att fler personer utför dem dagligen. Det skulle vara bra om du kunde vara säker på att du alltid köpte arbetskostnadsbesparingar med ERP, men ibland gör du det inte. Du handlar faktiskt med något högre arbetskostnader för förbättrad kapacitet och/eller interna kontroller. För många företag är det en affär som är värd besväret, men förvänta dig att detta är en möjlighet.
Det finns en process som sker mot slutet av varje ERP-implementering som kallas datakonvertering som låter relativt okomplicerad och godartad. Det är dock vanligtvis mycket mer problematiskt än förväntat, och det är en vanlig orsak till förseningar och problem efter lanseringen. Datakonvertering är till stor del manuellt och tråkigt arbete, och det kräver vanligtvis arbete från funktionella resurser, som är mest bekanta med datas natur. Små misstag kan skapa stora problem när data väl har migrerats, så det är bäst att se till att du har en robust metod för kvalitetssäkring.
I en implementering förlitade vi oss på att det interna IT-teamet tog detaljerade lagerdata från det äldre systemet och mappade det korrekt till motsvarande fält i den nyligen implementerade ERP-lösningen. När data manipulerades i ett kalkylblad blev delar av det felinriktade mellan raderna och helt felaktiga attribut tilldelades tusentals specifika inventeringsartiklar. Detta orsakade ineffektivitet i den dagliga uppfyllelsen när lager beställdes och ett pågående manuellt saneringsprojekt som tog sex månader att slutföra.
En viktig del av datakonvertering är datarensning. Äldre system har ett sätt att ackumulera värdelös data över tid som inte är värt att ta in i den nya systemmiljön. Några exempel på detta är ofullständiga prisofferter och information om föråldrade produkter.
Den andra nyckeldelen av processen är dataöversättning. Det finns viktiga delar av information i det äldre systemet som måste mappas till motsvarande fält i det nya systemet. Många gånger är den out-of-the-box anpassningen av de två systemen inte perfekt eller enkel. Ett bra affärssystem kommer att ha användardefinierade fält som möjliggör nödvändig datainsamling och migrering.
Eftersom uppströms delar av processen tar längre tid än förväntat blir den totala processen vanligtvis försenad. I de flesta implementeringar finns det en frestelse för aktiviteterna i senare skede att komprimeras. VAR, som vanligtvis behöver sina anställda för att gå vidare till sitt nästa projekt, kommer ofta att lägga press på att rusa. Ge inte efter för denna frestelse och/eller press. Du bör börja med mentaliteten att tidsramen för testning, utbildning och datakonvertering inte kan förkortas av någon anledning, och att den kan förlängas om det behövs.
Underförstått innebär detta att startdatumet fritt kan förlängas vid behov. Det planerade startdatumet bör heller aldrig vara kopplat till något annat nyckeldatum, som slutet av ett kvartal eller räkenskapsår. Att göra det är en enorm risk. Det bästa som en CFO eller annan verkställande ledare kan göra för att minimera riskerna i en ERP-implementering är att upprätthålla disciplin över tidslinjen och se till att start sker endast när det finns mycket komfort att människorna och programvaran är redo.
När det är dags att gå live är det bäst att kommunicera till hela organisationen att alla måste vara maximalt flexibla och tillgängliga. Jag rekommenderar att du låter alla inblandade veta att de måste vara tillgängliga för att arbeta mycket övertid under de första dagarna, inklusive den första helgen. Oavsett hur bra förberedelserna är, kommer det att finnas några oväntade utmaningar.
I min senaste implementering (för en förvärvad affärsenhet inom ett större företag) upptäckte vi i mitten av lanseringen att artikelkvantiteter bara kunde gå till två decimaler, på grund av en global systeminställning som hade ställts in 20 år tidigare. Detta tvingade oss att ändra vår prissättning och måttenhetsstruktur i farten eftersom vi insåg att vi inte kunde sälja eller spåra ett uns (0,0625 pund) av vår bulkprodukt. Det här var en liten detalj som satte oss flera dagar tillbaka.
Du bör prioritera korrekt och omedelbar laddning av din startbalansräkning vid brytdatumet. 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.”
Har du en digital "väktare" för ditt dödsbo?
Ska du köpa en livränta till ditt barnbarn?
Envelope Budget:How to Make It Work for You
Sätt att få välbefinnande att fungera för dig när du går i pension
Kan din chef få dig att gå tillbaka till jobbet?
Behöver du verkligen en CFO för ditt lilla företag?
Har du en 5-årsplan för ditt företag?
Så fungerar det för dig att arbeta med din make