In a world where the attention span of customers is fast reducing, the longer the response time the greater the probability of losing the customer. The customer expects their order to be updated at appropriate time and wants the know the status in minutes at least, if not seconds. In this context, organisations handling sales order in an Omni-channel order processing, face a dilemma on whether to wait and process the sales orders in batch mode to optimise the load on applications or process the orders immediately as individual orders to service the customers faster? This blog tries to unearth this mystery by searching for various factors that might affect this decision.

                                                                                                                          Pic 1 - Batch or Individual mode

What's what:

In a true Omni channel scenario, sales orders are created via various means like ecommerce web site, an app in mobile or tab, traditional order entry means, customer service team order entry, orders entered in retail stores, orders via EDI, orders created in kiosk at shopping malls etc. While order capture systems are many, there is traditionally one fulfillment application (For example, Oracle Fusion cloud). There are 2 ways of interfacing, enriching, importing and processing these orders in the fulfillment application. Let us look at a theoretical definition of the options available

• Batch mode: Interface all sales orders from various applications into one single repository. At a specified time enrich, import and process the orders as one batch by running batch processes. In order to improve the performance, static or dynamic batch (batched as per order type or order source) is used
• Individual mode: Interface, enrich, import and process every single sales order from various applications individually i.e. order by order. In order to improve the performance, multi-threading is used

Following are few of the key considerations before the Sales order interface architecture is decided

1. Order cycle:

The order life cycle can range from weeks (for example in hi-tech industry) to just a few hours (typically in retail industry). But irrespective of the industry, with the advent of digitalization, the life cycle of orders is fast decreasing. The length of the order cycle needs to be considered before the selecting the mode of order import.

Verdict: Short life cycle à Import individual sales order

2. Order volume, order clock and seasonal:

2.1 Volume: In retail industry, the volume of sales orders is quite high. For example, there are retail customers creating 10,000 to 4 Mil sales orders per day. When the volume is high, it is a general trend to choose to batch the sales orders and import them at regular frequency during the day. This will optimize the utilization of server resources.

Verdict: High volume à Chose batch mode

2.2 Order clock: Order clock is the distribution of sales order volume throughout the day. Following are certain examples

• There are certain B2B customers or retail stores where sales orders are created throughout the day but interfaced only at mid night or post office hours

 

• Field service engineers create orders in their hand held device throughout the day. But these orders are interfaced only when the handheld device is physically synced in the deport or service station in the evening when the engineers close the day

When the order clock is skewed, there will be a sudden rush of sales orders in one particular point of time in the day, while rest of the day receive normal flow of orders. At these peak volumes, individual order import may not be the best method.

Verdict: At peak loads à Chose batch mode

2.3 Seasonal orders: There are certain items which have seasonal demand and hence a sudden inflow of sales orders during a particular time of the week or month or year where individual order import may struggle.

Verdict: At seasonal loads à Chose batch mode

4. Size of the orders:

In hi-tech industry, the sales order can have one high value custom manufactured item while in retail industry, the sales order can contain a laundry list of low value items. If the sales orders with thousands of lines are imported, it may end up queuing next orders for import if the orders are imported one by one.

Verdict:  Number of lines is less  à chose individual mode

5. Individualization:

In an age where "good old" emails are being replaced with apps, chat and voice services, there is a need for considering the need for individual customer preferences. Customer needs vary from getting and update once a day to getting every single update on their sales order. Hence the choice of the customer needs to be kept in mind while decided if a sales orders can wait for batch process or not. For example, furniture retail organization will have updates sent to the customer once a week or once in few days. Such industry can choose batch process

Verdict: Less updates to customer, frequency of updates to customer is low à Chose batch mode

Apart from these parameters, the below 2 subjective parameters also play a key role in the design choice

6. Capability or the ERP:

With organisations wanting to stick to standard functionality rather than customise the application, the capability of ERP chosen becomes one of the first factors to be considered. In current release R13 of Oracle Order Management Cloud (OMC), there is no means to import the sales orders into OMC in batch mode or interfacing the sales order from OMC to EBS in batch mode. This restriction is an example of ERP's capability. The case study is explained in detail towards end of this blog.

Verdict: Pick up the option based on capacity and appetite to customise

7. IT landscape and Architecture:

This is a broad topic and mostly technical in nature, but nevertheless that needs to be factored before the sales order import is decided. It compasses the following details to name a few

• If the applications involved are on cloud or on-premises or in hybrid model?
• Are there are multiple firewalls through which the sales orders need to be interfaced for order creation and status update?
• What is the Middleware used to integrate these applications and robustness of the middle ware?
• Performance considerations and how sized are the applications and middleware
• The list of applications the order has to pass through before closure of the order. For the sales order has to pass through order entry application, order orchestration, order fulfillment system (purchasing, manufacturing and warehouse applications), transport application and invoicing application. The longer the chain the difficult it is to made the MACD (modify, add, change, delete) when sales orders are individually imported
• Technology involved. For example, ODI (Oracle Data Integrator) can be much faster causing batching to be faster when involved from middleware like SOA while individual order creation via order creation web service in Order management cloud is faster when order transformation is minimal

Case Study:

The case study belongs to an optical retail chain giant, operating globally, which offers optician services, along with eyeglasses, contact lenses and hearing aids with global turnover of £1.8 billion in 2017. Following are the summary of requirements

• The sales order volume was expected to be 1.16 million lines per day when all Business units are live in OMC
• The retails orders are imported from multiple different legacy application into Oracle Order Management Cloud (OMC) for consolidation, orchestration, and routing
• These updated sales orders are then interfaced from OMC into eBusiness Suite (EBS) OM module for fulfillment
• Order cycles are short.
  • All pick to order sales orders created before 6 PM will be shipping on same day before 10 PM (35% of overall volume)
  • Sales orders that require manufacturing have life cycle of 7 days (65% of overall volume)
• Size of the sales order varies from 500 lines (maximum number of lines for Pick, pack, ship orders) to 30 lines (manufacturing SOs)

These requirements are plotted on the below chart

Pic 3 - Business requirements in the case study

The above chart can be used as a tool for deciding. All the dots (requirements) will possibly lie in the batch or individual mode to help the decision.

Below are the subjective parameters for the client.

• Order Management Cloud, as an application, could be scaled up to import the sales order individually despite of the nature of business and volumes explained above. But the interfaced between OMC and EBS could not be managed with the standard connector provided by Oracle. Hence a custom component was suggested. Following diagram explains the standard functionality of the application (individual mode) and custom component (batch mode)

        STANDARD FUNCTIONALITY (INDIVIDUAL MODE)                     CUSTOM FUNCTIONALITY (BATCH MODE)

Pic 4 - Standard and custom connector to integrate OMC and EBS

• Client had procured SOA 12c for designing and building new interfaces and had controlled approval for customizations

Based on the requirements plotted in the above mentioned tool and subjective parameters for the client, both individual and batch model was could not be suggested as the sole design choice. Even though the average number of orders and order lines are well within the parameters to decide individual mode, the outliers in terms of order volume per day demanded a need for batch import. Hence a hybrid option was suggested for the client. The sales order will be imported in individual mode or batch mode based on order type, volume of orders at a point of time, time of the day etc.

While there is no standard formula, the details given in this blog helps the architects to nail the right approach for each customer and in fact each sales orders in particular.