How to Implement a Supply Chain System Without Stopping the Warehouse

Nguyen Manh Thang Chief Executive Officer, AgileTech Vietnam

Published: August 17, 2026
Read time: 21 min

In short

Implementation fails on data and process ownership, not on software. Before you shortlist a system, establish one owner per master data domain, count how many of your item, supplier and location records are actually correct, and write down the decision rules your staff currently keep in their heads. Then pilot at one site with both systems running in parallel, and only cut over when the pilot site can produce a correct promise date without anyone checking a spreadsheet.

Most writing about supply chain systems is about choosing one. That is the easy part, and it is the wrong place to spend your attention. The difficult part is that a supply chain system is a mirror: it reflects, precisely and publicly, how well you already understand your own operation. If two departments disagree about which supplier record is authoritative, the new system does not resolve that disagreement. It renders it, on a screen, in front of a customer waiting for a delivery date.

This piece is about the sequence of a rollout rather than the shortlist. It assumes you have decided you need something better than spreadsheets and email, and it deals with the work that decides whether the result is trusted: who owns which data, what you fix before you load anything, how to run a pilot that proves something, and what the operating routine looks like once the launch team has gone. If you are earlier than that and still deciding how to structure the project itself, our guide to the software development process covers the delivery side of the same question.

Two side topics appear in almost every search on this subject, blockchain and connected sensors, and both get a straight answer here rather than a paragraph of enthusiasm. Each solves a real and narrow problem. Neither solves the problem that actually delays implementations.

Key takeaways

The software is rarely the constraint. Unclear master data ownership and undocumented decision rules are what turn a six month rollout into an eighteen month one.
Parallel running at one site is expensive and worth it, because it is the only test that produces evidence rather than confidence.
A promise date is the sharpest single test of whether the implementation worked, because it depends on stock, lead time and capacity being right at the same moment.
Blockchain answers exactly one question, whether independent parties can trust a shared record without trusting each other. If all the parties are you, it is expensive overhead.
Sensor data is only useful once somebody owns the exception it produces. An unowned alert becomes noise within a month, then gets muted.
Go live is the middle of the project, not the end. The steady-state operating routine is what determines whether the system is still trusted a year later.

Implementations fail on data and ownership, not on software

When an implementation slips, the post mortem usually blames the system or the integrator. That is almost never where the time went. The time went into discovering, one record at a time, that the organization did not have a single agreed answer to questions it had never needed to answer explicitly. Which of these three item codes is the real one. Whose number is right when purchasing and the warehouse disagree about on-hand stock. Who is allowed to approve a substitution when the requested item is short.

None of those are software questions. They are ownership questions, and a system cannot invent an owner. What it can do is force the question into the open, which is genuinely valuable and also why the first three months of an implementation feel like an argument rather than a project. Teams that expect that argument schedule it. Teams that do not, hit it during data migration, at the point in the plan with the least slack.

The second failure mode is subtler. Every operation runs on rules that live in people rather than documents. The dispatcher who knows that one particular customer will accept a partial delivery but that another will reject the whole load. The buyer who orders early in a specific month because a supplier always slips then. Those rules are real, they are load bearing, and if nobody writes them down before configuration then the new system will contradict them. Staff then do what staff always do: they keep the real rules in a spreadsheet alongside the system, and the system becomes a data entry chore that lags reality.

So the honest first question is not which system. It is whether you can name, today, one accountable owner for each of item data, supplier data, location data and customer data. If you cannot, that is the first work item, and it does not require a vendor.

The first month, done two ways

Do this

Name one accountable owner per data domainBy person, not by department. Items, suppliers, locations and customers each need a human who answers for them, because a system cannot invent an owner and a department cannot be asked a question.
Count how many records are actually correctPull the sample yourself rather than asking for a report. The percentage you get is the single best predictor of your timeline, and it is available in week one for the cost of an afternoon.
Interview the people who resolve exceptions dailyThey are carrying the real decision rules in their heads. Write those rules down before configuration, because a system configured against rules nobody wrote will contradict the operation and lose.
Agree what a promise date means, in writingBefore anyone configures a system that will calculate one. Stock plus lead time plus capacity is a definition with at least three arguments, and each of them needs an owner.

Not this

