Olivier Mangelschots

The through-line

One idea runs through everything: somebody has to sit in the architect's chair, and in most mid-sized companies that chair is empty. The diagnosis is not laziness. "Het probleem is niet dat KMO's niets doen. Ze doen voortdurend iets — brandje per brandje, tool per tool. Wat ontbreekt is iemand die uitzoomt" [2]. Left unattended, the result is predictable: "Wie is de architect van jouw bedrijf? Als niemand die rol opneemt, groeit de spaghetti vanzelf" [7]. The same observation is what prompted the founding of odum.digital after the sale of a previous software development company to Deloitte: owners of businesses with 25 to 500 employees lacked a digital vision and leaned too heavily on IT integration partners, so decisions were taken without a holistic view [14].

The role that fills the empty chair is deliberately not the one people expect. "Dat is wat we bij Odum doen. Niet de brandweer. De architect die weet welk blok eerst mag" [10]. And the ownership question is framed a step higher than IT governance usually puts it: the question is not who owns the IT department but who owns the digital future, because "een lege stoel stelt geen vragen" [11].

On why "we willen digitaliseren" is not a strategy

Digitalisation is treated as a presenting symptom rather than a plan. "'We willen digitaliseren' is geen strategie. Het is een symptoom. De vraag eronder is: wat wil dit bedrijf eigenlijk worden? Wie die vraag kan beantwoorden, heeft het moeilijkste al gehad" [9]. That ordering, business intent first and technology second, is what the fractional CIO work is built on: designing the IT landscape and then selecting the technology and the implementation partners, including the ERP choice [4].

The same discipline applies to AI. The interesting question is not capability but foundation: "AI versnelt wat er is. Dus de eerste vraag is niet wat AI kan, maar wat jullie eronder hebben staan" [5].

On the system that still just works

The most dangerous piece of a KMO's landscape is not the broken one. "Het gevaarlijkste systeem in een KMO is niet het systeem dat kapot is. Het is het systeem dat nog net werkt" [10]. Directions then see only two moves, replacing everything, which is unfeasible, or carrying on, which is comfortable until it is not. The third way is sequencing: "Je haalt de toren niet omver. Je vervangt hem blok voor blok, in een volgorde waarin hij blijft staan" [10].

The reason companies keep choosing option two is structural rather than stubborn. A KMO is an operating machine, and a transformation lands on top of that machine, carried by people who have never done one before, so it gets postponed [6]. What is striking is not that firms keep going but what it costs to get out later: "elk jaar uitstel maakt de weg eruit duurder. Er bestaat een punt waarop je er niet meer op eigen kracht geraakt. De meeste directies weten niet dat dat punt bestaat, tot ze eroverheen zijn" [6].

On focus as speed

The brake on digital maturity is misdiagnosed as money or people. "De grootste rem op digitale maturiteit in een KMO is niet budget of talent. Het is alles tegelijk willen doen" [8]. The maturity model says pick one discipline; experience in KMO trajectories suggests something more pragmatic, pick one discipline at a time. Eighteen months of customer experience, covering e-commerce, CPQ and customer service, and only then operational excellence with ERP, WMS and MES [8]. The conclusion is stated flatly: "Focus is geen beperking. Het is snelheid" [8].

On staying close to the standard

Choosing consciously does not mean hunting for everything outside the suite. Usually the opposite [3]. Four rules of thumb for anyone working with Odoo: stay as close to the standard as possible and use the modules as intended, because that is where the strength of the suite sits; dare to integrate externally where a domain is strategic and outgrows the suite, a Shopify for a serious B2C webshop, an MES that goes beyond what Odoo can handle; limit customisation, because "moet je modules zowat herprogrammeren en weet niemand nog hoeveel werk erin zit, dan ben je waarschijnlijk verkeerd bezig"; and pick an Odoo partner who supports that vision and has experience with such integrations, since not every partner is equally strong there [3]. The advice comes with an explicit independence statement: the team implements no Odoo and takes no commission from any vendor, it only draws the architecture [3].

On the implementation gap

Designing the landscape and picking the partner is where most advice stops, and where the real problem starts. At many clients there is nobody internally who can carry a large and complex implementation, so that role is filled from outside, on the client's side of the table [4]. The shape of the job is specific: one and a half to three days a week per client, typically over trajectories of twelve to twenty-four months, guarding scope, guiding key users from old to new, pulling the data migration along, coordinating test phases, and leading go-live and adoption [4]. In practice the person becomes the client's super key user, owning change management, coaching and internal communication [4]. This capacity is built as a network of independent experts rather than a payroll [4].

On what to outsource and what to keep

For mid-sized companies of 25 to 500 or more employees, the bottom layer of IT infrastructure is largely standardised across industries, which makes complete outsourcing the sensible default, while business-specific applications need a different treatment [12]. The corresponding advice to IT partners is to standardise that layer and operate it efficiently across many customers [12]. One thing stays inside: in larger organisations, internal coaching roles are worth keeping so users get help with productivity tools [12].

On accountancy firms and staying relevant

For accounting firms the transformation rests on three pillars. First, internal efficiency, doing more with the resources already there. Second, the customer experience and the way service is delivered, including client portals and onboarding journeys. Third, and hardest, strategic repositioning: honestly evaluating whether today's services will still be relevant in three to five years, in markets that are moving quickly [13].

On the tools you think in

For more than twenty years OneNote was the brain, starting when it was still a file on a PC, long before the cloud, holding notes, research, transcripts, syntheses, deliverables and SOPs [1]. The whole of ODUM.digital moved to Notion four years ago, and he was the last one across, pulled in by Hans Nissens [1]. What the move bought was collaboration rather than storage: sharing a single page with a client without login trouble, working with Microsoft, Google or anything else, where OneNote forces you to share an entire notebook, all or nothing [1]. Once clients are on the page they participate, so a process analysis is walked through together with inline comments until there is an approved version, with no rounds of email [1]. Databases sit alongside pages, so a market study of sixty WMS systems becomes one page per record, fields at the top, notes and subpages underneath, viewable as a table, a board or filtered per client [1]. And navigation works like a wiki, linking to a page or a colleague with @ [1].

Takeaways

• Ask who owns the digital future, not who owns the IT department; an empty chair asks no questions and the spaghetti grows by itself [7][11].
• Treat "we want to digitalise" as a symptom and answer the question underneath it, what this company actually wants to become [9].
• Before asking what AI can do, look at what is standing underneath it, because AI accelerates whatever is already there [5].
• Replace the tower block by block in an order that keeps it standing, and act early, because every year of postponement makes the way out more expensive until you can no longer get there under your own power [10][6].
• Pick one discipline at a time, for example eighteen months of customer experience before touching ERP, WMS and MES [8].
• With Odoo, stay close to the standard, integrate externally only where a domain is strategic and outgrows the suite, limit customisation, and choose a partner who backs that approach [3].
• Budget for a client-side project lead on ERP implementations, one and a half to three days a week over twelve to twenty-four months, owning scope, key users, data migration, testing, go-live and adoption [4].
• Outsource the standardised infrastructure layer entirely, but keep internal coaching capacity in larger organisations for productivity tools [12].