1. IT-DRIVEN BUSINESS SERVICES

Outside of a dog, a book is man’s best friend. Inside of a dog, it’s too dark to read.

Groucho Marx

1.1 Business need and value

The primary focus of this guide (with respect to the fundamentals of collaborative business service design) is the needs of the business; what information must be collected, how IT is processed, what is automated, can be automated, can never be automated, what is the result we want, how will this new service be paid for and what (if any) income is required from it.

As such, it is imperative to understand the characteristics of IT-driven services and service offerings. We need to understand the service requirements and to describe a structured approach to gather the right requirements for effective service solutions.

Rarely, however, do business managers pay the same attention to making sure the service they need is designed according to all their requirements and constraints (such as regulatory constraints, for example). This lack of attention leads to a poor customer experience. However, such an omission is often unintentional. It is usually the result of an overstretched business manager overlooking some essential factors because they are too busy to address every key point in a service design.

The different skills and experiences of the business and IT sections also need addressing. For example, business managers understand regulatory issues, but IT may not be aware of them or only have a superficial understanding of such constraints.

Poor understanding of the overall design is another concern because the lines of business in almost every enterprise are entirely dependent on IT. All the supporting organisational services, such as payroll, HR, facilities or purchasing, for example, are IT driven. As a consequence, IT is essential in the customer-oriented services in the lines of business (LoB). Information technology is increasingly fundamental to the value proposition in any business.

Business managers spend an enormous amount of time worrying about IT when problems arise and even more time using IT services (comprised usually of one or more IT applications) that gather, process and spit out the information they need.

Any medium or large enterprise can have several LoB. An insurance company, for example, will almost certainly sell property insurance, personal insurance, holiday insurance and many other products and services. Each of these is likely to be an organisational entity or unit. Other units will also exist, including HR, payroll, audit and finance. Even IT is an organisational unit, which can and will be comprised of other units. The LoB and organisational units will all be supported by a combination of specific IT services. This includes IT services that are dependent on one another and IT services that rely on invisible technology, that is they exist only to support the existence and operations of IT.

The purpose of the LoB is to continue to exist and to create money, or to otherwise ensure that the enterprise serves its stated objectives and goals. Generally, specific business purposes are supported by IT services that were designed and built and operated in house, though operational running of IT services has, increasingly, become outsourced.

The purpose of the organisational units is supported by IT services. These are often off-the-shelf products that may exist outside of internal IT operations (payroll is a common example).

Your business transformation drivers impact your business model. The enterprise architecture requires you to think about governance and strategy regarding your information/data, as well as how to improve and operate delivered services. Furthermore, you must maintain the business, data, service and technology perspectives throughout the creation of your operating model (Figure 1.1).

It is crucial for an enterprise to continuously define, develop and improve services that customers want to use (and, of course, pay for). Services are more than ever IT driven and dependent. Complexity lurks beneath every surface. A required service must be fully understood to know if it is truly of value and worthy of investment. And, without an overall business service architecture, it is difficult to picture every nuance.

Figure 1.1: Collaborative business service design

Therefore, it is only logical that business stakeholders want to be involved in the development and implementation, or adaptation, of highly IT-driven business services to ensure that different perspectives, interests and principles are included.

1.2 Capturing the characteristics of IT-driven services in a service design statement

Business service design (BSD) is a best practice rooted in design thinking¹ to better understand IT-driven business services, its characteristics and requirements, from a business perspective. BSD is rooted in the pragmatic approach and logic of the UK Government Gateway method; the method of service blueprinting and the well-understood stakeholder approach of obtaining executive consensus.

In navigating the BSD approach, you will derive a service design statement before you start designing, prototyping and developing. This explains to all the stakeholders what the business wants and needs, what providers should and can deliver, and what essential requirements should be part of the final design and delivery. Using BSD, you will gain improvement in the total service lifecycle, which leads to improved operational excellence, more customer intimacy, faster time to market and more strategic agility.

Figure 1.2: Positioning the service design statement

The service design statement (SDS) provides the link between the needs of the business and the detailed functional design needed to start the development or improvement of service offerings. The needs of the business (and what the business will value) are captured in a language of text and pictures, in facts and metaphors and in the business and technical principles. These components will engage all stakeholders (demand and supply alike) in the understanding of the full-service offering.

