For communication service providers, order fulfilment is at the heart of the business. Customer expectations are extremely high and service providers need to fulfil orders quickly and with the highest degree of accuracy.
Today’s consumers and businesses alike want the ability to turn on new digital services instantly from any device, on any platform, over the phone or online with as little friction as possible.
So why haven’t CSPs been able to give their customers the agility and service excellence they desire when it comes to fulfilling orders? Why is order fallout, especially for new products, so high? Why is it still so costly and time-consuming for IT to support the order automation of new products?
The problem lies in a fundamentally flawed approach to order management. Legacy order management systems prevent service providers from quickly delivering new products, drive up costs with inefficient integration and contribute to high levels of order fallout.
A Bottleneck for Launching New Products
All order management software vendors would claim today that they are catalog-driven. But for many vendors this means embedding a product catalog uniquely architected to work only within their order management system. This means that when the CSP describes a new product in the central product catalog they then have to swivel chair over to the embedded catalog and add the new product all over again, often in a very different format – always with very different tools. This “waterfall” approach to order management is costly, time-consuming and is error-prone even for making minor changes to existing product specifications.
Another approach we see with legacy order management is to have the system pull data from disparate systems. While a better approach than a manually updated embedded product catalog, this approach assumes data across repositories is pre-synced. To handle the synchronisation, dedicated teams are put in place to handle synchronisation and de-bugging of the data across multiple systems. Any change to product rules and constraints has to be updated by these teams to suit each systems’ unique needs.
What do both of these approaches have in common? In both models each business unit keeps its products, rules and restrictions living in a separate silo. This creates an information disconnect that makes launching new products a long, labor-intensive process.
Separate order and product catalogs
Order decomposition today is usually handled by a legacy order management system interacting with its embedded catalog. Because order capture may have been done using the product specification found in the central catalog, it may not link directly with the embedded order management catalog. These separate catalog definitions run inefficiently and result a very costly form of order fallout.
Inefficient FULFILMENT workflows
Order management systems all come with some process or workflow design tool. This tool is used to model all of the steps needed to process a given order. Over time these business processes become more and more complex as more steps are added. So what happens at run-time? When an order enters the order management system the unwieldy process is invoked and begins to perform order tasks. While many of the tasks are not required at run-time – there is no intelligence applied to analyse each incoming order, and optimise the process to the specific order requirements. The result for operators is extra tasks being performed that may not need to be executed at all.
A truly catalog-driven approach for order management
In order to take full advantage of a centrally deployed product catalog, CSPs need to pay careful attention to the APIs needed to interact with the catalog during run-time operations. A real-time catalog-driven architecture provides a rich set of interfaces to select up-to-date products, apply product rules & constraints and decompose a product order efficiently. The software must be highly performant and be available to service the transaction volume.
With real-time catalog APIs allowing unfettered access to product, service and resource specifications many of these problems are eliminated. There is no need to manually clone the master product data or to convert it into a format the target system can understand. Instead, the order management system has its own embedded version of the central product catalog that it can query at run-time to perform product decomposition.
In an advanced catalog-driven order management system what you model at design time is what you fulfil at runtime. Whatever you put in your catalog, you will be able to fulfil and realise. Breaking down orders into actionable items is much easier because it is all feeding off the master data management.
End to End visualizations
With an integrated master product catalog, CSPs can rapidly model new products, change existing products and validate the end-to-end configurations at design time, prior to deploying the run-time environment. Event-based modelling shows every step of the customer experience throughout the order. With a real-time catalog-driven order management system, CSPs are able to do real time validation of orders against the catalog during run-time and test it before it goes out in design-time.
Automation and In-Flight Changes
The end result is a modern architecture allowing product and marketing teams to adapt their offerings quickly, while delivery and operations teams can extend configurations for fulfilment using the same master model.
In a digital world where customers expect compelling new products at the flick of a switch, it is far too costly to be encumbered inefficient legacy systems. The industry’s first truly real-time, catalog-driven order management system is now available to help CSPs achieve drastic reductions in cost to market, time to market and order fallout.
