10 Tips Och Tricks För Att Lyckas Med Ert Sap-projekt

3m ago
85 Views
2 Downloads
1.55 MB
6 Pages
Last View : Today
Last Download : 4d ago
Upload by : Nora Drum
Transcription

20SAPSANYTT 2/201510 tips och tricks för attlyckas med ert SAP-projektDe flesta projektledare känner säkert till Cobb’s paradox. Martin Cobb verkade som CIO för sekretariatet förTreasury Board of Canada 1995 då han ställde frågan ”If we know why projects fail and we know how toprevent their failure, why do they still fail?”. Trots att det är mer än 20 år sedan Cobb’s, till synes, triviala frågeställning ställdes är den i allra högsta grad aktuell.Vi läser fortfarande om ERP-projekt med kostnadsöverdrag, missade ”deadlines” och med störningar efterdriftsättningen. Detta bekräftas av en studie gjord av Gartner i början av 2015, där så många som 41 % av allaSAP-implementationer var försenade i förhållande till den ursprungliga tidsplanen, 31 % av projek ten överskred kostnadsbudgeten och 21 % uppnådde inte de förväntade effekterna efter projektavslut.I den här artikeln ger vi 10 tips på ”best practices” för implementering av SAP-projekt. Dessa tips är baseradepå våra samlade 20 års erfarenheter vardera i ledande befattningar inom internationella SAP-projekt. Listanär givetvis inte komplett och det finns många ytterligare exempel som skulle kunna ha hamnat på listan, mende utgör enligt oss en bra början.eracticBest P#1Säkerställ att projektet/programmet ledsav personer med praktisk erfarenhet av attframgångsrikt leda SAP-implementationer.Att ett SAP-projekt är bland det mest komplexa IT- och affärsprojekt som finns är nog väldigt många överens om. Kraven påprojekten är ofta mångfacetterade med utveckling och harmonisering av affärsprocesser, förändring av organisation i kombination med tuffa tidsplaner och ofta med en begränsadtillgång till nyckelpersoner.Inom militären finns en tydlig befälsordning och ett väl etablerat befordringssystem. Du blir inte general om du inte gåttvägen om gröntjänsten ute i förbanden och lärt dig ditt skråfrån grunden. Det gäller såväl genom teoretisk utbildning, menframförallt genom praktiskt utförande. Inom IT, (SAP är definitivt inget undantag), sker det däremot inte sällan att storaprogram/projekt leds av personer utan erfarenhet från motsvarande uppdrag. Ofta leder detta till dyrköpta erfarenhetermed överdragna budgetar, förseningar och problem efter driftsättning som resultat.Lösningen är lika enkel som självklar – se till att projektet/programmet bemannas med personer med flerårig erfarenhetav att framgångsrikt leda stora SAP-projekt. De flesta företagsom inför ett SAP-system har inte – av naturliga orsaker – justdetta som sin kärnverksamhet, men det finns det ju som bekantde företag som har. Använd deras samlade erfarenheter ochinsikter och undvik att göra de mest uppenbara misstagen.eracticBest P#2Ett SAP-system är ingen utvecklingsplattform.Det här rådet skulle också kunna ha hetat ”håll er till standard”.De flesta, om inte alla, SAP-program har detta som sin vision,men en studie av 1400 SAP-system gjord av West Trax 2013talar om en annan verklighet. Denna studie fann att upp till 45 %i ett SAP-system är anpassad kod och att mer än 40 % av denanpassade koden inte används samt att 30 % av anpassningarna direkt kan ersättas av SAP standardfunktionalitet. Studienvisar också att åtminstone 70 % av standardfunktionaliteten isystemet är oanvänd. Självklart leder detta till högre livscykelkostnad (TCO) och högre risk att framtida funktionalitet hosSAP inte kan användas fullt ut.

If we knowprojects fa whyknow how il and wetotheir failur preventthey still fae, why doil?”

