Welcome to article two of Jeopardy Management feature for the Vancouver release. We will deep dive into the design time activities required to enable jeopardy management workflow run time logic to work properly.
The hardest lift for enabling the feature is the upfront design work that goes into updating existing sub flows to use the new five out of the box jeopardy workflow actions.
There are two design scenarios for the service provider to enable jeopardy management to work at run time for their customer order fulfillment and orchestration.
- For existing sub-flows pre- Vancouver release
- For new sub-flows designed in or after the Vancouver release
Because the service provider may have many existing product offerings delivered by designed NEW/MACD (Move, Add, Changed, Disconnect) fulfillment plans, the service provider will probably not initially go through the labor of redesigning existing sub-flows to leverage the jeopardy management feature as soon as released in Vancouver OMT.
The service provider must decide what plans will benefit most from using the feature in the immediacy based on factors such as:
- What order types (order actions) for product offerings for categories of lines of businesses that have fulfillment contracts that are legal commitments that historically, we have had challenges in fulfilling customer orders on time and have been accessed penalties.
- We have identified a high percentage of order re-prioritization of orders and escalations due to untimely fulfillment of orders.
- We have identified a percentage of fulfillment plans that we believe need to be optimized because we see a correlation between untimely delivery of orders and those order fulfillment workflows, and need to enable jeopardy management to obtain jeopardy data on what order tasks are exceeding task SLAs, or trending more into higher levels of jeopardy/risk and cause fulfillment fallouts.
- Based on the number of customer complaints of untimely delivery, our brand is suffering, and we need customer order fulfillment risk and resolution proactively to enable us to anticipate potential risk to raise the level of customer satisfaction
- Order to cash revenue lost for certain types of products are due to non-timely order fulfillment, missed delivery commitment and completion dates that has cost us customer sales – lost customers!
- We have order to cash revenue KPIs and need proactive customer order jeopardy management as one of our risk tools to ensure we get to billing and capturing revenue on time.
- Our customer satisfaction survey results indicate we have a “brand” issue specific to order fulfillment delivery date commitments.
For new product launches - product managers may have mandated that all new product launches require jeopardy risk and mitigation enablement as a best practice criterion for all new product offerings launched. It is less labor to configure jeopardy management workflow and decision tables upfront in the fulfillment flows before product is launched, then having to redesign the active fulfillment flows afterwards and play catchup!
Jeopardy Management enablement – design time
For Jeopardy management logic to execute at run time, we need to introduce the idea of order tasks as “planned tasks”.
Similar to creating within a project plan, planned tasks, jeopardy management workflow at design time needs to capture up front - planned tasks, the duration of planned tasks, the relationship and sequence of planned tasks, task dependencies, and calculate based on task durations and plan task start and end dates, total time to complete the tasks during fulfillment.
That is why we have reparented and extended order task from planned task - with the introduction of OMT jeopardy features, CSM order task now extends from planned task, which extends from base task, which makes OMT order task extend from planned task,
We can now use project plan capabilities for jeopardy logic in OMT - Order task will receive date fields and date fields’ roll up logic that come with planned task and order task will now be able to take advantage of planned task relationship, which establishes relationship between two planned task records!
Another similarity to configuring a project plan, in jeopardy management decision table, we assign task SLAs to planned tasks.
As the plan changes due to task duration delays, the start and end dates shift accordingly – date rollup. I won’t dive into an PPM tutorial – see “Basics of PPM” Basics of Project Management (servicenow.com)
In summary, jeopardy management acts like a shadow project flow and needs to be aware of sub flow actions, conditions, and flow stages to be able to execute its jeopardy workflow logic at run time, OMT knowing what order tasks upfront as planned tasks enables jeopardy management logic to baseline the plan start and end dates, estimate the total duration to fulfill the customer order, asses risk impacts to the customer fulfillment delivery commitment as promised or estimated, and roll up (shift) plan end dates.
Flow Designer flows and Jeopardy Management logic
The following flow designer flows and sub flows are introduced as part of TMT Order Management (sn_ind_tmt_orm) plugin:
[Flow] Populate Baseline Dates for Jeopardy Orders – This flow is triggered after order tasks have been created by fulfillment sub flows and planned dates have completed roll up process. The flow triggers subsequent sub flow, which populates estimated (expected) date fields for order line item, domain order, and order task tables.
[Subflow] Populate Expected Start and End Dates for Jeopardy – This sub flow is called from Populate Baseline Dates for Jeopardy Orders flow, as well as after staggered decomposition is triggered.
For OMT Vancouver release - The following demo fulfillment sub flows are introduced as part of TMT Order Management (sn_ind_tmt_orm) plugin that use the new jeopardy management five OOB workflow actions as example workflows to help the user understand how the actions can be applied:
- Ethernet Edge Device Fulfillment
- Ethernet Modem Fulfillment
- Change Ethernet Edge Device
- Disconnect Ethernet Edge Device
- Disconnect Ethernet Modem
- Network Interface Profile Fulfillment
- Change Network Interface Profile
- Disconnect Network Interface Profile
- EVC Configuration Fulfillment
- Disconnect EVC Configuration Service
Deep Dive - jeopardy management OOB workflow actions
Before we deep dive into the jeopardy management design time work, let’s summarize the work required.
E2E Design Use case - configure jeopardy business logic and workflow:
As a customer admin, in order to use jeopardy management at runtime for customer orders created in OMT, I need the ability to easily configure, fulfillment sub-flows with jeopardy workflow actions and logic that will execute at order runtime.
Summary of design time steps
The example below illustrates how the new OOB jeopardy actions are introduced into a new order (order action = new) Ethernet Edge Device Fulfillment sub flow:
Example depicting how new jeopardy flow actions relate to a sub flow.
Here is how it looks in Flow designer for a new sub flow created – New Ethernet Edge device.
Create planned task – Order tasks reparented to extend from Planned Task
Ethernet Edge Device fulfillment sub flow with jeopardy workflow actions designed in.
All Placeholder Tasks Created for Domain Order – This action updates stage on domain order, indicating that all order tasks for this domain order have been created through sub flow. The use case for this is that user can now use Set Task Relationship to create inter-sub flow order task relationship with current flow order tasks.
All Placeholder Tasks Created for Domain Order jeopardy workflow action.
Set Task Relationship action - This action sets a relationship between two order tasks by creating a record in the planned_task_rel_planned_task table. This action can only create one relationship at a time, so if user wishes to create 1: N relationships for order tasks, they'll have to invoke this action multiple times. This should ideally be used for creating relationships for tasks in different sub flows.
Set Task Relationship jeopardy workflow action.
All Relationship Created for Domain Order action - This action marks on domain order level that all order task relationships have been set. What this means is order task dates roll up logic will stop for the first round (which is for creation). This indicates user can create records in planned task baseline (aka getting a snapshot of domain order's initial start end dates)
All Relationship Created for Domain Order jeopardy workflow action.
Set Order Task State action – Prior to jeopardy management, we already have this logic in place, the idea being that once an order is approved, user should know which domain order to start with (being marked as in progress). Then as they set off to complete tasks, the moment one becomes closed complete, the next one in sequence (indicated by flow, this is something user manually defines) becomes in progress.
This same logic is used in jeopardy sub flows. What's new is that the state change for tasks now have new purpose. When a task moves to in progress, it kicks off task SLA. This is also used to kick off actual start time, which in turns affect subsequent tasks' planned start and end dates.
When tasks become closed complete, it terminates the task SLA, but also sets actual end date (which again, affects planned dates of the entire hierarchy). Additionally, when it becomes on hold/scheduled, it pauses/restarts task SLA.
Compare the new flow actions against an existing SD-WAN sub flow that does not have the new jeopardy workflow actions added to fulfillment plan:
SD-WAN Edge Device fulfillment sub flow - without new OOB jeopardy workflow actions
For more information on creating sub flow for specification, fulfillment (order lines), please start with these reference documents:
Flow Designer (servicenow.com)
Configuring order fulfillment in Order Management (servicenow.com)
Create a flow (servicenow.com)
Jeopardy management decision tables
Use case - End to end jeopardy workflow logic design time work summary.
As an admin, I need to be able to configure at design time jeopardy management logic decisions as business rules that will apply at runtime to enable jeopardy management order line-item specifications.
Decision Tables – contains information such as order task duration, jeopardy level assignment, and jeopardy enablement. Decision tables are used for the following purposes:
- Determining if an order, upon creation, is subscribed to jeopardy management logics, if any specification contained within the order is not subscribed to jeopardy logic as determined by decision table, then order will not be subscribed to jeopardy logic and jeopardy related date fields will not be populated in order forms.
- Determining the planned duration of order tasks when they are first created by fulfillment sub flow.
- Determining the conditions for jeopardy logic actions to apply to such as – order task and order line-item SLA progression threshold settings, and the conditions that determine Jeopardy level/risk level assignments for order tasks and order line items.
Summary pf Design steps and activities
I also need to do the following jeopardy management design time work:
- SLA Definitions – tracks how much time each type of order task will take.
- SLA Processing Flow (if not using OOB flow) – details when jeopardy level calculation should occur for each order task.
Use case – Configure order task expected duration.
As an administrator, I want to be able to define the expected duration of a task OMT at runtime that OMT will associate with Task SLA duration.
Note:
- Value assigned to output column of this decision table should be in decimal hour format, i.e., 24 corresponds to 24 hours, 0.5 corresponds to 30 minutes.
- This table can be configured with additional input conditions such as
- Planned duration assigned in this decision table must match the ones defined in SLA definition and yes, it’s painful having to input duration as a decimal tick! Currently order task duration decision table uses decimal data type for its result column. In future we will change the column row input to use duration data type.
Order Task Duration Assignment decision table
Note: This table can be configured with additional conditions to match and targeted to results
Use case - Configure Task SLA Definition
As an administrator, I want to be able to define and assign an SLA task definition that will be associated and matched with an order task duration definition to configure the conditions required to start task SLA monitoring and enable jeopardy logic to execute at runtime (after OLI decomposition is complete).
Find the SLA definition configured for the order task, or click on new to create an SLA definition:
List of Task SLAs - select or create new definition.
Verify that the Task SLA duration matches with the task duration of the order task:
Note: best practice tips and constraints:
- Proper start condition, pause condition, cancel condition, and reset condition should be specified by customer per use case.
- Only default schedule is supported, which is 24x7.
- Duration should be specified so proper tracking can be achieved when task SLA is created.
- Duration specified in SLA definition should match the one created in decision table.
- Service provider can use OOB flow, which triggers jeopardy level calculation for order tasks at 50%, 75%, 100% task SLA progression.
- Customer can duplicate this flow to customize it, or create new flows control timing for order task jeopardy level calculation and other behaviors.
Configure and view SLA Definition
Order Task Assignment Duration value against Task SLA duration value - verify values match!
Use case - Configure order task jeopardy calculation level decision conditions.
As an administrator, I want to be able to define a business requirement for the % of progression duration time that a task can stay in a state other than terminal state that corresponds to a specific jeopardy level so that task delay risk impact can be assessed, captured and viewed so fulfillment stakeholders to view and proactively assess, capture and report on the OLI risk level and then execute risk mitigation actions.
Notes:
- Service provider can use OOB jeopardy workflow flow, which triggers jeopardy level calculation for order tasks at 50%, 75%, 100% task SLA progression.
- Customer can duplicate this flow to customize it, or create new flows control timing for order task jeopardy level calculation and other behaviors.
Order Task Jeopardy level calculation decision table
Example of a configured Task jeopardy runtime SLA progression duration threshold crossing triggered that triggers assignment of risk:
Use case - Configure order line jeopardy level decision table conditions.
As an administrator, I want to be able to define a business requirement to calculate the delay percentage threshold for a top order line item that will correspond to a specific jeopardy level per OLI specification.
This will allow fulfillment stakeholders to view and proactively assess, capture, and report on the OLI risk level and then execute risk mitigation actions.
Order Line-Item Jeopardy Level calculation decision table
Note:
- Service provider can add addition condition columns per BR requirements.
- Different threshold % increments can be configured per specification (OOB) and extended to meet additional OLI attribute value conditions (customization)
Top Order Line-Item Jeopardy Level Calculation Policy decision table
Run time usage example for configured OLI Jeopardy Level calculation.
Use Case - Configure order jeopardy enablement policy.
As an order management system administrator, I want to configure what product/service/resource specifications will have jeopardy enabled as requested by product managers or other product line of business stakeholders.
Order Jeopardy Enablement Policy Decision table
Note:
- Backward compatibility: specifications created in previous releases of OMT will stay intact and will not be jeopardy enabled if set to false.
- Specifications which have flow designer flows created with jeopardy flow actions will be subject to jeopardy logic when order decomposed.
- All specifications realized in an order as an order line item must be configured in the table as “true” for enablement. If any of the specifications that are part of the order are not configured, then Jeopardy enablement will not be applied to the customer order.
Order Jeopardy Enablement decision table
The following diagram describes how the design time decision table conditions configured; enables execution of run time jeopardy workflow logic:
This concludes article two – Jeopardy Management Feature Enablement - design time configurations, considerations and best practices.
As TMT product management obtains usage feedback from solution consultants, partners, and customers as to what customer outcomes the feature solves for, we will have future articles to share from the customer and SI/partner perspective to discuss in future (shorter) articles to learn from.
Reference material – Design time Troubleshooting Guide
Customer order's jeopardy_management field value is not expected.
Reference material - SN Jeopardy Management Feature doc:
Configuring Jeopardy Management (servicenow.com)
Scripts introduced.
The following scripts are introduced as part of TMT Order Management (sn_ind_tmt_orm) plugin:
Script includes
- JeopardyMgmtUtilOOB
- JeopardyMgmtUtil
- postEngineHandlersExtension
- Script action
- Calculate order task jeopardy level
JeopardyMgmtUtilOOB
This script include contains logic that control jeopardy dates roll up logic and jeopardy level roll up logic. These logics are called from business rules and flow actions. Functions included in this script can handle:
- Expected dates roll up
- Planned dates roll up
- Jeopardy level determination logic
- Jeopardy level retrieval logic
Customer can override the above functions in the file sn_ind_tmt_orm.JeopardyMgmtUtil script.
postEngineHandlersExtension
-
This script implements extension point for global.postEngineHandlersExtension, which is an extension point for PostEngineHandlers. Inside this script, the process function is triggered after rolling up logic for order task and domain order planned dates is completed once (i.e. each time a new order task is created).
-
This script cannot be changed; however, customer can add additional steps after each round of roll up logic by creating their own extension point in global.PostEngineHandlers
Reference material - Jeopardy Feature Design Flow Actions functions introduced in Vancouver.
The following flow designer actions are introduced as part of TMT Order Management (sn_ind_tmt_orm) plugin:
- Create Order Planned Task
- Set Task Relationship
- All Relationships Created for Domain Order
- All Placeholder Tasks Created for Domain Order
- Update jeopardy level by CDD
- Set Order Task State
- Update OLI expected dates.
- Reset planned start date.
- Create event for order task jeopardy calculation.
Reference material - ACL and Roles
- Read access for Task SLA table (task_sla) granted to:
- sn_ind_tmt_orm.service_order_agent
- sn_ind_tmt_orm.order_fulfilment_agent
- Adding sn_sla_definition_read role to existing order agent personas, granting read access for SLA Definition (contract_sla) table:
- sn_ind_tmt_orm.service_order_agent
- sn_ind_tmt_orm.order_fulfilment_agent
- Restricting edit access of OMT Date fields to admin only through ACL
Reference material - new business rules introduced.
The following business rules are introduced as part of TMT Order Management (sn_ind_tmt_orm) plugin:
- Populate order task duration.
- Reset jeopardy on order task closure.
- Update decomposition status for OLI
- Capture baseline for staggered use case
- Update jeopardy on domain order
- Update customer order planned dates.
- Update jeopardy on customer order
- Update jeopardy on order line item
- Jeopardy Management Rule
- Update OLI actual end date
- Update OLI actual start date
- Validate OLI committed due date.
