Dinsdag 12 april Open ontwikkelavond Integrale modellering van bedrijfsvoering.

Transcriptie

1 Dinsdag 12 april Open ontwikkelavond Integrale modellering van bedrijfsvoering. Interview met Casper Nahon, organisator van deze avond. Hoe was het 12 april? Gezellig én nuttig, als vanouds. We hadden goed eten, een goede gastheer, leuke gasten en een prima discussie. Waar hadden jullie het over? Ik had gekozen voor een ouderwets hardcore Webboek-onderwerp: het integrale modelleren van bedrijfsvoering. Daarmee bedoelen we: architectuurplaatjes, processchema s, functionele ontwerpen, requirements, werkinstructies, compliance-eisen, hoe haak je dat nou allemaal hard aan elkaar? Dat lukt vaak wel in onze projecten, zij het moeizaam, maar na onze projecten versloft de boel doorgaans. Dus vroegen we ons hardop af: hoe komt dat? Werken integrale modellen überhaupt wel? En, werken integrale modellen? Open deur natuurlijk, maar modellen zijn een vereenvoudigde weergave van de werkelijkheid. En daarom werken ze prima om richting te geven of om dingen uit te leggen. Modellen maak je voor verschillende doelgroepen en verschillende doeleinden. Bijvoorbeeld: swimlane-schema's zijn heel nuttig om de koppeling te laten zien tussen processtappen en rollen. Voor de werkvloer zijn die dingen intuïtief: je ziet meteen je rol in een keten, wat mag jij van anderen verwachten, wat kunnen anderen van jou verwachten. Ander voorbeeld: voor functioneel ontwerpers zijn data flow diagrams (dfd s) heel geschikt, omdat daar de link tussen processtappen en informatiestromen zichtbaar wordt. Waarom zou je verschillende schema's maken, we willen toch integrale ontwerpen? Je kunt al die zaken wel in één schema kwijt, maar met een groot nadeel: hoe meer je in een model laat zien, hoe minder bruikbaar het wordt voor een specifiek doel. Mensen raken snel de draad kwijt doordat er informatie in zo'n schema staat die hen niet primair interesseert. Zo'n combinatieschema staat dan eigenlijk voor iedereen vol ruis, waarmee het voor alle doelgroepen zijn waarde verliest. Het is dan geen vereenvoudigde weergave meer. Eigenlijk zou je daarom één repository willen - een database waarin je alle dwarsverbanden consistent bijhoudt - met daarop verschillende views: swimlane-schema s, organigrammen, gegevensmodellen, een hoofprocessenplaat voor het MT, dfd s voor de functioneel ontwerpers et cetera.

2 Voorbeeld van een swimlane-schema. Bron: brcommunity.com. Klinkt goed, dan zijn we er dus? Nou, in principe wel, maar in de praktijk is dit helaas nog niet zo makkelijk. Het is een enorm karwei om een integraal PAGO-design (processen, applicaties, gegevens, organisatie; zie ook hoofdstuk 7, Inrichten Ontwikkelaanpak) te maken, om alle dwarsverbanden te legen en te onderhouden. Als je dat in Visio doet, zul je alle consistentie 'handmatig' moeten managen. Daarom heb je tooling die je daarbij helpt, en die zo n onderliggende repository heeft. Helaas kennen we nog niet veel hosanna-ervaringen met dergelijke tools. De tools zijn allemaal ooit ontstaan vanuit één discipline, bijvoorbeeld vanuit procesmodellering, zoals ARIS en Casewise. En daar zijn ze dan ook het sterkst in. Een andere toolonafhankeljke - lastige kwestie bij consistentie is: kiezen tussen vrijheidsgraden of afgedwongen consistentie. Vroeger had je SDW (system development workbench). Daarmee kon je heel veel modelleren, maar dat dwong je bijvoorbeeld eerst een organisatie-afdeling aan te maken voordat je een proces kon maken dat in die afdeling plaatsvond. Een ander probleem is: op welk niveau leg je de dwarsverbanden? Bijvoorbeeld: zijn applicaties nou gekoppeld aan processen of zijn applicatiemodules van die applicaties gekoppeld aan deelprocessen? Je wilt een genormaliseerd gegevensmodel van de bedrijfsvoering zelf, maar dat geeft allerlei van dit soort ingewikkelde keuzes. Klinkt ineens weer heel moeilijk, kan het wel? Jazeker, het is flink klussen maar het kan zeker wel. Sterker, we doen het ook zo in de projecten bij onze klanten. De vervolgvraag is dan echter: wat nu na die projecten, als de boel in beheer komt. Dan heb je dus dat mooie integrale ontwerp, maar bij wie laat je dat dan achter? Er is toch een beheerclub? Er is vast en zeker een IT-beheerclub, die waarschijnlijk gewend is om functioneel ontwerpen te onderhouden, maar zeker niet de procesmodellen en de requirements die aan die ontwerpen ten grondslag lagen. En misschien is er een ambitieuze business partij of een centrale processenclub die

