Most technology spend in the mid-market fails for one reason: the system was bought before the problem was understood.
An ERP gets selected because a competitor has one, or because a vendor made a convincing pitch, or because the business has simply outgrown spreadsheets and something has to change. Eighteen months and a significant budget later, the new system runs alongside the spreadsheets rather than replacing them — because nobody documented the process the system was meant to support, and the people who have to use it every day were never in the room when it was chosen.
This isn’t a technology problem. It’s a sequencing problem. Get the process right, then buy the system to fit it, then earn the adoption — in that order. Reverse any two of those steps and the spend doesn’t disappear. It just stops working.
Technology & Data is the fifth of Cerebratum’s seven pillars, and it’s rarely the actual root cause of the problem it’s blamed for. A “the ERP doesn’t work” complaint is very often an Operations problem the system merely inherited — a process that was never documented, dressed up as a software failure. Where that’s the case, the same team follows the problem upstream, under the same principal, rather than selling a second implementation on top of the first one’s mistake.
PILLAR 05 · TECHNOLOGY & DATA
3
The order technology decisions actually need to happen in — process, then system, then adoption — and the order most organisations follow instead, which is roughly the reverse.
0
Technology recommendations we’ve made before understanding the process the technology is meant to support. The system is never the first conversation.
19
Years running the technology infrastructure — including a full platform re-architecture onto Azure and Kubernetes — behind a global enterprise SaaS platform.
Process. System. Adoption. Most organisations run this backwards.
Most technology engagements start with the system. A vendor is shortlisted, a demo is run, a business case is built around the software’s features, and the process the software is meant to support is assumed to already exist, or expected to sort itself out during implementation. It rarely does either.
The right order starts with the process — documented, before any vendor conversation happens. What does the business actually do, step by step, today? Where does the informal workaround live, and why does it exist? A process that isn’t documented can’t be evaluated against a system, because there’s nothing concrete to compare the system’s features to. Most “requirements documents” written for a vendor RFP are actually written during the RFP, under time pressure, by whoever happened to be in the room — which is a description of what people remember, not what the business actually does.
Only once the process is real does the system selection make sense. At that point the question stops being what does this software do and becomes does this software do what our process actually needs, without forcing us to redesign the process around the software’s limitations instead of the other way round. That’s a fundamentally different evaluation, and it changes which vendor wins.
And the system is only half the outcome. Adoption is the other half, and it’s the half nearly everyone skips. A system that goes live and isn’t used correctly by the people who have to use it every day isn’t a technology asset. It’s a cost with a login screen. Adoption isn’t a training session in the final week of a project — it’s a plan, built alongside the system selection, for how the people who’ll actually touch the software every day get from “I was told to use this” to “I’d notice if this broke.”
our approach
Diagnose the process. Choose the system. Build the adoption. In that order.
Three capabilities, sequential, each depending on the one before.
01 · Technology Strategy & Process Diagnosis
What to build, what to buy, what to leave alone — sequenced against the business, not the vendor’s roadmap.
Every technology engagement starts the same way here, regardless of what the client thinks they need: what does the business actually do, and where does the current way of doing it break down. Not a wishlist of features. A real map of the process as it exists — including the informal workarounds, the spreadsheet that’s secretly load-bearing, the step everyone does slightly differently.
From that diagnosis comes the technology roadmap — not a single system recommendation, but a sequenced view of what needs fixing first, what can wait, and what the business should build itself versus buy from a vendor. Most organisations skip this step because it feels slower than just picking a system. It’s the step that determines whether the system that gets picked afterward actually works.
02 · Systems Selection & Implementation
Requirements defined before the vendor conversation, not during it.
ERP selection, systems integration, and legacy modernisation all follow from the same discipline: the requirements exist as a real document, built from the process diagnosis, before a vendor is shortlisted. That document is what gets evaluated against — not the vendor’s demo, which is designed to show the system at its best, on data it was never asked to handle badly.
Where systems already exist and don’t talk to each other, the work is integration — making the stack function as one system rather than as a set of expensive islands that each do their job well and collectively do nothing coherent. Where the existing systems have been genuinely outgrown, the work is legacy modernisation — migrating off them without stopping the business to do it, which is a harder and more common failure mode than the migration itself.
This is also where cloud and infrastructure decisions sit — not chosen for their own sake, but sequenced against what the business’s actual growth trajectory requires, with the cost discipline that stops cloud spend becoming the new version of the capex problem it was meant to solve.
03 · Data, Analytics & Adoption
Turning scattered data into decisions — and turning a system that’s live into a system that’s used.
A system generates data from the day it goes live. Whether that data becomes useful is a separate piece of work, and it’s the piece most implementations never budget for. Data architecture is the discipline of turning scattered, inconsistent data into a single, trustworthy version of the truth. Business intelligence and analytics is the discipline of turning that trustworthy data into dashboards that answer a management question, rather than dashboards that simply exist because the software came with a reporting module.
Adoption sits alongside both. A system’s success is measured six months after go-live, not on go-live day — by whether the people using it have actually changed how they work, or have quietly built a new spreadsheet workaround around the new software the same way they built one around the old one. Every technology engagement Cerebratum leads includes an adoption plan built at the same time as the system selection, not bolted on afterward when someone notices usage has quietly stalled.
Where the brief calls for it, this extends into applied AI and automation — evaluated with the same discipline as everything else in this pillar: where it genuinely earns its place in the business, and, more often, where the honest answer is that it doesn’t yet.
in practice
Where this practice has been applied.
GLOBAL ENTERPRISE SAAS PLATFORM
From Hosted Software to an Actual SaaS Product
SITUATION
Ten years ago, “it’s on the cloud” was enough. A buyer heard AWS and moved on to the next question. That bar has moved. Enterprise buyers today know the difference between software that happens to be hosted and software that is genuinely built as SaaS — and they ask about it directly, because the difference determines what they’re actually buying.
The platform, as it originally stood, was the former. It ran on AWS virtual private servers — single-tenant, one client per instance. Which sounds like a minor technical detail until you follow what it actually meant in practice: every client’s deployment carried its own small deviations, its own accumulated customisations, its own slightly different version of the product. Not a different product for each client — but not the same product either. A services business, delivered through software, rather than a software product.
WHAT DEFINES SAAS ISN’T THE CLOUD. IT’S THE PIPELINE.
The re-platforming wasn’t a hosting change. It was a rebuild of what “the product” actually means. Every client — single-tenant or multi-tenant — now runs the same code. One codebase, one CI/CD pipeline: automated build and release, automated testing, source control through GitHub, deployed onto managed PaaS infrastructure on Azure and Kubernetes. A change ships once and every client receives the same product, the same day, built and tested the same way.
That’s the actual definition of a SaaS product, and it’s not a semantic distinction. A company running single-tenant instances with client-specific code deviations cannot ship a fix once. It has to ship it N times, test it N times, and carry N slightly different products under one brand — which is a support and engineering burden that compounds every year the business keeps signing new clients the old way. A true multi-tenant architecture on a real pipeline eliminates that compounding cost entirely, on day one of the rebuild.
THE PART MOST TECHNOLOGY MODERNISATION STORIES MISS
The compliance and security credentials enterprise buyers now demand as standard — SOC 2, ISO 27001, and the rest of the due-diligence checklist that shows up in every serious procurement process — are, to a significant extent, a function of the hosting and engineering discipline the platform runs on, not something built independently from scratch. A platform on managed PaaS infrastructure, with a real CI/CD pipeline and a single governed codebase, inherits a meaningful share of that credibility from the platform it’s built on and the discipline it’s built with. A platform running bespoke single-tenant deployments on unmanaged boxes has to build every piece of that credibility itself, from zero, client by client — which is slower, harder to prove, and considerably harder to defend under a serious security review.
WHAT IT CHANGED
Before: a services business wearing a software label. Every client on a slightly different version of the product. Every fix shipped multiple times. Every compliance question answered from a standing start.
After: one product, one pipeline, every client on the same code. A platform that can say, accurately, that it is SaaS — because the engineering discipline behind it is what actually makes that word true, not the fact that a server sits in a data centre instead of an office.
This is the same discipline the rest of this pillar is built on: understand what the system actually needs to be, before deciding how to rebuild it. The decision here wasn’t “modernise the infrastructure.” It was “stop running a customised service business and start running an actual product” — and the infrastructure rebuild was the mechanism, not the goal.
If a system you already paid for isn’t being used the way it was meant to be — that’s rarely a training problem.
Start with the process it was built to support. Tell us what the system was supposed to fix and what it’s actually doing today. We’ll tell you whether the gap is the system, the process underneath it, or the adoption that never happened.