Technology adoption in Japanese companies usually stalls because the purchase is treated as the result. Once the tool is bought and the vendor has configured it, the project is reported as done, while daily work carries on much as before. Lock-in follows from the same habit: the company hands requirements, customization and administration to a system integrator (SIer) or vendor, keeps no one in-house who understands the setup, and signs contracts that leave the code, data and admin access effectively with the vendor. To avoid both, start from the workflow, own the accounts and data, prefer standard configuration, and write the exit into the contract before you sign.

This is Part 2 of a short series on how Japanese business systems turn intent into change, or fail to. Part 0 looked at what 2026 makes visible, and Part 1 at who does the work of execution. This part looks at the mechanism in the middle: buying technology.

Why does procurement get mistaken for adoption?

In many organizations, an approved decision counts as progress. Committees align, budget is allocated, a vendor is chosen, documents circulate, and a kickoff is held. What rarely follows is someone who owns the outcome. Responsibility spreads across departments and up the hierarchy, so when adoption fades nobody is clearly accountable.

Implementation then absorbs weeks of effort. Trainers are booked, sessions are held, and attendance is recorded. Training often assumes a level of technical familiarity staff do not have, and a culture that discourages questions means confusion stays hidden. People attend, nod and return to their spreadsheets. Project managers see time disappearing without usable results, but nobody wants to stop the project, because stopping means admitting the purchase did not fit.

So the system persists. It does not fail visibly, and that is treated as success.

Why do expensive tools sit unused?

Capable platforms such as HubSpot or Salesforce show the pattern clearly. Dashboards fill, activity can be demonstrated and training can be logged, so from a distance the rollout looks credible. But these tools assume conditions many Japanese organizations do not provide: a clear owner for results, authority to change the workflow and willingness to act on what the data shows. Without those, the software does not break. It goes quiet.

That quiet suits everyone in the short term. Dissatisfaction is rarely escalated, canceling feels awkward, and licenses renew. The cost that does not appear on the invoice is fatigue. Staff learn that new systems mean disruption rather than improvement, and each failed cycle makes the next initiative harder to take seriously. Harvard Business Review’s piece on why so many high-profile digital transformations fail makes a similar point about treating digital programs as cosmetic.

How does SIer dependence happen?

Japanese companies rely on outside vendors more than companies in many other countries. Most IT engineers in Japan work for vendors and SIers rather than inside the businesses that use the systems. The typical result is a buyer that hands over the whole job (丸投げ) because it has no one who can write requirements or question an estimate.

Lock-in then builds in small, reasonable-looking steps:

  • Heavy customization. Standard software is altered to match every existing habit, so only the original vendor understands the configuration.
  • Accounts in the vendor’s name. The domain, cloud account or admin login is registered by the vendor, and the company never holds the master credentials.
  • Unclear rights to deliverables. Under Japanese copyright law, rights in custom code and documents generally stay with the vendor unless the contract transfers them or grants a clear license.
  • No documentation. Setup notes, data definitions and integration details were never a deliverable, so a new vendor has to reverse-engineer everything.
  • Data you cannot easily export. Records live in a proprietary format or a custom database without a documented export.
  • Maintenance fees nobody reviews. Annual 保守 contracts renew automatically for systems that have barely changed in years.

None of this requires bad faith. It happens because the buyer did not ask.

How should a small company buy business software in Japan?

Start with the workflow, not the product. Write down the process the tool must support, who uses it, what data goes in and what must come out. This page is your requirements document, and it lets you compare vendors on the same terms. I explain this step in why DX projects in Japan fail before the software arrives.

Prefer standard SaaS over custom builds. For most SME needs, such as accounting, invoicing, CRM, chat, file storage and workflow approvals, a mainstream service like freee, Money Forward, kintone, HubSpot, Google Workspace or Microsoft 365 configured close to its defaults is cheaper to run and far easier to leave than a bespoke system. Adapt the process to the tool where the difference does not matter to your customers.

Own the accounts. Register domains, cloud tenants and SaaS subscriptions in the company’s name, with a company email address and a company payment method. Give vendors their own user accounts with the permissions they need, and remove them when the work ends.

Put ownership and exit in the contract. Specify who owns code, configuration and documents, what documentation is delivered, how data is exported and in what format, and what help the vendor gives if you move away. METI and IPA publish model contracts for system development that are a useful reference when reviewing a vendor’s draft. Know whether you are signing a fixed-deliverable contract (請負) or a time-based services contract (準委任), because responsibilities differ.

Pilot before committing. Run real work through the tool with two or three of the people who will use it daily for a few weeks. Fix what slows them down before rolling it out, and cancel if it does not help.

Keep one person inside who understands it. Not necessarily an engineer, but someone who owns the system, holds the admin access, knows the vendor contacts and can judge a change request. For many small companies this is a part-time role supported by outside help, which I describe in what fractional IT management means for a small business.

Review renewals on a calendar. List every system, its renewal date, notice period and monthly cost, and decide each year whether it still earns its place.

Why do small operators often adopt technology faster?

Small independent teams do not adopt tools well because they are more skilled. They do it because they cannot hide failure. If a tool does not help within weeks, it is dropped. People learn by using it, not in formal sessions. Outcomes are visible and responsibility is unavoidable, so poor fit shows up early, when it is cheap to fix.

Large institutions can absorb poor fit for years behind committees and documentation. Small operators cannot, and that exposure turns out to be an advantage. Any business can borrow the principle: tie each purchase to a named owner, a measurable change in the workflow and a date to decide whether to keep it.

What changes when execution is visible?

For a long time, the slow approach could be defended by saying the alternatives were unproven. That argument weakens as small teams and regional businesses run modern tools that genuinely change how their work gets done. Once those results are visible, it becomes harder to explain why a larger organization with more budget cannot do the same.

This does not guarantee reform in large companies. It does mean smaller businesses no longer need to copy their procurement habits to be taken seriously.

Getting help with a purchase

If you are about to buy or replace a system, or suspect you are paying for one nobody uses, a Diagnostics review maps what you have, what it costs, who controls it and what to change. For ongoing vendor oversight and purchasing decisions, Ongoing Stewardship puts an experienced buyer on your side of the table.

Further reading: training staff to replace legacy systems · digital literacy is part of running the business · treating domains, accounts and access as business assets