Business rules or business processes?

In many companies, employees are busy capturing their operations in "business processes". In defining these you face a few challenges:
• What standard do you use, for example BPMN 2.0
• What drawing tool do you use, Visio or a more sophisticated tool
• Which level of abstract do you choose, descriptive level 1; Level 2 analytical; Level 3 executable
• Will you also record the business rules in the processes, and if so, how
• How do you harmonize the processes across the locations / units / countries / etc
• How do you deal with exceptions
To start with the last point, how to handle exceptions? Often the first draft of a business process is drawn in a workshop. During the workshop a discussion with "yes-but" will occur. In other words, the right process is drawn, unfortunately there are some exceptions. After some discussion and wrangling comes the liberating word: "Let's not model exceptions, but the main process. We aim for a 95% coverage. " For the drawing, this approach is fine, unfortunately for implementation not. The automated systems to support the processes must 'understand' when anything is permissible to deviate from the 95%. Software does not understand this automatically, so there should be clear rules for that. As a result, all transactions will be enforced through the drawn process, or there is a loophole created for the exceptions. When and how the loophole is used is often ambiguous.
There is a solution that always works. Capture the business rules. Business rules can be described as 100% adequate. Just try to write all the rules in an existing process containing a decision. Drawing contain "approved / disapproved." For the approval of products, the rules could be:
• Temperature between 2 and 5 ° C
• Weight per bag between 10.0 and 10.5 kg
• Label scannable
• Packaging damage
• Etc
If one of the criteria is not satisfactory, it is clear that the process cannot continue. That is clear to everyone, and you do not draw complicated loops in the process.
In short, in order to successfully execute a change, drawing of a process is not enough. It is also essential to capture all business rules. Capturing these rules should be done by the business itself, and not by ICT. ICT should make the translation into software systems, but do not have to write the rules. Practice shows that companies that establish their rules well in advance, are 25% faster in the project implementation and reduce cost of failure with 20%!

Hoe bereik je synergie

Veel bedrijven zullen de situatie herkennen dat er overnames zijn geweest of nieuwe samenwerkingsverbanden zijn aangegaan. Over het algemeen is het doel hiervan om synergie te bereiken. Synergie bereik je niet door op het hoofdkantoor uitgebreide berekeningen van de mogelijke voordelen te maken. Op de werkvloer(en) zal er het een en ander moeten gebeuren. Producten en diensten van de betrokken partijen moeten over en weer bekend worden, en waar mogelijk geïntegreerd of geharmoniseerd. 

Bij het harmoniseren treden een aantal complicaties op. Voorbeelden van deze complicaties zijn dat de bedrijfsprocessen anders zijn, de (product) definities anders zijn en dat de ICT systemen verschillen. Dus al wil je samenwerken, dan lukt het niet door al deze complicaties.
Wat is dan de oplossing? Gebruik standaarden voor je definities, en leg je processen vast aan de hand van deze definities. Belangrijk bij deze stap is om ook de onderliggende bedrijfsregels vast te leggen. Met deze set, en uiteraard een beetje ondersteuning van tooling als YMYT, kun je het vergelijk tussen de partijen maken. Vervolgens kies je de best practice, en gaat die toepassen. Er voila, eindelijk pak je de winsten die headquarters al lang had uitgerekend!!

Regels of bedrijfsprocessen

In veel bedrijven zijn medewerkers druk bezig om de bedrijfsactiviteiten in “business processes” vast te leggen. Bij het vastleggen hiervan loop je tegen een aantal uitdagingen aan:
• Welke standaard gebruik je, bijvoorbeeld BPMN 2.0
• Welke tekentool gebruik je, Visio of een meer geavanceerde tool
• Welke diepgang hanteer je, level 1 descriptive; level 2 analytical; level 3 executable
• Leg je de bedrijfsregels ook vast bij het proces, en zo ja hoe dan
• Hoe harmoniseer je de processen over de locaties/ units/ landen/ etc
• Hoe ga je om met uitzonderingen
Om maar met het laatste punt te beginnen, hoe ga je om met uitzonderingen? Vaak wordt de eerste opzet van een bedrijfsproces in een workshop getekend. Na een tijdje ontstaat er in de workshop een discussie die met “ja-maar” begint. Met andere woorden, het getekende proces klopt, helaas zijn er ook gevallen waarin het proces toch anders verloopt. Na wat discussie en gesteggel komt dan het verlossende woord: “laten we niet de uitzonderingen modelleren, maar het hoofdproces. We streven naar een dekking van 95%”. Voor de tekening is deze aanpak prima, helaas voor de implementatie die volgt niet. De geautomatiseerde systemen die de processen moeten ondersteunen moeten immers “snappen” wanneer het even is toegestaan om van de 95% af te wijken. Software snapt dit niet vanzelf, daar moeten duidelijke regels voor zijn. Het gevolg is of dat alle transacties afgedwongen worden via het getekende proces, of dat er een achterdeurtje wordt opgezet voor de uitzonderingen. Wanneer en hoe de achterdeur gebruikt wordt, is dan vaak niet eenduidig.
Er is een oplossing die wel altijd werkt. Leg de bedrijfsregels- business rules- vast. Business rules kunnen wel 100% dekkend beschreven worden. Probeer het maar eens om in een bestaand proces bij een besluitvormingsdriekhoekje alle regels op te schrijven. Vaak staat in de tekening “goedgekeurd/ afgekeurd”. Voor het goedkeuren van producten zouden de regels kunnen zijn:
• Temperatuur tussen de 2 en 5°C
• Gewicht per zak tussen de 10,0 en 10,5 kg
• Label scanbaar
• Verpakking niet beschadigd
• Etc
Als een van de criteria niet voldoet, is het duidelijk dat het proces niet verder kan. Dat is voor iedereen duidelijk, en hoef je niet via ingewikkelde loops in het proces te tekenen.
Kortom: om succesvol een verandering door te voeren is het tekenen van een proces niet voldoende. Essentieel is ook om alle business rules vast te leggen. Het vastleggen van deze regels moet door de business zelf gebeuren, en niet door ICT. ICT moet de vertaling naar software systemen maken, maar dus niet zelf de regels opstellen. De praktijk toont aan dat bedrijven die hun regels vooraf goed vastleggen, 25% sneller zijn in de project uitvoering en dat de faalkosten met wel 20% afnemen!