22SAPSANYTT 2/2015Självklart finns olika sätt att reducera riskerna för ett modifieratsystem, men nedan ges några exempel: En jordnära, men formell ändringshantering i form(”Change Control Board”). En väl fungerande förändringsledning(”Change Management”). Starkt stöd från en engagerad högsta ledning. En tydlig definition av vad den ”globala templaten”ska innehålla och var gränserna går för vad som ärtillåtet att förändra.eracticBest P#3Börja inte med ett ”vitt papper”.Använd förkonfigurerade lösningarsom accelerator.Ert implementationsprojekt behöver inte starta från ett vittpapper. Många affärsprocesser bygger på väletablerade industristandards som oftast finns designade, utvecklade ochtestade i förkonfigurerade lösningar som t ex SAP BusinessAll-in-One eller SAP Rapid Deployment Solutions (RDS).Se till att använda dessa verktyg för att korta implementationstiden och implementera industristandards. Det är ytterstfå företag som skapar konkurrensfördelar genom att ha en egenredovisnings- eller bokslutsprocess, eller en rekryterings- ochkompetensutvecklingsprocess. Lägg istället den frigjorda tidenpå att utveckla lösningar för processer som verkligen skaparytterligare affärsnytta eller differentiering. I S/4HANA kommerdessutom många processer att vara förkonfigurerade och redoatt ”demas” direkt ur ”boxen”. Det lovar definitivt gott och ären bra utgångspunkt för en framgångsrik implementering.eracticBest P#4Använd prototyping tidigt, kombinerat medett agilt arbetssätt med tydliga milstolpar föratt skapa engagemang och förståelse!Regel no 3 innebar ju att man inte ska utveckla eget inom ”smöroch-bröd-områden”. Men för de processer som kan skapakonkurrensfördelar kan det vara värt att lägga lite extra krut.Undvik då att gå i fällan med PowerPoints och teoretiskamodeller. Att implementera ett SAP-system har den fördelenatt de framtida processerna och sättet att arbeta kan visastidigt som ett led i designarbetet. Som nämndes så kommerS/4HANA, i likhet med många lösningar, med ett antal redanfärdiga affärsprocesser som kan användas från dag ett för attskapa en bättre förståelse för hur de framtida affärsprocessernaoch IT-stödet kommer att se ut.Detta skapar en betydligt bättre förståelse, högre engagemang från nyckel- och slutanvändare samt i slutändan en merförankrad lösning. En användning av prototyping tidigt idesignarbetet är ett av de mest kraftfulla verktygen för attundvika kostsamma sena ändringar, låg användaracceptansoch risk för förseningar.Den traditionella ASAP-metodiken byggde på en klassisk,välstrukturerad vattenfallsmetod som började med kravanalys,design av lösning, utveckling/konfigurering av lösning, testosv. Ofta resulterade denna metod i långa Business Blueprint(Design) och realiseringsfaser där ingen, eller åtminstone väldigt liten, interaktion med nyckel- eller slutanvändarna förekom. Detta medförde en uppenbar risk att delar av kraven pålösningen missuppfattades samt risk för lågt engagemang ochatt lösningen i slutändan inte uppfattades uppfylla kraven.Trots att de nyare versionerna av ASAP (och även SAPActivate i framtiden) bygger på ett agilt arbetssätt körs fort farande många SAP-projekt enligt den gammalmodiga vattenfallsmetoden. Genom att använda ett agilt arbetssätt, med väldefinierade, tidssatta iterationer skapas en bättre förståelse förden framtida lösningen tidigt i projekten. Utöver detta leder ettagilt arbetssätt också till högre fokus och en större resultatorien tering, då samtliga projektmedlemmar fokuserar i detalj på vadsom ska göras de närmaste 1-2 veckorna, istället för att fokuserapå en leverans 2-3 månader fram i tiden. Jämför gärna dettamed idrottens sätt att resonera kring att ta en match i sänder.eracticBest P#5Undvik att bryta processkedjor mellanolika system.En stor fördel med ett SAP-system (förvisso alla ERP-system) äratt integrationerna mellan delprocesser och funktioner inomen värdekedja, samt mellan logistik, ekonomi, HR och grunddata redan är utvecklade och testade. Vilka delar företagenväljer att implementera, och i vilken sekvens, får ofta storakonsekvenser på komplexiteten, stabiliteten och i slutändankostnaden för projektet.Det är ofta i just gränssnitten mellan olika system, som oftabygger olika affärslogik och definitioner, som många utmaningar och problem lurar. Därför bör man noga utmana en designsom bygger på att en processkedja styckas upp i ett flertal system.Ta t ex processen ”order till fakturering” där det integrerade ERP-systemet innehåller gemensam master data ochfärdigtestade integrationer mellan delprocesser/funktioner.Men i ett fragmenterat systemlandskap skulle orderläggningenkunna utföras i ett system, leveranshanteringen i ett annat ochfaktureringen i ett tredje. Ofta leder den typen av design tilldyra, komplexa integrationer med stora utmaningar i fleradim ensioner (tekniska, svarstider, master data-hantering, felhantering etc), som i värsta fall kan få direkt negativ påverkanpå kritiska affärsprocesser.eracticBest P#6Project Preparation ska sätta fundamentetför ett framgångsrikt projekt, se till att använda tiden effektivt!Ett SAP-projekt kan liknas vid en oljetanker. Det tar tid att fåupp ångan och när den väl fått upp farten så är det svårt att fåden att stanna eller att ändra riktning. Därför är det så viktigtatt projektet startar snabbt, men framförallt att det startas upprätt från början. Alltför ofta startas program och projekt upputan en ordentlig ”Project Preparation” med otydlighet i planer,vad som ska levereras och ansvar. Många av de väletableradesystemintegratörerna arbetar med tydliga checklistor och medegna start-up-kit som redan från början har standards, mallar,