Build a several hundred row requirements matrixScored by committee, it measures how many people attended rather than what the operation needs. It also reliably omits the ownership questions, because those have no feature to tick.
Run vendor demos before checking your own numbersA demo runs on clean data by construction. Watching one before you know which of your records are wrong tells you how the software behaves in a situation you are not in.
Assume integration is small because there are APIsThe APIs are the easy part. The work is deciding which system owns each field, and that is a business decision with no technical shortcut.
Plan a single cutover to avoid pilot costParallel running at one site looks like duplicated effort on a plan. It is the only step that produces evidence, and removing it does not save the money, it defers the discovery to a worse moment.

Everything in the left column can start on Monday without a vendor, a budget line or a signature.

Relative weights, illustrative and not a quote. The shape is the point: the two largest bands need no vendor and can start before any software decision is made.

Master data is the project, and it is measurable before you start

Master data is the set of records that everything else references: items, suppliers, customers, locations, and the units and pack sizes that connect them. It is unglamorous, and it is the single strongest predictor of how a rollout goes, because every calculation the new system performs is a function of it. A promise date is stock plus lead time plus capacity. If the pack size is wrong, the stock figure is wrong, so the promise date is wrong, and the first customer who is told a wrong date teaches an entire sales team not to trust the system.

The useful move here is to treat data quality as a measurement rather than an impression. Pull a sample of a few hundred item records yourself, before any vendor is involved, and check each against physical reality or against the source document. You will get a percentage. That percentage, not the vendor timeline, is what tells you whether a credible go-live is three months away or nine.

There is a decision hidden in the result. If accuracy is high, load and go. If it is clearly poor, cleanse before you load, because loading bad data into a new system converts a data problem into a trust problem, and trust is far more expensive to recover. If you genuinely do not know, measure first, because both of the other paths are wrong when chosen blindly. That is a three-way decision and it is worth making explicitly rather than by default.

One warning about cleansing: it is not a project that finishes. Records decay because suppliers change pack sizes and warehouses reorganize. What you are building in this phase is not a clean data set, it is the ownership and the routine that keeps it clean. A one-time cleanse with no owner attached will be stale within two quarters, and you will be back where you started with a more expensive system.

What to measure before you shortlist anything

The records themselves

Item records: Correct unit of measure, pack size and primary supplier, all three at once, on a sample you pull yourself
Supplier records: One authoritative record per legal entity, with an agreed lead time and the person who owns it named
Location records: Every stock-holding place represented, including the ones staff use that nobody ever put in a system
Customer records: One record per billing relationship, with the delivery rules that differ between them written down

The rules and the surface

Decision rules: Written substitution, partial-delivery and expedite rules, sourced from the people who apply them today
Promise date definition: What the date means, which inputs it uses, and who may override it and on what evidence
Integration surface: Every system that will read or write these records, with the direction of truth stated per field
Baseline measures: The handful of operational numbers measured once before anything changes, so improvement is measurable later

None of this requires a vendor, and all of it changes what you should be asking one.

Terms that get used loosely and cause real confusion

Master data: The reference records everything else points at: items, suppliers, customers, locations. Shared, long lived, and the thing an implementation stands on.
Transactional data: The events: orders, receipts, movements, adjustments. High volume, short lived individually, and only meaningful if the master data it references is right.
System of record: The one place a given field is allowed to be authoritative. If two systems both claim a field, you do not have a system of record for it, you have a reconciliation job.
Available to promise: What you can actually commit to a customer, as opposed to what is physically on a shelf. Depends on stock, inbound supply, allocations and capacity simultaneously.
Cycle count: Counting a subset of stock continuously rather than shutting down for a full count. The routine that keeps accuracy from decaying once the system is live.

Three paths, and the middle one is the one teams skip. Loading data you know is wrong converts a data problem into a trust problem, which costs far more to recover.

A sequence that survives contact with an operating business

The rollout shape that works is boring and repeats across industries: assess, design, pilot at one site, roll out, then run. What distinguishes plans that hold from plans that slip is not the phase names, it is that each phase has an exit test somebody outside the project team can apply. Without that, phases end when the calendar says so and the unfinished work moves silently downstream. Whether those phases run as one sequential pass or as iterations inside a frame is the delivery-model choice, and agile versus waterfall compared covers which one this kind of program actually needs.

Assess ends when you can state your data accuracy as a number and name your data owners as people. Design ends when the decision rules are written and a person from operations has read them and agreed they match what actually happens. The pilot ends when one site can produce a correct promise date without anyone consulting a spreadsheet, which is a far harder test than the system being installed and users being trained.

Notice who has to be present. This is not an IT project with operational input; it is an operations project with heavy IT content, and the swimlane below is deliberately arranged so that operations carries work in every phase. If your plan has operations appearing only at training and go-live, the plan has already located the failure.

