Building the Business Case for Process Digitalization Without Inventing ROI

The Fragmentation Cost Model

Turn signs of fragmentation into categories of cost that can be observed and tested.

Re-entry cost is repeated typing of the same information. Reconciliation cost is the effort to resolve conflicting records. Coordination cost is the messages, meetings and follow-ups needed to move work. Visibility cost is the delay before management has a usable view. Change cost is the effort of altering a brittle workflow. Scale cost is manual effort that grows with volume.

The earlier fragmentation article helps find disconnected work. This framework asks what that work costs the organization and what a change might require. Record the category, where it occurs, who sees it, an observable measure and a confidence level. A category without an observable measure is a hypothesis, not a claimed return.

The Fragmentation Cost Model helps reveal costs that sit between systems rather than on a software invoice. Re-entry occurs when the same information is typed again. Reconciliation is the work of resolving contradictory records. Coordination is the time spent finding the right person or status. Visibility is the delay between an event and a reliable management view. Change cost is the effort of adapting a brittle workflow; scale cost appears when volume rises but the process cannot absorb it. Use these as categories for discovery, not as automatic monetary claims.

Trace a representative item from initiation to decision. If a request moves from email to spreadsheet to an application and back to a report, note each handoff, owner, elapsed time and source of truth. The most expensive-looking step may not be the right starting point. A modest change that removes a recurring reconciliation loop could matter more than digitizing a form while preserving every downstream manual correction. Link the proposed intervention to the specific handoff it changes.

Capacity released by a process change is not the same as cash saved. A business case should explain whether freed time is redeployed to more work, a service improvement or an avoided future hire. Do not translate every minute into a guaranteed financial return. Similarly, better visibility is valuable when it changes a named decision; a dashboard with no owner or action path is not a benefit merely because it exists.

Make benefits conditional on adoption. A system can create an authoritative status, but if teams continue updating the old spreadsheet, reconciliation may grow rather than shrink. The business case should state who changes behavior, how old routes are retired and what evidence shows the new record is actually used. Treat adoption as work with owners and support, not as an automatic effect of installing software.

Establish a current-state baseline

A credible business case begins with sampled work, not a borrowed benchmark.

Follow a transaction, request or report through its handoffs. Count how often the process occurs over a representative period, how many roles touch it and how much time is spent on repeated entry, checking and chasing. Capture exception frequency and the time needed to resolve it. Distinguish direct expenditure from capacity that might be redeployed, not eliminated.

Mark uncertainty. If the workflow is seasonal or work varies by case, use ranges and explain the sample. Do not multiply a best-case time saving across every employee and call it realized profit. Identify which management decision would change if visibility improved; the value of that decision may be important but hard to quantify honestly.

Observe the work as it occurs. A process map drawn in a meeting often omits exceptions, side spreadsheets and approvals handled through informal messages. Sample a variety of routine and exceptional cases, recording timestamps, corrections and people involved. Note what the current system measures reliably and what must be estimated. A baseline can be small but should be transparent: its period, sample, exclusions and uncertainty are more useful than a precise-looking number borrowed from another company.

Distinguish elapsed time from labor time. A request waiting for approval may take days while requiring little active work; a manual reconciliation may take concentrated staff effort. Record both if the business decision depends on them. Also identify where errors surface: at data entry, during review or only at reporting time. If an intervention moves error detection earlier, show how that will be observed rather than assuming errors disappear.

Do not inflate a case with hypothetical losses. If past incidents exist and the organization can verify their consequences, document them with context and appropriate review. Otherwise describe risk qualitatively and explain what evidence would allow it to be estimated. Finance, operations and technology owners should agree on definitions before results are used for approval.

Show the baseline as a range when the sample is small or work varies widely. If one exceptional request takes far longer than routine requests, present both instead of averaging away the distinction. Explain which step consumes human effort and which step is waiting for a decision. Gather input from people doing the work, not only their managers; they often know which side spreadsheet or informal approval actually makes the process function. Use those findings to refine the proposed scope before estimating benefits.

Compare the full investment, not only the development invoice

A useful case includes one-time and recurring ownership costs.

One-time work may include discovery, integration, data migration, testing, change management and training. Ongoing work includes hosting, support, process ownership, platform subscriptions, security review and future change. Consider alternative paths: improve the existing system, integrate two useful tools, replace a spreadsheet dependency or redesign the process before writing software.

