Catalogue-driven order management

Enterprise product catalogue plays an important role in the catalogue-driven order management in managing the relationships between commercial products, the services that they represent, and the resources that are required to implement the services, or what is otherwise called as Product-Service-Resource (PSR) model.

This article aims to shed light on various ways of implementing a catalogue-driven order management (CDOM) as against a monolithic setup. There is a general misconception that a CDOM has to be a pre-integrated monolithic system. However, the CDOM, as a concept, can be realized even in a distributed and best of breed environment. For example, the catalogue, CRM and order management can be from different product vendors and yet, CDOM can be realized.

The below diagram illustrates the principles on which the CDOM works. As long as these principles are followed, the CSPs will still be able to achieve CDOM without majorly altering their existing eco-system.

The entire concept of CDOM revolves around the PSR model where the relationship is managed between the products, services and resources. Once the relationship is established, the participating systems like enterprise product catalogue (EPC), CRM and OM can seamlessly realize the catalogue-driven fulfillment. The relationship can be either within the monolithic setup or across distributed systems.

The principle also emphasizes on lean customer facing service (CFS ) layer where multiple offerings from the same product/service group can be mapped to single fulfillment workflows, thereby, enabling faster time-to-market of services. The examples are given in the ensuing sections.

Alignment to the PSR model Adopting a PSR model

enables CSPs to quickly launch products and services without causing much disruption to their IT systems. PSR model provides unambiguous direction to seamlessly introduce new products/services with minimal /no impact in the underlying service fulfillment systems.

The key principle is to decouple the commercial offers from technical implementation through the PSR model (CFS-RFS specification) which means that the developed solution should decouple itself from the frequently changing commercial layer to minimize the impact on the order management layer when new products/services are introduced/launched.

Best Practice

• Fulfillment workflows should be aligned to CFS and not to offers/bundles
• Mapping of multiple CFS to the same fulfillment workflow should be avoided
  

The following diagram provides a sample of how the products created in the catalogue are mapped to the underlying fulfillment patterns in the OM layer. The concept revolves around having a lean CFS layer, which means any new product offering would have zero impact on the OM layer because the product offerings are derived from product specifications, which has a one-to-one relationship to CFS. If any product/service results in new technology addition, there is an impact on the RFS layer where a separate technology flow is required due to new CFS being introduced.

The above diagram serves as an example of how CFS-RFS mapping will be carried out, end-to-end, across BSS and OSS systems. OM maps the CFS originating from the upstream (CRM) to appropriate fulfillment patterns. As part of the service fulfillment process, the fulfillment workflow sends CFS information to the inventory (in this case, it can be a service/technical catalogue) to resolve/translate into RFS. However, the need for an external technical / service catalogue is determined based on the EPC’s capability to support CFS-RFS mapping through its technical catalogue.

Design time and runtime

CDOM, as a concept, can be implemented either by using best of suite or best of breed products. The principle behind CDOM is to maintain the relationship between the product specification, CFS/RFS and the fulfillment patterns so that appropriate fulfillment patterns are invoked at run time for seamless fulfillment journey. As long as these relationships are maintained, either centrally or in a distributed manner, the CDOM functionality can be achieved.

The diagram below illustrates at high level the various configurations that would be carried in the distributed best of breed and best of suite CDOM.

From the above diagram, it can be clearly seen that the fulfillment of services is always realized in the OM system, which is independent of EPC in both the scenarios. The difference is, in the best of suite scenario, the EPC and OM are pre-integrated. OM performs a simple lookup during runtime to determine the fulfillment flow.

In the best of breed scenario, EPC will synchronize the CFS/RFS information with the OM/technical catalogue during the design time. Once configured in OM, based on the CFS information received from CRM/upstream system as part of the order capture, the OM invokes the right fulfillment pattern by doing an internal lookup. In both cases, the decoupling of commercial offers is always achieved and there is no impact whatsoever from time to market of services.

Concept to market – How it works in a CDOM environment

Time-to-market of services is of paramount importance to service providers. The principle of CDOM is to decouple the commercial offerings from technical implementation thereby allowing faster introduction of services. However, there are certain scenarios which call for change in the fulfillment layer depending on the type of offering  introduced in the commercial layer.

Conclusion

The guidelines and best practices expressed in this article emphasize the need for having a modular approach with reusability at both the product management and fulfillment domains to effectively achieve the decoupling of the product’s commercial and technical view.

R Venkataraman

Senior OSS Architect & Consultant, Wipro Limited.

Venkataraman, with close to two decades of experience focused on OSS, has been instrumental in designing and developing industry-aligned and complex solutions for large communication service providers worldwide.