6 ingrediënten voor optimaal rendement uit SAP-projecten

SAP on Azure

SAP-implementeren of migreren naar Microsoft Azure? De beheersing en -bewaking van dit soort grote en complexe projecten is vaak niet eenvoudig. Ga je scrummen of levert een Agile methodiek in de praktijk problemen op? Met de 6 ingrediënten in deze blog zorg je in iedere geval dat je project van start tot oplevering volgens plan loopt. 

1.    Breng mensen fysiek bij elkaar

SAP-projecten en migratietrajecten zijn niet exclusief IT-projecten. Je hebt te maken met onder andere interne IT, externe stakeholders, de oude en de nieuwe softwareleveranciers, en de business die ermee aan de slag moet. Haak iedereen aan zodat het geen wij-zij-verhaal wordt. Organiseer een kick-off waarbij mensen elkaar de hand kunnen geven. Dat zorgt voor een groter wij-gevoel en urgentie dan alleen contact via e-mails en telefoongesprekken. Breng relevante stakeholders bijvoorbeeld maandelijks bij elkaar om dit gevoel op peil te houden en mogelijke plooien glad te strijken. Maak daarnaast een wiki aan met alle belangrijke informatie voor de stakeholders.

2.    Zorg voor transparantie, eerlijkheid en duidelijkheid

Je moet tijdens een project altijd op elkaar kunnen rekenen. Met een eerlijke en open cultuur vermijd je fouten waar je later pas achter komt. Een gouden regel luidt daarom: doe wat je zegt en zeg wat je doet. Dat geldt ook voor het aangeven van prioriteiten. Voor de projectmanager van het SAP-project heeft het SAP-project prioriteit, maar voor een externe medewerkers misschien veel minder. Voorkom verkeerde verwachtingen en spreek duidelijk af hoeveel prioriteit ieders onderdeel heeft ten opzichte van andere werkzaamheden. Maak daarom duidelijke commitment-afspraken met de managers van degenen die meewerken aan dit project. Op die manier creëer je draagvlak en duidelijkheid.

3.    Stel de haalbare doelen

Veel organisaties willen de switch maken van de Waterfall-methodiek naar een Agile-manier van werken. Vaak gaat dat mis vanwege tijdsdruk en een kennistekort. Een team wil bijvoorbeeld 50 objecten opleveren. Men denk dat er 10 passen in 1 sprint. Na de eerste sprint zijn 2 objecten klaar en 8 niet. Vanuit Agile zou je helemaal opnieuw moeten plannen aan de hand van prioriteiten. Onder tijdsdruk houden projectteams echter vaak de oude planning aan en doen ze die 8 objecten ‘erbij’. Op die manier stapel je werk op werk en draai je iedereen een rad voor ogen. Wees daarom transparant in de actuele status en stel haalbare doelen. 

4.    Kies de juiste methodiek

Iedereen wil Agile werken, maar geeft dat wel altijd het beste resultaat? Pak je een groot SAP-project aan via de Waterfall-methodiek dan gaat SAP in één keer over van de oude naar de nieuwe digitale omgeving. Gebruik je Kanban-, Scrum- of een andere Agile-methodiek, dan gaat dat stapje voor stapje en draai je altijd twee digitale omgevingen naast elkaar. Per stap zet je één module van het oude systeem uit en in het nieuwe systeem weer aan. Dit brengt veel interfacing met zich mee en de informatie-uitwisseling tussen de twee systemen moet foutloos en goed zijn. Daarnaast is het moeilijk voor de producteigenaar de juiste prioriteit te stellen over wat eerder moet worden opgeleverd. Sales vinden het belangrijkste dat ze orders kunnen maken, magazijnmedewerkers willen orderbonnen kunnen printen. Bij dit voorbeeld is de prioriteit gemakkelijk: zonder sales, geen orders. In een groot project wordt de juiste prioriteit al snel een stuk moeilijker.

5.    Durf van de methodiek af te stappen

Agile is niet de heilige graal, maar een tussenstap naar een toekomst waarin Waterfall, Agile en DevOps elkaar aanvullen. In de mobile wereld gaan de ontwikkelingen zo snel dat je alleen maar Agile kunt werken, maar met grote, zware ERP-systemen loop je al snel tegen alle bijbehorende extra onderhoudskosten aan. Regelmatig komen projectleiders er na verloop van tijd achter dat Agile toch niet werkt vanwege het type organisatie of het soort project. Durf dan de methodiek aan te passen, voordat het project volledig ontspoort. Een SAP-project leent zich voor een Agile-werkwijze tot de integratietesten. Dan wil je checken of enkele honderden objecten samenwerken. Dat complete valt niet te vatten in Sprint-gewijze opleveringen.

6.    De data moeten klaar zijn voor de test

Functionele consultants zien testen meestal als noodzakelijk kwaad: het is tijdrovend en saai. Daarom wordt regelmatig niet diepgravend genoeg getest. Geeft een object bij bepaalde input de juiste reactie?! Prima, en door! Maar dat is natuurlijk niet goed genoeg. De tester zou meerdere variaties moeten uitvoeren. Bij functionele tests moeten de data voor 70 á 80 procent in orde zijn. Als een eindgebruiker aan de slag gaat, moeten de data 100% procent klaar zijn. Vaak is dit niet het geval vanwege de tijdsdruk die achter deze projecten zit. Genereert het systeem na oplevering een fout, dan weet je niet of het aan de ontwikkeling of de data ligt. Deze fout achterhalen kost enorm veel tijd.