De controller als regisseur van de dynamische informatievoorziening: van extrapoleren naar exploreren (deel 1)

Op donderdag 12 april 2018 spreekt Fred Conijn, managing consultant bij PA Consulting, op het NIVE Controllerscongres. In zijn keuzesessie ‘Aan de slag met een dynamisch besturingssysteem’ vertelt hij u graag meer over wat u kunt doen om informatievoorziening te dynamiseren. In aanloop naar het congres zullen wij een aantal van zijn artikelen publiceren om u kennis te laten maken met een dynamisch besturingssysteem.

Toekomstvast bestaat niet meer. Het is een term uit de 20e eeuw. Onze omgeving is nog nooit zo volatiel, complex en onzeker geweest als nu. Realistische ambities en prognoses zijn door de dynamiek in de omgeving al weer achterhaald als ze op papier staan. Eenvoudigweg extrapoleren van prestaties en resultaten uit het verleden volstaat niet meer bij het plannen, budgetteren en forecasten. Het moet anders, maar hoe?

De beschikbare methoden en technieken voor informatievoorziening zijn uitgebreid beschreven in de managementcontrolboeken. Hoe je ze invoert bij jouw organisatie staat er niet in. Bovendien bestaat er niet één aanpak die voor iedereen werkt. Er bestaat wel een managementcontrolraamwerk dat helpt de relevante componenten te identificeren en te realiseren. Maar wat is nu de samenhang tussen de verschillende componenten en wat zijn de ervaringen en leerpunten bij de realisatie? Een goed raamwerk stelt de controller in staat te anticiperen en de rol van regisseur van een dynamische informatievoorziening te vervullen.

Dynamisch sturen met de OODA-loop

De nadruk in de besturing wordt verlegd van extrapoleren naar exploreren. Daartoe worden alternatieve strategieën verkend en ontwikkeld als respons op mogelijke toekomstscenario’s om in onzekere tijden kansen te benutten en bedreigingen af te wenden. De PDCA (plan-do-check-act) cyclus, of Deming cycle, die veel bedrijven toepassen voldoet dan niet meer. Een alternatief is de OODA-loop. De term OODA-loop komt van origine uit de Amerikaans luchtmacht (zie kader). Het is de afkorting voor Observe, Orient, Decide & Act. De OODA-loop biedt organisaties een tactiek die ervoor zorgt dat ze sneller in kunnen spelen op veranderingen dan hun concurrenten.

Ontstaan OODA

De term OODA is door US Air Force piloot en Pentagon-adviseur kolonel John Boyd bedacht voor gevechtspiloten. Hij had een weddenschap dat hij vanuit een nadelige positie, zijn vliegtuig binnen 40 seconden kon manoeuvreren in een voordelige positie, waarmee hij elke tegenstander kon verslaan in een luchtgevecht. Naar verluidt heeft hij deze weddenschap nooit verloren. Kolonel Boyd betoogt dat het vermogen om heel snel de OODA loop te doorlopen, belangrijker voor succes is dan individuele kwaliteiten zoals een uitstekend gezichts- of reactievermogen.

Hoe passen dynamische organisaties de OODA-loop toe?

Observeren. De omgeving van de organisatie wordt voortdurend gemonitord en voornamelijk externe ontwikkelingen worden geïdentificeerd. Early warning indicatoren voor de belangrijkste drivers identificeren ontwikkelingen in de externe omgeving. Vastgesteld wordt hoe de drivers zich ontwikkelen. Continue wordt beoordeeld of het gehanteerde model (nog) is voorzien van de juiste uitgangspunten, waarden en marktprojecties voor wat betreft de omgeving.
Oriënteren. Op basis van de mogelijke ontwikkeling van de omgeving wordt gekeken naar de positie van de organisatie. Mogelijke omgevingsscenario’s en de projecties voor de organisatie gegeven het eerder gekozen strategisch (respons)scenario worden beoordeeld. De mogelijke alternatieve responsscenario’s worden vastgesteld.
Kiezen (decide). Er wordt een keuze gemaakt in de mogelijke omgevingsscenario’s en het responsscenario. Met het model worden scenario’s gesimuleerd om de effecten van responsscenario’s op omgevingsscenario’s door te rekenen. Hiermee wordt het verwachte omgevingsscenario en responsscenario gekozen.
Uitvoeren (act). Het gekozen responsscenario wordt uitgevoerd.

