I wrote on Linked In about when you don’tneed to consolidate several systems that serve the same purpose. A GC I described was running three CLMs across three businesses after a series of acquisitions, and the businesses were different enough that forcing them onto one platform would have cost more than it saved. What they needed was a reporting layer over the top, not a whole new system.
That doesn’t mean consolidation is always wrong. Most business leaders already have a good instinct for when it’s the right call. What’s harder is backing that up with a clear rationale, especially when there’s pressure to decide quickly.
There are two situations in particular where I think consolidation is the right answer:
When the businesses are fundamentally similar
In the acquisition scenario, consolidation works when the underlying businesses are structurally the same. The clearest sign is what’s happening on the legal, contracting and organisational side: common templates and processes being adopted across different business units, overlap in the clients or vendors the teams deal with, key stakeholders with cross-business responsibilities. The more integrated the businesses are in practice, the stronger the case for one system.
When the tools were never bought strategically
The second situation is more common, and it isn’t really about the systems. It’s about how they got there. Procurement bought a CLM to solve its own problem. Legal has been managing contracts in a separate system. Sales has been storing signed contracts in the contacts module of its CRM the whole time, without telling anyone else in the business that’s what they needed.
Each function chose and implemented its tool tactically, to solve an immediate problem, and no-one ever looked holistically at contracting across legal, procurement, and sales. That’s the plain-English version of “this was never a strategic decision.”
Probably, no one even realised it was an issue, until something happens that forces attention, like a divestment, a leadership change or a strategic initiative. Whatever that trigger is, it doesn’t create the problem. It just forces the question that tactical buying never answers: does this make sense for the whole business, not just for this immediate need?
A visibility layer only helps if the systems are good enough
If each of those three systems is doing its job well, meeting all of each function’s requirements without any niggling issues, pain or frustration, a reporting layer is genuinely enough. If they are not, then consolidation brings not just efficiency gains, but also opportunities to deliver more value to the businesses or functions they serve.
These opportunities typically exist where the systems were bought tactically rather than strategically, where they are stand-alone tools with little or no integration into the organisation’s other systems, or where the configuration hasn’t evolved with the business needs, perhaps due to budget limitations, knowledge and capacity gaps or simple lack of ownership. Out of date templates, manual steps and user frustration are good indicators that you need something more than just visibility.
Three questions before you move forward
Before going ahead, answer these three questions:
- Is the contract process capable of being broadly harmonised across functions, contract types and geographies? Whatever the trigger for consolidation, Legal is usually the common denominator, even where processes and workflows differ today. The test isn’t whether they’re the same now, it’s whether they’re capable of becoming one coherent process (note: process, not contract language).
- Are the current tools good enough? Look at the functionality gaps that exist, the points of friction with or between other systems and processes, and user experience. Manual data entry or duplication is a data quality risk. Every document upload that relies on a human is a data accuracy risk, with no guarantee you’ve got the complete picture. Users having to switch between different tools in the same workflow costs time.
- Have you got the full picture on cost, benefits, and risks? Not just the implementation and disruption cost, but the benefits genuinely expected, and any factors impacting the timeline, like being required to migrate off systems post-divestment, or aligning with other organisational transformation projects.
Making it work
Answering yes to those gets you some of the way, but the next steps are just as important:
- Validate requirements in detail, beyond a list of features. Understand the workflows, the contracts and the business needs properly, find where they genuinely overlap, and map today’s pain points honestly, including the new friction a change might create.
- Lock in the success criteria and user experience early. What does good look like for the people using it day to day, and what will they get that they don’t have today? Paint the future state before a tool gets picked, not after.
- Standardise where differences don’t need to exist. Where they do (different geographies, regulatory regimes, risk appetite) understand why.
- Only start on the business case and selecting a tool once you’ve done the first three. Skipping these gets you an answer quicker, but doesn’t guarantee it’s the right answer for your business.
- Implement in phases, sequenced across functions or geographies rather than all at once. Sandbox testing with end users allows you to iterate the configuration around your operational reality, not a consultant’s impression of the workflow.
- Prioritise change management and adoption from day one. If you only start at go-live, it’s too late.
One thing that isn’t in the six steps above but deserves its own mention, because I’ve seen it derail projects far more than tool choice, is stakeholder alignment.
A consolidation across functions or businesses needs every function and key stakeholder genuinely bought in, not just informed. Genuine alignment means people are more likely to turn up: to help define requirements, to engage properly, to test what’s actually being built, and to use something that they know adds value. Without it, you can build the right system and still not get the value out of it.
What this means in practice
Consolidation isn’t right or wrong by default. It’s right when one of the two situations above genuinely applies and the three questions confirm it, and it only delivers if the six steps happen in order rather than jumping straight to tool selection.
Explore our CLM Consulting Services.
