Operations Modernization

Consolidate onto one system of record. Then optimize on top of it. In that order.

Most distribution and manufacturing operations carrying two systems of record know they should consolidate. What they usually miss is that the consolidation and the optimization are the same project, and doing them in the wrong order wastes both.

The sequencing principle. Do not optimize what is being retired, and do not strand the data the optimization depends on. Those two sentences determine whether this work compounds or gets rebuilt.

Why Order Matters More Than Effort

While a business runs on two systems, every network-level answer is assembled across two sources of truth by hand. Those answers are not merely imprecise — they are wrong in ways that are difficult to detect, because nothing about a reconciled spreadsheet announces which side of it was stale.

So the analysis that would justify the investment cannot be trusted until the consolidation is done. And the consolidation, done without regard for the analysis, throws away exactly the history the analysis needs.

DependencyConsequence if ignored
Optimization models are built against the destination system, onceLogic built against the system being retired is discarded at cutover, then built again.
Operational history is migration scope, not an archive afterthoughtPick, lot and bin history is the input to the velocity model. Left in a decommissioned database, a migrated site restarts its optimization clock at zero.
Network analysis waits for a single system of recordTransfer-versus-buy computed across two systems will be confidently wrong, and the errors will not be obvious.
Destination layout is designed, not copiedMigration is the one moment warehouse layout can be redesigned at near-zero marginal cost. Copying the legacy layout forfeits it, and changing it later means physically moving inventory you just put away.

That last one is the one people miss. If sites migrate before the slotting model exists, they get loaded into a bin structure mirroring whatever they had. Fixing it afterwards is a physical cost, not a data cost.

The Three Tracks

Track 1

Consolidate

Migrate the remaining business onto one system of record, with operational history brought forward rather than stranded.

Seven workstreams get planned and scoped from day one: master data, inventory, open transactions, financial, history, customizations and integrations, and reporting. The first four are what everyone plans for. The last three are what run migrations late, because they are typically discovered in month three rather than scoped in month one.

Guiding principles we hold to:

  • One system of record, with a hard date. Indefinite parallel operation is the most expensive available outcome and the most common one.
  • Migrate the business, not the database. Where the destination does something differently and adequately, adopt it. Recreating legacy behaviour requires justification, not default acceptance.
  • Balance before beauty. Inventory quantity and value, receivables, payables and open backlog reconcile exactly before anything else is judged.
  • Every extract is repeatable. Scripted, versioned, re-runnable. No hand-edited spreadsheets in the load path — these get run many times before the run that counts.
  • Retain the cross-reference permanently. The old-key-to-new-key map is the only way to answer questions about pre-migration history for years afterwards.

History strategy is a business decision, not a technical one, and it is the single largest lever on cost and timeline. We generally recommend migrating open items plus item-level usage and sales summary — preserving what the analytical work needs at a fraction of full-detail cost — while treating pick, lot and bin history as in-scope regardless, because that is the input to Track 2.

Electronic trading partner integration is almost always the critical path. Map rebuilds and partner-side test cycles are measured in weeks and cannot be compressed by adding staff. We enumerate partners in week one and open those conversations during build, not after it.

Track 2

Optimize

Once the data is in one place, the same analytical capacity that accelerated the migration turns to the operational questions.

Slotting. Assign every item to a bin whose travel cost matches its pick frequency, subject to cube, weight, zone and handling constraints. Re-evaluated on a cadence rather than set once a decade.

Conventional ABC classification ranks by dollar volume, which is the wrong primary axis for slotting — a high-value item picked twice a month should not occupy prime real estate. The model uses three inputs instead: velocity derived from pick-line frequency weighted toward recent periods, handling class from cube, weight and pack configuration, and affinity — items that repeatedly appear on the same order, slotted near each other regardless of individual velocity. That third one is where pattern detection genuinely beats judgement, because nobody holds pairwise co-occurrence across tens of thousands of items in their head.

Multi-order consolidation. Three orders shipping today each containing the same item from the same lot means someone travels to that pallet three times and breaks it down three times. The pull should happen once, split downstream. We measure the duplicate-touch baseline first — that number is the size of the prize, and most operations do not know it — then build wave grouping that maximises shared touches while respecting ship date, carrier cutoff and staging capacity.

Slotting and consolidation compound: consolidation reduces the number of trips, slotting reduces the cost of each trip. Done in isolation, either is diluted by the other.

Purchasing. Where analytical capacity converts to cash fastest, because the levers are inventory dollars, freight dollars and unit price — all recorded in detail and rarely analysed in aggregate. In recommended sequence: lead-time reality check against promised dates with variance rather than averages; order point tuning where policy and actual usage have drifted apart; purchase order consolidation across sites to reach price breaks and freight thresholds; container fill analysis; forecast variance by programme; a forward expedite-risk list; and a vendor scorecard that is a standing report rather than an argument.

Network replenishment. Most multi-site operations maintain sourcing item by item and never analyse it as a network. Items that should be centrally stocked and transferred are almost certainly being bought at several sites, and items needing local stock are almost certainly being transferred at a cost nobody has priced. Neither condition announces itself. This one waits for Track 1 to complete, for the reason in the table above.

Track 3

Enable

The failure mode of analytical work is that it lives in one analyst's spreadsheet and leaves when they do.

The model gets built once and parameterised per site. Each location has its own velocity profile, zone topology and constraint set, so recommendations differ — but the logic, the queries and the review workflow are shared. That is the difference between seven separate projects and one project run seven times.

Alongside it: documented playbooks held somewhere the whole company can reach, and site leads brought into the analysis months before their site is affected. People who have followed the work adopt the result faster than people handed a finished workbook on go-live day.

How the Engagement Runs

Prove, package, propagate. Run the full analysis at one proving-ground site. Convert what worked into a documented playbook. Apply it at the next site with that site's data. Each subsequent site should take materially less effort than the one before — and if it does not, that is the signal the playbook is not yet real.

Baselines before changes. Travel proxy per pick ticket, share of picks from prime locations, forward-bin replenishment frequency, and how much prime space slow movers currently occupy. Without these, any claimed improvement is an opinion. Capturing them is the first two weeks.

The access model

Nothing here is a black box making operational decisions. Access escalates in three stages, and each one has to earn the next:

StageWhat it means
Read-onlyAnalysis against a snapshot. Nothing is written anywhere.
Human-executed recommendationsOutput arrives as a reviewable workbook — current state, proposed state, expected effect, and the sequence required to get there without deadlocking. A supervisor approves or rejects.
Staged writesApproved changes staged as instructions, still executed through the host system's own transaction path, still with a human approving the batch.

What You Actually Receive

Who This Is For

Operations running more than one system of record, or one system nobody has analysed in aggregate. Multi-site distribution where transfers happen but nobody has priced them. Warehouses where slotting was set once and has not been revisited. Purchasing where order points are maintained by hand and lead times are assumptions rather than measurements.

This is a different job from reporting, and the two work best together. A dashboard tells you what happened and where to look — we build those too, and most engagements start there because you cannot change what you cannot yet see. This work is the step after: it changes where things sit, how they are picked, and what gets bought. See it, then change it, then watch the same dashboard confirm the change landed.

Start with the baseline

The first conversation is about what you can measure today, because that determines what any of this can be held to later.

Get in touch · See the integration work · How the analysis actually gets done