Het management van de organisatie weet dus hoe het gaat acteren als bepaalde omstandigheden zich voor gaan doen. Zij hebben daar van te voren over nagedacht en responsscenario’s voor ontwikkeld. Dit heeft een grote impact op het besturingsmodel en de informatievoorziening.

De controller realiseert het managementcontrolmodel

Een dynamisch organisatie vereist een dynamische informatievoorziening. De controller vervult daarbij een cruciale rol. Hij ontwikkelt en implementeert het managementcontrolmodel. De belangrijkste componenten zijn:

het businesscontrolmodel. Deze omvat de unieke kenmerken van het gekozen bedrijfsmodel, de drivers, de early warning indicators en de wijze waarop ze elkaar beïnvloeden. Het maakt duidelijk wat de drivers zijn voor kansen en welke risico’s zich voor (kunnen) voordoen;
de informatiestructuur. Dit toont de relevante oogpunten voor de bedrijfsvoering, hoe deze hun weerslag krijgen in dimensies van de informatievoorziening en hoe ze concreet en tastbaar worden gemaakt in de chart of accounts;
registratie. Hiermee wordt duidelijk hoe kosten en opbrengsten worden gealloceerd, toegerekend aan afdelingen, diensten en producten om het gewenste gedrag te bereiken en hoe dat verankerd is in de administratie in de vorm van multidimensionale journaalposten;
rapportages. Zodat niet alleen wordt voldaan aan wettelijke verantwoordingsrapportages, financiële informatie voor stakeholders en de operationele rapportages, maar ook een businessdashboard wordt gerealiseerd waarmee de operatie wordt bestuurd en response scenario’s gekozen.

De volgorde en het belang van het ontwikkelen van deze componenten hangt af van de huidige volwassenheid en aard van de verandering die wordt doorgevoerd in de informatievoorziening. Sterker nog de controller kan al starten met het ontwerp voordat de implementatie start. Een overzicht waarin de belangrijkste bedrijfsactiviteiten zijn weergegeven is wel altijd het startpunt. Dit wordt gevisualiseerd in het zogenaamde ‘bedrijfsactiviteiten model’ (BAM). Het BAM geeft op één A4 de belangrijkste activiteiten van een bedrijf weer. De BAM bevat minimaal twee niveaus: niveau 1 geeft weer wat de belangrijkste type activiteiten zijn die een bedrijf succesvol maken. Het is simpel, zodat direct blijkt wat belangrijk is en wat minder belangrijk. Niveau 2 omvat de belangrijkste activiteiten per activiteitengebied. Dit maakt een activiteittype concreet en maakt duidelijk waar de ene activiteit stopt en de volgende begint.

Kenmerken BAM

Goede businenessactiviteitenmodellen voldoen aan vijf principes: zij geven de duurzame bedrijfsactiviteiten weer, identificeren unieke competenties en activiteiten, abstraheren organisatie- en procesmodellen, maken uitbreiding voor specifieke implementaties mogelijk en zij tonen het belang voor het bedrijf.
Zodra een organisatie de competenties heeft geïdentificeerd, kunnen ze verder worden uitgewerkt in de vorm van eigenschappen die bepalen hoe de activiteit wordt uitgevoerd. Voorbeelden van deze eigenschappen zijn: mensen, proces, technologie, informatie en operationele indicatoren. De belangrijkste uitdaging is het creëren van een model dat er simpel uit ziet en tegelijkertijd veel betekend is voor de gebruikers. (Bron: Forrester reasearch: January 14, 2010: The anatomy of a capability map)

