Processen opruimen tijdens je Odoo-implementatie

De meeste bedrijven behandelen een Odoo-implementatie als een technisch project: het oude systeem eruit, Odoo erin, data overzetten. Wie er middenin zit, ontdekt iets anders. De grootste vraagstukken zijn zelden technisch.

Ze gaan over processen die al jaren op een bepaalde manier lopen, zonder dat iemand zich ooit afvroeg of dat eigenlijk klopt.

Wat er boven water komt

Zodra je een systeem écht opnieuw inricht, moet je elk proces opnieuw doorlopen. Dat dwingt vragen af die jarenlang niemand stelde. Een paar voorbeelden die ik regelmatig tegenkom bij bedrijven die overstappen naar Odoo:

Retouren en credits die verkeerd werden verwerkt. In het oude systeem ging een retour er soms als correctie in, soms als nieuwe transactie, soms helemaal niet apart geboekt. Niemand deed dit met kwade opzet — het groeide zo, en het werkte "goed genoeg". Tot je de voorraadaantallen naast de boekhouding legt en er structurele verschillen blijken te zitten die nooit zijn opgelost, alleen maar opgestapeld.

Gebruikersrechten die veel te breed waren. In veel oudere systemen krijgt iedereen op den duur toegang tot bijna alles — niet omdat dat nodig is, maar omdat het makkelijker is dan steeds rechten aan te passen. Het gevolg: mensen kunnen boekingen goedkeuren die ze eigenlijk niet zouden mogen goedkeuren, of voorraad aanpassen zonder dat daar een tweede blik op zit. Dat is geen wantrouwen richting die mensen — het is gewoon slecht voor de controle, en voor je accountant een reden om vragen te stellen.

Een inrichting die niet optimaal was. Denk aan onnodig veel intercompany-transacties: leveringen en verplaatsingen tussen entiteiten die er historisch ingeslopen zijn, zonder dat iemand nog weet waarom het zo moet. Elke intercompany-stroom betekent extra boekingen, extra afstemming, en extra kans op fouten — terwijl een deel ervan bij nader inzien overbodig blijkt.

Waarom dit altijd gebeurt

Dit is geen teken van een slecht geleid bedrijf. Het is een normaal gevolg van groei. Processen ontstaan ad hoc, iemand vindt een werkbare oplossing voor een probleem van dat moment, en die oplossing wordt de vaste manier van werken. Niemand krijgt ooit de opdracht om het geheel opnieuw te bekijken — daar is simpelweg geen natuurlijk moment voor.

Een implementatie is dat moment wél. Je kunt niet "even snel" het oude proces overzetten, want het nieuwe systeem werkt anders. Dat dwingt je te kijken naar wat een proces eigenlijk moet doen, in plaats van hoe het toevallig gegroeid is.

De kans die er ligt

Precies daarom is een implementatie het beste moment om te versimpelen — en dat mag verder gaan dan alleen het proces zelf. Neem intercompany-stromen. Bij het herinrichten daarvan is het de moeite waard om ook te kijken wat juridisch en fiscaal daadwerkelijk nodig is. Welke leveringen en verplaatsingen zijn verplicht vanuit btw- of verrekenprijs-overwegingen? En welke zijn er puur bij gekomen omdat het historisch zo werd gedaan?

Hetzelfde geldt voor rechtenstructuren: een nieuwe inrichting is het moment om functiescheiding opnieuw vast te leggen in plaats van de oude, te brede rechten één-op-één over te zetten.

Waarom dit meer is dan techniek

Dit soort veranderingen raken mensen persoonlijk. Iemand die jaren op zijn eigen manier retouren verwerkte, ervaart een strakker proces al snel als kritiek op zijn werk. Iemand die gewend was overal bij te kunnen, ervaart minder rechten als wantrouwen — ook als het puur om controle gaat.

Dat is de kern van change management bij een implementatie: niet alleen het nieuwe proces neerzetten, maar uitleggen waarom het anders wordt, en mensen de ruimte geven om te wennen. Een implementatie die alleen op de techniek let en dit negeert, loopt vast op weerstand — ook als het systeem zelf perfect werkt.

Waar ik in beeld kom

Ik bouw Odoo niet. Dat doet de implementatiepartner. Waar ik in beeld kom: samen met de organisatie in kaart brengen welke processen echt kloppen en welke workarounds zijn geworden. Welke rechten bij welke functie horen. En welke intercompany-stromen juridisch en fiscaal nodig zijn, versus historisch gegroeid. Dat sluit aan bij wat ik breder doe rond financiële grip op Odoo, vóór, tijdens en na de implementatie.

Dat is finance- en controlwerk, niet iets dat een technische partner er even bij doet. Als je dit overslaat, moet het na de implementatie alsnog gebeuren — maar dan met een systeem dat de oude rommel al heeft vastgelegd.

Kortom

Een Odoo-implementatie voelt als een IT-project, maar het echte werk zit in de processen erachter. Retouren die verkeerd liepen, rechten die te breed waren, stromen die niemand meer kon verklaren — dat komt tijdens een implementatie vanzelf boven water. De vraag is niet óf je dat tegenkomt, maar of je het gebruikt om te versimpelen, of dat je het één-op-één overzet naar het nieuwe systeem.