Je hebt een controller aangenomen. Je data is nog steeds een chaos.

Je hebt een controller aangenomen. Goede reden: de cijfers liepen achter, te weinig grip op cashflow, je wilde maandcijfers binnen redelijke tijd. Drie maanden later kijk je terug en de chaos is er nog steeds. Andere mensen aan de knoppen, dezelfde puzzel.

Wat is er gebeurd? Je hebt de volgorde omgedraaid. Eerst moet de data op orde, dan pas kun je sturen. Niet andersom.

Sturen lukt alleen als de basis er ligt

Een controller stuurt met cijfers. Analyseert, signaleert, kijkt vooruit. Dat werkt alleen als er één betrouwbare basis onder ligt. Wat de meeste MKB-bedrijven hebben is iets anders: verkoop in CRM-systeem A, finance in boekhoudpakket B, projecten en uren in C, en daarnaast vijf Excels die niemand officieel beheert. Verschillende klantnummers, verschillende definities, geen gedeelde waarheid.

Wie daar bovenop een controller zet, krijgt geen sturing maar opruimwerk. De controller wordt de-facto data-engineer, in een rol waar ze niet voor zijn aangenomen.

Drie oorzaken die niets met de persoon te maken hebben

Geen data-eigenaarschap. Vijf mensen onderhouden vijf Excels. Niemand is verantwoordelijk voor één bron-van-waarheid. Je controller wordt automatisch die ene persoon — en die moet dan iedereen zover krijgen dat ze hun eigen bestanden loslaten. Dat is geen finance-werk, dat is verandermanagement.

Geen gedeelde definities. Wanneer wordt een factuur ingeboekt? Wanneer wordt een offerte een opdracht? Wat is een "actieve klant", wat is "openstaand"? Zonder afspraken ga je elke maand opnieuw discussiëren wat de cijfers betekenen. Daar gaat de tijd in zitten die je dacht aan rapportage te besteden.

Geen consistente sleutels. CRM en boekhouding hanteren andere klantnummers. Operations werkt met projectcodes die finance niet kent. Elke maandafsluiting is een handmatige puzzel om cijfers te matchen die bij elkaar horen.

Wat er eerst moet staan

Voordat een controller kan sturen, moet dit staan:

• Eén bron per soort gegeven. Klanten in één systeem. Uren in één systeem. Facturen in één systeem. Niet drie van elk, niet "ook nog in een Excel".
• Per bron één eigenaar. Niet de controller — de eigenaar van het proces. Verkoop is eigenaar van klantdata, operations van projectdata, finance van facturen.
• Gedeelde definities en sleutels. Hetzelfde klantnummer in elk systeem. Eén definitie van "omzet", "openstaand" en "actieve klant" die overal geldt.
• Een rapportagekader. Welke vragen wil je elke maand beantwoorden? Welke cijfers heb je daarvoor nodig, uit welke bron? Pas daarna kies je de tools — Power BI, een datawarehouse, of voor sommige bedrijven gewoon een goed ingericht boekhoudpakket met dashboards.

Pas als dit staat heeft een controller iets om mee te werken.

Waarom dit zelden lukt met alleen een fulltime hire

Een fulltime junior of medior controller weet meestal niet in welke volgorde dit moet. Ze gaan rapporteren met de data die er is, lopen vast, en beginnen onder druk aan handmatige oplossingen die elke maand opnieuw moeten. Voor je het weet besteden ze 70% van hun tijd aan reconciliatie en 30% aan analyse — in plaats van andersom.

Dit is de fase waarin ik als fractioneel controller het meeste waarde toevoeg. Niet met techniek, maar met volgorde: welke afspraken eerst, welke bron leidend, welke definities vastgespijkerd, welk rapportagekader. Vaak in samenwerking met een systeem- of implementatiepartner die de koppelingen of een datawarehouse bouwt. Twee dagen per week, drie tot zes maanden, en de structuur staat. Daarna heb je twee opties: ik blijf op kleinere schaal voor analyse en sturing, of je neemt een junior controller aan die met een werkende structuur prima uit de voeten kan.

Conclusie

Eerst je data op orde, dan pas sturen. Wie de volgorde omdraait, krijgt een dure adviseur die opruimer wordt. Begin met structuur, daarna pas met mensen.