Bij het herontwerp van bedrijfsprocessen moeten het businesscontrolmodel en de informatiestructuur vooraf helder zijn. Zij bepalen hoe de processen eruit zien. Een proces wat is gebaseerd op snelheid, omdat dit een kritische succesfactor is, ziet er immers heel anders uit dan een proces waarbij accuratesse het succes bepaalt. Tijdens uitvoering van de processen moet de realisatie worden geregistreerd. De indicatoren en de dimensies bepalen waarover informatie beschikbaar moet komen en de structuur van de informatievoorziening bepaalt hoe dit gebeurt. Het bedrijfsproces zorgt ervoor dat de resultaten van de bedrijfsgebeurtenissen worden geregistreerd en de juiste wijze worden gealloceerd. De resultaten worden weergegeven in het business dashboard dat het management in staat stelt om te anticiperen. Kortom voordat de implementatie start moet de controller een goed beeld hebben van alle componenten van het managementcontrolraamwerk, zodat deze meegenomen worden in het ontwerp.

Het businesscontrolmodel maakt kansen en bedreigingen meetbaar

Het businesscontrolmodel omvat het performancemanagementmodel en het risicomodel. In de sturing op de werkvloer is het managen van risico’s een integraal onderdeel van het performancemanagement. Bij het ontwerp wordt expliciet vanuit beide invalshoeken gekeken zodat ze beiden voldoende aan de orde komen.

Het performancemanagementmodel maakt duidelijk hoe de organisatie zijn geld verdiend en snel in kan spelen op nieuwe kansen. Het toont hoe verschillende bedrijfsactiviteiten samenwerken en elkaar kunnen versterken. Als het verdienmodel bijvoorbeeld is gebaseerd op service-inkomsten zullen de andere activiteiten dat moeten ondersteunen. De verkoop gaat dan niet primair om het realiseren van marges, maar om genereren van marktaandeel en ervoor zorgen dat tegelijkertijd de service wordt vastgelegd in servicecontracten. Deze doelstellingen worden geconcretiseerd in de vorm van indicatoren gebruikmakend van de reeds beschikbare indicatoren. De meest organisaties beschikken over een uitgebreid arsenaal aan kpi’s. Ze zijn echter meestal sterk financieel georiënteerd en bepaald per afdeling of leidinggevende. De controller plot de strategische indicatoren op het BAM. Hij beoordeelt of de ‘core’ bedrijfsactiviteiten de boventoon voeren en of de indicatoren van de overige activiteiten deze ondersteunen.

Vervolgens bepaalt hij per activiteit welke operationele indicatoren beschikbaar zijn, hoe die bijdragen aan de strategische indicatoren en hoe zij elkaar beïnvloeden. De strategische indicatoren worden zo concreet gemaakt voor de werkvloer, zodat iedereen weet wat van hem wordt verwacht en hoe dit wordt gemeten. De strategiemap is daarvoor een uitstekend hulpmiddel. Met behulp van de strategiemap toont de controller aan hoe financiële indicatoren en klantindicatoren in de processen worden gerealiseerd en hoe het leeraspect daaraan een bijdrage kan leveren. Veel organisaties zijn niet zo ver: vaak worden de financiële en de klantindicatoren gemeten, maar de procesindicatoren vergeten, terwijl het daar gebeurt…

Wat de controller in de praktijk doet is:

visualiseren: alle indicatoren en hun relaties weergeven in één A4;
definiëren: de formules en definities van alle indicatoren vaststellen en zorgen voor eenduidigheid, deze zijn vereist om kunnen te bepalen wat meetbaar is door het systeem;
relateren: expliciet maken hoe de indicatoren elkaar beïnvloeden;
ontdubbelen: makkelijk meetbare indicatoren die vaker voorkomen eruit halen. Denk bijvoorbeeld aan het voor de serviceactiviteiten zowel meten van ‘tijd vanaf uitval’ als het aantal ‘gevallen die binnen vijf dagen afgewerkt waren’;
completeren: toetsen dat alle factoren die de financiële indicatoren bepalen opgenomen zijn en nagaan of er praktische bepalende factoren zijn die nog niet werden gemeten. Bij het ontwikkelen van de strategie map voor de serviceactiviteiten lag de nadruk eerst op het snel en goed oplossen van problemen. Het ‘dekkingspercentage vaste kosten’ en ‘productiviteit’ zijn toegevoegd aangezien zij mede bepalend zijn voor de marge. Voor de klanttevredenheid bleek de ‘reactiesnelheid’ heel belangrijk te zijn. Direct terugbellen en doorgeven dat het probleem binnen drie dagen is opgelost, werd meer gewaardeerd, dan het probleem zonder enige vorm van afstemming binnen twee dagen op te lossen;
realiseren: onderscheid maken tussen wat meetbaar is met het huidige systeem, wat gemakkelijk te realiseren is met een paar kleine aanpassingen en wat pas op langere termijn meetbaar is.

