This third blog of my Go-Live learnings series will focus on Business Anomalies. The objective of this blog is to explain business anomaly management that’s modelled in a solution which can become a big hurdle during Go-Live. Like any IT application, Sterling OMS also cannot be designed to completely handle all possible business scenarios because of:
1. Non-standardized operational procedures across multiple business divisions (example: approvals, tolerance handling)
2. Inconsistent exceptional workflows designed or built differently in the IT applications ecosystem.
3. Random and unexpected external or internal factors affecting the supply chain causing many transaction outliers in the system which need a
unique resolution for each case.
All the above factors inject business anomalies at various stages during an entity (order, shipment, etc.) life cycle.
The anomaly occurrences and their related impacts get amplified during the Go-Live phase due to a new paradigm shift in handling the IT workflows and business operations. This is illustrated in the five scenarios described below:
- A shopper identified by CRM as a high-profile loyal customer was refunded upfront upon placing a return order before the product was physically returned to the fulfillment center. (In normal situations, upon physical receipt, post quality control team tagging an appropriate disposition code, refund requests are initiated). On receiving a refund, the shopper intends to keep the product and not return it anymore. This implies a charge back is initiated to reverse the refund transaction. But what will happen if the customer’s credit card has expired, he is not reachable, etc.? OMS can support such a refund without receipt transactions, but the application cannot reverse the financial loss.
- A shopper used a lost/stolen gift card as a payment option to place an The Sterling OMS application will treat this like any other gift card if it is valid (within expiration date) and has sufficient funds to cover the order amount. After shipping the product, business eventually learns that the gift card was stolen and hence is blacklisted. In this situation, OMS will allow the customer service representative to contact the related customer for returning the product but can’t do anything about the financial loss.
- For the transaction of a high value item, a business would not like to exhaust a customer’s credit-card limit to protect the interest of the customer. Say, home theatre system costing $2K is purchased by a customer and their credit card is authorized for the cost On receiving a damaged product, the customer wants to return and exchange the same item, however the refund will take three business days. But now, the business decides not to authorize another $2K on credit card because of reaching the credit limit. Hence, they decideto ship the fresh item without waiting for the original damaged product to come back. Now, if the customer doesn’t return the product, the business will incur a financial loss on such a transaction. OMS does facilitate business needs to handle such uncommon return-exchange scenarios, but it cannot stop the financial losses.
- Quite often, business analysts draw a set of requirements which appear like a chicken and egg situation. This puts the transaction workflow in the application at jeopardy. For example, holding an order for fulfilment as the payment has not been completely received, but reserving the inventory fully to honor FIFO needs. Now, say the next order in queue is paid for completely but is sitting in backorder waiting for the inventory unit to arrive. Business deliberation is pushing OMS at stake from an inventory allocation perspective.
- Under/Over utilized resource personnel to illustrate is when personnel at store A are having lot of tasks which is causing fulfilment delays and negative customer experience While personnel at Store B are idle with no work resulting in unproductive business hours. Sterling OMS is forced to consume Store A’s inventory due to sourcing constraints while the operational analytics has provided business a view that fulfilling from Store B is expensive in the situation.
Having understood the anomaly scenarios above, we can look further on how such anomalies creep into the Infrastructure layer pushing applications to jeopardize data exchange.
Upstream Impact - This is always linked to bad data received by OMS which has a recurring impact throughout the order life cycle. Often, this is handled through the interface contracts driving the grammar of data type, length, mandatory and optional fields. However, there are situations which bypass these criteria’s and data attributes are received incorrectly. This requires an honest customizedvalidation on an individual case basis without which jeopardy would be written on the wall.
Downstream Impact - With Sterling OMS’s playing the role of the primary orchestrator, transactions published downstream are incorrectly published or lost due to technical issues in middleware and incorrect runtime attributes set because of upstream corrupt data. This scenario needs to be managed through OMS by resending the failed messages, but this is tricky because the transaction workflow would have already triggered the next set of jobs, processes in the workflow. This implies systems are out of sync giving enough opportunities for anomalies to magnify.
To conclude, there is no single resolution to resolve such jeopardies in an application during business anomalies. And considering, one jeopardized application easily impacts other applications, an early anomaly detection coupled with an agreed resolution on variants with stake holders is imperative without which an entire solution will become handicapped including the OMS application.
Stay tuned for my final blog to learn about other technical areas during Go-Live. Links to previous edition: