|
|
article
page | 1 | 2 | 3 | 4 |
the provisioning of each individual component in order to fulfill the product as a whole. This includes being able to validate what the customer has requested is possible in their environment, understanding and operating on combinational factors such as managing conflict across shared resources, and being able to recognize and reuse orphaned resources, for example.
Although the ideal is for rapid product assembly to support the discovery and reuse of any type of component across the four categories identified above and potentially others in the future, CSPs implementing this concept are likely to want to do so a step at a time, starting with their network services. CSPs network services today are typically fragmented, running on different platforms and often in different networks, making it difficult to maximize their value by reusing them in multiple product contexts.
|
|
Rapid product assembly needs to be supported by a single, joined-up fulfillment process that can handle any product assembled from multiple different service components. |
|
combine it with others in new product bundles that deliver convergence, not only is this approach inflexible, typically resulting in slow customer adoption for example, but the total cost of ownership associated with it will soar. CSPs will potentially have to then try to integrate multiple fulfillment systems to support product bundles, and if they do this in a process-driven way, they will be narrowing their options as to which network services can be assembled together into products.
Even when CSP’s have rationalized their
|
|
|
|
As a first task, CSPs need to identify, model, and expose their network services as components available for rapid assembly and this means making information (metadata) about the services available through a product catalogue. They will then need to revisit their traditional approach to fulfillment to ensure that they can deliver each service when it is specified as part of an assembled product.
Can Existing Fulfillment Systems Support Rapid Product Assembly Today?
The simple answer is that traditional fulfillment systems are typically attached to a particular service. When CSPs launch a new service, they often introduce new BSS/OSS implementations to accompany it, this being the fastest way of bringing the service to market. CSP’s argue, rightly, that there are a number of benefits to maintaining this “silo” approach: they can get a service up and running quickly, demonstrating its potential, and initial overall capital investment is low. If a CSP wants to offer a limited portfolio of services to a small number of customers, this approach remains viable. However, if it wants to scale the service and to be able to
|
|
fulfillment systems, selecting a single system to support multiple products, the product is usually defined to the fulfillment process as a monolithic entity and tightly coupled with that process. The fact that the product exists inside a discrete process and has no external, data-driven description means that it cannot be reused as a component in a larger, value-added product. Not only is the product unable to participate in a rapid assembly process, changing it is expensive because this means also changing the process.
Data-Driven Fulfillment: the Key to Rapid Product Assembly for CSPs
If CSPs wish to broaden their service portfolios and reap the benefits of rapid product assembly, they must embrace a data-driven approach to product creation and fulfillment. Rapid product assembly needs to be supported by a single, joined-up fulfillment process that can handle any product assembled from multiple different service components. This means that the process has to exist independently from any specific component (service), and that it understands
article
page | 1 | 2 | 3 | 4 | |
|
|