The BSD approach to deriving a SDS is a practical and powerful tool to help you identify the four essential elements needed to assure your business stakeholders that you can achieve the necessary outcomes. These elements will help you:

1. To promote the coherent design (and possible disaggregation of services) so that fundamental issues and requirements of the requirements are mapped, based on different perspectives between demand and supply.

When you use the method what will the deliverables be? Examples include:

2. To obtain insight into the dynamics between stakeholders within an enterprise.

The financial component is often viewed as the most important, but it does not solely influence the final decision. Board decisions are also made based on other considerations too; this is discussed in Chapter four. Important questions include:

A certain level of empathy and understanding helps to design service offerings so that they are acceptable for the various stakeholders within the enterprise. Will you always immediately create the best design? Probably not. Because the first draft is never the final picture. It is the start of a development and deployment process and, consequently, the beginning of the discussion.

3. To reflect on and formulate a practical and realistic roadmap.

Think about the service as a roadmap that provides insight into:

A roadmap helps you to understand the underlying processes and provide support for discussions with, and the involvement of, the different stakeholders during the development process. The roadmap approach fits well with Agile and DevOps methodologies as you will make quicker progress by prototyping the big picture at an early stage. This is especially true when a service is innovative or has no precedent. It might be impossible to find anyone that can provide experience to the design. As such, we recommend that a solid foundation is in place so you can build on and add features as time progresses.

4. Explore ideas or problems, and think about and develop possible interventions.

The scenarios and possible interventions explicitly create a dialogue between the parties concerned. Information obtained from previous BSD sessions then help to enrich this dialogue. The BSD ‘constellation’ (discussed later) does provide guidance about decisions to be made, and supports the understanding and exploring of their consequences.

1.3 From business vision to operation: methods to use

ITIL is one of several good practices to ensure that a service operates as expected (there are a myriad of other practices including Service Integration And Management (SIAM) and various ISO standards). In Figure 1.3, we provide an example of how the generic service development model is supported by many frameworks. In advance, we apologise to those who miss the appearance of their favourite framework or standard, but we must get the point across in one picture.

Figure 1.3: Methods and frameworks used to develop IT services

Later, in Figure 2.1, you will be able to see an expanded version of the service lifecycle steps in the centre of the diagram. In the context of the service lifecycle we have placed the well-known methods, not necessarily the one (or more) with which you may be familiar with. And where many choices exist, we have consolidated the listings using project management, PRINCE2 or PMI as examples.

The point of the illustration is that when it comes to the development of business services, there are many methods that will help you manage projects, or systems to help you with your analysis or coding. However, there are not so many to help you design your service effectively in relation to your stakeholders’ needs.

1.4 Who should read this guide to fundamentals?

This guide is intended for anyone responsible for designing and implementing IT-driven services, or involved in their operation.

It is designed to help those who want to take examinations and obtain certificates at different experience levels, and covers the essential facts from the ITGP published book Collaborative Business Design; Improving and innovating the design of IT-driven business services.

Enterprises with a ‘business relationship’ role or organisational unit can use this guide to help them identify the most important IT requirements of the business and ensure that these are implemented in any of the solutions proposed by internal or external suppliers.

On the supply side, any internal or external provider of a service, whether IT based or not, will also benefit. Think about your service managers, contract managers, bid managers, lead architects, requirement analysts, etc.

This guide may also prove to be useful to consultants involved with the set up or professionalisation of business service design and to students of business administration, business informatics and service management.

_____________________

¹ See for example Stickdorn, M., Schneider, J., editors (2011–2013), This is service design thinking, Basics, tools, cases, Bis Publishers, Amsterdam and Polaine, A., Løvlie, L., Reason, B., (2013), service design: From insight to Implementation, Rosenfeld Media. Mootee, I. (2013), Design thinking for strategic innovations; what they can’t teach you at business or design school, John Wiley & Sons, New Jersey. Reason, B, Løvlie, L., Brand Flu, M. (2016), Service Design for Business; A practical guide to optimize the customer experience, John Wiley & Sons, Osterwalder, A., Pigneur, Y., Bernarda, G., Smith, A., Smith (2014), New Jersey. Value Proposition Design, how to create products and services customers want, John Wiley & Sons, Hoboken, New Jersey.