Separate avoided manual effort, service quality, risk reduction and new capability. They should not be combined into one precise ROI figure without reliable evidence and agreed financial assumptions. A CFO may still approve a bounded pilot because it exposes a costly operational risk or resolves a known bottleneck.

Include the full cost of change: discovery, design, integration, data cleanup, training, support, parallel operation and ongoing ownership. A new workflow may briefly demand more effort while people learn it and historical records are migrated. The plan should say who supports users during that transition and when the old route can be retired. A procurement price alone does not show whether the organization can sustain the result.

Integration can dominate the work. A new interface may depend on old identifiers, inconsistent statuses or access controlled by another team. Identify those dependencies before approving a broad rollout and budget a discovery step where uncertainty is high. State what is included, what remains a hypothesis and what would trigger a revised estimate. This makes the business case more credible than hiding unknown work in a single optimistic figure.

Assign a process owner after launch. Someone must approve rule changes, maintain access, review exceptions and evaluate whether the workflow still supports the business. A digitalization investment without an operational owner can recreate the original fragmentation in a new tool.

Compare a minimum useful change with a broader platform plan. A narrow integration may solve the immediate handoff, while a larger rebuild may address several related processes but require more adoption work. Document what each option leaves unresolved, the dependencies it creates and how it will be operated. A 'do nothing yet' option can also be reasonable if the baseline shows little consequence or the process is about to change for other reasons. Decision quality improves when the alternatives are explicit.

Design a pilot that can change the decision

A narrow test should confirm both the process hypothesis and the cost of operating the solution.

Choose one workflow with a named owner and a clear beginning and end. Record baseline handling time, exception types, completion time and reporting effort. Then define adoption, quality and continuity measures before changing the process. Include manual fallback and how historical information moves.

The spreadsheet-based project tracking case study documents a digitalization context; it does not publish quantified savings. Refer to a case study for the type of intervention, not a projected result. When the pilot ends, compare observed measures, adoption and actual operating cost to the initial assumptions and decide whether to expand, revise or stop.

A pilot should test one important handoff from start to finish with the people who use it. Decide in advance what evidence supports expansion: fewer duplicate entries, a shorter wait for a specific approval, a clearer exception queue or a more reliable management status. Compare with the baseline using the same definitions. Record unintended effects, such as extra work for another team, as carefully as visible gains.

Choose a pilot boundary that can be reversed or isolated if assumptions fail. Set a review date, a named decision-maker and the conditions for continuing, revising or stopping. If the intervention does not reduce the chosen friction, investigate whether the process rule, integration or adoption is the cause before buying more software. The point of a pilot is to improve the next decision, not to prove a preconceived return.

Consider a purchase-approval process in which a requester emails a spreadsheet, an approver replies in another thread and a coordinator copies the result into a management report. A small intervention could record the request, approval and status in one governed path. The baseline should capture how often information is re-entered, the waiting time for decisions and how frequently a coordinator has to resolve missing context. A pilot measures those same signals on comparable requests; it should not claim a universal saving merely because a form was replaced.

The investment estimate must include connecting the new process to the existing purchasing record, migrating open requests where necessary, training approvers and supporting exceptions. If the report still requires manual export and correction, the intervention has not removed that part of the fragmentation. Leadership can decide whether a second phase is justified using evidence from the first, with uncertainty stated plainly.

A successful pilot may still reveal a policy problem. If approvals stall because authority is unclear, automation can make the stall visible but cannot decide who should approve. Assign the decision owner and change the rule before scaling the technology. A credible business case follows the constraint even when the answer is not more software.

Show decision-makers a simple evidence register next to each expected benefit: baseline observation, proposed change, measurement method and owner. Where an expected effect cannot yet be measured, label it an assumption and test it in the pilot. The register makes a proposed investment defensible without pretending to know a future ROI, and it gives the implementation team a clear basis for choosing which friction to remove first.

Review the case again after adoption, not only after launch. A feature can be delivered on schedule while manual handoffs persist outside it. Interview users and inspect a few real records to confirm that the intended process changed. If not, adjust training, ownership or integration before claiming the original benefit was realized.