Why Oracle ORPOS, ATG, and Siebel Need to Merge?
Granted, it is a provocative headline and I could already visualize question marks being raised on the headline itself of this blog. However, it is time we take a fresh look at good old point of sale (POS) application that has perhaps had its golden run for over 20+ years in its various incarnations by multitude of app developers.
Customer Touch Points:
Though commonly known as cash register to a layman at the checkout counter of a retail store, POS is the only retail applications that a customer comes face-to-face and store sales associate use to ring up a sale, or perform a sale transaction in a technical sense. For the uninitiated, in addition to a performing sale POS also helps perform returns at the customer service counter, and few additional things in terms of beginning of day and end of day processes such as opening the register for the day, totaling the sale at the end of the day/shift, and pass on all transactional information to corporate systems for additional processing and reporting. Therefore, POS is the only retail store application that provides a customer touch point. Similarly CRM applications that power retail sales performed through a call center (Siebel) or web store application that power online sale (ATG) provide the touch points for the end customers.
If these applications and associated channels they help power were to remain separate and islands in themselves, there won't be any need to look at them through a single lens. However, in the last 5 years, especially for brick-and-mortar retailers who have gradually moved into multi-channel world, the processes cutting across the channels not only just intersect but do it in such a way that systems for capturing customer sales order and fulfilling them need much more holistic solutions.
Today click n' collect is becoming extremely popular more so with increasing use of smart phones whereby the customer places an order online and collects the merchandise at a store. In this scenario customer could fully pay at the time picking up the merchandise at the store, or partly pay at the time of order and the rest at the store, or as a third alternative fully at the time of the order. Therefore, in effect two systems - online (e.g. ATG from Oracle) and retail POS (e.g. ORPOS from Oracle) - could end up processing and tendering customer orders, which in the isolated world would have been done only by respective applications. Though from the customer's perspective it is great, which is what is should be, from the system's perspective it is becoming challenging. Let us look at how seemingly simple scenario of click n' collect is doing to the systems:
- Now the online system not only needs to capture the customer order, it also needs to let the store system know that the order needs to be filled.
- Store systems, which POS is part of, needs to understand and fill a customer order sent by completely different system. Though rudimentary customer order taking feature has been available in a packaged application like ORPOS, handshake with other order taking system like ATG is not there and will have to be added.
- When ORPOS fills the order, the store system also needs to loop back to online system to update its status that the order has been filled. Again this is another handshake that in the current scenario will have to be a custom interface solution.
- If this is not enough, somewhat bigger challenge is financially accounting two different transactions from two different systems to figure out total sale amount realized from the customer order, reducing the inventory, and margins made. Typically one transaction from POS would be funneled and audited through the sales audit system (e.g. Oracle ReSA). Now ReSA will have to reconcile multiple transactions from two dissimilar systems to realize income, and inventory updates, which could again require customization to existing package.
- We could add more complexity to this scenario, e.g. multiple fulfillments against one customer order, and one could visualize how difficult it would make financial accounting of the sale.
- I have not even talked about various fulfillment scenarios that could make the entire process even more complex. For example, a retailer might decide to fulfill all customer order from the warehouse instead of from the store where it is being picked up.
- Another complex scenario is when a customer order is part merchandise sale and part future income e.g. when a telecom provider sells a mobile phone device - a merchandise sale - that also includes a calling plan with monthly invoicing - a future income.
Simpler Systems:
If we had one system that could perform store sale similar to POS as well as handle online and call center orders from customers, our task will be that much simpler as all tendering and sale transaction will be performed with the same system with no necessity to reconcile multiple transactions from multiple systems. Fulfillment and financial accounting will be that much simpler to handle from the system's perspective.
Therefore from Oracle's perspective if ATG, Siebel, and ORPOS were to merge into a single customer sale/order system this could lead to much simpler system than building custom interfaces and providing custom bolt-on solutions for each retailer to achieve the above objectives.
