Every year, mid-market organizations in Canada and the United States commit meaningful capital to transformation initiatives — ERP consolidations, CRM deployments, AI-enabled operations, shared services transitions — and a substantial portion of those initiatives either stall, go materially over budget, or deliver a fraction of the intended value. The failure is rarely the technology. In our experience working with operations, finance, and strategy leaders at organizations between 150 and 1,500 employees, the root cause is almost always the same: the organization attempted to implement a solution before it had defined the operating model the solution was meant to support. The software gets selected, the vendor gets contracted, the project kick-off happens — and somewhere in month three or four, the project team realizes that no one has agreed on who owns the process, what the data standard is, or how the new workflow connects to the reporting structure. At that point, the project becomes an expensive exercise in backfilling decisions that should have been made first.

What an operating model actually is — and what it is not

The term “operating model” is used loosely in most organizations, which is part of the problem. An operating model is not an org chart. It is not a process map or a technology architecture diagram. It is the integrated design of how an organization delivers value — the explicit, documented answer to how work gets done, by whom, using what systems and data, under what governance, and measured against what outcomes.

A complete operating model has six components, and they are not independent variables. They are a system. Changing one without accounting for the others produces instability.

• Processes: The end-to-end workflows through which the organization executes its activities — from demand generation through fulfillment, from budget allocation through financial close, from hire-to-retire. Processes define the sequence of activities, the handoff points, and the decision rights embedded in operational execution.
• People: The roles, skills, spans of control, and accountability structures required to execute the processes. This is distinct from the org chart — it includes the competency profiles, training requirements, and capacity models necessary to sustain operations.
• Technology: The systems, platforms, and tools that enable process execution and data capture. Technology is the third component, not the first. The selection of technology should be driven by the process and people design, not the reverse.
• Data: The definitions, ownership, quality standards, and flows of information that run through and across processes. Data design determines whether the organization can trust what the technology produces. In our experience, this is the most consistently underinvested component in mid-market transformations.
• Governance: The decision rights, escalation paths, policy frameworks, and oversight structures that coordinate work across functions, entities, and geographies. Governance is how the operating model manages exceptions, resolves conflicts, and evolves over time.
• Performance management: The KPIs, reporting cadences, accountability mechanisms, and consequence structures that signal whether the operating model is functioning as designed. Without this component, the organization has no closed feedback loop.

The design sequence that most organizations invert

The correct sequence for operating model design is logical once stated explicitly, but it is violated constantly in practice. The sequence is: strategy first, then process, then people, then technology, then data, then governance, then performance management.

Strategy defines the value proposition and the capabilities the organization must develop or sustain. Process design flows from the capabilities the strategy requires. People design follows process — you cannot define roles, spans, or skill requirements until you know what the process demands. Technology selection follows people and process — the platform must support the workflow and the team structure, not define them. Data design follows technology selection because data architecture depends on what the systems capture and what the processes require as inputs. Governance follows data — decision rights over information and process ownership must be established before the model goes live. Performance management closes the loop by connecting the outputs of the operating model back to the strategic objectives that initiated the design.

What organizations typically do instead is: select technology based on analyst reports or peer benchmarks, implement the vendor’s default configuration, and then attempt to redesign processes and roles around the software’s assumptions. This is not transformation. It is vendor-led configuration, and it produces operating models that are optimized for the software, not for the organization’s strategic intent.

Running a current-state assessment that is actually useful

A current-state assessment is not a documentation exercise. Its purpose is to produce an accurate, shared understanding of how the organization actually operates today — not how the process documentation says it operates, and not how leadership believes it operates. These three versions are rarely identical, and the gaps between them are diagnostic.

An effective current-state assessment across the six operating model components involves the following workstreams:

1. Process observation and mapping: Walk the process with the people who execute it. Shadow sessions, structured interviews, and process walkthroughs consistently surface steps, workarounds, and exception-handling routines that do not appear in any documentation. For mid-market organizations, it is common to discover that 20 to 40 percent of actual process steps are informal — they exist in email threads, spreadsheets, or individual knowledge, not in any system of record.
2. Role and capacity analysis: Map actual role activities against formal job descriptions. Identify where work falls into gaps between roles, where single individuals are load-bearing risks, and where decision authority is ambiguous. Time-on-task analysis, even informally conducted, frequently reveals that high-value employees are spending the majority of their capacity on activities that could be automated, delegated, or eliminated.
3. Technology landscape inventory: Enumerate every system, tool, and integration in use — including shadow IT. At most mid-market organizations, the number of active tools is materially higher than IT has documented. Each undocumented tool represents a data flow, a security posture, and a process dependency that must be addressed in the future-state design.
4. Data quality audit: Sample data from the systems of record that the transformation will touch. Assess completeness, accuracy, consistency across systems, and timeliness. Poor data quality discovered during an ERP go-live or a CRM migration is a project-stopper. Discovered during current-state assessment, it is a design input.
5. Governance mapping: Document who currently makes what decisions, and at what level. Identify where decisions are made by default rather than by design — where the loudest voice in the room, the longest-tenured employee, or the most accessible spreadsheet determines outcomes. These are governance gaps that the future-state model must explicitly resolve.
6. Performance baseline: Identify what metrics exist, how they are calculated, how frequently they are reviewed, and whether they drive any consequence. In many mid-market organizations, performance metrics are produced but not acted upon — they are reporting artifacts rather than management instruments.

