BPM en EA, “a match made in heaven”!

In een wereld waarin kostenbesparing het “leitmotiv” is en waar “in control” zijn geen keuze maar steeds meer een wettelijk plicht is, krijgt Business Process Management (BPM) veel aandacht. Anderzijds wordt het onderwerp Enterprise Architectuur (EA) veelvuldig voor het voetlicht gehaald. Hoe verhouden die twee zich tot elkaar? En kunnen ze eigenlijk wel zonder elkaar?

Het idee dat bedrijfsprocessen de kern van een organisatie zijn, is zeker niet nieuw. Bedrijfsprocessen geven aan op welke manier het werk wordt uitgevoerd, en vormen daarmee de basis voor verbetering van efficiency, effectiviteit, flexibiliteit, klantgerichtheid, etc. Door de jaren heen hebben bedrijfsprocessen een belangrijke rol gespeeld, soms voor korte tijd en soms voor veel langere tijd, in populaire managementstromingen zoals Total Quality Management (TQM), Lean Six Sigma, Business Process Redesign (BPR), etc. En alhoewel er natuurlijk verschillen, grote maar vooral ook kleinere, tussen deze stromingen zijn, draait het in alle gevallen om grip op die bedrijfsprocessen te hebben, en om ze continue te verbeteren. Zo ook bij “Business Process Management” (BPM) waarbinnen procesanalyse, -modellering, -implementatie, -monitoring en –automatisering structureel aandacht krijgen. Eén aspect dat BPM onderscheidt van TQM, BPR, etc., is de expliciete nadruk op de rol die ICT speelt in het ondersteunen van bedrijfsprocessen, en het meten van de performance ervan. Dit heeft inmiddels geleid tot niet alleen een reeks van procesmodelleringstools, maar ook tot “BPM suites” die onder andere de mogelijkheid bieden om door middel van een “process engine” applicaties aan te sturen, en door middel van een “business analyzer” diezelfde processen te analyseren op serviceniveaus, performance indicatoren, issues, trends, etc.

Van denken naar doen

BPM kent de afgelopen jaren een sterk toenemende schare gebruikers, volgers en belangstellenden. Logisch, gezien het feit dat kostenbesparing het “leitmotiv” was, en nog steeds is. En gegeven de toenemende druk, o.a. vanuit wet- en regelgeving, op het “in control” zijn. Als je dan geen grip op je bedrijfsprocessen hebt, ga je simpelweg de bietenbrug op.

Hoe dringend de behoefte aan BPM ook moge zijn, het implementeren van BPM is een stevig traject. Net als in “het echte leven” gaat het bij BPM om het bepalen van waar je nu bent, waar je heen wilt, hoe je daar denkt te komen, en het vervolgens gaan doen. De kunst is veelal om die laatste slag te maken, van denken naar doen, en om daar de successen te behalen. Van procesdenken naar “proces doen”. Anderzijds biedt “rennen als een kip zonder kop” ook geen soelaas, en zonder duidelijk en gedetailleerd procesontwerp zal het implementeren van een BPM suite in een organisatie een ramp zijn.

Een van de eerste ontwerpactiviteiten is het identificeren van welke processen er zijn in de organisatie. BPM kent meerdere niveaus van procesbeschrijving zoals procesketens, bedrijfsprocessen, werkprocessen, activiteiten en handelingen. En processen kennen inputs en outputs, proceseigenaren en procesexperts, en hebben mensen en middelen nodig. Een dergelijk overzicht van de processen in een organisatie wordt ook wel een procesarchitectuur genoemd. “Procesarchitectuur? Dat doet me denken aan Enterprise Architectuur? Hoe zit dat dan?”

Enterprise Architectuur

Enterprise Architectuur (EA) definieert vanuit visie, missie en strategie van een organisatie de inrichtingsprincipes, bedrijfsmodellen en producten & diensten. Producten & diensten worden voortgebracht door bedrijfsprocessen. Op dit niveau wordt gesproken over de bedrijfsarchitectuur. Bedrijfsprocessen verwerken gegevens waarvan de samenhang gedefinieerd is in informatiemodellen. Gegevens wordt verwerkt door en uitgewisseld tussen applicaties, waarbij interfaces en berichtformaten een rol spelen. Op dit niveau wordt gesproken over de informatiearchitectuur. Applicaties kunnen niks zonder onderliggende ICT infrastructuur, en dus dient ook de “technische architectuur” beschreven te worden. De architectuurlagen bepalen gezamenlijk hoe een organisatie doet wat zij moet doen.

“Maar”, zult u wellicht zeggen, “hoe verhoudt zich BPM dan tot EA?!” Een terechte vraag, absoluut. Met eigenlijk een relatief eenvoudig antwoord. Want BPM en EA kunnen niet zonder elkaar!

Voor het voortbrengen van producten & diensten kent EA, zoals hiervoor aangegeven, bedrijfsprocessen. Net als BPM. En EA kent actoren die bijvoorbeeld proceseigenaar kunnen zijn. Net als BPM. EA kent ook gegevensbronnen die door bedrijfsprocessen gebruikt c.q. bewerkt worden. Net als BPM. Maar daar waar BPM in detail inzoomt op uiteindelijk individuele activiteiten en handelingen, kiest EA er veelal voor om dat detailprocesniveau niet te modelleren, te beschouwen . Daarvoor in de plaats kijkt EA explicieter dan BPM naar producten & diensten die door bedrijfsprocessen worden voortgebracht, naar gegevensbestanden die door bedrijfsprocessen worden gebruikt, naar applicaties die de bewerkingen op die gegevensbestanden realiseren, en naar de onderliggende technische architectuur die dit alles mogelijk maakt. BPM biedt op procesniveau, voor wat betreft de modellering, dus een detailperspectief op een groot deel van de bedrijfsarchitectuur zoals EA die kent.

