Het belang van een goede samenwerkingstool bij een ERP project

Tijdens een ERP project is het van belang dat de diverse projectleden goed met elkaar samenwerken. Daar hoort een tool bij die naast communicatiemogelijkheden ook een structuur biedt om de ERP werkzaamheden in goede banen te leiden. Het doel is om door middel van heldere werkafspraken met alle betrokken partijen op dezelfde manier te werken. Dat zorgt uiteindelijk voor minder ruis op de lijn en voor heldere objectieve rapportages over de scope en de status.

Een voorbeeld van een samenwerkingstool die bij ERP projecten vaak wordt gebruikt, is Microsoft Azure DevOps en JIRA (van de Atlassian groep). In dit artikel lichten we toe hoe je een dergelijke tool kan gebruiken om goed vorm te geven aan je ERP implementaties. Dit is een voorbeeld van onze eigen ervaring.

Work item logica

Deze tools werken met work items. Een work item kan eender wat zijn wat je wil opvolgen. Denk aan een taak, een requirement, een proces, een user story enzovoort. Bij een ERP project is het van belang om vooraf goed na te denken welke type work items je wil gebruiken. In dit artikel geven we een voorbeeld van diverse work item types die handig zijn tijdens een implementatie en hoe je ze logisch aan elkaar koppelt.

Processen als kapstok

Een ERP implementatie omva diverse bedrijfsprocessen. Denk aan o.a. inkoop, verkoop, logistiek, productie en finance. Elk proces heeft zijn eigen functionele wensen waar het pakket aan moet voldoen. Omdat een ERP traject erg omvangrijk is, is het cruciaal om de processtappen als kapstop te gebruiken voor alles wat verder volgt in de implementatie. Komt iemand met een specifieke user story, zorg dat deze gelinkt wordt aan het juiste proces. Wordt er ergens een fout geconstateerd, idem dito. Dit helpt enorm om tijdens het project goed in de gaten te houden wat de status is van dit proces. Zonder een dergelijke kapstok is het erg moeilijk om grip te houden op het project.

Gebruik altijd een procesboom als kapstop binnen een ERP project! Het zorgt voor een duidelijke structuur die iedereen kan plaatsen.

User Stories om de gebruikswensen te inventariseren

Een user story is een korte omschrijving die vanuit een individuele rol is geschreven. Bijvoorbeeld: “Als inkoper wil ik inzicht hebben in de voorraad zodat ik tijdig nieuwe contracten met mijn leveranciers kan afspreken.” Het geeft inzicht in het wie, wat en waarom. Alle user stories samen weerspiegelen de wensen die de eindgebruikers hebben van het systeem. Als elke user story gekoppeld wordt aan een processtap, dan heb je in je ERP project al een mooie omschrijving van de potentiële scope.

Vaak wordt een user story voor ontwikkeldoeleinden omgezet naar een functioneel ontwerp zodat voor de ontwikkelaars helder is wat ze exact moeten opleveren. Om de ontwikkelaars aan te sturen kunnen dan weer taken “Tasks” gekoppeld worden aan deze user stories. Als in een tool zoals ADO of Jira deze taken dan weer gelinkt worden aan de user stories, is het cirkeltje rond en is voor iedereen duidelijk waarom iemand aan bepaalde taken werkt.

Gaps

Het zal in elk ERP project voorkomen dat een user story niet afgedekt wordt door de software. Deze kan dan gemarkeerd worden als een gap, i.e. een gat tussen wat gewenst is en wat de software kan opleveren. In dat geval moet er eerst intern gekeken worden of deze gap acceptabel is of niet. In dat laatste geval zal er een stuk maatwerk moeten worden opgeleverd of een aanpassing in het werkproces moeten gebeuren. De stuurgroep komt dan in beeld om dit goed of af te keuren, gezien dit impact kan hebben op tijd, resources en wellicht de planning.

Ons advies is om gaps die opgelost gaan worden, opnieuw naar een User Story om te zetten, terwijl gaps die niet worden opgepakt, als gap geregistreerd te laten staan. Periodiek is het handig om door deze lijst te lopen en op basis van voortschrijdend inzicht te bepalen of het nog steeds een gap is of het wellicht door een aanpassing in de werkafspraken is afgedekt.

Issues en Bugs

Er heerst een diversiteit in hoe organisaties omgaan met de definitie van Issue en Bug in de registratiesystemen. In de werkwijze die wij omarmen, zijn issues zaken die anders werken dan verwacht of er niet zijn, maar waarvan niet 100% duidelijk is of dat missende functionaliteit is of een fout in het systeem. Met andere woorden, de experts moeten er naar kijken en bepalen of dit uiteindelijk een user story, gap of een bug is.

Een bug is namelijk een duidelijke fout in het systeem. Het doet iets anders dan wat je verwacht volgens de functionele specificaties. Hier is geen twijfel over mogelijk: het moet door de ontwikkelaar opgelost worden.

Opnieuw, het linken van issues en bugs aan een proces of aan een test case (die op zijn beurt weer aan een proces gekoppeld is), is cruciaal om de status en kwaliteit van het product op te volgen. Het is de sleutel om gericht acties uit te zetten en met de betrokken projectleden de juiste gesprekken te voeren over voortgang en prioriteit.

Test cases

Systemen zoals JIRA en ADO laten toe om ook de test cases te registreren. Als deze test cases ook weer aan de processen worden gekoppeld en vervolgens de bugs ook aan de test cases, dan is de cirkel rond. Zodra de leverancier aangeeft dat een aantal bugs zijn opgelost, is in 1 oogopslag duidelijk welke test cases opnieuw getest kunnen worden. Andersom is voor een specifieke test case snel inzichtelijk welke bugs het afronden blokkeren.

Tasks

Het work item “Tasks” zijn specifieke taken die iemand moet uitvoeren. Vaak wordt er bij de taken nog een onderverdeling meegegeven door ze een categorie mee te geven.

Maak vooraf duidelijke definities en werkafspraken

Werken met dergelijke registratiesystemen vergt discipline van zowel de leverancier als het interne project team. Men moet er op vertrouwen dat alles geregistreerd en up to date is. Hier schuilt dan ook een enorme rol voor de project manager zowel aan de klantzijde als de leverancierszijde. Het mantra “Staat het niet in het systeem, dan bestaat het niet!” werkt als een tierelier.

Neem dan ook de tijd om aan het begin van het ERP project deze structuur goed neer te zetten en duidelijke werkafspraken te maken. Het zorgt voor heldere objectieve rapportages en helpt zowel in de communicatie naar het project team en de stuurgroep als met de software leverancier. De ruimte voor ruis wordt hiermee een stuk kleiner, wat in een ERP project veel geld waard is.