The finance lane matters more than it looks. Finance is where a wrong number becomes visible and permanent, and finance is also the function most likely to keep a parallel spreadsheet indefinitely if the system does not reconcile. Bringing them in at design rather than at month end is what prevents a shadow set of books from becoming the real one.

Five phases, each with an exit test somebody else can apply

AssessStarts before any vendor

Measure data accuracy, name the owners, and document the rules people are carrying in their heads

Done when the accuracy number exists as a number, and every data domain has a named individual rather than a department
DesignLonger than quoted

Configure to the documented rules, decide the direction of truth per field, and agree what a promise date means

Done when somebody from operations has read the written rules and confirmed they match what actually happens today
Pilot one siteDeliberately expensive

Run the new system and the old process together at a single site, and log every disagreement between them

Done when the site can produce a correct promise date, resolve a shortage and close a week without external help
Roll outSite by site, never all at once

Extend one site at a time, carrying the pilot lessons forward rather than restarting the argument

Done when each new site reaches the pilot standard before the next site is started
Steady stateContinuous, and planned before go-live

Cycle counting, named exception ownership, and a monthly review of the numbers the system produces

Done when the shadow spreadsheets are gone, and they are still gone three months later

The exit tests matter more than the phase names. A phase without one ends when the calendar says so, and the unfinished work moves silently downstream.

Signs the pilot is not actually finished

Somebody checks a spreadsheet before quoting a dateThe system is not trusted for the one calculation that matters most. Find out which input they doubt, because they are usually right about which one is wrong.
Stock adjustments are posted in weekly batchesAdjustments posted late mean the record was wrong all week and nobody could act on it. Real-time posting is what makes the stock figure usable rather than historical.
Exceptions are resolved in a chat threadA thread has no owner, no aging and no record. The exception gets solved and the reason it happened is lost, so it happens again next month.
The team can say what the system says, not whyA calculated date nobody can explain will be overridden the first time a customer pushes back. Understanding the inputs is part of the cutover, not a nice extra.
Finance still reconciles to their own parallel recordThe most durable shadow system of all, and the one most likely to become the real books. If finance does not trust the system at month end, the pilot has not passed.

Any one of these means the site is running the old process with extra typing. None of them appear in a project status report.

Operations appears in all five phases deliberately. A plan where operations shows up only at training and go-live has already located its own failure.

Parallel running is the expense that buys you evidence

Running the old process alongside the new system at one site, for a real period, is the most commonly cut item in an implementation plan and the one most worth defending. It is genuinely expensive: staff do the work twice, and for several weeks productivity at that site falls. What you get for the money is the only thing in the entire project that constitutes evidence rather than confidence, namely a set of cases where the two approaches disagreed and you found out which was right while the stakes were still small.

The disagreements are the point. A parallel run with no discrepancies means either you were unusually well prepared or, far more likely, nobody is really using the new system. Expect discrepancies, log every one, and classify each as a data fault, a configuration fault or a process fault. The mix tells you what to fix and it also tells you whether you are ready: when new discrepancies stop being data faults, your master data work has landed.

Choose the pilot site for informativeness rather than for ease. The simplest, best-run site will pass smoothly and teach you very little, then the second site will surface every problem you deferred. A site with real complexity but a cooperative team is the useful choice. You are buying information, and easy sites are cheap information.

Set the exit test before you start, in writing, and make it operational rather than technical. Not "the system is live and users are trained", which is a statement about the project. Instead: this site can produce a correct promise date, resolve a shortage, and close a week without external help. That is a statement about the business, and it is the only kind worth cutting over on.

What a discrepancy log tells you, by fault type

Fault type	What it looks like	What it means for the plan
Data	The system and the shelf disagree on quantity, pack size or supplier	Master data work is not finished. Do not cut over; the same fault will appear at every site.
Configuration	The system applies a rule correctly but the rule is not your rule	Design phase missed a documented decision. Cheap to fix now, expensive after rollout.
Process	The system is right, the data is right, and staff worked around it anyway	The new way is harder than the old way somewhere. Find where, or the workaround becomes permanent.
Timing	Both are right but at different moments	A synchronization or posting-frequency question, usually the least urgent and the most often misdiagnosed as a data fault.

Classify every disagreement into one of these four. The mix, not the count, is what tells you whether you are ready to cut over.

