3. STAKEHOLDER DYNAMICS IN THE SERVICE CONSTELLATION

One doesn’t discover new lands without consenting to lose sight of the shore for a very long time. Andre Gide

3.1 Delivering what is needed: Business service design

The enterprise focuses on outcome. There is a need or responsibility to accomplish something. For example, ‘ensure trains run on time’, ‘make sure social security and pensions are paid’, ‘be sure a new generation workspace is installed and functioning’, ‘make sure that salaries are paid’. It is not merely the working of the application that is the heart of service development. Services must support desired outcomes; they must be designed to make sure that the salary application is in place to ensure salaries are paid. Furthermore, good design should ensure that all other activities that support employees have been considered. For example, access to information through a tablet or smartphone, or ensuring that people have access to all their information, anytime, anywhere, anyplace.

Customers often do not want the service they think they asked for, they need something else that perhaps they were not adept at explaining. Therefore, it is of utmost importance to delve deeper into the necessary outcome than the requested output (a service or contract that looks right but does not stand up to usage in operation, for example). Most likely they need some other ‘thing’ that helps them reach their outcome.

This should lead to three specific actions. First, to design and develop the service offering you must account for the different perspectives within the enterprise and between demand and supply, and try to understand what is really needed. You must have insight into the service offering. Second, you need to have insight into the elements that will comprise the service offering. And third, when preparing for design of the service, describing the position of the needed services in the service lifecycle (is it completely new, is it a major change, is it an IT service, does it require applications to be developed). This step is essential to understand the right transactions.

To gain the essential requirements, we developed Business Service Design (BSD). At the core of BSD is the service constellation, as depicted in Figure 3.1. In this chapter and the next, we will explore the different elements of the service constellation and explain how it helps you to compose the total set of service requirements.

The service constellation is defined by the stakeholder participants (the actors) and the requirements generated between these actors because of how they interact. As mentioned in Chapter two, the central actor is BSC, the representative of the owner of the service. The relationships arise between domains because of stakeholder interactions and dependencies. Each domain defines specific requirements that are particular to the stakeholders involved, as can be seen in Figure 3.1.

In this chapter, we specifically focus on the dynamics and the underlying activities that make up the relationships between the stakeholders. These relationships will materialise in transactions that are part of the service offering. Transactions follow on from capabilities and resources that are deployed and serve to make agreements between stakeholders.

Figure 3.1: The service constellation

3.2 A stakeholder view of the enterprise

There are four stakeholder elements or strands. Think of them as DNA components from which a myriad of combinations will create different outputs (and outcomes). All the strands are of equal importance; it is how they are combined in different ways that ensure the correct output. We could argue that combining the strands incorrectly is, in biological terms, the same as a mutation in what was really the intention of nature.

3.2.1 Stakeholders from the business services coordination perspective

Although there are many stakeholders within an enterprise, to produce meaningful services that are purchased and consumed by users, BSC focuses on the four main stakeholders. These are the board, customers, providers and users. Each has dominion over a specific domain of the enterprise.

The different stakeholders make up four domains within the service constellation. A domain is the area of the enterprise that is specific to a stakeholder or group of stakeholders (and, of course, a domain will most often represent many individuals within an enterprise).

Within each domain environment are several measures that can be deployed to calibrate and monitor the dynamic equilibrium. There are four different domains:

1. operations/operational services (delivery)

2. orchestration (tactical services)

3. governance (strategic services)

4. quality (experience and features).

Examples of typical questions and consequent requirements that are asked in the different domains are presented in Figure 3.2.

Demand is driven by the board, users and customers. Effectively, there is a balance between supply and demand thus, architectural service design is a tension between the five roles (don’t forget the BSC!) and these four surrounding domains.

Figure 3.2: Typical questions within the different domains

3.2.2 Users

In explaining the different roles and responsibilities of the stakeholders, we first start with users. Users consume the services and products from the suppliers. In Figure 3.3, we provide just a few examples of the roles you might need (and, in some cases, will need) in the enterprise. Some of these are advisory, some external. Some of the roles are guardian roles; can you identify what you need?

Figure 3.3: Roles that exist in the enterprise

In general, users do not pay for their internal services. In market situations, you will find that users might contribute by paying for products that are delivered. But after that it is not their decision about which products are to be built, nor can they influence quality levels and quantities. For example, when a passport is needed, civilians must pay but have no influence on the quality of the product or service. If we don’t like the product (or service) we can complain, though the chances of influencing any change are minimal. Try calling Microsoft and asking for a change in PowerPoint.

3.2.3 Providers

At the base of Figure 3.1, you will see that providers (whether they are internal or external suppliers) deliver the actual service and technology to users who need them to get their work done or their wishes fulfilled. The service might be provided to users in accordance with a product and service catalogue and maintained, for example, through service management and a service desk.

3.2.4 Customers

The customer acts within the boundaries set by the Board. Often, customers are viewed as those who have the mandate and budget to carry out strategies to realise the enterprise’s vision. The most important customer is also, generally, on the management board or in control of management of the portfolio for business operations. Effectively, they pay for generic or basic services.

Thus, services are purchased for users by customers, so they can perform the necessary work efficiently and accurately. Based on the needs of the users, a budget is agreed alongside a price to be paid to provide the services. The specific needs of users are often laid down in internal service level agreements (SLAs); where services are procured from outside of the enterprise and the agreements most often relate to an overall contract. Users must accept the SLAs made with these third parties.

