For a manufacturer operating in Japan, the first valuable modernisation project may be a working explanation of the old system. Before replacing a scheduling application, capture the production rules, exceptions, and manual corrections that keep orders moving. Convert those discoveries into examples the replacement must reproduce or deliberately change.
Japan’s policy discussion supports looking beyond a code conversion. METI’s May 2025 legacy systems report calls for visibility into systems, stronger business participation, and greater ownership by user companies. That report is background for an ongoing transformation problem, not a new October 2026 deadline.
The missing specification is often beside the application
Imagine a fictional components factory using an old production scheduler. The application calculates a delivery date, but a planner adjusts it when a particular machine runs a certain material. Another employee keeps customer packaging exceptions in a spreadsheet. A third knows which overnight import can be safely repeated.
A replacement that accurately translates the program can still lose all three behaviours. Equally, copying every workaround can preserve a process the business should retire. The discovery challenge is to distinguish necessary operating knowledge from accidental limitations of the old software.
Ask operators to demonstrate their last difficult order. Follow what they read, change, check, and communicate. Screenshots alone will not explain why a planner overrides a result. Record the trigger, decision, consequence, and person authorised to resolve uncertainty.
Build a rule notebook that can become software
Use a small, structured record for each discovered rule. Keep it understandable to production staff and detailed enough for developers to implement.
- ▸Situation: a rush order shares equipment with a committed batch.
- ▸Inputs: promised date, machine availability, material, setup time, and customer priority.
- ▸Current decision: which batch moves and who approves the change.
- ▸Evidence: an anonymised historical order and the operator’s explanation.
- ▸Intended future behaviour: preserve, revise, or remove the rule.
- ▸Unresolved question: whose decision is needed before implementation.
Give each rule a stable identifier. Reference that identifier in acceptance examples and change discussions. This lets a manager challenge the underlying policy without arguing about an unexplained line of code.
An AI assistant may help group notes or identify similar cases. Treat its output as a draft for the people who understand the operation. A plausible explanation of a production constraint is not evidence that the constraint exists.
Recover dependencies before choosing the replacement boundary
A factory application rarely ends at its login screen. Trace its incoming files, label printers, shared folders, batch jobs, equipment interfaces, and exports used by finance. Include the small scripts owned by individuals. Record frequency, owner, failure signal, and the business activity affected by each dependency.
The IPA software modernisation report discusses black-box systems and outdated development practices. Our practical interpretation is to buy observable behaviour and maintainable ownership alongside replacement code. The report does not prescribe one platform for every Japanese manufacturer.
Choose a boundary that people can understand. Replacing the order exception queue may be safer to evaluate than replacing scheduling, inventory, procurement, and finance together. A contained boundary also makes the retained system’s responsibilities explicit.
Compare decisions before transferring control
Run the proposed component against a controlled set of historical scenarios. Compare its decisions with the accepted business outcome, not automatically with whatever the old program produced. Historical output may contain known errors or obsolete policy.
Include normal orders and awkward cases: partially available stock, changed delivery dates, missing supplier information, equipment downtime, and an order cancelled after planning. Keep disagreements visible. A difference should have an owner and explanation before it becomes an accepted change.
During a shadow period, the new component can calculate recommendations while the existing process remains responsible for execution. Prevent shadow outputs from sending purchase orders or machine instructions. Decide explicitly when a human may act on a recommendation and record that approval.
Design the handover around a second person
The project has not solved the original knowledge problem if only the new supplier understands the replacement. Ask someone outside the implementation team to complete a realistic support exercise using the delivered documentation.
They should locate a failed import, explain the affected orders, identify the relevant rule, restore service through the agreed procedure, and find the evidence of recovery. This exercise reveals missing operational knowledge more effectively than counting pages in a manual.
Agree who owns source repositories, deployment accounts, test data, rule records, and equipment configuration. Specify how a future supplier can reproduce a build. Our software project handover guide expands these ownership questions.
A sensible first commission
Commission a bounded discovery and executable demonstration. Useful deliverables include an interface map, a prioritised rule notebook, a scenario set, and a prototype for one operational decision. Add a list of unresolved business choices instead of hiding them inside an estimate.
Measure whether another planner can explain the process, whether a developer can reproduce an exception, and whether management can choose the next replacement boundary. These measures establish readiness; they do not promise a particular productivity improvement.
For budget discussions, separate knowledge recovery, integration, replacement development, and transition support. The discovery deliverables guide can help make those outputs reviewable before a larger commitment.
TuniCyberLabs can help scope custom software development around a factory workflow and its undocumented rules. Describe the application, the people who rely on it, and one difficult production scenario to discuss a practical starting point.