3 de eigen processen op orde wil houden. Maar die requirements richting de IT bijhouden, da s andere koek. Er is misschien een architectuurclub die graag integraal denkt, die willen best de abstractere onderdelen van het integrale ontwerp overnemen in beheer, maar al die onderliggende details, dat mogen anderen doen. En het project, de organisatie die tijdelijk in staat was om die disciplines te verenigen, is weg. Dus dat verwatert doorgaans. Dat is toch zonde van al die effort? Tja, zo voelt dat natuurlijk ook wel, als je daar in zo'n project met veel bloed, zweet en tranen zo'n prachtig model hebt neergelegd. Maar als je er rationeel naar kijkt, valt dat ook wel weer mee. Je moet een kosten/baten-afweging maken. Waarom en voor wie zouden we het bijhouden? Is het nog strikt noodzakelijk om deze kennis compleet uitgemodelleerd en integraal bij te gaan houden als de hoofdlijnen bekend zijn en toch al in de hoofden van de verschillende betrokkenen zit? Loopt de organisatie heel grote risico s als de processen iets uit de pas gaan lopen met de werkelijkheid? Meestal valt dat allemaal wel mee. En zet dan de kosten er tegenover: wie gaan het überhaupt bijhouden? Wie kunnen dat? Wie willen dat? Het is niet het meest dynamische vak. Het vergt diepgaande kennis en veel overzicht over alle aspecten van de bedrijfsvoering. Het is enerzijds secuur detailwerk en anderzijds abstract overzicht behouden. Vind die mensen maar eens. Bovendien vergt het handigheid met die tooling. Tools waarin je daadwerkelijk diepgaand kunt modelleren, zijn prachtig maar vergen heel specialistische toolkennis. Dus die heb je ook nog nodig. Dit zijn niet de goedkoopste mensen en er gaan toch wel wat FTE s in zitten. Maar dan verwatert het dus gewoon? Ja, als je het los laat, dan gebeurt wat eigenlijk altijd gebeurt: de werkelijkheid verandert door impliciete of expliciete changes in de bedrijfsvoering en dus gaan model en werkelijkheid uit elkaar lopen. En dan is het geen goed model meer, zelfs een slecht model, want het zet je op het verkeerde been. Het zit al in de definitie van model: het is geen vereenvoudigde weergave van de werkelijkheid meer. En dan bij het volgende project? Tja, dan begint het weer van voren af aan. Klinkt inefficiënt, maar heeft ook voordelen. Vaak zitten er toch andere mensen, spelen er andere belangen. Het kan natuurlijk eens in de zoveel tijd helemaal gen kwaad om weer s goed na te denken hoe we de dingen hier doen en waarom eigenlijk. Dus het Webboek Bedrijfsvoering raadt aan om integrale modellen van Bedrijfsvoering weg te gooien? Nee, hold your horses We raden altijd aan om op enterprise architectuurniveau de zaak integraal te blijven bijhouden. Voor ieder volgend project is die architectuur immers richtinggevend: de Richten-laag zou in beheer moeten blijven.