23SAPSANYTT 2/2015vittBörja inte med ettrkon-fiföndpapper. Anvärgainsnf igurerade lör.tosom acceleratala IT-komponenterna, men ännu viktigare är de logiskasystemkomponenter som styr och påverkar systemets förmågaatt leva upp till de framtida affärskraven.Ett SAP-system kan konfigureras på många olika sättberoende på vilka krav och egenskaper som ska ställas på detframtida systemet. Majoriteten av dessa krav och egenskaperska speglas i systemets konfigurering i form av antalet systeminstanser, klienter, kontoplaner, ”Operating concerns” och”Controlling areas”, för att nämna några exempel.Se till att definiera systemlandskap (enterprise structure)och namnsättningstandards mått- & objektmatris/rapporteringsdimensioner redan från början. Och se till att göra deträtt (!), det vill säga bygg inte in logik, skapa flexibilitet ochskal barhet. Annars är risken att det kommer stå er dyrt i slut ändan. Ofta upplevs detta som ett abstrakt område och därförär det inte alltför sällan som designen av dessa komponenterinte tagits på tillräckligt stort allvar och där beslut om dessafundamentala områden har tagits utan tillräcklig analys ellerutan att beslutsfattarna förstått magnituden av att dessa komponenter konfigureras på rätt sätt.Resultatet har blivit att systemet inte levt upp till förväntningarna och de utlovade möjligheterna att stödja de framtidaaffärsprocesserna. Konsekvensen har ofta lett till oerhört kostsamma erfarenheter som i sin tur många gånger har lett tillnya, dyra projekt med syftet att konsolidera och harmoniseraprocesser och IT-landskap. Detta har på senare år blivit än meraktuellt med tanke på dagens möjligheter med hybridbaseradelösningar med delar av applikationsportföljen ”on-premise”och delar i molnet.eracticBest Puppföljningsrutiner etc definierade. Se till att använda dessa ochdokumentera dessa standards och riktlinjer i en kvalitetsplan.Säkerställ dock att kvalitetsplanen blir ett operativt styr dokument som kan användas som ett verktyg i det dagligaarbetet och framförallt när nya projektmedlemmar ska introduceras och inte bara som ett prestigedokument som ska tasfram för att klara en kvalitetsgranskning eller en beslutspunkt.eracticBest P#7Säkerställ att systemets grundkomponenterär definierade tidigt baserat på en solid analys av framtida affärskrav.Ett SAP-system är uppbyggt av ett antal olika IT- och affärskomponenter som måste beslutas och definieras baserat påframtida affärs- och IT-krav. Det är uppenbart att val av hårdvaruplattform och operativsystem är två av de mest fundamen-#8Välj den första piloten noggrant och säkerställatt den blir en framgång.Det finns olika uppfattningar om huruvida man ska bygga en”global template” baserad på en verklig enhet eller om man skabasera den på en fiktiv enhet där alla krav byggs in från början.Vår uppfattning är att en ”global template” ska byggas baseradpå en verklig enhet, pilot, som då givetvis ska vara representativ för övriga enheter. Det finns många anledningar till detta,men ett av de viktigare är att få ett projekt som drivs mot verklighetsbaserade krav och mot en driftsättning som är ”på riktigt” och inte någon form av fiktiv eller teknisk ”go live”.Valet och beslutet om vilken enhet som ska vara pilot, ochdärmed vara den enhet mot vilken de globala processerna skadefinieras, byggas och verifieras samt vara den första enhetensom ska driftsättas, är därför ett av de viktigaste besluten attfatta tidigt.Självklart krävs även i detta angreppssätt att lösningenbygger på en global design av processer, grunddata, IT-komponenter och organisationsenheter samt att lösningen är globaltförankrad.Den första driftsättningen är självklart kritisk och framgången kommer att bli det viktigaste argumentet i den framtida införsäljningen, samt att de personer som varit med iprojektet blir de framtida ambassadörerna för det nya arbetssättet och sättet att implementera systemet.