Omdat het moeilijk is tegelijk en goed gebalanceerd te kijken naar kansen en risico’s wordt het risicomodel afzonderlijk opgesteld. Veel organisaties identificeren strategische, operationele, financiële risico’s en risico’s uit hoofde van regelgeving. Voor al deze risico’s wordt het ‘risk appetite’ bepaald, wat de ‘key risk areas’ zijn en hoe deze risico’s worden gemanaged. Dit wordt vaak geoperationaliseerd in de vorm van ‘internal control assessments’ en controleprogramma’s van internal audit. De controller plot de vereiste controls of beheersmaategelen op het BAM en maakt ze per bedrijfsactiviteit inzichtelijk. Vervolgens stelt hij vast wat eisen voor het informatiesysteem zijn om hieraan te kunnen voldoen. Deze completeert hij met de application controls. Voor al deze zogenaamde requirements stelt hij vast in hoeverre het systeem functionaliteit biedt om ze te vervullen. Door ze mee te nemen in de testscenario’s zal in een later stadium worden vastgesteld dat de beheersmaatregelen werken zoals bedoeld. Eén component zal hij in deze fase verder uit moeten werken. Dat betreft de Seggregation of Duties (SoD) oftewel de functiescheiding. De controller zal een SoD-raamwerk maken dat de basis vormt voor het ontwerp van het security model en de wijze waarop autorisaties zullen worden ingericht.

Het SoD-raamwerk omvat:

het beheersingsperspectief. Hoe wordt beschikken, bewaren, uitvoeren en controleren gescheiden om de integriteit te waarborgen (in het oorspronkelijke model was ‘registreren’ een aparte functie. De resultaten van de vier genoemde functies worden tegenwoordig echter direct in het systeem vastgelegd);
het procesperspectief. Wat zijn de kritische momenten in het proces vanuit beheersingsperspectief, oftewel wanneer vindt er ‘waardeoverdracht plaats met tegengestelde belangen’?
het gegevens- en systeemperspectief. Wat is de vereiste SoD voor het beheersen en beheren van transacties, master data en het ontwikkelen van de set up van het systeem.

De controller maakt eerst een overzicht van de belangrijkste rollen die bij zijn organisatie bestaan. Vervolgens stelt hij vast wat de ‘kritische momenten vanuit beheersingsperspectief’ zijn. Meestal gaat het daarbij om ‘aangaan van contracten van klanten’, ‘het inzetten van resources’, ‘het factureren van de klant’, ‘het incasseren van de vorderingen’, ‘het inkoopproces’ en ‘het betalen van verplichtingen’. Per ‘kritisch moment’ stelt hij vast hoe de functiescheiding eruit moet zien. Voor de functiescheiding vanuit gegevens en dataperspectief geeft hij aan welke rollen gegevens mogen muteren, beheren en welke rollen alleen mogen raadplegen. Ook geeft hij aan wat de minimum functiescheiding is bij het beheren van masterdata, het ontwikkelen van het systeem en later het beheer als het systeem operationeel is. Dit SoD-raamwerk wordt door de applicatieconsultants gebruikt bij het inregelen van de autorisaties en bij het testen van het systeem kan worden vastgesteld dat de functiescheiding in de praktijk werkt zoals hij is bedoeld. Zelfs voor ‘kleine Opco’s’ die niet voldoende mensen hebben om de functiescheiding door te voeren wordt deze aanpak gehanteerd. Er zal functievermenging zijn, doordat één persoon meerdere rollen vervult, maar het wordt wel transparant gemaakt. Daarnaast zullen er aanvullende controlemaatregelen worden uitgevoerd om de integriteit te waarborgen.

Ik wil groeien in

Ik ben op zoek naar