Fallout management Summary
To remain competitive, increase brand recognition and delight the customer, service providers must ensure when fulfilling a customer order, due date commitments are meet. Because a customer order fulfillment orchestration process may transition through multiple stages and be dependent on external systems and or fulfillment personal assigned to complete fulfillment task assignments, the possibility exists that at some point order tasks may experience a blocking issue, which potentially may impact timely delivery of the customer's order if the issue is not unblocked as soon as possible.
The OMT fallout management feature provides the ability for a fulfillment manager or agent to quickly create an order task fallout against the blocked order task. The order fallout created is routed to a fallout manager to resolve so that the customer fulfillment journey can continue to successful order delivery on time.
Manual or automated fallout creation:
The service provider may leverage the OMT jeopardy management feature to proactively identify that an order task is trending to a level of jeopardy that may potentially impact the customer’s expected or committed order fulfillment due date [if jeopardy management feature is enabled for an order specification]. Upon investigation, it is identified that an issue exists that prevents the order task from being completed within its planned task duration. The fulfillment manager or agent would then create a fallout issue, which then automatically routes the issue to a fallout manager to be resolved.
The fallout management process can be an action within in an automated order fulfillment process, a "create fallout" action is available to insert in a specification sub flow. if the fallout management process is part of the designed fulfillment flow.
An example is an external order fulfillment task completion request to be completed by an external application, and the application returns a processing error, a "create fallout" action is then triggered, which automatically creates a fallout issue against the order task, which is then automatically routed to a fallout manager's work queue for resolution. Note – fallout management as an automated process using the fallout action, and logic must be designed within the sub flow and is not an OOB capability of the feature. But we have created a flow snippet as an example in the article at the end to look at.
Why fallout of an order task may occur:
- Missing data - issue has prevented an order task from progressing such as an order task that requires an actor that is assigned a task is not available or has information that is not complete or understandable. Such as an OMT initiated work order that contains installation notes is not complete in instructions as to how to configure, install and test an CPE to be installed.
- A bad fulfillment flow process design that misses a process step and causes order task state progression to fail.
- Data integrity issue – incompatible resource state – product inventory for install based, incompatible for change order, or for a design and assig order task process – reserve, and assign resource is not available due to inventory update has not been maintained.
- Jeopardy management – Potential fallout issue may be noticed by OMT jeopardy management which proactively identifies a of a customer order is in risk of not be completed by the customer's due date. It may be leveraged as an early indication of potential jeopardy, which may be an indication that an order fulfillment order task has an issue in completing on time [its planned duration]. It’s a one-two punch! Vancouver release offers jeopardy management as a proactive indication that something is delaying completion of a fulfillment task on time, and fallout management, pre-Vancouver provides the means to create, assign and resolve the issue that delays an order task within the order from completing.
- A resource [actor] that the fulfillment manager requires to complete a task is not available and a fallout may be initiated that requires the fallout manager to track the person down – he is on an extended “coffee break” – very extended coffee break!
The idea here is that something in the fulfillment process has blocked, created an issue that must be corrected so the order task can be completed.
OMT Fallout Management roles capability roles
- sn_fallout_mgmt.fallout_manager
Capability: Can create, view, assign, edit fallout record
- Sn_fallout_mgmt.fallout_agent
Capability: Can view and update state of fallouts
- sn_fallout_mgmt.fallout_manager
Capability: Can create, view, assign, edit fallout record
- sn_fallout.mgmt.fallout_creator
Capability: Can create fallouts
- Sn_fallout_mgmt.fallout.viewer
Capability: Can view fallout and update state of fallout
Use case – create a fallout type:
As an admin, I need to create fallout types for specified order task or tasks created in this case SD-WAN fulfillment sub-flow so that a fulfillment agent can select a fallout type to create an order task fallout condition.
The use case is to create one or more fallout types with description of the type of issue that needs to be resolved. For example, "Initiate CPE delivery" order task within the SD-WAN Premium offering may have several different issues that could occur. CPE is not in stock, wrong shipping label address, etc. Or if it's an automated external call to a procurement and shipping application - an application processing issue. An order task may one of more fallout types that the fulfillment manager or agent can apply as a fallout issues. Or may just make it simple and not complicate things for the fulfillment manager/agent to scroll through ten different fallout issue fall types for the order task and have a catch all -"Initiate CPE delivery issue" or a specific fall out type may be created by the admin such as "CPE is not in stock". The fulfillment manager, or agent can add context on the issues in the fallout notes in any case. It's up to the fulfillment manager or agent to select the appropriate and correct fallout type.
The admin uses a cheat sheet list of order tasks which comprises an SD-WAN order fulfillment flow to select the order task name within the SD-WAN Service fulfillment plan - “Initiate CPE delivery" order task for example to create a fallout type. The admin can create as many fallout types as required to allow the fulfillment agent to select based on fall out issue encountered.
|
Project |
Product order = Project task |
Service order = project task |
Resource order= project task |
Order Task name |
Project Task Name |
Total Project Tasks |
|
SD-WAN service package |
SD-WAN service package |
|
|
Perform order validation |
Perform order validation |
|
|
|
|
|
|
LLD creation |
LLD creation |
|
|
|
|
|
|
Reserve resource |
Reserve resource |
|
|
|
|
|
|
LLD Signoff |
LLD Signoff |
|
|
|
|
|
|
Perform Test and Turn up |
Perform Test and Turn up |
|
|
|
|
|
|
Complete SD-WAN delivery |
Complete SD-WAN delivery |
1 parent, 6 child project tasks |
|
|
SD-WAN Edge device |
|
|
Prepare and Build CPE configuration |
Prepare and Build CPE configuration |
|
|
|
|
|
|
Allocate and assign CPE |
Allocate and assign CPE |
|
|
|
|
|
|
Initiate CPE delivery |
Initiate CPE delivery |
1 parent, 3 child tasks |
|
|
|
|
|
|
|
|
|
|
|
SD-WAN Optimization service |
|
Configure optimization |
Configure optimization |
|
|
|
|
|
Service Design for optimization |
Service Design for optimization |
1 parent, 2 child project tasks |
|
|
|
|
|
FEC |
Configure FEC |
Configure FEC |
1 parent, 1 child project tasks |
|
|
|
SD-WAN Routing service |
|
Configure routing |
Configure routing |
|
|
|
|
|
Service design for routing |
Service design for routing |
1 parent, 2 child tasks |
The admin creates a Fallout type for “Initiate CPE delivery” order task – describing the task and comes up with a fallout name to use.
A new fallout type has been created when submit is clicked. Because I did not like the name I initially created, I've renamed the fallout type to have issue as part of the name. Since of course, it's an issue to be addressed! updated the fallout record and alter the name:
The fallout type will be available from a drop-down list when the fulfillment agent needs to create a fallout for “initiate CPE delivery” order task.
Creating a fallout for an order task:
As a fulfillment agent, I’ve been working order task assignments for a customer order for SD-WAN premium offering. A order task assigned to me is “initiate CPE delivery. As part of the activity steps to complete the task, I need to contact a shipper to have a ship to label created and the warehouse to procure the CPE for a customer order for SD-WAN offering from the CPE fulfillment warehouse and have the warehouse create a ship to label.
The warehouse contacted me and responded to my request that that the CPE in stock status was wrong, and the CPE is not available for shipment.
I need to create a fallout record for the order task as I am unable to complete the task without manual intervention and assistance.
Orchestration view of SD-WAN order fulfillment tasks:
Step one - Create fallout record against Initiate CPE delivery order task. Note - the order task must be in the "in progress" state to create a fallout against it!
Step two - select the appropriate fallout type. The agent in this case, decides that there are multiple issues and not a fallout type that covers those. Therefore, the agent has elected to pick the "catch all" fallout type and explain more in the fallout work notes.
Step three - fill in as a best practice as much information as possible to provide the fallout manager actionable data to use to resolve the issue blocking completion of task. Fallout record state is “open”.
Fallout information viewed:
- Fallout number
- Fallout type
- Short description
- order task originated from
- fallout context
- fallout agent assigned (this is optional), if assignment not made, the fallout record will route to the fallout manager to assign a fallout agent to resolve the task. The fulfillment agent used a drop down and found an agent to assign it to. It's his favorite agent and he knows Andre Johnson will handle this issue promptly as he has experience for this type of issue in the past!
The order task when viewed shows a fallout has been created. OMT automatically updates the order task state to “on hold”.
When viewing the customer order, the fulfillment manager who oversees the agent's work sees that there is a fallout that exist for the order!
View one:
View two:
Fulfillment agent Andre Jonhson sees in his landing page the fallout issue assignment:
Andre starts working the fallout task to resolve as quickly as possible:
Ken – the fulfillment manager sees in OMT for the customer order that Andre – true to his skills and responsiveness has quickly resolved the issue. Note Andres posts work notes back to Ken in the fallout record.
Back on the order task – see that it went from “hold” state, and OMT automatically puts it back in progress, so that Ken can complete the order task to "closed complete".
This completes manual fallout process.
Now, we all are aware that many service providers also have automated orchestration for fulfillment of orders where the service provider’s order to cash eco-system may have OMT integrated with other applications working together from an end to end zero touch, or hybrid – manual and automated fulfillment – to orchestrate the delivery and fulfillment of the customer order from order capture to billing as instantly or quickly as possible with minimum manual intervention.
Flow designer fallout action and logic - for automated creation of a fallout record:
In such a scenario, the fallout process will be designed within the fulfillment sub flow. Let’s say in this example scenario:
Use case:
As a flow designer, I have a requirement to design within the SD-WAN fulfillment sub-flow a flow action to have the fulfillment orchestration flow for to make an external HTTP request [POST] to an external warehouse application. The REST POST will have a payload that instructs the warehouse application to a) get the CPE model and b) generate a shipping label.
I need to account for error conditions that may occur and have an action in my sub-flow to create a fallout record to be generated.
In this flow designer snippet, the flow designer has created after the “Create Order Task – create initiate CPE Delivery task:
- REST call to an external system.
- logic to handle if an error happens – in this example, if the response from the REST POST operation is a 404 error - The server cannot find the requested resource.
- creates a fallout record.
- the “Create Fallout has:
- Fallout Type – that was created by the admin which is selected in the Fallout Type drop down.
- And the Fallout Context – “Request shipping label and CPE from Warehouse”
- The logic then waits for the fallout to be closed by the fallout manager.
Request REST call
Error logic
Fallout action
Fallout action content
flow diagram view of flow snippet.
Hope this has been a fun article – and you find it gives a better appreciation of this vital OMT feature that enables additional capability for the service provider to ensure that the order to cash flow completes on time and provides delight to their customer by meeting the expected committed due date, as well as enabling cash flow to quickly be captured!
References:
Monitoring Jeopardy Management
