What must work on day one?
Begin with the operation you are opening. List the work the team must be able to complete at launch: taking an order, purchasing materials, receiving stock, delivering a service, or preparing a report. Then distinguish those essentials from improvements that can follow.
A list of department names is only a starting point. Walk through one typical transaction from beginning to end. Include the people involved, the information they need, the documents they create, and the exceptions they must handle.
For exampleA trading operation might follow a customer order through availability checks, purchasing, receipt, delivery, and a report to headquarters. Mark where each step depends on another team or system.
Capture in the brief: the essential workflows, a realistic example for each, and the target milestone they support.
Who will use the system, and how?
List the roles that will work in the ERP, including colleagues outside China who will review or approve information. Describe what each role needs to enter, change, approve, and read. Avoid assuming that everyone needs the same access or the same view of the business.
Record the working languages needed for daily use, training, documents, and reporting. Ask the people who will do the work: a manager's preferred language may differ from that of the operational team.
For exampleA local warehouse team, a China sales manager, and a headquarters controller may all follow the same order while needing different information and permissions.
Capture in the brief: a role list, expected users, working languages, and the decisions each role is responsible for.
What information does headquarters need?
Ask for examples of the reports or information headquarters expects. Agree what the figures mean, how often they are needed, which format is useful, and who is responsible for preparing and checking them.
A shared label does not always mean a shared definition. Clarify the dates, categories, and status changes behind a report before discussing how to automate it.
For exampleIf headquarters requests an order report, clarify whether it should include draft quotations, confirmed orders, delivered orders, or another defined set. Agree which team resolves differences.
Capture in the brief: sample reports, agreed definitions, frequency, and a named owner for each information requirement.
Which existing systems must stay?
Make an inventory of the systems already used by your business. For each, state whether it must remain, what information it owns, and what the China operation needs to send or receive. Include spreadsheets and manual handoffs that currently keep the process moving.
Describe the information exchange before choosing a technical solution. A periodic file, a manual review, and an automated connection have different requirements. The available options need to be checked against the actual systems and their interfaces.
For exampleHeadquarters may maintain the product list while the local operation records stock movements. Decide who can create or change a product and how both teams will identify the same item.
Capture in the brief: the systems to retain, data ownership, the direction and frequency of exchanges, and the interfaces still to investigate.
Who owns decisions, data, and preparation?
Assign owners to the work around the software: confirming requirements, preparing data, reviewing examples, organizing training, and deciding whether a workflow is ready to use. Make sure those people have time to participate.
Keep unresolved questions in a shared list. Give each one an owner and a decision point, especially where the answer affects scope, budget, or a launch milestone.
For exampleOne colleague may prepare the product data, another may check it, and an operations owner may confirm that a test order can be completed using it. Record those responsibilities separately.
Capture in the brief: decision owners, preparation responsibilities, target milestones, and open questions.
A shared brief for the next conversation.
Keep the first version short enough for both teams to read. A useful brief can include:
- A description of the China operation and its intended launch milestones.
- The workflows that must work first, with realistic examples.
- The roles, users, and working languages involved.
- The information headquarters needs and who owns it.
- The existing systems and data exchanges to consider.
- The people responsible for preparation, decisions, and unresolved questions.
Use this brief to guide software demonstrations and implementation discussions. Update it when the team makes a decision, and keep assumptions separate from confirmed requirements.
This guide is a starting point for an operational discussion. Product fit and the scope of any configuration, customization, or system connection need to be reviewed for your project.