Veel organisaties lopen tegen de grenzen van hun legacylandschap aan. Ze moeten upgraden naar een nieuwe versie van hun erp- of ander kernsysteem. Dit is te vergelijken met een openhartoperatie. Daar komt bij dat verschillende legacy-applicaties vaak niet of nauwelijks met elkaar ‘praten’, waardoor veel informatie nog altijd handmatig wordt verwerkt. Met de huidige personeelskrapte staat dat de groei van veel organisaties in de weg.
Een mooi voorbeeld zien we in logistieke omgevingen. Daar communiceren erp- en warehouse management system (wms)-systemen met tientallen of honderden verschillende systemen van toeleveranciers, transportbedrijven, klanten en douane. Op alle processen die hiermee gemoeid zijn, zijn vaak honderden verschillende business rules van toepassing, in goed Nederlands bedrijfsregels. Het zijn de spelregels en randvoorwaarden die je hanteert; de regels die bepalen hoe specifieke bedrijfsprocessen moeten worden uitgevoerd.
Die bedrijfsregels worden lang niet allemaal afgedekt door de standaardversies van het erp- en wms-pakket. Vandaar dat deze pakketten veel maatwerk kennen. En ondanks dit maatwerk vindt er, met name op de planningsafdeling, ontzettend veel handmatig werk plaats. Want het maatwerk voorziet lang niet altijd in de juiste koppelingen met andere systemen. Dit maakt het werk op planningsafdelingen complex. Het duurt maanden, zo niet jaren, voordat een planner goed is ingewerkt. Als iemand langdurig ziek wordt of het bedrijf verlaat, is dat een kleine ramp.
Rework
In zo’n omgeving zou je je processen willen automatiseren vanuit de bedrijfsregels. Regels die nu verstopt zitten in (het maatwerk binnen) het erp- en wms-systeem. Daardoor zijn ze niet voor iedereen even helder. Veel kennis zit in hoofden van mensen. Bovendien worden de regels niet automatisch goed toegepast in de communicatie met externe systemen van partners. Dit leidt tot veel fouten, met als gevolg veel rework. En dat terwijl de planningsafdeling al overbelast is.
Om dit probleem het hoofd te bieden, is er een manier van software ontwikkelen bedacht die de bedrijfsregels centraal stelt. Regels die je opstelt in de taal van de business en die daardoor voor iedereen helder zijn. Zo’n regel is bijvoorbeeld: als klanten rekeningen hebben die meer dan twee maanden open staan, dan mag sales geen nieuwe orders van die klanten aannemen. Die regels zet de low-code-software vervolgens met behulp van een zogenaamde rules engine om in werkende software. In dit geval is het dan simpelweg niet mogelijk om een order van zo’n klant in te voeren in het erp-systeem.
Verandert het bedrijf een bedrijfsregel, dan pas je die regel aan in je rules-database en dan verandert ook automatisch de applicatie mee waar die regel wordt toegepast. Tijdens de coronapandemie had je bijvoorbeeld kunnen aangeven: voor deze specifieke groep klanten rek ik de betalingstermijn tijdelijk op tot drie maanden vanwege de uitzonderlijke omstandigheden.
Low-code
Als je gaat automatiseren vanuit bedrijfsregels, gebruikmakende van een rules engine, dan programmeer je eigenlijk low-code. Deze aanpak werkt alleen net wat anders dan wat je kent van grote low-code-platformaanbieders zoals OutSystems of Mendix. Waar deze platformen uitgaan van processen en workflows – stappen die je in een bepaalde volgorde moet zetten, dus het ‘hoe’ – gaat een low-code-aanpak met bedrijfsregels uit van het ‘wat’: wat wil je bereiken en welke acties moet een bepaalde gebeurtenis bijvoorbeeld uitlokken?
Neem een inkomende container van leverancier X die te laat in het warehouse aankomt. Met een bedrijfsregelaanpak kun je zeggen: als inkomende goederen te laat aankomen, wil ik automatisch een seintje krijgen op welke klantorders dit gegeven impact heeft, zodat ik die klanten tijdig kan informeren. Bij een ‘normale’ procesgerichte manier van automatiseren zou het weken, zo niet maanden kosten om dit werkend te krijgen in je erp-systeem. Maar met een bedrijfsregelaanpak is het een kwestie van de regel schrijven en opnemen in je rules engine.
Tienduizenden berichten per dag
Het mooie is: je kunt deze methode niet alleen gebruiken voor het ontwikkelen van kleine apps, maar ook voor het automatiseren van complexe bedrijfsprocessen, waar tientallen applicaties tienduizenden berichten per dag uitwisselen. En juist die omgevingen lopen vandaag de dag vaak vast doordat legacysystemen eigenlijk vervangen moeten worden.
Met een bedrijfsregelaanpak hoef je geen openhartoperatie uit te voeren – je volledige coresysteem in één keer vervangen – maar kun je gefaseerd een modern landschap bouwen, gebruikmakende van al jaren bestaande componenten. Want je kunt met deze aanpak ook headless-applicaties ontwikkelen (applicaties zonder gebruikersinterface die zich focussen op machine-to-machine-communicatie). Je kunt dan ds componenten uit je erp-, wms-, crm- of ander systeem verbinden met andere componenten en zo een nieuwe applicatie bouwen met bestaande onderdelen. Zo versnel je innovatie én verlaag je de kosten en risico’s die gepaard gaan met it-vernieuwing.
(Auteur Frank Dignum is account executive bij USoft.)
Bedrijfsprocessen hebben niet alleen tot doel om de efficiëntie te verbeteren maar helpen ook om aan alle wet- en regelgeving te voldoen. Zo controleren EDP-auditors of bedrijfsprocessen voldoen aan wet- en regelgeving op het gebied van gegevensbeheer, privacy en beveiliging. Denk daarom dat het idee van orkestratie met bedrijfsregels in de taal van business wringt met regels van de ‘enterprise’ als we kijken naar muur van verantwoordelijkheid waar organisaties tegenaan lopen door rapportageverplichtingen met nieuwe wet- en regelgeving.
Never waste a good crisis blijft er zoiets als een verantwoordingsverplichting over doelmatigheid en rechtmatigheid, efficiëntie gaat straks ook om minder belasting van het klimaat. Want legacy die tienduizend berichten in de batch van één uur doet om vervolgens 23 uur te wachten op een volgende verwerking zou weleens groener kunnen zijn dan één-voor-één berichten te verwerken, SOA done wrong?
“processen willen automatiseren vanuit de bedrijfsregels”
de holy grail met aantekening dat men die na paar duizend jaar nog niet gevonden heeft.
Volgens het artikel loopt lowcode alweer achter.
Daarbij moet je nog steeds programmeren hoe je iets gaat oplossen.
Nee, men wil specificeren, aangeven wat je wilt en dat er daarna code uitkomt die daarvoor zorgt.
De belofte van de 5GL, al 40 jaar niet ingelost.
Ook wel benieuwd welke businessrules je er dan in stopt:
– doorvervuilen totdat imagoschade het niet meer toelaat, daarna je nieuwe groene imago uitdragen 🙂
– alle ouwe zakken eruit
– likken naar boven, trappen naar onder
– zo min mogelijk belasting betalen, anders verhuizen
– labour uitbesteden aan land waar mensenrechten niet belangrijk zijn
– zakkenvullen zolang het kan
– meteen 30.000 euro schadevergoeding voor gemaakt fouten beloven maar niet betalen en je opvolgers er mee opzadelen
– met alle trends meewaaien
– klokkeluiders ontslaan, met een neutrale reden
– strategie copieren van andere bedrijven, kun je nooit echt iets fout doen
– de wet ontduiken zolang er niet gehandhaafd wordt
Goh, iemand die integraal naar een organisatie kijkt. Een organisatie-landschap bestaat uit meer dan alleen bedrijfsregels, zoals Oudlid voorzichtig aangeeft. Overigens is er in deze geen heilige graal te verwachten. Dat heeft te maken welk gedragen strategisch kader (missie, visie, strategie, doelen en kernwaarden) een organisatie heeft omarmt. De invulling van deze termen voor elke organisatie is anders en bepaalt hoe met alle aspecten van een organisatie wordt omgegaan.
De persoon van de eerste reactie heeft helemaal gelijk. Uiteraard gaat het om uitvoer van activiteiten EN voldoen aan wet- en regelgeving. Het mooie van bedrijfsregels is dan ook het beleid van een organisatie, bijvoorbeeld rondom wet- en regelgeving, heel helder en concreet in regels vastgelegd wordt. Bedrijfsregels kunnen daarmee het gehele gedrag van de organisatie beschrijven, dus niet alleen de dagdagelijkse activiteiten, maar ook de governance daar omheen – dus “de business” en “de enterprise”.
En het duurzaamheidsaspect is zeker iets dat de komende jaren meer aandacht gaat krijgen. Er wordt op dit moment bijvoorbeeld steeds vaker gesproken over ‘data als nieuwe olie’, waarbij het niet bijzonder is dat meer dan 80% van data die opgeslagen wordt niet of nauwelijks gebruikt wordt. Dus ook voor applicatieve data moet je als organisatie scherp zijn op wat je echt nodig hebt en hoe je dit effectief gebruikt, inclusief de infrastructuur die je hiervoor inzet.
De tweede persoon zou ik willen vragen, kom eens kijken bij USoft.
Het punt is helemaal terecht. Je wilt niet eindeloos moeten programmeren, maar juist in natuurlijke taal je bedrijfsregels specificeren. Wat het artikel probeert te delen is dat het automatiseren van bedrijfsregels vrijwel altijd nog een programmeerslag vraagt, maar dat er nu low-code technologie is die het domein van bedrijfsregelautomatisering beschikbaar, laagdrempelig en vooral een business georiënteerd en niet IT proces maakt.
Ook worden er een aantal interessante vormen van regels genoemd. Ik weet niet of ik deze zelf naar software zou willen vertalen, want uiteindelijk is voldoen aan wet- en regelgeving een belangrijk beleidskader waarvoor organisaties gelukkig ook bedrijfsregels en processen hanteren.
Tot slot kan ik me ook aansluiten bij de derde reactie. Als je kijkt naar hoe je het gedrag van een organisatie in kaart brengt dat zie je vaak dat dit gespecificeerd wordt in processen en de daarbij horende bedrijfsregels. We leven wel in een wereld waarin er vaak primair vanuit een proces gedacht wordt, en beperkt aandacht is voor de onderliggende dynamiek, maar we zien de aandacht voor regels toenemen.
Het mooie en sterke aan de combinatie van processen en regels is dan ook dat je juist heel goed onderscheid maakt tussen de ene en de andere organisatie. Een orderproces kan bij twee organisaties bijvoorbeeld (vrijwel) gelijk zijn, maar de daarbij horende regels kunnen significant afwijken. Juist de specifieke keuzes die elke organisatie daarin maakt en die haar anders maakt dan andere, worden daarmee heel duidelijk. En als je dat als basis voor softwareontwikkeling gebruikt, past de oplossing dus ook naadloos bij die specifieke organisatie.
Hans Canisius,
Het is mooi dat je als CEO van USoft reageert maar de auteur is Frank en ik neem aan dat een account executive zelf ook kan reageren op de reacties. Termen zoals ‘accountability’ in de verantwoordingsverplichting gaan tenslotte niet om titels maar om de bewijslast waarin de data een steeds belangrijker rol speelt. Data governance is volgens Dino een stokpaardje van me maar dat komt door een andere achtergrond in het beheer, de lijken in de dossierkast hebben ook verzorging nodig;-)
De 80% van data die opgeslagen wordt maar niet of nauwelijks gebruikt wordt gaat grotendeels om de bewijslast, een leuke hierin is de Chain of Custody aangaande de orkestratie. Wat betreft de klokkenluiders van Dino gaat legacy om een besluitvorming van gisteren want al die rules engines zonder deugdelijke vastlegging van de geautomatiseerde besluitvorming gaan om ‘black boxes’ welke niet de goedkeuring van de auditor krijgt. Mogelijk ben ik te cryptisch maar aangaande de accountability moeten we niet de logfiles vergeten want headless-applicaties klinken als Russische roulette.
Inkomende container van leverancier X kan alleen tot een signalering naar klanten leiden als de inhoud ervan bekend is, de account executive vergroot zijn waarde als hij weet welke impact een vertraging in de levering heeft op de kritische ketens. Kennis van de processen geeft je een voorsprong omdat een gegeven pas waarde krijgt in de context van belangen, graag aandacht voor mijn opmerking over de orkestratie want iedereen denkt dat hij/zij belangerijk is maar BPO leert iets anders vanuit een holistische aanpak.
Met lowcode kun je blijkbaar nog kiezen of je wilt vastlopen met processpaghetti of bedrijfsregelspaghetti, maar combineren is ook heel goed mogelijk.
Zelf blijf ik een voorkeur houden voor lasagne 🙂
Er zijn maar 2 problemen met een bedrijfsregelaanpak:
het is qua theorie weerlegbaar en in de praktijk werkt het niet.
Bedrijfsregels zijn in werkelijkheid namelijk: normen.
Voor een overzicht van lowcode bij de overheid: https://regels.overheid.nl/docs/
Jack,
Regels gaan om de vastgelegde afspraken terwijl normen om ongeschreven regels gaan waaraan iemand zich wel of niet conformeert. Binnen het verbintenissenrecht contractueel een groot verschil als we kijken naar de toetsing van expliciete afspraken aangaande een resultaat en de impliciete verwachtingen van een inspanning.