Al jaren probeert men om de bedrijfsvoering inzichtelijk en meetbaar te maken. In een tijd waarin het zakelijk landschap in hoog tempo verandert is dit belangrijker dan ooit. Het is de enige manier om de concurrentie een stap voor te blijven. Een aanzienlijk deel van de oplossing lijken we nu binnen handbereik te hebben met business process model and notation (bpmn).
Iedere ondernemer streeft naar verbetering van zijn bedrijf. Om te kunnen verbeteren moet echter eerst helder zijn hoe het bedrijf op dit moment werkt. Om de huidige situatie binnen een onderneming in kaart te brengen worden onder andere bedrijfsprocessen vastgelegd.
Wanneer we de bedrijfsprocessen hebben vastgelegd, kunnen we onderzoeken waar verbeteringen mogelijk zijn. Het verbeteren van een proces kan er bijvoorbeeld toe leiden dat het proces verkort wordt door stappen weg te laten. Een andere mogelijkheid is het herkennen en verwijderen van dubbele stappen in een proces. Uiteindelijk kan het verbeteren van processen veel gevolgen hebben voor het bedrijf. Er kunnen kosten bespaard worden, de kwaliteit kan verbeterd worden, het aantal fouten kan teruggedrongen worden en uiteindelijk zal de klanttevredenheid omhoog gaan.
Verbeteren met bpmn
In de loop van de tijd zijn er verschillende technieken bedacht om processen binnen een bedrijf te beschrijven. Flow Charts, UML Use Cases, Data flow diagrammen en petrinetten zijn slechts een paar willekeurige voorbeelden. Iedere techniek heeft eigen specifieke kenmerken en geen van deze technieken voldoet perfect voor het beschrijven van bedrijfsprocessen.
Business process model and notation (bpmn 2.0) is een modelleringstechniek die specifiek is ontwikkeld met het doel om bedrijfsprocessen te modelleren. Sinds versie 2 kunnen we ook rekenen aan deze processen en bijvoorbeeld de werking van processen simuleren. Beiden zijn zeer krachtige manieren om de effectiviteit van je onderneming te verhogen. Het biedt de mogelijkheid om snel inzicht te krijgen in zwakke plekken, zodat er snel gewerkt kan worden aan verbetering.
Ondanks de krachtige mogelijkheden is bpmn toch heel toegankelijk. Bpmn is een universele taal die zelfs met weinig kennis al goed gesproken kan worden. Wanneer ondernemers zelf bpmn spreken, krijgt men niet alleen beter inzicht in het eigen bedrijf, ook overleg met externe partijen (adviseurs, ontwikkelaars) wordt veel eenvoudiger.
“All models are wrong, some are useful” -George E. P. Box
Ik ben gek op BPM en ik zal niet ontkennen dat BPMN nuttig is.
However, waar ik keer op keer tegenaan loop zijn deze twee zaken:
1) De gemiddelde manager / stakeholder / medewerker haakt al snel af als het model te complex wordt
2) Hoe beter het model is uitgewerkt, hoe extreem uitgebreider het wordt waardoor (1) optreedt.
BPMN is vooral een feestje voor de mensen van wie het hun vakgebied is, de rest heeft gewoon eenvoudigere voorstellingen van zaken nodig. Dit is gewoon een spanningsveld die elke keer plaatsvind. Hoe accurater het model hoe kleiner de groep die er wat mee kan.
Zie het plaatje bij dit artikel. Volstrekt incompleet waardoor de waarde snel verwaterd.
Niettemin raadt ik elke organisatie aan zijn processen in kaart te brengen en formaliseren.
Een model is een vereenvoudige weergave van de werkelijkheid, vaak met een leuke oppervlakte spanning maar inhoudelijk nogal magertjes.
BPMN is een standaard voor techneuten omdat simpelweg een normaal mens er geen touw aan vast kan knopen zonder uitleg. En eenduidig en simpel is het ook niet want heb in het wild al teveel dialecten en bijhorende work-arounds gezien.
Het is zeker beter als een beschrijving op een bierviltje. (Dat dan weer wel.)
Eens met bovenstaande reacties. En meer algemeen: modelleertalen zijn echt handig voor communicatie met vakgenoten om snel de boodschap over te brengen (als men zich ook aan de standaard houdt). Echter, omdat die boodschap vaak veel subtiliteiten kent, wordt de modelleertaal al snel complex. Vooral ook omdat er de neiging is om “exact” te modelleren.
In de praktijk merk ik keer op keer dat voor de gemiddelde stakeholder procesdiagrammen met flowcharts en architectuurplaten met rechthoeken en pijltjes meer dan voldoende detail is. En de subtiliteiten vertel je of schrijf je er gewoon bij in tekst als het nodig is..
Om inzicht te krijgen in de bedrijfsprocessen van een organisatie denk ik dan ook dat vaak eenvoudige modellen al voldoende helderheid scheppen. BPMN wordt pas echt interessant bij het uitontwerpen van details die dan ook geautomatiseerd uitgevoerd kunnen worden.
Kortom, BPMN is zeker interessant, maar naar mijn idee vooral voor proces-ontwerp en -realisatie en niet zozeer voor de ondernemer zelf. Die heeft voldoende aan “boxes and lines”
Mijn hemel, dat deden we al met SDM1, dat is meer als 25 jaar geleden!
Beste allemaal,
allereerst hartelijke dank voor jullie, overwegend, opbouwende reacties. Ik denk toch dat enige nuance op onderwerpen noodzakelijk is.
Allereerst is de bedoeling van een model dat het de werkelijk eenvoudiger weergeeft zodat deze beter te begrijpen is. Afhankelijk van de vraag wordt de realiteit gemodelleerd. Een model van een proces dat gebruikt wordt voor software ontwikkeling ziet er dus anders uit dan een model van een proces dat met een ondernemer besproken wordt.
Daarnaast lees ik in de reacties dat flowcharts of niet BPMN diagrammen eenvoudiger zouden zijn dan een BPMN diagram. Dit moet ik toch tegenspreken. Zo groot zijn de verschillen namelijk ook weer niet. Als mijn bovenstaande opmerking in acht wordt genomen is ook met BPMN een valide model te maken dat prima te begrijpen is.
De kracht van een taal als BPMN is juist dat het op alle niveaus toepasbaar is en dat je dus vanuit één taal kunt modelleren en niet bijvoorbeeld je flow charts hoeft te ‘vertalen’ naar iets anders, met alle gevolgen vandien.
Kortom, in mijn ogen zijn de genoemde problemen meer tekortkomingen in de kennis van de modelleur, dan een tekortkoming in de taal.
Beste mensen,
Goed om een stuk te schrijven over BPMN. Deze notatiewijze is inderdaad uitermate goed bruikbaar voor alle disciplines. Zowel het management, architecten en analisten als ontwikkelaars en beheerder kunnen BPMN lezen.
Een krachtige eigenschap van BPMN is de mogelijkheid om gelaagd te modelleren. Vanuit bedrijfsperspectief of zelfs bedrijfsoverstijgend wordt er allereerst gekeken naar ketenprocessen en bedrijfsprocessen. In de top van een groot bedrijf zijn dan een keten- en bedrijfsprocesmodel interessant.
Nu is het vervolgens de uitdaging om BPMN zo in te zetten dat bedrijfsprocessen eerst op hoog niveau gemodelleerd worden om ze vervolgens te verdiepen richting werkprocessen, processtappen of activiteiten en als laatste handelingen.
BPMN heeft grofweg drie lagen: beschrijvend, analytisch en uitvoerbaar. en zoals Anthony al aangeeft – al deze lagen zijn aan elkaar gekoppeld. Zo pas ik het ook in de praktijk toe.
Op hoog niveau ga je in gesprek met de business (beschrijvend). Let wel op: dan moeten de processen ook wel echt op hoog niveau gemodelleerd. Een niveau lager, en dat is dus een detaillering het beschrijvende/business niveau, praat je over de processen met analisten en kan je de impact van wijzigingen in het proces nog beter bepalen. Als laatste kom je op uitvoerbaar niveau. En dan wordt het mogelijk om deze processen te implementeren en zelfs te automatiseren met een Business Process Management Suite (zoals IBM BPM en Pega of Appian).
Als je BPMN op de juiste manier inzet, is het dus een uiterst krachtige notatie wijze, dat ook een open standaard is.
Business Process Managememt (BPM), Proces verbetering & performance, BPMN, BPMS en business-IT alignment passen bij elkaar!
@Eric je schrijft
“Nu is het vervolgens de uitdaging om BPMN zo in te zetten dat bedrijfsprocessen eerst op hoog niveau gemodelleerd worden om ze vervolgens te verdiepen richting werkprocessen, processtappen of activiteiten en als laatste handelingen.”
Vraagje: Hoe zorg je ervoor dat deze modellen synchroon lopen? Hoe zorg je ervoor of check je dat door wijzigingen de diverse lagen nog steeds waar zijn? Vaak zie ik dat er high level wordt gemodelleerd en dat dit model uiteindelijk niet aansluit de op de processen zoals deze wordt uitgevoerd, maar op een gegeven moment merk ik dat mensen tot verschillende conclusies komen door de laag waarop ze zich bevinden.
Als je 3 analisten een proces laat beschrijven met BPMN krijg je drie verschillende schema’s. Dat heb ik in de praktijk helaas te vaak gezien.
Dat is ongeveer hetzelfde probleem als met UML.
Als ze nu die gateways eens weglieten, dan wordt het al een stuk eenvoudiger. Laat dan de keuzen en excepties door taakvolwassen mensen uitvoeren in een activity. Een beetje conform SqEME wat volgens mij helaas een beetje uitgestorven is…
@Henri: het antwoord op je vraag is: breng gelaagdheid aan. Als je een goed BPMS toepast(zie opmerking Eric) dan kun je variaties op een proces faciliteren. Het voordeel hiervan is dat je eindelijk hergebruik maakt van zaken die al zijn gemaakt en afstapt van het credo dat de afdeling business preventie graag ziet gebeuren: one size fits all.