Tillbaka till bloggen

Tankar om implementering av företagsprogramvara och metoder för projektledning.

Alla projekt som hanterar en ERP-implementering, oavsett vilken metod som används eller hur faserna är märkta, är strukturerade på samma typiska sätt.

  1. Projektinitiering
  2. Planering
  3. Design
  4. Utveckling
  5. Testning
  6. Utbildning och förändringsledning
  7. Förberedelser inför driftsättning
  8. Go-Live
  9. Support efter driftsättning
  10. Projektavslutning

Och så har det varit sedan åtminstone de senaste 30 åren. När företag började använda "Agile" för projekt (och jag vet att jag tar en genväg här) förändrade det inte riktigt hur saker och ting görs; det innebar ofta bara att (detaljerad design och) utveckling och testning blev iterativa cykler.

  1. Initiering och planering
  2. Upptäckt och design
  3. Iterativ utveckling och testning
  4. Användarutbildning och förändringsledning
  5. Förberedelser inför driftsättning
  6. Idriftsättning och stabilisering
  7. Kontinuerlig förbättring

När konceptet "kontinuerlig förbättring" lades till hade inte många organisationer en aning om hur detta kunde integreras i deras organisationer, särskilt när implementeringsprojektgruppen upplöses.

Strukturen som används för att organisera ett ERP-projekt på det sätt som beskrivs i inledningen kommer från den korrekta förståelsen att en programvaruplattform stöder (eller bör stödja) en organisation: organisationens strategiska mål, organisationsstrukturen, dess geografiska närvaro, dess avdelningar, affärsprocesser, nyckeltal och alla anställdas krav på effektivt och ändamålsenligt arbete. Det innebär att projektet börjar med att analysera verksamheten, hur den fungerar idag, hur den är organiserad och vilka (strategiska) krav och mål är. Denna analys fokuserar på affärskrav, processkrav, affärsmål och mål. I mindre utsträckning fokuserar analysen på IT-kraven: det är affärsmålen och kraven som (bör) driva IT-kraven. Undantagen är migrerings- och applikationsintegrationskrav; här kommer efterfrågan från själva tekniken.

Kort sagt, den metod som används under ERP-projekt är att analysera kraven och designa den föreslagna organisationen, de (förändrade och nya) processerna och applikationerna, bygga applikationsplattformen baserat på designen och utbilda och testa de nya processerna och verktygen. Det sista steget är att driftsätta och stödja organisationen samt att lösa alla problem som organisationen stöter på under de första dagarna, veckorna eller månaderna efter driftsättningen.

Frågan är hur framgångsrika och effektiva implementeringsmetoderna baserade på ovanstående principer verkligen är. Många av dagens ERP-projekt misslyckas eller anses åtminstone vara mindre framgångsrika. Det som anses vara ett framgångsrikt projekt nuförtiden är ett projekt som åtminstone täcker funktionaliteten till en lika hög nivå som det gamla (ersatta) systemet gjorde, och det anses vara en vinst att tekniken uppdateras till dagens standarder….

Och det är märkligt, om projektet anses vara en framgång när det "enda" pluset egentligen är den nya tekniken och organisationen vad gäller kultur, processer, stöd för mål och syften, har vunnit väldigt lite eller ingenting. Frågan är, varför håller vi fortfarande fast vid metodiken?

Utmaningarna med dagens ERP-implementeringar sammanfattas bäst enligt följande:

  1. Organisationen är besviken över resultatet
  2. Projektet tar längre tid än väntat
  3. Projektet kostar mer än budgeterat
  4. Det finns frustration mellan implementeringspartnern och kunden

