Moving Beyond the Talent Shortage by Reconnecting Work and Data

01Count handoffs, not applications

The number of tools you pay for says little about the load on your team. What you need to know is how many times the same customer name is typed in, how many status definitions coexist, and how many items are reconciled by hand at month-end. For each handoff, record who passes which information to the next step, and on what basis.

Before you can measure fragmentation, the staffing reality arrives first. Teikoku Databank surveyed 23,083 Japanese companies between 16 and 30 April 2026 and received 10,538 valid responses (45.7%). Of those, 50.6% reported a shortage of full-time staff, above half for the fourth consecutive April. In seven sectors, including information services and transport and warehousing, the figure exceeded 60%. Filling the gaps between systems by adding people is no longer an available assumption.

What you are collecting is a list of the places where people move data. Write one handoff per row and fill in the columns of the template below. For a broader method of mapping all of your work, see our guide to business process inventories.

Pick exactly one type of work for each row: re-entry, reconciliation, or check. If a handoff involves two, split it. Rows with an empty decision rule are the places where people rely on experience. Those are the definitions to settle before you connect any systems.

02Worked example: from order to cash application

The following is a fictional example. It assumes the accounting team of a company that sells services to other businesses, and applies the template to the flow from order through invoicing to cash application. The volumes only illustrate how to fill in the table and do not describe any real company.

The first thing to notice is that row 2 has no decision rule. Nobody has written down how the bill-to party or due date is chosen, so the accountant decides by looking at last month's invoice. The customer name is also entered in four places (the CRM, the order management system, the invoicing service, and the accounting software) and is used again in row 3 to match remitter names. If you build integrations before deciding which system owns the customer name, every spelling variation spreads to all four systems.

Once the inventory is done, you do not need to start with the highest-volume rows. Look first at rows with no decision rule and at data that appears repeatedly. The first group needs a defined procedure. The second needs a source of truth.

03Assign a source of truth and an owner

For customer, opportunity, contract, and billing data, define one authoritative record and one accountable owner. Showing the same information on several screens is not integration if who may change it and when the change propagates are still unclear.

Carry identifiers, update timestamps, and origin through every integration, and decide the conflict rule before anything synchronizes. Route manual corrections through a single exception desk. The template below captures all three decisions in one row.

The first row follows the fictional example above. When you fill it in, name exactly one system of record and one owner per row. If you are tempted to write two, the unit of data is probably too broad. Splitting customer into company master data and bill-to details, for instance, usually makes it easy to name a single owner for each.

Assigning owners overlaps with segregation of duties in internal control. Keep the table complete enough that, when AI is later allowed to write data, you can read who approves those writes straight from it.

04Master data erodes during operation

Data inconsistencies are invisible when a system goes live. As operation continues, master data gradually erodes, and field names and levels of detail drift apart across sites. In sustainability disclosure consolidation, re-mapping fields that mean the same thing under different names becomes a recurring exception task at head office.

To prevent this, decide the master data structure and the control rules at the time of implementation. Putting in both business-side rules (process controls) and system-side enforcement (system controls) lets you uphold the rules from the top. With only one of them, the data erodes again in daily operation.

Controls that are too strict, however, add input and maintenance effort and slow the work down. Design with this balance in mind: put efficiency first, and add only the controls needed for the accuracy, completeness, and validity the rules require.

05Connect systems through business events

Use business events such as order received, approved, or payment received to trigger the work that follows. Sharing events and state transitions across systems keeps the impact small when a tool is replaced, compared with wiring screens directly to one another.

For each event, define the condition that confirms it, what runs next, the key that prevents duplicates, and how failures are retried. If an event is processed twice, the customer receives two invoices. That is why the retry column must always state which identifier blocks a duplicate.

AI can help interpret events and classify exceptions, for example by sorting receipts whose remitter name does not match the bill-to party into a spelling variation, a combined payment, or unknown. Even so, write the conditions that make a state official and the retry rules into the table on the business side. Treat the AI's classification as a recommendation, and confirm a state only when the conditions in the table are met.

06Expand permissions in stages and keep a way back

Avoid a single cutover. Widen access in order: read-only, recommendations, approved writes, and then bounded automation. At each stage, compare the results with the old process and make sure you can return to the previous procedure whenever they diverge.

Agree on the criteria for moving to the next stage before go-live, stated as a period and an acceptable level of difference. For a monthly process, run through at least one full close before moving on.

Also confirm the manual fallback, the procedure for replaying unprocessed data, and who gets notified when an integration stops. Keep the old procedure documented in a form people can still follow.

07Let AI draft the inventory

Generative AI can produce a first draft of the handoff inventory quickly. Give it the process as bullet points and have it organize them into the template's columns. For how to build AI into internal procedures more broadly, see building generative AI into internal workflows.

Treat the output as a draft. Volume and decision rule are the columns AI is most likely to fill with guesses, so the prompt tells it to write "to confirm" instead, and the owners fill those cells in afterwards.

You are responsible for mapping business processes. From the process description below, identify every point where a person carries data from one system to another (a handoff).

# Output format
Return a Markdown table with these columns:
No | Process | Source system | Destination system | Data carried | Owner | Type of work (exactly one of: re-entry, reconciliation, check) | Monthly volume | Decision rule | What happens on a mismatch

# Rules
- One handoff per row. If one handoff involves two kinds of work, split it into two rows
- Do not guess information that is not in the description. Write "to confirm" instead
- After the table, list any data that appears three or more times, and every row whose decision rule is "to confirm"

# Process description
(Paste the process as bullet points here)

08Measure operational integration

Track re-entry, data mismatches, approval queues, and exception rework alongside cycle time. Show management how long it takes for decision-ready information to come together, and show operators how many actions it takes to finish one item.

Before integrating, keep the monthly volumes from the inventory as a baseline. Filling in the same table afterwards shows which handoffs disappeared, row by row. Integration has created capacity only when both the management measure and the operator measure improve.

• Re-entry: how many times people typed the same data again
• Data mismatches: how often another system disagreed with the source of truth
• Approval queue: items waiting with an approver, and for how many days
• Exception rework: items that fell out of automation and were redone by hand
• Decision latency: days needed for management to gather the information it needs