It may be that the basic service for some customer groups is not appropriate or insufficient for their needs. In that case, these customers can, through the governance organisation, negotiate separate agreements on additional services and different service levels. Additionally, for alternative arrangements, the board can decide whether to pass on additional costs. These specific arrangements are often referred to as having been designated to specific budgets.

3.2.5 Board of directors/general management

General management has overall responsibility for the performance of the enterprise. They discuss and decide upon the mission and vision of the enterprise. Focus is on the business model, market, profit and loss, and return on investment. They establish leadership and guiding principles and set policy on the operation and development of the organisation.

3.2.6 Business service coordination (BSC)

It is up to BSC to balance sometimes divergent interests of supply and demand in such a way that everyone can be satisfied. If the emphasis is solely on cost, suppliers will eventually become frustrated, inclining them to reduce cost at the expense of quality.

The needs of the internal customer and users are recognised in different ways. BSC is aware of the market and the current and future needs of the enterprise, and can advise effectively for decision makers. It is assumed that there are effective arrangements with the service providers. A total budget is, therefore, identified at the outset. If the total budget is insufficient, or providers are an issue, then this is explored in the process.

BSC outlines the need, and translates these functional requirements into a technical package of requirements that reflect the market supply. In addition, the outline considers demands from the environment in which the enterprise operates, such as architectural standards, branding, strategic principles, and so on. In addition, BSC will also advise the board on matters, such as new developments, standardisation policy and cost.

Based on the user experience, measurements (e.g. audits, satisfaction surveys, panels, etc.), and the performance of contracts, BSC obtains an idea of the perceived quality of the services being operated. The results are reported back to general management and the board. At this time, BSC may take the initiative to advise about new developments (motivated by the users or service providers).

BSC, therefore, takes a role in the creation and implementation of policy and strategy. IT oversees the invocation of policy advice to the strategic goals and directs the adoption to strategic plans (security, housing plan, subcontracting plan, etc.).

A clear relationship is also needed between the BSC roles and enterprise use of Gateway methods, and programme and project office roles and methods. In some enterprises, the roles might well all be in one place (or held by one person) because the stakeholders are easy to identify, and the size of the organisation is relatively small. In larger enterprises with multiple organisation units and lines of business, it would be unwise to expect one person, or one group, to be able to juggle multiple perspectives.

3.3 The domains

The five stakeholders exist in four different domains (or in some instances ‘kingdoms’, in worse scenarios, ‘fiefdoms’) in the service constellation, as shown in Figure 3.4. These are:

1. the domain of operations (or delivery)

2. the domain of orchestration

3. the domain of governance

4. the domain of quality.

Figure 3.4: The management domains

The domain sets out the activities that arise between the different stakeholders.

3.3.1 Domain: Operations

In this domain, the relationships between users, suppliers and the BSC are maintained, with the focus on the actual delivery of services. This applies also to the actual implementation of agreed projects and changes for which tenders have been issued. That means that the delivered products and services are known and recorded in a definitive list, or portfolio of products and services.

Typical questions asked in the domain operations

3.3.2 Domain: Quality

The quality domain is formed by the relationships BSC maintains with users and the board. The quality of service is a result of the agreements made by BSC with customers and suppliers, and the method of delivery. General management, or the board, is largely preoccupied (after making money), mainly with enabling employees to be able to continuously and smoothly conduct their work (which the cynical among us would say is making it easier to make money).

Tension will arise because users are not directly confronted with the costs. Therefore, users will be more inclined to overstate their needs and requirements, especially in times of cost rationalisation. This will increase the discrepancy between ‘wants and needs’ and available options. Value should be a key consideration; warranty and fitness for purpose must be considered but customers may not fully understand what users need in these terms. This situation is difficult to influence directly.

First, BSC can make sure that the service suppliers are performing well; second, BSC can regularly assess customer satisfaction through surveys or panels. Third, they can offer training and, finally, BSC can actively involve customers in pilot or innovative developments. Quality can be addressed in many dimensions, including enterprise policy regarding standards (software quality, security, operational management or perhaps governance) and promotion of good practice frameworks, such as BiSL next, PRINCE2 or ITIL.

Typical questions asked in the domain of quality

3.3.3 Domain: Governance

The domain formed by the relationships between BSC, its customers and general management, is regarded as governance. The content of the work in this area is generally strategic. It concerns the agreements resulting from enterprise goals, legal frameworks and financial areas, and which roles are required for the direction (advisory, informative or steering) of the development of long-term services. It can result in exploring or validating the business case. Think of architecture agreements and sourcing policies, portfolio management and policy objectives.

Typical questions asked in the domain of governance

3.3.4 Domain: Orchestration

When the executive board decides on the foundation for execution, it will be in the domain of orchestration where the operating model is managed and guarded. An operating model is the necessary level of business processes integration and standardisation for delivering goods and services to the users.⁷ This domain includes the organisational methods, systems and procedures that dictate the working patterns and formal behaviour of the organisation.

Typical questions asked in the domain of orchestration

In this domain, the relationships between customers and suppliers are maintained. These relationships are reflected in the agreements made between functional needs and the supply of products and services based on price, time and quality. This means that BSC identifies the current and future need, and verifies that the requirements have been translated into agreements with the suppliers. This is done with the support of the procurement and/or purchasing departments.

In the next chapter, we focus on the analysis of the service constellation.

_____________________

⁷ See Ross, J., Weill, P, Robertson, S.C. (2006), Enterprise Architecture as strategy; creating a foundation for business execution, Boston MA, Harvard Business School Press.