Christiaan Boiten

Christiaan Boiten

Inhoudelijk projectleider op het vakgebied van management accounting & control. Mobiel +31 (0)6 3882 7924

Praktijkverhalen van een adviseur: Uitwaaieren en trechteren

Share on twitter
Share on linkedin

Veel organisaties die in het vorige decennium bezig waren met het inrichten van hun ERP omgeving, zijn in dit decennium bezig om de besturende processen verder vorm te geven met behulp van softwarematige oplossingen. Er is niet alleen  behoefte om managers van adequate bestuurlijke informatie te voorzien die verder gaat dan alleen financiële informatie, ook is er vaak behoefte om de planningsprocessen zoals meerjarenplanning, begroting en prognose, vorm te geven zodat managers en controllers kunnen samenwerken in één digitale omgeving.

Het blijkt in de praktijk toch nog best lastig om de bestuurlijke processen eenduidig en begrijpelijk te beschrijven, zodat een leverancier bij een selectietraject of aanbesteding ook goed op de vraagstelling kan reageren. Hoe pak je dat nu aan, zodat de kans op een succesvolle selectie zo groot mogelijk wordt, en de risico op van mislukking of grote tegenvallers in de implementatie fase zoveel mogelijk beperkt wordt?

Het is van belang dat je tot de kern doordringt, zonder in details te verzanden. In dit artikel geef ik graag wat gedachten mee naar aanleiding van een methode die je zou kunnen aanduiden als ‘eerst uitwaaieren’ en daarna ‘trechteren’. Met dit trechtermodel kun je tot de kern doordringen, maar je houdt het overzicht.

Eerst uitwaaieren

Om een proces te kunnen ondersteunen met een toepassing, moet je eerst weten om welk proces het gaat. Wat is het hoofdproces en welke onderliggende stappen of sub-processen zijn te onderscheiden? Het kan heel behulpzaam zijn om voor deze eerste stap gebruik te maken van beschikbare referentiearchitectuur modellen die voor verschillende sectoren beschikbaar zijn, zoals het Nictiz referentiemodel voor de zorgsector of het Hora referentiemodel voor het hoger onderwijs.

Als er consensus is over de hoofdprocessen en de onderliggende deelprocessen, kan er verder uitgewaaierd worden door te kijken wát er in elke processtap gebeurt. Welke rolhouders moeten er iets doen, welke gegevens worden gebruikt, hoe zien die gegevens er in gestandaardiseerde termen uit. Om te voorkomen dat je hierbij in teveel details beland, kun je ervoor kiezen om hiervoor de gegevens te beschrijven op basis van informatie objecten, zoals ‘client’, ‘medewerker’, ‘organisatie eenheid’, etc. Voor de integratie van een oplossing in het informatie landschap is het ook van belang om de weten uit welk  bronsysteem de gegevens komen.

Naast de informatie objecten is het van belang om per processtap te bepalen welke meetwaarden en business rules van toepassing zijn. Bij planningsmodellen die ter ondersteuning van besturende processen worden gebruikt, zoals meerjarenplanningen, jaarplannen, prognoses, waarderingsmodellen en impairment modellen, komen we hier tot een belangrijke kern. In dit soort modellen worden namelijk veel verschillende berekeningen toegepast. Voor de selectie zijn dit soort berekeningen van belang omdat vastgesteld moet worden of de te selecteren toepassing de complexiteit van de gewenste berekeningen kan ondersteunen met behoud van voldoende performance. Tegelijk geldt hiervoor ook dat niet bekende of niet gestandaardiseerde berekeningen tot hogere implementatiekosten en projectrisico’s zullen leiden.

Het kan de nodige tijd kosten om te komen tot overeenstemming over de processen omdat verschillende organisatie onderdelen het betreffende proces op een verschillende manier hebben vormgegeven. Om hoge implementatiekosten te voorkomen is harmonisatie van de processen een randvoorwaarde, waarbij eventuele uitzonderingen op het standaard proces het beste beoordeeld kunnen worden op basis van een analyse van de baten afgezet tegen de extra kosten.

Uitwaaieren als een pauw

En dan trechteren

Als er uitgewaaierd is, wordt het tijd om te trechteren. Welke conclusies kunnen getrokken worden voor de functionele requirements? Wat moet de oplossing ondersteunen en hoe moet de oplossing dat doen? En niet onbelangrijk, wat is écht de kern van het vraagstuk en dus belangrijk dat dit goed ondersteund wordt en wat is secundair en van minder groot belang? Niet alles kan een ‘must’ zijn in de termen van de ‘MoSCoW’ methode.

Bij het trechteren kan ook vanuit alle informatie objecten en gerelateerde databronnen een conclusie getrokken worden over de gewenste datakoppelingen zodat die onderdeel kunnen worden van het programma van eisen (en wensen).

Naast het kernachtig benoemen van een beperkt aantal requirements op basis waarvan de selectie plaats vindt, is het wenselijk om de scope van de implementatie te beschrijven. Op basis van een heldere scope kan een leverancier een betere offerte opstellen, omdat er minder onzekerheid is die geprijsd hoeft te worden of via disclaimers buiten de offerte blijft, maar vervolgens als een boomerang in de projectfase terug komt. Het harmoniseren van processen en berekenwijzen binnen de besturende processen van de organisatie zorgt voor lagere inrichtingskosten en verhoogt de kans op een succesvol project dat binnen scope, tijd en budget opgeleverd wordt.

Visualisatie van het trechtermodel

Lees ook deze artikelen.

Technology Business Management

Technology Business Management  Inleiding  Voor bestuurders en financials is de ontwikkeling van de IT-kosten regelmatig een hoofdpijndossier. Welke kosten horen bij welke dienst of product? Hoe krijgt de IT afdeling