A parallel run that produces no disagreements has not tested anything. It has confirmed that people are still doing the work the old way and typing it into the new system afterward.

The pattern behind smooth pilots and difficult rolloutsWhy an absence of findings is a finding

Six operational questions, answered before and after. Each row is a question a customer or a controller can ask on any given day.

Blockchain and connected sensors, answered plainly

These two arrive in almost every conversation about supply chain systems, and they deserve a direct answer rather than enthusiasm, because both are genuinely useful for narrow problems and neither addresses the thing that delays implementations.

Take the distributed ledger question first. It answers exactly one question well: can several independent parties, who have commercial reasons not to fully trust each other, share one record whose history none of them can quietly rewrite. If that is your situation, for instance a provenance claim that a buyer will audit and that passes through processors you do not own, then the property is real and hard to get another way. The test is simple and it is about your counterparties, not about the technology: are the parties independent, do they have a reason to dispute the record, and would a shared database owned by one of them be unacceptable to the others. If all three are yes, look at it seriously. If the parties are all subsidiaries of you, then you have a database question and a governance question, and a ledger adds cost and operational complexity while solving neither.

Sensors and connected devices are the opposite shape: the technology is straightforward and the discipline is not. A temperature probe in a trailer or a reader at a dock door produces a stream of readings, and the readings are worthless until somebody owns the exception they generate. The failure pattern is completely predictable. Alerts are configured generously at launch, they fire more often than anyone can act on, staff learn to dismiss them, and within a month the alert channel is muted and the sensor investment is decorative. The fix is not better hardware. It is deciding, before installation, which exceptions have a named owner and a required response, and configuring only those.

There is a useful sequencing rule for both. Neither belongs in phase one. Both depend on the master data and exception ownership you build in the earlier phases, so attempting them first means building an audit trail or an alert stream on top of records nobody trusts. A traceability claim resting on item data that is wrong is worse than no claim, because it is a confident wrong answer with a cryptographic signature on it.

Is a shared ledger the right tool for your situation?

Who are the parties, and do any of them have a reason to dispute the record?

Several independent companies share one record and could dispute it

Worth serious evaluation

This is the problem the technology is genuinely for: a history that no single participant can quietly rewrite, without appointing one of them as the owner of the database.
A buyer or regulator will audit a provenance claim across parties you do not own

Worth evaluation, scoped narrowly

Scope it to the specific claim being audited rather than the whole chain. The narrow version is achievable and the broad version is a multi-year program with every supplier as a dependency.
All the parties involved are entities you control

No, and the honest answer is a database

You have a system of record question and a governance question. A ledger answers neither, and it adds operational complexity and cost to a problem that a table with one owner solves.
The goal is visibility into your own inventory across your own sites

No, this is the master data project

Calling it a ledger project delays the work that actually produces the visibility, which is agreeing which system owns each field and fixing the records underneath.
Nobody can name who would audit the record, or why

No, and the question itself is the finding

A requirement with no named auditor almost always arrived from a conference rather than from the operation. Ask who would read it, and if there is no answer the requirement is not real yet.

Every branch turns on the counterparties rather than on the technology, which is the correct way round for this question.

Integration is a question about which system owns each field

Integration is usually scoped as a list of systems to connect, which is why it is usually underestimated. The systems are the easy inventory. The work is deciding, field by field, which system is allowed to be authoritative, because every field where two systems both believe they own the truth becomes a permanent reconciliation task and eventually a source of visible errors.

Do this as a table rather than a diagram. For each field that crosses a boundary, write the owning system, the direction of flow, and what happens on conflict. That last column is the one teams skip and the one that matters, because conflicts are not exceptional. A supplier lead time updated in the buying system and separately in the planning system will diverge, and the plan needs to say which wins before it happens rather than during a shortage.

The count matters too. Point to point connections grow with the square of the systems involved, which is why the fourth integration always feels disproportionately harder than the third. That arithmetic is worth doing on your own numbers before committing to an approach, and it is the honest argument for routing through one hub rather than a preference for architecture diagrams. If you are evaluating who should build this, our guide to evaluating a software partner covers the questions that actually predict delivery.

One practical caution about the direction of truth: it is a business decision, not a technical one, and it should be made by the person who owns the data domain rather than by whoever is writing the interface. Interfaces built on a developer guess about ownership work correctly and produce the wrong answer, which is the most expensive category of correct.

How to scope integration so it does not expand later

List the crossing fields, not the systemsHalf a day, and it changes the estimate

