On the customer-facing side there are more products, more features, more partners, and more sales channels. Implementation of a centralized, federated product catalog consolidates and simplifies product definition and delivers accurate, consistent support to every sales channel; with a single product catalog, the bottleneck is then pushed to the service catalog and activation.

At the resource layer the growing number of elements and the complexity of converged services has caused service providers to implement unique fulfillment stacks for individual network elements and additional stacks for service-specific overlays. For example, there’s one fulfillment stack for each brand of radio equipment and another for LTE services. The interim approach for providers trying to keep up with market demand for new products has been to throw orders over the wall for translation to existing fulfillment stacks without considering whether the products that have been ordered can even be delivered.

Getting there from here

Implementing a strategy to evolve fulfillment relies on several important underlying priorities. The first is simplicity: too much complexity can’t be reliably or cost-effectively automated, so it’s important to determine the proper balance between the kind of simplicity that gets the job done and the kind of complexity that gets a project bogged down in implementation and is ultimately never completed. Service providers must insist, whenever and wherever it’s feasible, that redundant BSS/OSS solutions and complexity be eliminated. When that isn’t possible, an approach must be taken that federates existing data and processes in order to implement a data-driven architecture that aligns product development, provisioning, order capture, and activation.

The next priority is flexibility. Rather than implementing expensive systems integration that requires ongoing software development and maintenance of interfaces, service providers can make use of automated fulfillment solutions that include agile orchestration and eliminate manual processes while still reducing costs. Providers are more willing now than in the past to consider hosted solutions for some, or even all, components of the order-capture and validation process. Analytics are also being engaged to understand patterns in failed orders and then use that insight to improve product development, offer management, order capture, and customer experience.

Finally, service providers cannot overlook “carrier class” requirements for scalability, reliability and availability. If the service layer is the hub for fulfillment it must scale to process thousands of orders and reliably deliver complex products to millions of customers, all while being available in real time and with no downtime. Activation must be automated across network infrastructure and service applications in such a way that products are turned on as soon as a customer or service representative hits “enter.” Each order must be validated against the service catalog and tracked through every step of the fulfillment process to detect fallout and errors.

There is a need for the next generation of fulfillment to peacefully coexist with current BSS/OSS solutions and data, which represent large investments and complex integrations that are nearly impossible to replace en masse. Existing CRM, order-management and fulfillment systems and data will remain part of service providers’ operations for the foreseeable future, meaning new functionality must be aligned so that ongoing operations aren’t put at risk.

Implementing service-layer fulfillment enables providers to continue using proven fulfillment stacks and embedded CRM systems as they transition their functionality to a new, data-driven architecture, thus allowing them to retire systems and platforms when the time is right. Fulfillment touches nearly every part of service provider’s operations, and they’ve learned through (sometimes painful) experience that fundamental changes to fulfillment constitute an evolution, not a revolution.