24SAPSANYTT 2/2015eracticBest P#9Definiera tydligt vad den ”globala templaten”innehåller (och vad den inte innehåller).De flesta globala SAP-program baseras på en ”global template”som definieras tidigt i form av en global design. Efter att pilotenär implementerad så förväntas utrullningen ske industriellt iett snabbt tempo. Att detta är ett allmänt vedertaget och detmest effektiva sättet att arbeta är svårt att ifrågasätta, men detfinns en hel del att tydliggöra.Alltför många SAP-program är alldeles för vaga och otydliga i sina definitioner om vad den ”globala templaten” innehåller. Några refererar till de processer som den är tänkt attstötta, andra refererar till de dokument som ska levereras ellertill vilka länder som är inkluderade, och andra till något heltannat. Om något så fundamentalt inte är definierat hur kan mandå vara säker på vad som ska levereras och än mindre om lösningen uppfyller de framtida affärskraven?Det saknas utrymme i den här artikeln att ens försöka sigpå att översiktligt gå igenom vad en ”Global SAP Template”bör innehålla, men utan tvivel så behövs det en tydlighet i allatyper av SAP-program av detta.UtbyteracticBest P#10Delat ansvar är inget ansvar.Missförstå oss inte nu. Alla riktigt framgångsrika projekt vi harsett under våra 40 år tillsammans i branschen har utmärktsav kunder som går ”all in”, tar sitt ”ansvar” och tillsätter sinavassaste hjärnor. Den delen går inte att ”outsourca”. Vi brukardessutom alltid förespråka en ”speglad” projektorganisationmed representanter från både kund och leverantör på allaledande poster.Vi förstår att det är lockande att ”plocka russinen ur kakan”och att sätta ihop ett ”dream team” med experter inom respektive område. Problemet är bara att man då ofta missar mångaav de tidigare nämnda möjligheterna, dvs att använda er leverantörs acceleratorer och bandbredd fullt ut. Och om det integår som det var tänkt; vem håller ni då ansvarig?Kom ihåg: 41 % av alla SAP-implementationer gick över tid,31 % överskred budgeten och 21 % levererade inte de förväntade effekterna. Och även om ni följt våra råd vore det väl småttförmätet av oss att tro att vi just knäckt Cobb’s paradox :-)TEXT: anders E Nilsson ochjonas bjärkäng, CapgeminiSom avslutning vill vi bara konstatera att SAPtidigare i år (på SAPPHIRE) annonserade att ASAPkommer att ersättas av SAP Activate. Det ska enligtuppgift innehålla en kombination av förkonfigureradelösningar, guidad konfigurering och en metodik somär optimerad för S/4HANA som bygger på ett agiltarbetssätt. Om SAP Activate levererar vad det lovar såär det definitivt ett steg i rätt riktning!www.sapsa.seHåll dig uppdateradIMPULS är vår återkommande årskonferensdär vi under två höstdagar bjuder närmare600 personer på fler än 70 föreläsningarinom en rad olika ämnen. Hur nischad duän är i ditt SAP-arbete kan vi garantera attdu kan hitta de med samma specialområdegenom oss.Vi arrangerar också en rad andra event som ärutmärkta tillfällen för nätverkande och ovärderliga källor till inspiration och ny kunskap.Väx dig klok och stark

10 tips och tricks för att lyckas med ert sap-projekt 20 SAPSANYTT 2/2015 De flesta projektledare känner säkert till Cobb’s paradox. Martin Cobb verkade som CIO för sekretariatet för Treasury Board of Canada 1995 då han ställde frågan