The Operating Model Question: Why Picking a Platform Isn't the Hardest Part of Modernization
The energy in most modernization conversations gets poured into one macro decision: which platform, Oracle or Salesforce? Within that are myriad sub-questions: Cloud-native or cloud-hosted? Single suite or best-of-breed? The buyer’s team will spend months on the minutiae — vendor demos, reference calls, annotated RFPs, and side-by-side comparisons in spreadsheets so wide they need a second monitor. The decision feels enormous, and it’s treated like it.
Then, the platform is selected, the implementation starts, and somewhere in the second quarter of design sessions, the project lead often realizes the conversation that mattered most was never really had. That’s the operating model question, and it’s where most tech modernizations actually succeed or fail.
Operating models: the plumbing no one sees.
The operating model isn’t the org chart or the five-year strategy. It’s the granular reality of how decisions actually get made — who owns what, where accountability lives when something breaks, how incentives align with the behaviors the new platform will demand, how fast a decision can travel from the floor to a VP and back. The plumbing nobody volunteers to present at a steering committee.
These questions aren’t glamorous. They show up in the slides nobody wants to present at the steering committee. They get pushed to phase 2, or to “post-launch optimization,” or to the change management workstream that gets resourced last and de-scoped first. But the operating model determines whether a platform actually changes how the business runs, or whether the business uses new software to do its old work, only slightly slower than before.
A simple example: A company moves to a new CRM. The platform supports lead routing based on territory, deal size, account history, and a dozen other signals. But the sales VP and the inside sales manager have never actually agreed on who gets which deals, and the new system requires such agreement to function. So either the agreement is reached quickly by people whose performance depends on the answer, or the new CRM is configured to mimic the routing used by the old one. The platform investment, in the latter case, mostly buys a slightly faster way to argue internally about the same things.
Why operating models are the harder problem.
Vendor selection is relatively easy. There are matrices, references, demo scripts, RFP scoring rubrics, and analyst quadrants you can rely on. The platform decision is a problem you can buy your way through, and most enterprises are reasonably good at it by now.
Operating model design is different. It requires honest internal conversations about who owns what, who reports to whom, who has the authority to overrule whom, and which incentives need to change. It surfaces disagreements between functions that have lived politely beneath the surface for years. And it requires executive sponsorship that’s actually sponsored, not just listed on a slide.
The people who need to participate are the people whose jobs the modernization is most likely to change. That’s why the conversation keeps getting postponed — first into the change management workstream, then into UAT, then into “we’ll address it after go-live.” Each delay sounds reasonable, but the cumulative effect is fatal.
What actually happens is that the platform is stood up to support the existing operating model. The team learns the new tool but applies it to the old process. The board gets a successful go-live announcement and, a year later, asks why the productivity gains the business case promised never materialized.
Why discussions about operating models should come first.
The operating model conversation can and should occur in tandem with platform selection. In some cases, it should even happen first. Both decisions become more honest when they’re made together: the platform you pick depends on the way you actually want to run the business, and the operating model you design depends on what the platform can support.
This isn’t a rebrand of change management. Change management, as the term is usually used, is downstream work: training plans, communication calendars, superuser networks. Important, but distinct. Operating model design is the upstream decision about how the business will actually run after the platform lands. The training comes after.
That’s the conversation Apex IT’s strategic advisory practice exists to put on the table — as the foundation the platform decision ultimately sits on, rather than a phase-2 add-on. If you’re evaluating platforms without a parallel conversation about the operating model, the modernization may not be behind schedule yet, but it’s likely it will be. Connect with us to learn about our holistic approach to the operating model question, and how we can apply it to the needs of your business.