The Hidden Cost of Your Last Technology Investment

There is a conversation I have had more times than I can count, in boardrooms across Lagos.

A CEO leans back in their chair and tells me about the ERP system they implemented eighteen months ago. The figure they spent. The months of disruption. The consultant fees. The staff training. The promise of what it would do for the business.

Then they pause.

"The system is running," they say. "But honestly? I am not sure what we got for it."

I always ask the same question: "Before you chose the system — did you document how the business actually works?"

The answer, almost every time, is no.

And that is the hidden cost of your last technology investment. Not the licence fee. Not the implementation. Not even the lost productivity during the transition period. The real cost is the gap between what you paid for and what you actually received — and the reason for that gap has nothing to do with the technology.

The problem is not the system

Nigerian enterprises are not under-investing in technology. Walk through any serious mid-market operation in Lagos or Abuja and you will find ERP systems, CRM platforms, HR software, accounting tools. The investment is real. The intent is genuine.

What is consistently absent is something far less visible — and far more important.

Call it the operating model. The documented architecture of how the business works: what processes exist, who owns them, in what sequence they run, who decides what, and what happens when something goes wrong. The structural logic of the organisation that any system — human or technological — must conform to before it can add value.

When this architecture does not exist, technology cannot save you. In fact, it makes things worse.

Because technology does not redesign your business. It automates whatever is already happening. If what is already happening is undocumented, inconsistent, and founder-dependent — technology makes those problems faster, more visible, and significantly more expensive.

The Wright Brothers did not need a bigger engine

In 1903, the most-funded aviation projects in the world were failing. Not for lack of power. They were building larger engines and bolting them onto unstable frames. They kept solving the wrong problem.

The Wright brothers succeeded because they understood that flight was not a power problem. It was a control and integration problem. They designed the three-axis control system before they worried about the engine. The architecture came first.

Most technology implementations in Nigerian enterprise are the bigger engine. More processing power, more modules, more data. Bolted onto a business whose underlying architecture was never designed in the first place.

The result is predictable: the system runs. The business does not improve. The CEO looks at the dashboard and wonders why the numbers still require explanation every Monday morning.

What I keep finding

In the diagnostic work Crelligent does across Nigerian mid-market enterprises, one finding recurs with a consistency that no longer surprises me.

The constraint is almost never the market. Rarely the technology. Almost universally, the primary constraint is the operating model — the absence of a deliberate, documented architecture for how the business works.

Processes that exist in the founder's head but nowhere else. Decision rights that are assumed but never written down. New hires who cannot perform not because they lack skill but because there is no system for them to plug into. Meetings that recur because the same decisions are made — and unmade — every week.

Into this environment, an ERP is installed. And the ERP faithfully reflects the chaos it found. It simply does so in a database.

The sequence that actually works

The enterprises I have seen make technology work share one characteristic: they designed the architecture before they selected the tool.

Not perfectly. Not in some waterfall project management fantasy where everything is documented before anything moves. But deliberately enough to answer the questions that determine whether a system will work: What processes does this technology need to support? Who makes decisions inside this process, at what threshold, and how quickly? What does "working correctly" look like — and how will we know when it isn't?

These are not technology questions. They are architecture questions. And they cannot be answered by a software vendor.

When you answer them first — even partially, even imperfectly — the technology implementation becomes simpler, cheaper, and more likely to deliver what you paid for. The team knows what the system is supposed to do. The system knows what it is supposed to support. The two things fit together because they were designed together.

When you skip this step — when you let the technology vendor define the architecture by the shape of their modules — you inherit their assumptions about how businesses work. And their assumptions were built for someone else's business.

The question worth sitting with

Before your next technology decision — before the demo, before the proposal, before the shortlist — ask yourself one question honestly.

If the answer is no, the technology investment you are considering will not solve the problem you think it will solve. It will digitise the absence of architecture. And you will have that conversation — the one about what you got for the money — in eighteen months.

The architecture comes first. The system follows. In that sequence, technology performs. In the other sequence, it disappoints.

That is not a technology problem. It is a design problem. And design problems have design solutions.