När vi försöker koppla dessa frustrationer till hur implementeringsprojektet är organiserat eller den metod som används, kan vi säga att följande områden är huvudorsaker till så kallade ERP-implementeringsmisslyckanden:

  1. Projektledning och styrning: Omfattningsförändringar, problem med resursallokering och tillgänglighet, och naturligtvis projektledarens oförmåga att organisera projektet på grund av bristande stöd eller för att metodiken inte är implementerad i organisationen och organisationen/ledningen inte förstår metodiken.
  2. Förändringsledning och användarutbildning: Anställda motsätter sig förändringar på grund av obekanthet eller rädsla för att bli omplacerade, eller på grund av brist på tillräcklig utbildning och kommunikation. Mängden och djupet av utbildning som krävs för att användarna ska förstå vad projektet handlar om underskattas ofta. Naturligtvis är utbildningen i användningen av det nya systemet och processerna senare i projektet för liten och ineffektiv.
  3. Kulturell och organisatorisk påverkan: Avdelningar och intressenter som inte delar ett gemensamt mål och/eller vision är ett vanligt problem för många projekt. Dessutom är projektet inte i linje med företagets strategiska mål, och dess ledning är inte villig att erkänna projektets betydelse inom detta område (och därmed en dramatisk brist på stöd), vilket är en viktig faktor för misslyckanden och frustration. Och vidare om förändringsledning: den kulturförändring som krävs för att anpassa sig till nya processer och verktyg underskattas eller till och med ignoreras, vilket återigen orsakar besvikelse och frustration. Två andra viktiga uppmärksamhetspunkter: kommunikation och flexibilitet. Ledningen förstår först projektets (förändringens) press på organisationen för sent och orsakar ett paniktillstånd som minskar viljan att vara flexibel, kreativ och öppen för anpassning till projektet. Vi märker också att ju svårare det blir, desto mer minskar kommunikationen till organisationen och glöms bort.
  4. Processomstrukturering: Som tidigare i den här artikeln betonats är det mycket mer komplext och tidskrävande än vad som förväntas eller vad organisationer är villiga att acceptera (investera i) att noggrant förstå och dokumentera befintliga processer innan man utformar nya processer eller övergår till det nya ERP-systemet. Att anpassa önskade affärsprocesser till ERP-systemets standardprocesser utan omfattande anpassningar kan vara utmanande och kan frustrera eller demotivera projektgruppen.

Är detta de enda orsakerna till frustration och projektproblem? Det är värt att notera att datamigrering ofta nämns som en utmaning för projektet. Men även om det i vissa projekt orsakar förseningar och extra kostnader, är datamigrering nästan aldrig orsaken till besvikelse eller missnöje med vad projektet tillför organisationen (det upplevda värdet). Dessutom kan svårigheter med anpassningar och integrationsutveckling orsaka, eller nästan kommer att orsaka, extra tid och kostnader. Men detta är aldrig anledningen till att folk efter driftsättning har en känsla av att inte allt som önskats eller allt som krävs levereras. Jag skulle till och med vilja påstå att det är tvärtom: det enda som verkligen mäts och kontrolleras är programvaruleveransen. Applikationens funktionalitet, migrering, anpassningar, integrationer, rapporter och så vidare är i grunden de "enkla sakerna" att hantera.

Och när projektutvärderingar visar på testning eller stöd efter implementering som utmaningar, skulle jag säga att detta snarare relaterar till dålig projektledning och/eller organisationens motivation att allokera rätt (mängd) människor och att erkänna projektets betydelse och inverkan, som nämnts tidigare.

Jag tror att orsakerna som lyfts fram ovan är orsakerna till projektmisslyckanden och kräver att vi omprövar den metod vi använder och att vi tänker på de resurser och den kompetens vi behöver för att hantera och genomföra ett ERP-projekt framgångsrikt.

Det är viktigt att nämna att en agil eller alternativ projektimplementeringsmetod har större chans att bli framgångsrik än vattenfallsmetoden, av skäl som flexibilitet och anpassningsbarhet, användarengagemang, riskreducering och förbättrad kommunikation.

Det är också viktigt att nämna att jag tror att efter ett inledande svårt projekt att implementera ett ERP-system, kommer kontinuerliga förbättringsprojekt att ha en mycket bättre chans att lyckas och organisationer kommer att uppleva mycket mer värde från dessa projekt, naturligtvis bara om dessa organisationer fortfarande tillåter dessa projekt och gör "aptit för förändring" till ett kärnvärde för organisationen. Det måste sägas i detta avseende att molnsystem har fördelen att vara det bästa verktyget för kontinuerlig förbättring.

Jag skulle vilja se detta dokument som ett diskussionsdokument och början på en diskussion i p2-i och bland partners och kunder, för att hjälpa oss att förbättra vår egen organisation och våra tjänster för att:

  1. Fastställ rätt metod
  2. Organisera vår PM-funktion
  3. Anställ de personer vi behöver för att utföra arbetet enligt metodiken
  4. Utbilda och kontinuerligt utbilda våra medarbetare för att lyckas med vår metodik
  5. Utbilda och organisera säljgruppen för att kunna sälja våra projekt
  6. Leverera projekt framgångsrikt

Jag älskar att höra era kommentarer och åsikter!

 

Skrivet av Amit Kumar

9 december 2024