5. SERVICE DESIGN STATEMENT

All truths are easy to understand once they are discovered; the point is to discover them.

Galileo Galilei

5.1 Business service design deliverable

In this chapter, we will reiterate the principal steps in BSD mentioned in Chapter two, focusing on the actual ‘thing’, the SDS that you must deliver. The result of the BSD session should be a design description encapsulated in a ‘SDS’. It may not be the best service offering because the BSD deliverable is the most appropriate service offering. Service design thinking facilitates the enterprise in extensively checking this ideal service design offering and governing the development of the proposed service and innovation requirements. The design thinking approach will surface enough information in the design stage to influence design choices made and understand the capabilities needed. Therefore, the output is a description of a service offering, rather than the detailed design of the service offering.

The content of the SDS helps you to understand whether the overall design aligns with all operational, quality, governance and demand objectives within the domains.

The position of the SDS in the service lifecycle (between business demand and the problem analysis and requirements analysis that leads to a detailed functional design (as shown in Figure 1.2). In other words, get it right before you go too far.

5.2 Putting the pieces together

By merging all the different transactions and underlying resources, a design should emerge.

Figure 5.1: The four steps in the service constellation

Business service design follows four steps. The first step in the service constellation is explaining the type of questions asked by the different stakeholders, their need or responsibility, as is explained in Chapter three. In the second step, you identify the transactions that make up the requirement and conditions of the IT drivers and apply resources to construct transactions. The next step requires merging the transactions and domains in a service design. In addition, the needed transactions and resources can be summed up in an agreement between the stakeholders, as all is described here in this chapter.

The business service design is not complete until:

• All stakeholders are satisfied (with acceptance of the outputs and assurance of plausible outcomes).

• The necessary transactions are balanced and relevant compliances are in place.

• The extent of deployment of resources is clear and accepted.

• All corresponding risks have been assessed and addressed, and a risk management strategy is in place.

How do we know that the collective transactions lead to the desired output and are the building blocks of the business service we need? In general, one could say that if operations deliver, there is no further use to explore, because what you need is what you get.

Although, that is not perfectly true. In many enterprises, you will find that when a service is delivered, initially people get excited. But if a new service is not able to match the changing needs or easily adapt to a changing organisation, things start to go south. Were it only for delivering the service, then the transactions identified in the quality and operations domain should be enough to keep people satisfied. But remember our service lifecycle? Change is on us all the time and we need to blend the service within the enterprise policies and transformational needs.

Let’s give you a simple example. If, based on best practice, policy dictates that large projects should be developed and delivered in small tranches, you must be careful to ensure that an overall big picture design exists, but that the whole shooting match is not delivered at one time. If you are not paying attention to policy change, you will probably find your enterprise mentioned in the newspaper as another project that has gone over time and budget.

5.3 Balancing in a favourable design

Remember our remark in section 4.2 about whether there are enough transactions to complete your IT-driven business service design? The integrated service constellation provides you with inbuilt checking mechanisms. The check to balance your service in a favourable design must answer the requirements set in the four domains. This leads to the need to answer four essential questions:

• Does it fit the delivery requirement (user journey, for example prototyping possible solutions)?

• Does it fit policy and strategy?

• Does it integrate with the enterprise architecture and organisational and marketing objectives?

• Does it fit efficiency needs?

In answering these four essential questions, you walk through the service constellation as pictured in Figure 5.2. Begin with the operations domain (the actual point of delivery) and progress anti-clockwise to the quality domain, governance domain and orchestration domain.

Figure 5.2: Completing the architectural service design story

Some thoughts in answering these questions:

• The success of a service offering is clear only when users are content with the service and are consuming the service. The service offering should be determined by understanding the experience of the user when they are actively involved in its operation.

• Furthermore, the service offering must be aligned with business goals and objectives. We indicated earlier that sometimes a service offering will not match certain policies, but is nevertheless consciously part of a business strategy, for example to gain market share. Validating these questions and perspectives is important for successful delivery. A more mundane reason for careful examination of policy versus need can be found in that service offerings are often developed from the perspective of a specific consensus by (general) management.

• In a market situation, the offering is part of a business model and, therefore, should be compliant with enterprise goals. If service offerings cost more than they make, that might not seem to be an effective use of resources. Of course, it may not always be a clear-cut situation. Sometimes offerings are part of a company’s desire to offer a more complete portfolio and the enterprise will accept situations where offerings are financially less interesting (or even cost money) but lead to a more complete portfolio, or perhaps offer important added value.

• In non-profit situations, one can imagine that political goals and policy outcome far outweigh financial objectives. Sometimes, discussion revolves about the price of medicine compared to the price of a life. What is the cost at which a life-saving operation, or treatment with expensive medicine, will be declined? This question arises in national health services as well as insurance-driven services, such as that provided (or more often avoided) in the US.

• Next, you should decide whether the design aligns with organisational, architectural and marketing objectives. For example, will it suit existing contracts, are prospective new providers able to work within the enterprise eco-system, will the service offering fit marketing decisions, will the delivery make use of existing systems and so on?

• Finally, all of these perspectives (operations, quality, governance and orchestration) must be aligned in the most effective and efficient delivery of the service offering. Understanding these perspectives and exploring different strategies must lead to choices that not only satisfy stakeholders but also deliver a viable service design. This decision rule is known as ‘satisficing’.¹¹ This should, of course, not imply that a solution that is acceptable to all participants but does not lead to the desired service provision will be accepted! And beware of compromise; compromises are often enforced with the result that no one is satisfied.

5.4 Using the SDS

Success depends on whether all the information is available to cover all the information in the design and development stages. From a business point of view, you should have all the business information needed to justify further investment and sign-off. It is essential that the business understands that the service offering statement reflects the service they need, not necessarily the service they requested. It supports the balancing between customer intimacy and operational excellence.

The SDS should now be signed off by the SRO (not BSC!) or steering committee, whichever is responsible, and you are ready to go forward in your business service lifecycle. The SDS now specifies the essentials that need to be absolutely nailed down, and can be used as a guideline to focus the work to be done. It directs the choices and activities that must be in place to build, implement, maintain and execute the service delivery.

In Figure 5.3 some ideas are offered about the possible use for your SDS.

The primary value of the SDS is in evaluating service offering feasibility. It therefore is an essential part of the business case. In many instances, the statement will also serve as the starting point for the detailed design and development phase.

The SDS is the foundation for a request for information (RFI) or request for purchasing (RFP), potentially used, for example, in best-value purchasing. It can act as input for the supply to validate technical delivery perspectives and to identify more details to complete the design stage. In such instances, a comprehensive check focusing on whether providers can deliver the needed service offering is recommended.

Figure 5.3: Practical use of the Service Design Statement

In earlier chapters, we surmise that the providers involved in our BSD sessions are always on hand. This is not always the case. It is imperative that we acknowledge that sometimes the right provider has not been involved, or that the necessary tasks are not assigned to the right providers. Thus, in the BSD sessions, it is always recommended that contract managers are involved because of their inside knowledge.

There are two principal issues that are frequently overlooked that will lead to problems later; first, the provider, whether they are involved in the initial BSD sessions or later in the development and delivery lifecycle, must have the capability to deliver. Second, it is possible that the desired solutions are beyond the level of technology available in the market. If your enterprise is the first to seek a particular technology solution, keep in mind that this is a risk as well as an opportunity. NASA might see an opportunity with flights to Mars, even if technology is new and not tested. However, the preference is likely to be to create a modern webstore or information web portal using proven technology and standards, and focus principally on the desired outcome.

Early in the design process, it must be clear whether the service offering should comply with standard solutions. The advantages of standard solutions are that prices tend to be more reasonable because of economies of scale for the providers, and because there is competition.

5.5 One final thing: managing the BSC

BSC is the key role in navigating the service constellation. BSC retains responsibility for referencing the SDS throughout in the service development lifecycle. The BSC, remember, has the responsibility to bind the transactions together to make sure the service offering is effective. We can list the tasks (Table 5.1) relating to the different activities and accompanying processes. This can be used as a guideline and described differently in any enterprise.

When no BSC exists (whatever you name it) you must allocate the BSC responsibilities to the different departments or units within your enterprise. The BSC can be instantiated in numerous ways and we consider the role within BSD could be conceptual, to assign to it all the activities and responsibilities that cannot be (directly) allocated to the four other stakeholders. We could decide that for each service offering (or LoB) there is a separate BSC. Or we could decide that all service offerings are managed within one BSC. Secondly, a BSC might be one department, or the responsibility of one person, or alternatively, all the tasks of BSC may be dispersed over different departments.

We again stress that there is no absolute right or wrong. There can be many reasons why a specific type of design or configuration is chosen. And often we find hybrid situations where some service offerings are under one BSC and other service offerings are managed by a collective of departments or organisational units. Nevertheless, a choice for one configuration has consequences. For example, if a task for one service offering is dispersed within the enterprise, coordination, control and innovation will be more difficult than specific tasks brought under one responsibility.

Table 5.1: Tasks of the business service coordination

_____________________

¹¹ Satisficing; a strategy for decision making or cognitive heuristics that refers to a searching algorithm along different alternatives till an acceptable threshold has been reached. The approach is coined by Henry Simon in 1959. Simon, H.A. (1959), Theories of decision-making in economics and behavioural science, In: American economic review, vol. 49, issue 3 (June 1959), pp. 253–283.