4 Dan het Verrichten-niveau. Ook daar zijn er wel degelijk situaties waarin je wel gek zou zijn om een dergelijk integraal detailontwerp na een project of programma te laten versloffen of om het weg te gooien. Soms wegen die beheerkosten wel degelijk tegen de baten op. Een eerste voorbeeld is als er een nieuwe innovatie te verwachten is binnen afzienbare tijd. Als er in het betreffende deel van de bedrijfsvoering op korte termijn nieuwe releases of grote innovaties zijn voorzien, dan kun je maar beter zorgen dat je straks niet weer opnieuw moet beginnen. Denk aan grote IT-programma s die releasematig eens per halfjaar een major release live brengen. Maar denk bijvoorbeeld ook aan de energiesector. Daar volgen de wettelijke en marktontwikkelingen zich zo snel op dat het verstandig is / was geweest om binnen die bedrijven de bedrijfsvoering centraal grondig te administreren, zodat wijzigingen ook echt goed en snel door te voeren zijn. Een tweede voorbeeld van een goede reden om een (gedeelte van) een bedrijfsvoeringsmodel gedetailleerd bij te houden: Voor heel repetitieve of procedurele processen met bijvoorbeeld veel personeelsverloop (denk aan een callcenter met veel parttimers) zijn er flinke baten in besparing op opleidingskosten te behalen. Dan is de business case dus snel gemaakt. Een derde voorbeeld is - last but not least - : risico s en compliance. Sommige wet- en regelgeving, certificeringseisen of maatregelen zijn heel specifiek, bijvoorbeeld vanuit veiligheid of financiële eisen. In zulke gevallen moet een organisatie voortdurend kunnen aantonen in control te zijn. Een up to date, integraal, gedetailleerd bedrijfsvoeringsmodel bijhouden is dan een heel efficiënt hulpmiddel. Wat is de algemene conclusie? De deelnemers aan de avond concluderen drie dingen: 1. Integraal ontwerp van de bedrijfsvoering is noodzakelijk; de dwarsverbanden zijn essentieel. Dat geldt voor alle niveaus: richten, inrichten, verrichten. 2. Om een integrale bedrijfsvoering te ontwerpen moet je modelleren: de werkelijkheid eenvoudiger afbeelden. Daarbij kun je het best verschillende modellen maken voor verschillende doeleinden en verschillende doelgroepen. Bijvoorbeeld swimlanes voor de werkvloer en dataflowdiagrammen (dfd s) voor de IT ers. Combinatieschema s zijn vaak onleesbaar, die verliezen hun kracht als model. Maar de samenhang blijft wel noodzakelijk: het proces in dat swimlane

5 diagram is tenslotte hetzelfde proces als in de dfd. Daarom heb je tooling nodig om die modellen consistent te houden. 3. Het is niet per se noodzakelijk om dat integrale ontwerp tijdens het verrichten (na live gang van een project) te gaan beheren. De architectuur wel, de details vaak niet. De baten wegen vaak niet tegen de kosten op. Het is arbeidsintensief en kennisintensief werk, organisaties zijn daar meestal niet voor uitgerust. Uitzonderingen daarop zijn bijvoorbeeld wettelijke noodzaak of spoedige nieuwe innovaties. In dergelijke gevallen zul je beheer moeten inrichten, met als voornaamste uitdaging: mensen vinden die in staat zijn de wijzigingen op de bedrijfsvoering integraal bij te houden. Je moet je dus altijd afvragen waarom en voor wie er gemodelleerd wordt. Projecten moeten zich vooraf buigen over de life cycle van de resultaten. Wat gebeurt er mee als die tijdelijke organisatie straks weg is? Daar moet je vooraf over nagedacht hebben. En als de conclusie is dat beheren wel degelijk verstandig is, betrek die beheerpartij er dan vooraf bij, zodat het de overdracht ook kans van slagen heeft. En daar hebben jullie het de hele avond over gehad? Ja! En daarbij was het nog gezellig ook! Redactie Webboek Bedrijfsvoering