Client
Confidential Global Sportswear Retailer
Deliverables
Business Process Analysis Stakeholder Analysis System & Data Flow Mapping Requirements Engineering Business Rules User Stories & Acceptance Criteria AS-IS / TO-BE Process Design
Year
2025
Role
Business Analyst
Business analysis for a global e-commerce environment focused on improving how orders move across interconnected systems, teams and operational processes. The project involved analysing the end-to-end order lifecycle, identifying process gaps and system dependencies, and translating complex business scenarios into structured requirements and business rules. The goal was to create a clearer, more scalable order management model capable of supporting standard fulfilment as well as exceptions such as stock changes, cancellations, split orders, payment issues and returns.
Outcome
The project established a structured business and system model for managing orders across the complete e-commerce lifecycle.
By mapping processes, systems, decision points and exception scenarios, the analysis clarified how orders should move from placement through payment, inventory allocation, fulfilment, delivery and potential return or cancellation.
Business needs were translated into requirements and rules that defined system responsibilities, expected behaviours and alternative flows. This created a shared foundation for product, engineering and business teams to align on the future order management experience.
The resulting model also established measurable areas for future optimisation, including order processing efficiency, fulfilment accuracy, manual intervention and exception resolution.
Key results
Key Analysis Outcomes
The analysis revealed that many operational problems were not isolated system issues. They resulted from dependencies between systems, unclear ownership of decisions and inconsistent handling of exceptions.
Five areas became central to the target process:
Reliable inventory decisions - stock availability and reservation needed clearly defined ownership and timing.
Structured exception handling - failures and alternative scenarios required explicit workflows rather than manual interpretation.
Clear system responsibilities - each stage of the order lifecycle needed a defined system of record and decision owner.
Consistent fulfilment rules - cancellations, split orders and unavailable inventory required predictable business logic.
End-to-end visibility - operational teams needed to understand the current state of an order and what action was required next.
Challenges
The complexity of order management was largely invisible from the customer perspective.
A customer placed a single order, but fulfilling that order required coordination across multiple systems responsible for commerce, payment, inventory, order management, warehouse operations, shipping and returns.
The standard path was relatively straightforward. Complexity increased when something changed: inventory became unavailable, payment failed, an order had to be split, a customer cancelled part of an order or a return affected several downstream systems.
The key business questions included:
Which system owns each stage of the order lifecycle?
When should inventory be checked and reserved?
What happens when availability changes after an order is placed?
Under which conditions can an order be split?
How should payment and fulfilment failures be handled?
Which exceptions can be resolved automatically?
When does an operational team need to intervene?
How should cancellations and returns propagate through connected systems?
What information do teams need to understand and resolve an order issue?
Objectives
The objective was to create a clear business model for the end-to-end order management process and translate it into actionable requirements for the future solution.
The analysis aimed to:
map the complete order lifecycle and its system dependencies
identify stakeholders and responsibilities across the process
document current workflows and exception scenarios
identify gaps, manual interventions and unclear ownership
define business rules governing key order decisions
translate business needs into functional requirements
define standard, alternative and exception flows
create a target TO-BE process
establish clear acceptance criteria for critical scenarios
Process
UNDERSTANDING THE SYSTEM
The analysis started with the order lifecycle as a business process rather than with individual screens or features.
An order moves through a network of systems and operational responsibilities. Commerce captures the transaction, payment services authorise it, inventory determines availability, order management coordinates fulfilment, warehouse systems prepare the shipment and logistics providers complete delivery.
Looking at these elements independently would have hidden many of the most important dependencies. The first step was therefore to understand how information, decisions and order states moved across the complete ecosystem.
AS-IS PROCESS ANALYSIS
The current-state analysis mapped the order journey from placement through fulfilment and delivery, including the actors, systems and decisions involved at each stage.
Particular attention was given to handovers between systems. These were the points where incomplete information, conflicting states or unclear ownership could create operational problems.
The analysis also separated the standard order flow from alternative and exception paths. This was important because many of the most significant business requirements emerged not from successful orders, but from situations where the standard process could no longer continue.
Examples included insufficient inventory, unsuccessful payment, partial fulfilment, cancellation after processing had started and returns after delivery.
FROM PROCESS GAPS TO REQUIREMENTS
WHAT WE FOUND | WHAT IT MEANT |
|---|---|
Inventory state could change during processing | Define when inventory is validated and reserved |
Exceptions required manual interpretation | Introduce explicit exception states and resolution paths |
Responsibilities crossed several systems | Define system ownership for each decision |
Alternative fulfilment created complexity | Establish consistent fulfilment rules |
Order state was distributed across systems | Provide end-to-end operational visibility |
Mapping the AS-IS process exposed where business intent was not sufficiently represented by existing system behaviour.
These gaps were translated into requirements rather than immediately into interface solutions. Each requirement was connected to a business need, process stage or identified exception.
Requirements were separated into business requirements, functional requirements and business rules to distinguish why something was needed, what the system needed to do and under which conditions a decision should be made.
REQUIREMENTS ENGINEERING
Requirements were structured around the complete order lifecycle rather than individual product features.
This helped maintain traceability between the original business problem, the relevant process step and the expected system behaviour.
Example:
BR-01 - Order state consistency
Order status must remain consistent across systems involved in fulfilment.
BR-02 - Inventory allocation
Available inventory must be validated and allocated before an order is released for fulfilment.
FR-01 - Exception identification
The system must identify when automated order processing cannot continue and assign an appropriate exception state.
FR-02 - Resolution guidance
Operational users must be able to identify the reason an order is blocked and the action required to resolve it.
FR-03 - Status propagation
Changes affecting fulfilment must be propagated to dependent systems.
BUSINESS RULES
Business rules were particularly important because many order decisions depended on conditions rather than simple linear workflows.
Instead of documenting only the happy path, the analysis defined how the system should behave when different combinations of payment, inventory, fullfilment and customer actions occurred.
Examples:
BRULE-01 - Inventory unavailable
If inventory cannot be allocated, the order must not automatically proceed to fullfilment.
BRULE-02 - Partial availability
If only part of an order can be fulfilled, the system must evaluate whether split fullfilment is permitted.
BRULE-03 - Cancellation
Cancellation eligibility depends on the current fullfilment state and whether downstream processing has already started.
BRULE-04 - Manual intervention
If an exception cannot be resolved through a defined automated path, the order must be routed to the appropriate operational team.
TO-BE PROCESS
The target process introduced clearer ownership of decisions and explicit handling of both standard and exceptional order scenarios.
Each critical decision was assigned to the appropriate system or operational role. Alternative paths were defined before implementation rather than being left for operational teams to resolve after problems occurred.
The TO-BE model also distinguished between decisions suitable for automation and situations requiring human judgement.
The objective was not to automate every possible scenario, but to ensure that the system always knew the expected next step - whether that meant continuing automatically, requesting additional information, changing the fulfilment path or involving an operational team.
VALIDATION
Requirements and business rules were reviewed through scenario-based walkthroughs rather than only as individual statements.
Each scenario was followed from its initial trigger through system decisions, alternative paths and expected outcome. This helped identify missing requirements, contradictory rules and process states without a clearly defined owner.
Validation covered both standard and exception scenarios, including:
successful order and fullfilment
payment failure
inventory unavailable after order placement
partial availability
split fulfilment
customer cancellation
fullfilment failure
return after delivery
This approach helped ensure that individual requirements worked together as a coherent end-to-end process.
TRACEABILITY
Business Need | Requirement | Rule | Scenario |
|---|---|---|---|
Reliable fullfilment | BR-02 | BRULE-01 | Stock unavailable |
Reduce manual handling | FR-01 | BRULE-04 | Processing exception |
Support partial orders | FR-03 | BRULE-02 | Partial availability |
Consistent cancellation | BR-01 | BRULE-03 | Customer cancellation |
Maintaining traceability between business needs, requirements, rules and scenarios helped keep the analysis focused on business outcomes rather than isolated system features.
Final thoughts
E-commerce order management is not a single feature. It is a chain of business decisions distributed across systems, teams and operational processes.
The project showed why understanding the complete process is essential before defining individual product requirements. Many of the most important decisions happened between systems - in ownership, state transitions, business rules and exception handling.
A reliable process is not one in which nothing goes wrong. It is one in which the expected response is clear when it does