Digital transformation in Japan is usually discussed too late in the process.

By the time the software enters the conversation, the important mistakes have often already happened. Someone has decided the business needs a CRM, an ERP, an AI workflow, a website rebuild, a booking platform, a data warehouse, or some enterprise tool with a vendor deck full of clean diagrams. Procurement begins. Budgets get assigned. Internal meetings happen. A system is selected.

Then the project runs into the actual company.

The staff do not use it. The data is inconsistent. The old spreadsheet survives because people still trust it more than the new platform. The Japanese-side workflow does not match the global template. The vendor understands the software but not the business. Management thinks the rollout is complete because the contract was signed and the login page exists.

Nothing meaningful changed.

That is not a software failure. It is a pre-software failure.

Procurement is not progress

Japan has a habit of treating procurement as a visible sign of action. Buying the tool becomes proof that the company is modernizing. The system exists, therefore the transformation exists.

But a purchased tool is only an empty container. It does not know which customer records are trustworthy. It does not know why one salesperson keeps private notes in LINE. It does not know which approval step is legally required and which one is just an inherited habit. It does not know that the person everyone calls for answers is retiring next year.

Software cannot repair an operating model nobody has mapped.

This is why so many projects produce a strange double reality. On paper, the company has modern systems. In practice, people still run the business through email, Excel, Chatwork, paper, side conversations, and memory. The official system becomes a reporting surface. The real system stays underground.

The company pays for both.

The real workflow is usually not the official workflow

When I look at a business system, I do not start by asking what software the company uses. I want to know how work actually moves.

Where does a customer inquiry enter? Who sees it first? What happens if it arrives in Japanese? What happens if it arrives in English? Which system gets updated? Which system is ignored? Who knows the price exception? Where is the quote stored? What happens after the sale? What does the customer think is happening while the team is moving information between tools?

The answers are rarely as clean as the org chart.

A business may say it has a sales process, but the real process depends on one senior employee who remembers the customers. It may say it has documentation, but the useful version is buried in old Slack threads. It may say it has a shared drive, but nobody can explain the folder structure. It may say it has bilingual operations, but the translation layer is one exhausted person bridging two teams by instinct.

That is the system. Not the diagram.

If you buy software before understanding that system, the software will either fail or force the business into a fantasy version of itself.

Data quality is not a cleanup task at the end

A lot of digital transformation projects treat data quality as something to fix after implementation.

That is backwards.

Dirty data tells you how the business has actually been operating. Duplicate customer records, missing fields, inconsistent naming, private notes, abandoned spreadsheets, and broken tags are not just technical debris. They are evidence. They show where responsibility was unclear, where workflows split, where staff stopped trusting the system, and where the company quietly accepted manual workarounds instead of deciding how information should move.

If you clean the data without understanding why it got dirty, it will get dirty again.

This is especially important in Japan because a lot of business knowledge is contextual. Names, relationships, introductions, payment habits, local vendor history, honorific nuance, and seasonal patterns may not fit neatly into a generic global software template. If the system does not respect that context, staff will preserve it somewhere else.

Usually, that means another spreadsheet.

Ownership is the missing role

Tools fail when nobody owns the operating layer around them.

A vendor can configure a platform. An internal champion can push adoption for a while. Management can announce the initiative. None of that is the same as ownership.

Ownership means someone is responsible for the health of the system after the rollout. They know what the tool is for, what data belongs inside it, who uses it, what behavior is expected, what exceptions are allowed, when the process should change, which vendor promises are real, and what happens when the system stops matching reality.

Many Japan SMEs and foreign-owned teams do not have that person. The CEO is too busy. The operations manager is already overloaded. The most technical employee becomes responsible by accident. The vendor is accountable to the contract, not to the business outcome.

So the system decays.

Not because people are lazy. Because no one was given the authority, time, and context to keep the system alive.

AI makes this worse if the foundation is weak

AI has made the pre-software problem more urgent.

A business with clean data, clear workflows, good documentation, and strong ownership can use AI in practical ways. It can summarize customer history, assist with bilingual communication, draft internal notes, classify documents, support research, or reduce repetitive work.

A business without those foundations mostly gets faster confusion.

If the source data is messy, AI will confidently process the mess. If the workflow is unclear, AI will generate outputs nobody knows how to evaluate. If ownership is missing, AI becomes another tool sitting beside the old tools, producing more content, more drafts, more suggestions, and more places for responsibility to disappear.

AI is downstream of infrastructure.

That is not anti-AI. It is respect for sequence.

The Japan-specific layer cannot be ignored

Many foreign-owned SMEs in Japan inherit a difficult mix of expectations.

The foreign side wants speed, clarity, metrics, self-service, and software that behaves like the tools they used elsewhere. The Japanese side may depend on paper processes, vendor relationships, hanko-era habits, accounting conventions, local etiquette, and communication norms that are not irrational, but are often poorly explained to outsiders.

Bad transformation projects pick one side and pretend the other side is the problem.

Good infrastructure work translates between them.

Some Japanese practices are real constraints. Some are habits. Some preserve trust. Some waste time. Some paper processes are connected to compliance. Some are just fear wearing a procedural costume. The work is to tell the difference before imposing a tool.

That requires diagnosis, not procurement.

What should happen before buying software

Before a company buys another platform, it should do the boring work.

Map the real workflow. Identify every place information enters, changes form, gets duplicated, or disappears. Find the unofficial systems people actually trust. Name the person who owns each tool and each handoff. Review vendor contracts and renewal dates. Check which data fields matter and which ones are fantasy. Document the Japanese-side and English-side versions of the process. Decide what should be preserved, what should be simplified, and what should be killed.

Only then should software enter the conversation.

At that point, the question changes. It is no longer “Which tool is best?” It becomes “Which tool fits the operating reality we have chosen to build?”

That is a much better question.

The practical path

Digital transformation in Japan does not need more theater. It needs more adult sequencing.

First, understand the business. Then map the workflow. Then clean the data. Then assign ownership. Then choose tools. Then train people around the real process. Then review the system when reality changes.

This is slower than buying a subscription. It is much faster than spending six months implementing software nobody trusts.

For owner-led and foreign-owned teams in Japan, this is the reason I usually start with a Stack Audit. The goal is not to shame the current setup. Most businesses are held together by reasonable decisions made under pressure. The goal is to find what the business is actually running on, what is fragile, what is redundant, what is expensive, and what should be fixed before anyone adds another tool.

Japan’s digital transformation problem is not that companies have failed to buy enough software.

It is that too many companies buy software before they understand the system the software is supposed to serve.

Start there.

A serious DX conversation has to include the company, the customer, the workflow, and the local market. This external video is useful because it frames Japanese digital transformation as an operating question for real SMEs, not just a software purchase.

Stacks of paper documents and file folders — External visual reference: unmanaged records before they become a software problem. Photo by Wesley Tingey on Unsplash.

Source video: EU-Japan Centre for Industrial Cooperation on digital transformation in Japan. The important lesson for operators is sequencing: understand the workflow before selecting the platform.