Standardize Before You Automate

Six things made the same across every team form the foundation; agents run only the written-down work above it; the stage is done when the first process is handed over.

Standardize before you automate is the principle that a workforce planning function assembled from several organizational heritages — through merger, acquisition or regional consolidation — must formalize, centralize and standardize its foundations before any of its processes can be handed to AI agents. The stage should end with the first agentic handover rather than with a platform going live. It has six standardizations: technology by planning horizon, process documentation, roles, objectives, data definitions, and interfaces to adjacent functions. It is the second stage of the agentic journey map, following definitional reconciliation and preceding the sorting of work into the three bands.

Why standardization comes first

Agents execute what is written down. A function that runs four scheduling practices, four definitions of a skill and four ways of counting a headcount cannot hand any of them to an agent, because the agent would need to be told which of the four it is executing and the organization cannot say. The platform-migration finding makes the same point from the technology side: a migration cannot be executed without shared definitions of the objects the platform holds, and a migration that lands on unreconciled definitions ends with one platform instance carrying one heritage's taxonomy adopted wholesale, with the other heritages' distinctions lost. Automation raises the stakes of the same requirement. An automation program that lands on unreconciled definitions produces as many agentic estates as there were heritages, none comparable with the others — the consolidated organization's original problem reproduced in software.

The shape of the stage is an old one in centralized planning functions: a standard that names uniformity of goals, roles and processes across all sites as its destination, while accommodating known site-to-site variation for a stated interim. Uniformity as the destination, tolerated variation with a date on it as the path.

The six standardizations

#	Standardization	What is standardized	The rule
1	Technology — one platform per planning horizon	One platform for short-term forecasting and scheduling; one for intraday automation; one system of record for long-range capacity, with the simulation engine held separately from it	The platform executes the ontology; it never defines it. Placing any product at the center adopts its interval, state and skill constructs as the enterprise data model — the thing a consolidation is trying to escape. The data warehouse and the canonical workforce object model are the core; every platform is an execution endpoint
2	Process — documentation to a standard	Every planning process decomposed to the L0–L3 standard: identity, one-page flow, step table with the tools each step touches, work instructions — the layered form that quality-system documentation guidance and structured analysis both anticipate	The step table's tools column is the permission map an agent will need. Documentation level becomes the sorting rule at the next stage; start with the processes that are easiest to write down
3	Roles — organized by horizon	Seats defined by planning horizon (long-range, forecasting, scheduling, intraday, placement) rather than by business segment; leader-facing partners as a thin layer over estate execution	The seat that owns where work sits is defined as a workforce-planning seat; supplier administration is a separate function. The overseer role is defined here and filled for the first handed-over process
4	Objectives — an owned register	Competing objectives (cost, experience, revenue, compliance) held in a register with owned, versioned orderings; the planning function prices the distance between orderings rather than arguing them	One measured attribute per objective per node, including the agentic node. An objective with no instrument collapses out of every model silently (Instrumenting the Objective Before Building the Model)
5	Data — shared definitions, then one measurement view	A small set of definitions agreed across heritages — the headcount perimeter, what a client-exclusivity promise means operationally, agent states, forecast vintages, quality-instrument versions — then a single measurement view built on them	The framework comes before the platform. Demand-side intent taxonomy and the data-definitions program are one program, not two
6	Interfaces — named owners and cadences	Finance (the budget–forecast–actuals loop); Commercial (what an offer may promise about placement); Technology (the migration plan); suppliers (governance and the commitment interface); HR and talent acquisition (the proficiency pipeline)	One named owner and one cadence per interface. A platform default is a decision someone must own; which stages of work a commercial offer may bind is decided with the placement function, not after it

The exit criterion

The stage ends when one planning process has passed all five tests of the agentic handover gate and is running agentically under an overseer. Not when the definitions are agreed; not when a platform goes live. The reason is sequencing discipline. Making the first handover the exit criterion forces the documentation standard, the objective instruments, the measurement view and the overseer role to exist for at least one process before any of them is declared standard. It also converts the most common open question in consolidation programs — can one workflow be named that ships in six weeks? — from an open question into a milestone.

A stage that ends with a platform going live has a different failure mode: the platform goes live on the definitions it shipped with, and the standardization is discovered afterwards to have been the platform's, not the organization's.

The forcing function

Standardization programs without a clock tend to run on hygiene and stall. The clock in most consolidations is a platform migration: accounts and teams must land somewhere, and they land in the new ecosystem or the old one. A design rule resolves the matrix while the migration runs: planning follows the account, so an account's outlook moves to the receiving planner on the day it is reassigned; support follows the platform, so the estate team keeps running it on the legacy systems until the migration's own schedule moves it. The rule makes the migration the schedule for the standardization rather than a separate project competing with it, and it is the operating form of the broker design in The Workforce Broker.

Relation to integration theory

The acquisitions literature distinguishes integration modes by the need for strategic interdependence and the need for organizational autonomy, and holds that the mode should be chosen for the acquisition rather than applied by default. The inference drawn here — that the default in workforce-function consolidations is absorption of the smaller heritage into the larger's practices, and that this loses value where the smaller heritage held the better practice — is this page's, not the source's. Standardizing by reconciling definitions first, rather than by adopting one heritage's platform configuration, lets the best practice of each heritage be written into the standard rather than overwritten by the largest. Inherited Sourcing Doctrine in Merged Service Estates describes the same reconciliation for sourcing rules specifically.

The layered form of the L0–L3 standard descends from two traditions: quality-system documentation guidance that layered policy, procedure and work instruction, and structured systems analysis, whose levelled data-flow diagrams decompose a process top-down with each level expanding one process of the level above.

Failure modes

• Platform-led standardisation. The chosen platform's data model becomes the standard by default — the outcome the migration finding describes. Countermeasure: the ontology is written first and the platform is configured to it; the rule in row 1.
• Definitions without a view. Definitions are agreed and never instantiated in a measurement view, so the four heritages continue to report on their own. Countermeasure: the view is the deliverable; the definitions are its specification.
• Standardisation as hygiene. No forcing function, no exit criterion; the programme runs until attention moves. Countermeasure: tie it to the migration clock and end it with the first handover. The exit criterion also guards against the irony that the processes easiest to automate are the ones whose failure the remaining people are least practised at handling; a first handover chosen for a visible, recoverable failure mode is the safest place to learn that.
• Automating the unreconciled. Agents deployed heritage-by-heritage before definitions are shared. Countermeasure: the gate's first test (documented to the shared standard) is the entry condition for any handover.

Maturity Model Position

The stage moves a function from Level 2 — platforms deployed, practices still local — to Level 3, where the function is connected to adjacent data and its rule-based automation runs on shared definitions. Its exit criterion is the first act of Level 4.

See Also

• The Agentic Journey Map — the sequence this stage sits within
• Platform Migration as a Definitional Forcing Function — why the migration is the clock
• Process Decomposition (L0–L3) — the documentation standard
• The Workforce Broker — the operating design the standardized function runs
• Inherited Sourcing Doctrine in Merged Service Estates — reconciliation of inherited rules
• Instrumenting the Objective Before Building the Model — why the objective register comes before the model
• The Agentic Handover Gate — the exit criterion
• Technology Journey from Level 2 to Level 5 — the platform path the standardization stage runs on