SS

Bundling of supporting services with core services has implications for the design and operation of services. Decisions have to be made whether to standardize on the core or the supporting services. One can arrive at the same level of differentiation in a service offering taking different approaches to bundling (Figure 5.25). However, the costs and risk s involved may be different. Service Transition processes guide such decisions. The costs and risks for supporting services may be overlooked during initial stages of planning and development . Not only that, since supporting services are often shared by several core service s, there is often poor visibility and control over the demand for supporting services and their consumption.

Figure 5.25 Differentiated offerings

While service providers must focus on the effective delivery of value from core services, they should also devote enough attention to the supporting services. Satisfaction surveys show that user dissatisfaction is often with supporting services even where the core service is being effectively delivered.

Some supporting services, such as help desk or technical support services typically bundled with most service package s can also be offered on their own. This is an important consideration in strategic planning and review s. Service providers may adopt different strategies for core services and supporting services. For example, they can drive standardization and consolidation for supporting services to leverage economies of scale and to reduce operating costs, while developing core service package s specifically designed for particular customers. Or they may standardize the core service package and use supporting services to differentiate the offerings across customers or market segments. These strategic decisions can have enormous implications for the overall success of a service provider at the portfolio level. This is particularly important for service providers who need to balance the differing needs of, typically, not one but several enterprises or business unit s while trying to keep costs down across that portfolio to remain competitive.

5.5.4.3 Service level packages

Services packages come with one or more service level package s (SLP). Each SLP provides a definite level of utility or warranty from the perspective of outcomes, assets and the PBA of customers. Each SLP is capable of fulfilling one or more patterns of demand (Figure 5.26).

Figure 5.26 Business outcomes are the ultimate basis for service level packages

SLPs are associated with a set of service level s, pricing policies, and a core service package (CSP). CSPs are service package s that provide a platform of utility and warranty shared by two or more SLPs (Figure 5.27). Combinations of CSPs and SLPs are used to serve customer segments with differentiated value. Common attributes of SLPs are subsumed into the supporting CSPs. (This is like the popular game of Tetris in which the bottom-most layer of bricks gets subsumed when all its gaps are filled with the falling bricks.) This follows the principle of modularity to reduce complexity, increase asset utilization across SLPs, and to reduce the overall cost of services. CSPs and SLPs are loosely coupled to allow for local optimization while maintaining efficiency over the entire supported Service Catalogue. Improvements made to CSPs are automatically available to all SLPs following the principle of inheritance and encapsulation. Economy of scale and economy of scope are realized at the CSP level and the savings are transmitted to the SLP and to customers as policy permits.

Figure 5.27 Service level packages are a means to provide differentiated services

In certain contexts, CSPs are infrastructure service s offered by a specialized service unit. This allows for greater economy, learning and growth from specialization. This is similar to the arrangements between product marketing groups and manufacturing.

5.5.4.4 Advantage of core service packages

Some enterprises have highly consolidated core infrastructure units that support the operations of business unit s at a very large scale with high levels of reliability and performance . An example is a global supply chain and logistics company famous for its brown delivery trucks and industrialized service . The high levels of performance and reliability translate into similar levels of service warranty offered to businesses and consumers on the delivery of parcels and document s. The strategy is tight control over core service s used by all business units so that complexity is under control, economy of scale is extracted, and business outcomes are assured. Each business unit can develop SLPs based on application s and processes to serve their own market space s, and have them hosted on top of the core infrastructure services (Figure 5.28).

Figure 5.28 Going to market with service packages

From the business unit perspective, where the SLP is hosted has implications for exposure to quality , cost, and risks. The company is required to negotiate the best possible terms for having their SLPs supported by appropriate CSPs. The principle of separation of concerns is applied here to increase focus on customers without compromising the economy, efficiency and stability of centralized service operations and infrastructure.

The infrastructure unit may offer their CSPs as third-party OEM services to other service provider s who package them with their own set of SLPs. This further reduces the financial risk s of service asset s used to operate the CSP.

5.5.4.5 Segmentation

SLPs are effective in developing service package s for providing value to a segment of user s with utility and warranty appropriate to their needs and in a cost-effective way. SLPs are combined with CSPs to build a Service Catalogue with segmentation (Figure 5.29). This avoids underserved and over-served customers and increases the economic efficiency of service agreement s and contract s.

Figure 5.29 SLPs are targeted at customer segments

CSPs and SLPs are each made up of reusable component s many of which themselves are services (Table 5.10). Other components include software application s, hardware, licences, third-party services and public infrastructure service s (Figure 5.30). Some service components are assets owned by customers.