Every field that moves between systems, named individually. The list is always longer than the system count suggests, and that gap is the useful surprise rather than an estimating error.
Assign exactly one owning system per fieldA business decision, not a technical one

Where two systems both claim a field, escalate to the data domain owner instead of splitting the difference in code. A field with two owners is a permanent reconciliation task wearing the costume of an integration.
Write the conflict rule for each fieldThe column teams skip

What happens when both sides changed since the last sync. Last write wins is a legitimate decision and a terrible default, and the difference is whether somebody chose it knowing what it does to a lead time.
Decide the frequency per flow, separatelyPer flow, never per project

Real time is a cost rather than a virtue. Stock levels and promise dates usually justify it. Supplier postal addresses do not, and treating every flow as urgent is how an integration budget doubles.
Name the behavior when a flow is downIf unknown, not yet scoped

What the business does when this connection fails for an hour. If nobody can answer, the integration is not scoped yet, because the answer determines whether you need a queue, a cache or simply a phone call.

Done in this order, the scope stops growing. Done as a list of systems, it grows every time somebody remembers another field.

Direction of truth, decided once and written down

	Owning system	On conflict
On-hand quantityread by everything	Warehouse system	Warehouse wins, because it is closest to physical reality
Supplier lead timedrives every promise	Buying system	Buying wins; planning consumes it and must not edit it
Customer credit statusblocks orders	Finance system	Finance wins, and order entry must read it live rather than cache it
Item pack sizesilently breaks quantities	Master data owner	Neither operational system may change it; changes go through the owner
Promise datethe customer-facing output	The new system	Calculated, never typed, and never overridden without a logged reason

Five fields, as an example of the shape. The real table has a row for every field that crosses a system boundary, which is why it is built from the field list rather than the system list.

Point to point connections grow with the square of the systems involved. The arithmetic multiplies out in this caption: four systems fully connected need six links, six systems need fifteen, eight need twenty eight. Hub routing grows in a straight line.

What to measure afterward, and the one number that tells the truth

Most post-implementation reporting measures the project rather than the operation: modules deployed, users trained, tickets closed. Those are activity measures and they can all look excellent while the business is quietly running on spreadsheets alongside the system. The measures worth watching are the ones that only improve if the system is genuinely being used and genuinely correct.

The sharpest single one is promise date accuracy: of the delivery dates you committed to customers, what proportion did you meet, and how has that changed. It is unforgiving in a useful way, because it depends on stock accuracy, lead time accuracy and capacity all being right simultaneously. A system can be fully deployed and produce no improvement in this number, and when that happens it is telling you the master data work is unfinished rather than that the system is bad.

Watch two second-order signals as well. Stock adjustment volume should fall and then stabilize, because adjustments are the operation correcting the record, and a persistently high rate means the record is still not trusted. And exception aging, meaning how long an exception sits before someone resolves it, tells you whether ownership actually landed or whether the queue is a place things go to be forgotten.

Set the baseline before go-live. This sounds obvious and is very often missed, and without it every improvement claim afterward is an argument rather than a measurement. Measure the same handful of numbers for a month before anything changes, using whatever imperfect method you have, because a consistent imperfect baseline is far more useful than a perfect measurement with nothing to compare it to.

The four numbers worth reporting monthly

Promise date accuracy Committed dates actually met The sharpest single test, because it depends on stock, lead time and capacity being right at once

Stock adjustment volume How often the record is corrected Should fall then stabilize. Persistently high means the record is still not trusted

Exception aging How long before someone resolves it Tells you whether ownership landed or whether the queue is where things go to be forgotten

Shadow spreadsheets Parallel records still maintained The honest adoption measure. Any number above zero is an unfinished conversation

Chosen because each one only improves if the system is genuinely used and genuinely correct. None of them can be improved by deploying another module.

Illustrative values, not measured results, and the point is the gap rather than the numbers. A system can be fully deployed while promise date accuracy has not moved, and when that happens the master data work is what is unfinished.

If you are starting this in the next quarter

The order below is deliberately front loaded with work that requires no vendor and no budget approval, because that work both shortens everything after it and tells you whether you are ready to spend. If the first three items are difficult, that difficulty is the finding, and discovering it in a week costs far less than discovering it during data migration.

On team shape: this needs one person from operations with real authority, one who understands the data, and one who can make process decisions stick. It does not need a large committee, and a large committee is a reliable predictor of a long project, because every additional approver adds a round trip to decisions that need to be made in hours.

