When an industry proposes a digital platform, it is easy to list functions: procurement, orders, inventory, delivery, settlement and reporting.
After making the list, we still need to answer which problem the first phase will solve, who will actually use it, how a business event will be completed, who handles errors and what will demonstrate that the work is done.
I think we can start with one real business process and make it a working system with clear boundaries and someone ready to operate it, then expand.
The first phase may cover one type of business and a small number of parties. It should still connect initiation, delivery, exceptions and reconciliation. Explain which steps the system supports and which remain manual.
Build in stages, and assess system capability separately from business outcomes. Here is a reference arrangement to adapt to the activity concerned.
1. Identify the business problem before defining the first phase
Start with a recurring problem.
Perhaps buyers and suppliers use different specifications, confirming orders requires repeated calls, or delivery records do not match reconciliation records. Examine these situations to identify the step needing change, the roles involved and what a platform can undertake.
Be specific. Who initiates the activity, confirms supply, delivers and checks the result? What does each step receive and produce, and whose confirmation must it await?
Once those relationships are clear, determine the first-phase functions.
A “minimum scope” means a complete business process that can be examined independently. It need not include every product category or region, and effective manual practices can remain.
Within that process, however, there should be a place for normal work, changes, authorized confirmation and reconciliation. Otherwise, the pages may be built while people still have to connect the actual work informally.
State what this phase excludes. Register other requests and why they may be useful later, rather than turning every discussion directly into a new task.
A baseline record is also useful: which actions previously confirmed a transaction, where errors occurred and who carried extra coordination work. This provides a basis for later comparison.
2. Connect business statuses, roles and records
For an ordinary fulfilment process, begin with four steps: request, supply confirmation, fulfilment and delivery, and reconciliation confirmation.
Each step should answer who acts, on what basis and what record remains.
A request does not mean that a supplier has committed. A delivery still requires checking receipt, discrepancies and settlement conditions. Keep these statuses separate so users can see where the activity stands.
Link related records through business IDs. A request may become several orders, an order may have partial deliveries, and several events may be reconciled together. Preserve individual records and their relationships.
I would avoid using a single “completed” status to cover all these matters. Delivery, reconciliation, receivables and cash received can be checked separately; a green indicator on a screen is insufficient.
Identify who maintains the information. If specifications, units, supply conditions or delivery dates change, who confirms the new version, which outstanding activities are affected and how will users know?
Information reaching the next step is only part of the job. Someone must be responsible for its meaning, origin and scope.
Figure 1 is a general reference architecture. Documents are linked by their business relationships. Partial deliveries, changes and disputes require separate handling; one order need not correspond to one delivery or one receipt of payment.
3. Include permissions, exceptions and reconciliation in the first phase
A process working in a demonstration still needs to be examined against its users and possible changes.
Permission to view information does not necessarily include authority to confirm an order. Permission to enter data does not allow someone to change another party's result. Arrange viewing, entry, confirmation, amendment and export separately according to actual responsibilities.
Use only information the team is authorized to use and needs for this activity. Assign responsibility for its source, updates and error correction. Keep the corrected result distinguishable from the original evidence.
Design exception handling too. What status follows a changed requirement, insufficient supply, partial delivery, a quantity discrepancy or disagreement over reconciliation? Who takes over?
If every error can only be resolved by a developer changing data behind the scenes, frontline users struggle to understand what happened and later review loses its basis.
Provide handling routes for common exceptions. Record the facts, assign an owner, retain the handling and confirmation records, then return to the appropriate step. Keep unresolved matters pending rather than forcing confirmation to close the workflow.
Check easily missed cases: can a repeated delivery submission create a duplicate? Can other steps see a withdrawal or correction? Are old permissions adjusted when a person leaves their role?
These matters directly affect reliable operation and belong in first-phase acceptance rather than being postponed indefinitely.
4. Advance through four stages, with evidence for each transition
Stage one: define the problem and acceptance scope
Agree the problem, this phase's boundaries, participating roles, current conditions and separate system and business checks.
Confirm the scope, necessary records, permissions, principal exceptions, owners and resources together.
At this stage, the business and implementation teams should be able to use the same process diagram to explain the start and end, human confirmations and system processing.
Stage two: complete the bounded workflow
In a controlled environment, test normal activity and the main exceptions. Actually perform each step: can it be executed, who may confirm it, does the data have corresponding evidence, and can errors be found and corrected?
When a problem appears, record what happened, the affected step and the person responsible for correction, then recheck. A ticked feature list is not enough.
Manual steps with explicit boundaries are acceptable, provided there is an owner, a recordkeeping method and a view on future adjustment. Do not move a scope into live use while gaps affecting critical activity remain unresolved.
Stage three: trial within the confirmed scope
After system checks pass, admit limited real activity and participants.
Arrange daily support, issue response, information checks and fallback procedures for failures. During the changeover, identify the primary business record and how differences will be handled.
If short-term parallel checking is necessary, agree its purpose, owner and ending conditions. Do not indefinitely require frontline staff to enter the same activity twice while excluding the extra work from costs.
Collect system performance and business changes separately. Being able to record and confirm is one result; less rework, shorter waits and better reconciliation are another.
If critical permission, record or fulfilment problems prevent processing under the confirmed conditions, suspend the relevant new operations and use the agreed fallback for necessary work. Reconcile discrepancies, retest affected scenarios and obtain authorized confirmation before resuming.
Stage four: establish stable ownership before reviewing expansion
Once this process is stable, someone must formally take over daily operation.
Assign actual owners and usable instructions for business rules, staff and permission changes, issue response, costs, and information export, retention and recovery.
Test the handover. Can the receiving team complete a transaction and handle the main exceptions? Can they find a fallback during a failure? Can backed-up information actually be restored and reconciled?
Then consider adding categories, participating nodes or regions. Review the new volume, information differences, support costs and responsibilities.
Figure 2 organizes stages around delivery and acceptance conditions. Reaching a date or launching a function does not automatically authorize the next stage. A system may pass while business outcomes remain under observation.
5. System acceptance and business acceptance answer different questions
I think the key distinction is between what the system can do and what consequently happened in the business.
| Acceptance area | Main checks | Possible evidence |
|---|---|---|
| System capability | Executable workflow, correct permissions, traceable records, and ways to handle exceptions and failures | Normal and exceptional operation records, permission checks, reconciliation and recovery tests |
| Business outcomes | Actual use, changes in delivery and reconciliation, rework, waiting, costs and burdens | Before-and-after records, participant feedback, inputs and issue-resolution records |
These conclusions need not be forced into one “pass.”
If the system supports the bounded process but the observation period is insufficient, retain “outcomes under observation.” Where agreed system conditions and business responsibilities are satisfied, limited use may continue while expansion is deferred.
Conversely, an apparently improved business period does not remove important permission, data or exception problems. People may have added substantial coordination effort, or other conditions may have changed. One favourable result should not conceal these issues.
Define the comparison: included activity, period, what counts as rework, and how extra hours and expenses are recorded. Use consistent definitions where possible.
Volume, order complexity, supply conditions and prices may also affect results. Record these changes to improve judgment, without expecting one limited trial to establish every causal relationship.
An acceptance conclusion can be specific: what is usable, what remains unresolved, who handles it, what cannot yet be confirmed and when the team will return to check.
6. A fictional industrial-consumables example
This situation was written for illustration. It does not describe a real enterprise or an achieved implementation result.
Several manufacturers and their supply and delivery partners want to improve inquiries, delivery and reconciliation for common industrial consumables.
The first phase can be limited to one category of standard consumables, a defined group of participants and one fulfilment chain, rather than all procurement and management activities.
Clarify specifications, units and delivery conditions first. Supply confirmation creates the corresponding business record. Delivery and receipt link to it; partial arrivals, quantity differences and reconciliation opinions retain separate statuses.
| Stage | Initial deliverable in this example | How to check |
|---|---|---|
| Define scope | One process from request to reconciliation, roles and acceptance definitions | Can parties explain responsibilities, inputs, outputs and phase boundaries? |
| Complete workflow | Normal ordering, supply confirmation, partial delivery and discrepancy handling | Can people act by role, and can quantities and records be reconciled? |
| Controlled trial | Limited live activity, issue support and fallback procedures | Who actually uses it, does it add duplicate work, and how are issues resolved? |
| Handover and expansion | Daily ownership, maintenance arrangements and review materials for the next scope | Can the receiving team operate independently, and does expansion have resources and evidence? |
If specifications are clearer but reconciliation still requires manual reaggregation, trace that step. Are records unlinked, definitions inconsistent or responsibilities unclear? Revise accordingly.
If one group can use the system normally while another needs extensive extra support, the conditions for use need further clarification. Examine the differences before maintaining the limited scope, retesting after changes or deferring expansion.
Feature construction, real use, daily handover and operating improvement remain connected but separately assessed.
7. Revisit costs and responsibilities before expanding
A platform can usually do many more things. Every added scope may also create information maintenance, training, support and exception-handling work.
Include continuing operating costs in expansion review. Who pays for development, information preparation, role training, daily support, process changes and maintenance? Separate premises, equipment and fulfilment inputs by actual use rather than putting them all into a software-development budget.
Establish what existing systems can provide before deciding how to fill gaps. This approach does not presume that a particular software package must be replaced or that every industry needs the same technology.
More features, nodes and records still need to be assessed in actual activity. Whether they help the parties work more clearly and reliably provides a basis for further investment.
Before the next stage, ask:
- Which business process has this phase actually connected?
- Are normal and exceptional situations owned and supported by checkable records?
- What has been established about system capability and business outcomes separately?
- Who can take responsibility for daily operation, failures and information maintenance?
- What resources, responsibilities and authority does the next scope need?
Move forward with clear answers. Leave matters without adequate evidence pending review or validation.
A platform can be built process by process. Each part that can be delivered, used and taken over provides a basis for the functions and scale that follow.
Download the accompanying Phased Construction and Acceptance Checklist