Six months after a new system goes live, someone in a leadership meeting asks the fair question: did it work? And the room goes quiet. Not because the project failed, but because nobody wrote down what things looked like beforehand. The team has opinions — it feels faster, the complaints stopped — but opinions don't survive a budget review, and they certainly don't survive a change in leadership.
This is the quietest failure mode in digital transformation. The system works. The value is real. The proof doesn't exist.
Why post-hoc ROI never convinces anyone
When you try to reconstruct the before state after the fact, you get two kinds of numbers: ones pulled from the old system that nobody trusts anymore, and ones people remember, which are always shaped by how they feel about the project. Skeptics discount both. Champions oversell both. The conversation becomes a debate about the measurement instead of a decision about what to do next.
The cost isn't just an awkward meeting. It's the next project. Without evidence, every subsequent investment starts from zero credibility, and the organization defaults to the cheapest option rather than the right one.
Pick three numbers, not thirty
A baseline isn't a data warehouse. It's a small set of measurements tied directly to the problem you claim to be solving. Three is usually enough, and they generally fall into these buckets:
- Cycle time — how long something takes end to end. Quote to cash. Order to ship. Month-end close. Requisition to purchase order. Pick the one the project is supposed to shorten.
- Touch count — how many people and how many systems a single transaction passes through. This is the number integration work moves, and it's the easiest to measure honestly because you can count it by walking the process.
- Rework rate — how often something has to be corrected, re-entered, or chased. Credit memos issued. Orders with a post-submission change. Invoices disputed. Payroll corrections.
If your project is about adoption or capacity rather than throughput, add a fourth: time to competence. How long before a new hire can run the process without supervision? That number tells you whether you've built a system or a specialty.
Capture them in a week, not a quarter
The reason baselines get skipped is that measuring properly sounds like its own project. It doesn't have to be.
Sample instead of surveying everything. Pull the last twenty-five orders, twenty-five invoices, or twenty-five service tickets and trace each one by hand. Note the timestamps you can find, and where timestamps don't exist, note that too — an absent timestamp is itself a finding about your data foundation.
Use a stopwatch for the manual steps. Sit with the person who does the work and time them doing it three times. You'll learn more in ninety minutes than in a month of surveys, and you'll surface the workarounds that never appear in any process document.
Ask the people doing the work to estimate, then write the estimate down as an estimate. A labeled guess is far more useful than an unlabeled one, and it's honest. When the after-measurement comes in, you compare like with like.
Finally, screenshot the reports. Whatever dashboards, aging reports, or close checklists exist today — save copies with dates. They cost nothing to keep and they're the only unbiased record you'll have.
Write down the claim before you start
The baseline is only half of it. The other half is a short, specific statement of what you expect to change and by roughly when. Not "improve efficiency." Something closer to: we expect order entry to drop from three touches to one, and we expect to see it within sixty days of go-live.
Committing to that in writing does two things. It forces the project scope to stay tied to a business outcome instead of drifting toward feature completeness. And it makes the post-go-live review a factual exercise rather than a political one.
Expect the dip, and name it in advance
Almost every meaningful system change gets worse before it gets better. Cycle times stretch while people learn. Error rates rise while new validations catch things the old system silently allowed. If you haven't warned leadership that this is normal and bounded, the first bad month becomes evidence that the project failed.
Name the dip up front. Say how long you expect it to last and what you'll watch to confirm recovery is underway. A transformation program that predicts its own rough patch earns trust when the rough patch arrives on schedule.
Assign an owner to the number
A baseline with no owner decays immediately. Someone — ideally the operational leader who benefits, not the project manager who leaves — should own re-measuring on a set cadence: thirty days, ninety days, then quarterly. Same method, same sample size, same definitions. That consistency is what turns a one-time measurement into a management instrument.
The companies that get the most out of ERP, integration, and automation work aren't the ones with the best software. They're the ones that can tell you, precisely, what changed. That discipline compounds — every project that proves its value makes the next one easier to fund.
If you're scoping a system project and aren't sure which numbers will matter six months from now, that's exactly the conversation worth having before the build starts. We'd be glad to help you frame it.