Designing the future state without overengineering it

Future-state operating model design is a discipline in specificity. The output is not a vision statement or a set of guiding principles. The output is a documented design across all six components with enough detail that an implementation team can build to it.

The design should answer, at minimum: What are the end-to-end processes that will operate in the future state, and how do they differ from today? What roles are required, what skills do those roles demand, and how does the accountability structure change? What systems will be in scope, and what will be retired or replaced? What data standards apply, who owns each data domain, and what quality thresholds are required? Who has decision authority for what, and how are escalations handled? What does good performance look like, and how will it be measured and reported?

The gap analysis as a change workplan

The gap between current state and future state is where most organizations lose the thread. The gap analysis is typically presented as a list of differences — a column of “current” and a column of “future” for each operating model component. That format is accurate but not actionable.

A gap analysis that drives transformation treats each gap as a discrete change initiative with ownership, sequencing dependencies, and a completion criterion. The following table illustrates the structure organizations we work with use to convert a gap analysis into a workplan:

This structure forces three things that a standard gap list does not: it names an owner for every gap, it surfaces the dependencies between workstreams, and it creates a basis for sequencing the implementation in a way that respects those dependencies rather than running workstreams in parallel when they should be sequential.

Where mid-market organizations are most exposed

Large enterprises maintain program management offices, enterprise architecture functions, and organizational effectiveness teams that, however imperfectly, hold operating model design accountable during transformation. Mid-market organizations between 100 and 1,500 employees typically do not have these functions as standing capacity. The VP of Operations is running operations. The CFO is managing the close. The IT Director is managing infrastructure. No one is unambiguously accountable for the coherence of the operating model design across functions and over time.

This is not a criticism — it is a structural reality of mid-market organizations, and it is why the risk profile of transformation in this segment is disproportionately high relative to the capital and organizational energy invested. The mitigation is either to build temporary internal capacity specifically for the transformation program, or to engage external support that is explicitly scoped to operating model design — not to technology implementation, which is a different discipline with different incentives.

Frequently asked questions

How long does an operating model design process typically take before technology selection?

For a mid-market organization undertaking a significant transformation — an ERP implementation, a shared services consolidation, or a major process redesign — a credible current-state assessment and future-state design across the six components typically requires six to twelve weeks of focused effort. This assumes executive availability for decision-making, access to operational staff for process walkthroughs, and a dedicated internal or external resource coordinating the workstreams. Organizations that compress this phase below four weeks typically rediscover the skipped work as project issues during implementation, at a materially higher cost to resolve.

Can we run operating model design in parallel with technology selection?

To a limited degree. Market scanning — understanding what categories of technology exist and what major platforms are capable of — can proceed in parallel with current-state assessment without causing harm. What should not happen is vendor engagement, RFP development, or contract negotiation before the future-state process and data design is sufficiently mature. Vendors will configure their demonstrations to your stated requirements; if your stated requirements are undefined or premature, the demos will validate whatever the vendor shows you rather than validating fit to your actual needs.

What is the most common mistake organizations make in the gap analysis phase?

Treating the gap analysis as a project deliverable rather than a decision-making tool. We frequently see gap analyses produced as slide decks or spreadsheets that are presented to leadership, acknowledged, and filed. The mistake is not producing the analysis — it is failing to translate the gaps into owned workstreams with sequencing and accountability. A gap analysis that does not result in a change workplan with named owners and dependency mapping has limited operational value, regardless of its analytical quality.

How do we handle governance design when the organization has strong political dynamics around decision rights?

Directly and explicitly. Governance design surfaces latent conflicts over authority and ownership that exist whether or not they are named. Avoiding the design conversation does not eliminate the conflict — it ensures the conflict will be resolved during implementation, when the cost of resolution is higher and the time pressure makes good decisions less likely. In our experience, the most effective approach is to conduct governance design in structured working sessions with the relevant senior leaders, facilitated by someone with explicit authority from the CEO to drive decisions. Without that mandate, governance design sessions become dialogue rather than decision-making.

What does “good enough” future-state design look like before starting implementation?

A future-state design is sufficient to begin implementation when four conditions are met: the end-to-end processes in scope are documented at a level of detail sufficient to configure the technology; the roles and accountability structure have been approved by the relevant HR and operations leadership; the data standards and ownership for each data domain in scope have been defined and assigned; and the governance structure — including decision rights for ongoing model changes — has been ratified. Perfect future-state design is not the standard. The standard is: sufficient definition that implementation decisions can be made against a stable design reference, rather than being made ad hoc by the implementation team.

Operating Model Design: The Foundation Every Transformation Needs Before Technology

Most senior operations directors, CFOs, and VPs of Strategy at mid-market organizations have experienced at least one transformation initiative that consumed significant resources and delivered significantly less than projected — and the root cause, on examination, was that the operating model was never coherently defined before the technology was selected. This post provides the diagnostic framework and the design sequence to prevent that outcome.