Standardizing operations across acquired locations

Standardisation across sites buys four specific things and nothing else: comparability, transferable staff, a consistent customer experience, and a lower cost of adding the next location. Every candidate for standardisation should be tested against those four. A practice that improves none of them is a preference being imposed, and imposing preferences across an acquired site is the fastest way to lose the manager who was running it well.

The vocabulary matters here because these three artifacts do different jobs. A standard operating procedure describes how a recurring process is performed, with its trigger, steps, decision points and owner. A checklist is a memory aid for a procedure someone already knows. A policy states what is and is not permitted and usually exists for legal or safety reasons. Confusing them produces procedures nobody reads because they are written as policy, and policies nobody follows because they read as suggestions.

Two integration cases sit underneath and they are not the same problem. Adding a location to an operating system you already run means absorbing it into an existing cadence and an existing account structure — the standard exists, the work is porting it. Standing up a multi-site operation from two formerly independent businesses means building both for the first time, with two incumbents who each believe their way is the standard. The second is substantially harder and is routinely under-planned because the corporate integration literature assumes an acquirer with a documented operating model to absorb into.

That literature transfers only in part. Day-one, day-hundred and year-one gating transfers, and so does tracking whether the benefits you underwrote are actually appearing. An integration management office at forty headcount does not. Corporate merger-integration material is the most seductive wrong-seat reading in this whole subject, because it is abundant, well written and calibrated for a company two orders of magnitude larger.

The highest-return standardisation is also the least disruptive: make every site measure the same things the same way. Two locations reporting different numbers for what they both call the same metric is the normal starting condition, and it makes every comparison you attempt useless without anybody realising it. A shared definition dictionary — one written definition per number, with its source system named — costs a week and pays for itself the first time you try to work out which site is actually more profitable.

Three same-word traps recur across sites specifically. Utilisation means billable hours over available hours in one tradition and a dollars-based ratio in another. Overhead rate is a multiple of direct labour in some professional-services benchmarking and a percentage of revenue in the trades. And a fifty per cent markup is a thirty-three per cent margin, which is where two sites quoting 'the same margin' turn out to be quoting materially different prices. Each of these has a real chance of being live between two businesses that were run by different people.

A single chart of accounts across sites is the structural version of the same fix. Until each location's revenue and cost map to the same account structure, site-level margin comparison is arithmetic performed on incompatible categories. This is the work that has to precede any consolidated reporting, and it is worth doing before the second location's numbers get folded in rather than after.

Cascading a scorecard to site level is then straightforward and worth doing: the same handful of rows, per site, with one named owner each. That is the point at which comparability becomes management rather than reporting — you can see which site is moving and ask its manager how, which is a far better mechanism for spreading practice than a directive from the centre.

Write the procedure where the work is already done well rather than at head office. Every multi-site operator has a site that handles a given process better than the others, and documenting that site's actual practice produces a procedure that is known to work, has a credible author, and can be defended to the other sites by someone who is not you. Go and watch the work being done before writing anything — the gemba discipline from lean practice is exactly the right instrument here, and its whole point is that the procedure describes what happens rather than what is supposed to happen.

Sequence by risk and frequency. High-frequency, high-variance processes first — quoting, scheduling, the handoff between sales and delivery, month-end close — because those are where inconsistency costs money weekly. Rare, low-consequence processes can stay local indefinitely, and pretending otherwise generates a documentation programme that exhausts everyone before it reaches anything that matters.

The standard-work idea from lean practice sharpens what a good procedure looks like: the current best-known method, written by the people who do the work, and expected to be replaced when someone finds a better one. That framing matters across sites, because a procedure imposed from the centre and never revised becomes something the sites route around, while a procedure a site improved and had adopted everywhere becomes a source of standing.

Give the whole programme an owner. In a multi-site business of this size that is usually an operations manager rather than the owner, and it is a real part of a job rather than a project someone does alongside everything else. Watch for the title collision that plagues multi-site trades businesses in particular — operations manager, service manager and dispatcher describe overlapping work in different companies, and porting a procedure between two sites that use the same title for different jobs is how a standardisation programme quietly fails.

Writing a procedure is the easy half. Getting a site that has done it another way for eleven years to follow it is the hard half, and it is the half nobody publishes, because framework stewards sell the artifact rather than the adoption. The mechanism that works is the same one that makes a scorecard survive: the procedure is referenced in a recurring meeting the owner attends, compliance is visible rather than assumed, and deviation has a stated consequence — in that order. A daily huddle at each site does more for adoption than any document management system.

Procedures decay. Review them on a fixed cycle — attaching the review to the quarterly meeting works because it already exists — and treat a procedure that no longer matches practice as worse than none at all, because it teaches everyone that the documented way and the real way are different. When a site changes something and it works, the change should flow back into the standard rather than existing as a local exception nobody wrote down.

Systems standardisation follows a different rule from process standardisation, and inverting it is the classic multi-site mistake. Migrate what breaks the close; freeze what breaks operations. The accounting system migrates because a split ledger breaks consolidated reporting. Dispatch, inventory and customer systems freeze until the operation is stable, because migrating them breaks the ability to do the work. And three constraints eliminate most candidate dates: nothing migrates mid-month, mid-payroll-period, or in peak season.

One financing fact shapes how the next site gets added, and it is buried in a document most operators never open. Where an existing business acquires another in the same six-digit industry classification, with identical ownership, in the same geographic area, as co-borrowers, the standard operating procedure treats it as an expansion with no minimum equity injection — as against the ten per cent of total project cost required otherwise. For an operator adding comparable sites that is the single most consequential rule in the programme, and it is worth understanding before the third location rather than after.