When commissioning an offshore partner to modernize a business system, “preserve every existing function” can sound like an easy agreement. Yet a list of old screens does not explain which functions remain essential, which overlap, or which have no identified users.
For SIers, CTOs and DX leaders, a useful step before fixing the scope is to create a decision register: rebuild, retain temporarily, investigate further or propose retirement.
1. Start with the work, not just the screens
For each function, record who uses it, the business task it supports, when it is used and who receives its output. Compare interviews with business teams against available documentation, output reports and automated processing schedules.
No recorded access during a particular period is insufficient evidence of non-use. Ask specifically about period-end processing, annual activities and infrequent situations. Also check whether another system consumes the function’s output.
2. Record the evidence behind each decision
The register can include the function, business owner, evidence of use, dependencies, proposed action, approver and review date. Separate four possible actions:
- Rebuild: the business need remains, and the outputs to preserve are understood.
- Retain temporarily: dependencies remain; assign an operating owner and a review deadline.
- Investigate further: evidence is incomplete; record the question, respondent and confirmation deadline.
- Propose retirement: an alternative exists or the need has ended; obtain the business owner’s approval.
The development team assesses technical impact. An authorized customer representative decides business necessity. Silence should not count as approval to remove a function.
3. Hypothetical example: two similar sales reports
Suppose an SIer is preparing to rebuild an order management system for a Japanese business. The inventory contains two similar sales reports. To narrow the scope, the project team proposes combining them.
After consulting accounting, the team discovers that the second report supports annual reconciliation and handles cancelled orders differently from the monthly report. The appropriate next step is to preserve the reconciliation requirement, clarify the rules and consider a common data source. Whether the interfaces can be combined is a separate decision. This is a hypothetical illustration, not a TECHNEST project or result.
4. Put exclusions into the plan
When a function is approved for retirement, record how historical data will remain accessible, who will handle questions and what would trigger a review of the decision. Agree on data retention separately: retiring a function does not automatically mean deleting its data.
Keep the approved register alongside development requirements and acceptance criteria. Shared function IDs and decision records give Japanese and Vietnamese teams a common reference. Identify unresolved items as assumptions or investigation tasks, rather than silently including them in—or excluding them from—the estimate.
5. Talk with TECHNEST
TECHNEST brings years of experience serving the Japanese market in business system design, development and legacy modernization, alongside collaboration with Japanese consulting partners. We suggest starting the conversation with one business workflow and a list of functions whose future is still uncertain.
Explore our enterprise systems services or contact TECHNEST to discuss the investigation scope and deliverables to agree on before development begins.
