Why DX projects in Japan fail before the software arrives

Most digital transformation (DX) projects in Japanese companies fail before the software is installed. The company chooses a tool before it has mapped how work actually moves, which data can be trusted, who will own the system afterwards and what the vendor contract commits it to. The new system then meets the real business, staff route around it, and the old spreadsheet, fax or LINE thread stays in charge. Fixing that means doing the mapping first and choosing software last.

By the time a CRM, ERP, booking platform, AI tool or website rebuild reaches a procurement meeting, the decisions that determine success have usually been made already, often without anyone noticing. This post covers where those early mistakes happen and what to do instead.

Why does DX fail so often in Japan?

Buying the tool is treated as the transformation

Procurement is visible. There is a budget line, a vendor presentation, an approval, a kickoff and eventually a login page. Those steps look like progress, and in many organizations they are reported as progress.

A purchased tool is an empty container. It does not know which customer records are reliable, why one salesperson keeps notes in LINE, which approval step is required by law and which is inherited habit, or that the person everyone calls for answers is retiring next year. When those facts are unknown, the business ends up with two realities: the official system that produces reports, and the real one running on email, Excel, Chatwork, paper and memory. It pays for both.

METI’s 2018 DX report framed the national problem as the “2025 cliff”: legacy systems that nobody fully understands, blocking change. The same pattern appears at small scale in SMEs, just with spreadsheets and old vendor setups instead of mainframes.

The real workflow is not the official one

When I review a company’s systems, I start by asking how work actually moves rather than which software it uses. Where does a customer inquiry arrive? Who sees it first? What happens if it comes in English rather than Japanese? Where is the quote stored? Who knows the pricing exceptions? What does the customer experience while staff copy information between tools?

The answers rarely match the org chart. The sales process depends on one senior employee’s memory. The documentation that matters is buried in old chat threads. The shared drive has a folder structure nobody can explain. The bilingual operation is one tired person translating between two teams by instinct.

Software chosen without that picture either fails or forces the business into a fictional version of itself.

Data quality is treated as a cleanup task at the end

Duplicate customer records, empty fields, inconsistent company names and abandoned spreadsheets are evidence. They show where responsibility was unclear, where workflows split and where staff stopped trusting the system. If you clean the data during migration without understanding why it got dirty, it will be dirty again within a year.

This matters more in Japan because a lot of business knowledge is contextual: introductions, relationships, payment habits, seasonal patterns and how to address a particular client. If a global software template has no place for it, staff will keep it somewhere else, usually in another spreadsheet.

Nobody owns the system after launch

A vendor can configure a platform. A keen employee can push adoption for a few months. Management can announce the initiative. None of that is ownership.

Ownership means one person is responsible for the system’s health after rollout: what it is for, what data belongs in it, who uses it and how, which exceptions are allowed, and when the setup should change. In most SMEs and foreign-owned teams nobody has that job. The CEO is too busy, the operations manager is overloaded, and the most technical employee inherits it by accident. The vendor is accountable to the contract, not to whether the business improved.

The company depends on a vendor it cannot evaluate

Japanese companies rely heavily on outside vendors and system integrators (SIers). Most of Japan’s IT engineers work at vendors rather than inside the companies that use the systems, which is the reverse of the pattern in the United States. That leaves many buyers without anyone in-house who can judge a proposal, question an estimate or plan an exit.

The result is familiar: heavy customization that only the original vendor can maintain, change requests billed at the vendor’s rate, and data held in formats that are hard to move. I cover how to buy without that dependence in why technology adoption in Japan fails at procurement.

Does AI change any of this?

AI makes the sequence more important, not less. A business with clean data, clear workflows and an owner can use AI to summarize customer history, draft bilingual correspondence, classify documents and cut repetitive work. A business without those foundations gets faster confusion: confident summaries of the wrong version, outputs nobody knows how to check, and another tool beside the old ones where responsibility disappears.

AI sits on top of your infrastructure. It cannot stand in for it.

What should a Japanese company do before buying software?

Map the real workflow. Follow two or three core processes, such as inquiry to invoice, from start to finish. Record every place information enters, changes form, gets copied or disappears, including LINE, fax, paper and personal inboxes.

Find the unofficial systems. Ask staff which spreadsheet or notebook they actually trust. Those files show you the fields and steps that matter.

Separate constraints from habits. Some paper steps exist because of tax law, the qualified invoice system or a customer’s requirements. Some exist because nobody questioned them. Some preserve trust with long-standing partners. Label each one before deciding what to change.

Review vendors and contracts. List every system, who administers it, the renewal date, the notice period and how you would get your data out. Note any system only one outside vendor can change.

Name owners. Assign one owner for each system and each handoff between systems, with time in their week to do it.

Write both language versions. In bilingual teams, document the Japanese-side and English-side versions of the process, and find where they disagree.

Only then choose the tool. At that point the question stops being “which tool is best?” and becomes “which tool fits the way we have decided to work?” That is a much easier question to answer, and the answer is often smaller and cheaper than the original proposal.

Video: Digital Transformation in Japan - Assessing opportunities for EU SMEs. from EU-Japan Centre for Industrial Cooperation.

How long does it take to do this properly?

For a small company, mapping core workflows, systems and contracts usually takes a few weeks of part-time effort, not months. That is slower than signing up for a subscription and much faster than spending six months implementing software nobody trusts, then another six working out why.

The practical order is: understand the business, map the workflow, clean the data that matters, assign ownership, choose tools, train people on the real process, and review it when the business changes.

Where to start

Most businesses are held together by reasonable decisions made under pressure, and the point of this work is not to criticize the current setup. It is to find what the business actually runs on, what is fragile, what is duplicated and what should be fixed before anyone adds another tool.

That is what a Diagnostics review covers for owner-led and foreign-owned SMEs in Japan. If you already know what needs to change, I can plan and carry out the implementation with your team and vendors.

---

Further reading: how to move a Japanese business off fax · how to digitize paper workflows · the hidden cost of good enough systems