BPM en EA kunnen niet zonder elkaar

Een prima aansluiting van twee “managementconcepten”. Maar ook een aansluiting die helpt om een mogelijke zwakte van beide concepten te ondervangen. Want het is opvallend om te zien hoeveel BPM initiatieven nooit verder komen dan procesanalyse en -modellering, nooit de stap maken naar de onderliggende informatiestromen en applicatiearchitectuur die tenslotte pas gaat “draaien” als er een techniek staat te “zoomen”. Mooie processchema’s, eenduidig toegewezen proceseigenaren, maar in de 21e eeuw kun je er dan nagenoeg niets mee als het niet doorvertaald naar ICT bouwstenen, en de samenhang daartussen. Zeker als je, wat BPM beoogt, ketens van bedrijfsprocessen wilt gaan monitoren. Vaststellen dat een bedrijfsproces een beschikbaarheid van 99% moet hebben is niet moeilijk, maar vervolgens dienen alle onderliggende (daar komt ie) architectuurlagen ingevuld te worden. En wel op een dusdanige manier dat op uiteindelijk het bedrijfsprocesniveau die 99% gehaald wordt. Dat vereist uiteindelijk een doorvertaling naar beschikbaarheden van applicaties en interfaces, en daaronder naar beschikbaarheden van servers, switches, routers, netwerkverbindingen, firewalls, etc. Ook EA initiatieven hebben, in alle eerlijkheid, soms de neiging om op een te hoog abstractieniveau te stoppen, te “blijven hangen”. Duidelijkheid over bedrijfsarchitectuur en informatiearchitectuur is zeer belangrijk voor elke organisatie, maar zonder doorvertaling naar ICT bouwstenen … gaat er niks gebeuren. BPM en EA hebben elkaar nodig, dat is een feit. Maar nog steeds dient er voor gewaakt te worden dat dergelijk exercities worden “afgemaakt”, tot op het niveau waarop dingen staan te “draaien” en te “zoomen”.

De normaalste vragen van de wereld

Je moet als organisatie weten wat de performance indicatoren van je bedrijfsprocessen zijn, en hoe je die bestuurt. Veel managers zijn in feite “service managers” op het niveau van bedrijfsprocessen. En dus krijgen ze “de normaalste vragen van de wereld” over hun bedrijfsprocessen:

• Welke bedrijfsprocessen zijn het belangrijkst?
• Wat zijn de dienstenniveaus zoals die voor deze bedrijfsprocessen gelden?
• Wat is de performance ten opzicht van die dienstenniveaus?
• Uit welke werkprocessen, activiteiten en handelingen zijn deze bedrijfsprocessen opgebouwd?
• Wie zijn de proceseigenaren?

Omdat we weten dat, enigszins kort door de bocht, zonder ICT alles stilvalt, weten we ook dat deze vragen zich doorvertalen naar de applicaties die een rol spelen in het realiseren van die bedrijfsprocessen. Hiervoor gelden dezelfde thema’s:

• Welke zijn het belangrijkst?
• Wat zijn de dienstenniveaus?
• Wat is de performance ten opzicht van die dienstenniveaus?
• Hie hangen de applicaties samen?
• Wie zijn de eigenaren?

U voelt ‘m al aankomen … diezelfde thema’s dienen beantwoord, en beheerd, te worden op het niveau van de technische architectuur. De samenhang tussen dit alles maakt dat een organisatie reilt en zeilt. En dat op de juiste manier ingespeeld kan worden op allerlei initiatieven voor verbetering van dienstverlening en/of verlaging van kosten:

• Wat zijn de jaarlijkse beheerkosten (van processen, applicaties, infra)?
• Welke mogelijkheden tot procesoptimalisatie zijn er?
• Wat is de impact hiervan op mijn informatiearchitectuur incl. applicatielandschap?
• Welke overlap zit er in functionaliteit tussen applicaties?
• Hoe vaak worden er functionele changes doorgevoerd?
• Wat zijn de beste kandidaten om tot applicatierationalisatie over te gaan?
• Wat is het budget voor die rationalisatie? En wat is de terugverdientijd?
• Wat is de end-of-support datum voor een commercial-off-the-shelf applicatie?
• Wanneer moeten we tot nieuwe licentieafspraken overgaan?
• Welke hardware en software onderhoudscontracten hebben we?
• Hoeveel hebben we gebruik gemaakt van dergelijke contracten?
• Wat zouden de investeringen zijn als we spare hardware aanschaffen?
• Wat is de afschrijving als we besluiten over te stappen op cloud computing?
• Welke fixes, patches en service packs zijn er uitgekomen?
• Welke hebben we daarvan reeds geïmplementeerd?
• Welke moeten we daarvan in het komende kwartaal implementeren?

Zo kunnen we nog wel even doorgaan. Iedere service manager, met een ICT of een business bril op wil, het liefst met een druk op de knop, antwoord kunnen geven op dergelijke vragen. Zie een eerder (in XR Magazine van juni 2011 geplaatst) artikel met als titel "Architectuur en service management, een superduo!". Daarvoor dienen bedrijfsprocessen gemanaged te worden (BPM) en dienen deze bedrijfsprocessen gekoppeld te zijn aan (een gemanagede) enterprise architectuur (EA). BPM en EA, “a match made in heaven”!