One of the most consistent patterns in technology project failures is the sequence: buy a platform, then figure out how to adapt your processes to it.

This sequence feels logical — you see a product, it looks like it solves your problem, you buy it. But in practice, this order produces predictable problems: expensive customisation, low adoption, and outcomes that don’t match the business case that justified the purchase.

The right sequence is the reverse. Define the process first. Then select the technology that supports it.

Why the order matters

A technology platform is a set of opinions encoded in software. It has a built-in model of how workflows should look, how data should be structured, and how users should interact with the system. When your actual processes don’t match that model, you have two options: change your processes to fit the platform, or customise the platform to fit your processes.

Both options are costly in ways that are rarely fully accounted for in the original business case.

Changing your processes to fit the platform is rarely as clean as vendors make it sound. Real organisations have regulatory requirements, customer commitments, and operational dependencies that constrain what can change. And even when a process can change, changing it without clear reasoning for why the new version is better — beyond “the software works this way” — produces confusion, resistance, and workarounds.

Customising the platform is its own trap. Every customisation creates technical debt that makes upgrades harder and increases the total cost of ownership. Vendors with strong platform roadmaps can outpace your customisations, leaving you on a version that no longer evolves.

What process definition looks like

The alternative isn’t elaborate process documentation for its own sake. It’s a focused analysis that answers a small number of specific questions before you look at any technology:

Who does what, when, and based on what information? This maps the current state — not as an aspiration, but as it actually operates, including the exceptions and workarounds that have accumulated over time.

Where are the meaningful friction points? Not every step that could be improved deserves investment. The meaningful friction is where delay, error, or bottleneck creates measurable business impact — slower customer response, higher cost, worse decisions.

What does a better version of this process look like? Before you know whether technology can help, you need to know what “better” means: What specific outcomes improve? By how much? How would you know?

Only then does it make sense to ask: Is there technology that supports this improved process without requiring us to rebuild it from scratch around the platform’s assumptions?

When platforms do come first

There are genuine situations where a platform-first decision makes sense: when the platform is sufficiently configurable that process alignment is straightforward, when the platform represents genuine best practice for your sector, or when the cost of the current process is so high that “good enough” with the platform beats “better” with a protracted process redesign.

None of these conditions should be assumed. They should be evaluated explicitly.

The practical implication

For most mid-market companies evaluating ERP upgrades, CRM replacements, or workflow automation tools, the most valuable two to four weeks before procurement is spent not on vendor demos but on a clear, honest map of: what the process actually is, where it breaks down, and what a viable better version would look like.

Technology vendors are good at showing what their software can do. They are less good at helping you evaluate whether it fits the specific way your business operates.

That evaluation is yours to do, and doing it rigorously before procurement is the highest-leverage investment in any significant technology decision.