5 aanbevelingen voor een succesvolle BPM implementatie

Mensen die mij kennen weten dat ik in Maastricht ben opgeleid. Kenmerk van deze Universiteit is dat het systeem erop gericht is om te leren door zelf antwoorden te vinden op gestelde vragen. Hierdoor ben ik geneigd om meerdere antwoorden te zoeken op vragen die ik in het werkveld tegenkom. Pas daarna trek ik, binnen de context van mijn opdracht, mijn conclusie.

Hierdoor vind ik het lastig om hetantwoord te geven op de vraag “Wat moeten we doen om ons BPM project succesvol te laten zijn?”. Voor mij dus geen “My way or the Highway”. Maar ik kan zeker een aantal aspecten benoemen om een BPM project succesvol te laten zijn. De invulling van deze aspecten varieert van klant tot klant, en kan per situatie verschillen. Ik bespreek er hier onder 5.

Specificaties en afstemming met gebruikers
Geen BPM project kan slagen zonder duidelijke specificaties. Hieronder schaar ik voor het gemak ook de doelstelling van de implementatie en de hiermee samenhangende requirements. Deze specificaties vormen de leidraad op basis waarvan het ontwikkelteam de BPM applicatie kan realiseren. Deze specificaties moeten zo vroeg mogelijk met toekomstig gebruikers worden gevalideerd. Trek hierbij alles uit de kast, want alleen userstories en flow charts zijn onvoldoende. Denk ook aan visualisaties, prototypes, mock-ups of waar je binnen het project ook maar toe in staat bent. Wat mij betreft gelden alleen de uitgangspunten: voorkom dubbel werk en maak geen onverantwoord hoge kosten.

Een duidelijke beschrijving van de “doelarchitectuur”
Stel 100 keer een vraag over architectuur en je krijgt denk ik 100 antwoorden. Maar dat is niet erg. In de meeste gevallen geven al deze antwoorden richting die kunnen helpen je BPM project succesvoller te maken. Voor mij moet uit de architectuur duidelijk blijken welke functies en verantwoordelijkheden in welke bedrijfsapplicaties zijn belegd. Pas wanneer dit helder is kun je zonder discussie een succesvolle procesketen realiseren. Of omgekeerd: zonder duidelijke architectuur kun je je voorbereiden op de nodige beren op de “highway”.

Planning versus realisatie en lessons learned
Om scherp te blijven als team moet ook de ontwikkelsnelheid uitgedrukt in iets als uren per punt of een variatie hierop worden bewaakt. Dat betekent dat reële inschattingen van benodigde inspanning moet worden gemaakt, en dat ook moet worden “geijkt” of deze schattingen betrouwbaar zijn gebleken. Zo niet, dan moeten hier lessen voor verbetering uit worden getrokken. Let op dat alle uren tot aan livegang, bij voorkeur zelfs productiesupport na livegang worden meegeteld.

Ik vindt het prettig als schattingen op meerdere niveaus gemaakt: Van het niveau van een hele release tot aan een individuele user story. Uit verschillen op meerdere niveaus kunnen waardevolle lessen worden getrokken.

Hoewel ik geen voorstander ben van teveel administratie is het goed om steekproefsgewijs een detailanalyse te maken van de tijdsbesteding om “waste”, tijdsverlies als gevolg onnodige, dubbele of niet waarde toevoegende activiteiten, in kaart te brengen en waar mogelijk te elimineren.

Samenwerking als een verantwoordelijk team
Een goede BPM implementatie is teamwork. Dat betekent niet alleen dat je samen optimaal gebruik maakt van elkaars talenten en desnoods buiten je kennis of confortzone helpt en ondersteunt, maar ook dat je gezamenlijk verantwoordelijkheid neemt. Achteraf Excuses bedenken voor een mislukte implementatie is hierbij wat mij betreft onverantwoordelijk gedrag, tenzij bewijsvoering in 3-voud kan worden aangeleverd. Zijn specificaties bijvoorbeeld niet duidelijk: bestorm desnoods met zijn allen de afdeling met gebruikers, of doe een aanname en communiceer de consequenties wanneer achteraf de aannames onjuist bleken, maar neem verantwoordelijkheid en doe dit samen.

Communiceer, communiceer, communiceer
Last but not least mijn persoonlijke valkuil: communiceer voldoende. Ruim per dag voldoende tijd in om met elkaar te communiceren wat er goed gaat, wat er fout gaat, of we nog op schema lopen, wat ons zorgen baart, waar we een afhankelijkheid zien ontstaan, wat we extra kunnen bieden, wat we verkeerd begrepen hebben, wanneer we in productie gaan, wat we verwachten van gebruikers, wat onze aannames zijn, wat we gaan bieden, wat er gaat ontbreken et cetera. Communicatie is een belangrijk product voor het ontwikkelteam. Al te vaak worden aannames gedaan of communicatie uitgesteld omdat “er iets af moest”. Dus … en ook als reminder voor mij zelf … communiceer!