To Scrum or not to Scrum?
SAP heeft met de Activate methodiek het Agile werken omarmd. Een beetje SAP S/4HANA implementatie staat bol van de daily scrums en sprints en we retrofitten wat af met z’n allen. In de praktijk blijkt dit echter weerbarstiger te zijn dan de theorie doet vermoeden. Voor het inrichten van best-practice bedrijfsprocessen is een sprintplanning goed te maken en kan in de sprint review ook een werkbaar product getoond worden. Maar hoe kan je zuiver Agile werken in een werkstroom als datamigratie? Dit artikel beschrijft een aantal belangrijke (on)mogelijkheden van een Agile datamigratie in een SAP S/4HANA implementatie.
Eerst even de setting bepalen
Om een datamigratie goed uit te voeren is een aantal disciplines nodig. Op technisch gebied kunnen we twee rollen onderscheiden:
- Iemand die de brondata uit een willekeurig systeem kan ontsluiten;
- Iemand die kundig is in de SAP Migration Cockpit om de brondata te transformeren naar SAP-formaat en deze in SAP S/4HANA kan laden.
De businesskant is vertegenwoordigd in de volgende rollen:
- Een eigenaar per dataobject. Iemand die beslissingen kan nemen over bijvoorbeeld scope en de vereiste datakwaliteit;
- Een of meerdere specialisten per dataobject. Iemand die functioneel kan beschrijven hoe de migratie van een dataobject uitgevoerd moet worden, die de brondata kan opschonen, die begrijpt hoe de brondata verrijkt moet worden met SAP-specifieke informatie, iemand die gemigreerde data kan valideren op compleetheid, juistheid, enzovoorts.
De klassieke fout is dat vaak alleen de technische man/vrouw die data in SAP kan laden in het projectteam is opgenomen. Alle overige rollen blijven belegd in de lijnorganisatie en blijven daardoor discussie geven over tijdsbesteding. Een andere klassieker is dat de key-users in het projectteam de rol van dataspecialist er even bij moet pakken. Een dergelijke werkwijze bezorgt je veel weekend- en avondwerk om de projectplanning te halen, daarnaast garandeer ik je zeker géén hoge datakwaliteit in jouw fonkelnieuwe SAP systeem.
Lost Agile werken dit probleem dan op? Maken we datamigratie onderdeel van de Scrum teams die ook processen inrichten en testen? Of is er meer aan de hand? Ik opteer voor het laatste voordat ik een conclusie kan trekken.
Datamigratie is namelijk een iteratief proces. In een SAP implementatie zijn meerdere testcycli nodig om uiteindelijk in het cut-over weekend een goede datamigratie uit te kunnen voeren. In de eerste test zal vooral gekeken worden of de migratie op technisch gebied goed werkt. Daarnaast zal er een assessment van de datakwaliteit gemaakt worden. Deze test geeft een eerste actielijst voor het opschonen en verrijken van de brondata. De tweede en derde migratietest zal normaliter laten zien dat de datakwaliteit verbetert. Dit past maar moeilijk in een Agile aanpak, waarbij elke sprint een werkbaar product moet opleveren. Want wanneer voldoet de data aan de Definition of Done? Waarschijnlijk pas na het go-live moment.
Als ik naar planningen van veel SAP projecten kijk, zie ik dat datamigratie parallel loopt aan het inrichten van de bedrijfsprocessen. Dat is simpelweg niet mogelijk. Datamigratie loopt altijd achter de muziek aan, omdat de data ondersteunend moet zijn aan de bedrijfsprocessen. Dus eerst moet het bedrijfsproces ingericht zijn voordat er een goede data definitie opgesteld kan worden.
Ook zijn er afhankelijkheden tussen de dataobjecten die team-overstijgend zijn. Neem bijvoorbeeld de SAP Material Master: Bij welk team wordt dit belegd? Welk team maakt gebruik van welke velden? Wat als een veld door meerdere processen gebruikt wordt met andere requirements? Enzovoorts. Een team kan op deze manier niet autonoom werken, één van de voordelen van Scrum als methode.
Samengevat zie ik een aantal kernproblemen bij meerdere projecten terugkomen:
- Dataspecialisten uit de business worden onvoldoende vastgelegd door het project;
- Datamigratie is een iteratief proces, waarbij de verwachtingen van datakwaliteit vooraf goed gemanaged moeten worden;
- De projectplanning houdt geen rekening met het feit dat de datadefinitie pas bekend is nadat het proces is ontwikkeld;
- Data is veelal procesoverstijgend.
En nu? Moeten we gaan scrummen of niet?
Scrum op zichzelf lost geen enkel van de beschreven problemen op, maar kan in een aantal gevallen wel helpen om een verbetering door te voeren.
Onvoldoende dataspecialisten
Hoe je het project ook inricht, als er onvoldoende dataspecialisten worden vrijgemaakt, heb je een probleem. Teams zijn in de praktijk nog steeds samengesteld rondom een bedrijfsproces, bijvoorbeeld Record 2 Report. Of de eigenaar van dit proces nu een Product Owner of een Business Process Owner wordt genoemd maakt voor datamigratie geen verschil. Maar plaats de dataspecialisten uit de business hoe dan ook in dit procesgeoriënteerde team en laat de PO of BPO deze mensen direct aansturen.
Managen van de verwachtingen per iteratie
Natuurlijk kan je spelen met de Definition of Done en die voor datamigratie bij elke sprint bijstellen. Zo kan je het iteratieve karakter behouden en tegelijk een groen stoplicht rapporteren. Maar wie hou je dan voor de gek? Laten we eerlijk zijn: de eerste migratietest laat altijd een laag niveau datakwaliteit zien. Gaandeweg het project wordt dat beter, maar Scrum als methode draagt daar niet aan bij.
Projectplanning
Een sprintplanning waarin staat dat datamigratie 2 sprints na procesinrichting gereed is, geeft een reëel beeld en voorkomt paniekvoetbal. Maar maak sowieso zichtbaar dat het ontwikkelen van datamigratie pas kan starten na de inrichting van het bedrijfsproces.
Data is proces overstijgend
Scrum lost hier niets op. Sterker nog, de autonomie van een Scrum team komt onder druk te staan als meerdere teams belang hebben bij hetzelfde dataobject. Teams zullen met elkaar in gesprek moeten blijven over procesoverstijgende zaken, zo ook over data.
Conclusie
Scrum is niet dé oplossing voor de veelvoorkomende problemen rondom datamigratie. Voor een aantal problemen draagt het zelfs helemaal niets bij. Wel kunnen elementen uit Scrum gebruikt worden om de datamigratie te versnellen of de datakwaliteit te verhogen:
- Een daily Scrum gaat zeker helpen om “kort op de bal te spelen”, focus op te houden en om snel bij te kunnen sturen;
- Als de technische mensen onderdeel uitmaken van het procesteam, verhoogt dat het wederzijds begrip van elkaars uitdagingen en kan er door de Product Owner een betere prioriteitstelling worden bepaald en een eenduidig en compleet beeld van de voortgang worden gerapporteerd;
- De aansturing van het project als geheel wordt eenduidiger als alle SAP Activate werkstromen in een Scrum team vertegenwoordigd zijn.
 |
Erwin Meerman | SAP Business consultant | LinkedIn profiel |
|---|