On sequencing the technology conversation: hold the shortlist until after the assess phase. Vendors are good at responding to requirements and cannot fix your ownership questions, so bringing them in before you have answers means paying for consulting on a problem you had to solve yourself anyway. If you want to see how the delivery side of a project like this is structured, our software development cost guide sets out what drives the numbers.

Finally, plan the steady state explicitly, in the plan, before go-live. Cycle counting cadence, who owns each exception queue, and a standing monthly review of the four numbers above. Implementations that are still trusted a year later almost always have this written down. The ones that quietly reverted to spreadsheets almost never did, and the reversion was gradual enough that nobody noticed the point at which it happened.

The first two weeks, in order

Name one owner per master data domainBy person. Items, suppliers, locations, customers. If two of the four land on the same name, that is worth knowing now rather than in month four.
Sample a few hundred item records yourselfCheck each against physical reality or the source document, and write down the percentage. This single number tells you which timeline you are on.
Interview the three daily exception resolversWrite down the rules they are actually applying. These are the rules the system has to agree with, and none of them are currently documented.
Agree what a promise date means, in writingWhich inputs it uses, who may override it, and on what evidence. Do this before anyone configures a system that will calculate one.
List the fields that cross system boundariesThen mark the ones where two systems both believe they own the truth. Those marks are your real integration scope.
Measure the four monthly numbers onceImperfectly is fine, and consistently imperfect is what matters. Without a baseline, every improvement claim afterward is an argument rather than a measurement.

None of this needs a vendor, a budget approval or a signature, and all of it changes what you should be buying.

Frequently asked questions

How long does it take to implement a supply chain system?

The honest answer is that the software timeline is not the constraint. What determines the duration is how accurate your master data is and how quickly your organization can settle ownership questions it has never had to answer explicitly. Two operations buying the identical system can be six months apart purely on data quality. That is why the first recommendation here is to measure your data accuracy in week one: it is the number that tells you which timeline you are actually on, and it is available before you talk to any vendor.

Should we implement everything at once or site by site?

Site by site, with a genuine parallel run at the first site. A single simultaneous cutover looks cheaper on the plan because it appears to avoid duplicated effort, and it removes the only opportunity you get to discover problems while they are still small. The pilot site should be chosen for how much it will teach you rather than for how easily it will pass, because an easy site produces a smooth pilot followed by a rollout that surfaces everything you deferred.

Do we need blockchain in our supply chain?

Almost certainly not, and the test is about your counterparties rather than the technology. A shared ledger earns its cost when several independent parties who have commercial reasons not to trust each other must share a record none of them can quietly rewrite, for example a provenance claim a buyer will audit across processors you do not own. If all the parties involved are entities you control, you have a system of record question and a governance question, and a database answers both more cheaply and with far less operational complexity.

What does IoT actually add to logistics operations?

Connected sensors are genuinely useful for conditions you cannot otherwise observe, such as temperature in a trailer or dwell time at a dock. The technology is straightforward and the discipline is not. Every alert needs a named owner and a required action decided before installation, because alerts configured generously at launch fire more often than anyone can act on, staff learn to dismiss them, and within a month the channel is muted. The constraint is exception ownership, not hardware.

What is the single best measure of whether the implementation worked?

Promise date accuracy, meaning the proportion of delivery dates you committed to customers that you actually met. It is the sharpest test because it can only improve if stock accuracy, lead time accuracy and capacity are all right at the same moment, so it cannot be satisfied by deploying another module. Measure it for a month before go-live so a baseline exists, because without one every improvement claim afterward is an argument rather than a measurement.

Why do staff keep using spreadsheets after go-live?

Because the spreadsheet is doing something the system does not, and the useful response is curiosity rather than a policy. Usually one of two things is true: the system contradicts a real decision rule that was never written down during design, or the new way is genuinely harder for a specific task. Both are fixable once found. What does not work is prohibiting the spreadsheet, because that hides the workaround without removing the reason for it, and you lose the signal that told you where the design was wrong.

Who should own the project internally?

Operations, with real authority, supported by someone who understands the data and someone who can make process decisions stick. This is an operations project with heavy IT content rather than an IT project with operational input, and the distinction shows up in whether process decisions can be made in hours or need to travel through a committee. A large steering group is a reliable predictor of a long project, because every additional approver adds a round trip to decisions that need to be quick.

If you want the data assessment run before anyone scopes a system, we are a software development company in Vietnam that will tell you plainly when the answer is to fix ownership first and buy nothing yet.