September 2016

Mac Taylor - Editor

 

SDP Investment Stakeholders

In the beginnings of SDP as architectural element of telecom services layer, investment decisions were the responsibility of the network operations departments and the CTO offices. As stated above, the SDP was deployed as a pure “technology push” with little emphasis on commercial aspects. Too many complex projects and tougher economic times pushed for an SDP investment to be a proven revenue generator, rather than an elegant technical solution for reducing service related OPEX.

Budgeting SDP projects is currently under pressure from business organizations: they require low cost integration and proven revenue streams from new services. This is a difficult test to pass for SDP suppliers, mainly because there is no standardized

Product Lifecycle Management around SDP services that could be easily used to make the integration and revenue generating case. Each operator has its own internal processes and decision criteria in the workflows that create, provision and operate services and resources. While many SDP suppliers have “out of the box” components and applications ready to deploy, introducing an SDP for one or more classes of services into these processes requires intimate knowledge of both the operational environment and the business strategy on the Service Provider side. A generic framework such as TeleManagement Forum’s business and operations processes map (eTOM) is useful to understand the bigger picture but it does not carry the Intellectual Property and Business Intelligence each CSP puts in its own business model.

For the SDP supplier, what seemed to be a technology problem becomes a complex people and processes problem to be solved for each CSP business objectives and “modus operandi”. SDP investments can be driven by solid business cases when better cooperation among the participants in the decision process happens , when they are all committed to understanding both technology and business challenges and can align their resources in making the SDP a joint project across organizations.

Creating SDP Requests for Proposals (RFPs) that reflect such collaboration, rather than just the technology requirements from the CTO architecture team, will signal a more mature understanding of the SDP investment among CSP stakeholders.

These stakeholders inside Service Provider organizations are:

Product Strategy groups

controlling the budgets in collaboration with Product Marketing groups who analyze demand and create new offerings;

IT organisations

whose strategy is led by a CIO office; they have the knowledge of design and operation of SOA-based third generation SDP architectures, CRM and IT service management;

Network organisations

whose strategy is led by a CTO office; they have the control over the network resources and their management. Increased customer expectations, the need for more diversified services and lately the consolidation of multiple lines of business as part of convergence, fuel better collaboration between network and IT organisations on assuring the end-to-end service delivery, correlated on customer experience rather than on assurance operations at network level. Similarly, business organisations collaborate more with technical organisation on understanding the value and the cost of various network and

IT assets, how they can be reused to generate new revenue streams and how to lower the OPEX by outsourcing their management. The changing relationship and relative importance of these three groups of stakeholders in an SDP project may be seen as an obstacle to SDP adoption because it could overly complicate SDP decision making processes. To simplify the decision process and crop long and inefficient projects, several Tier 1 operators (BT and Sprint for example) have recently reorganised and removed the CTO and CIO silos and oriented their business model more around service design from a holistic perspective (market strategy, IT, network) and service delivery from a customer perspective.

For new entrants who have small amounts of network and IT system legacy, the decision process can be simplified although the customer acquisition not the SDP investment is their first priority.

SDP projects, together with broader OSS/ BSS transformation projects, open a big opportunity for suppliers of methodologies and tools to help all these organizations improve collaboration on the whole range of needs: from business analysis and processes modeling down to specifying systems and interfaces to expose required services and evaluate costs of implementation and maintenance. There is a definite lack of such suppliers in the telecom industry and this affects the speed of SDP adoption, too.