4. CAPABILITIES AND RESOURCES WITHIN THE CONSTELLATION
Get your facts first, and then you can distort them as much as you please.
Mark Twain
4.1 Transactions, communications, resources and agreements
Stakeholders can and will affect, (and in turn are affected by), the achievements of organisational units. They affect the outcome by communicating, making choices, taking actions, etc. Some of these actions lead to specific transactions (think ‘requirements’) that are part of the germination of the services and, therefore, should be part of the architectural service design. It is very important that stakeholders communicate at the outset of designing services so that all essential requirements can be gathered.
Within BSD, we make these requirements and accompanying transactions explicit by analysing each domain in the service constellation, finding the essential transactions, extracting data and understanding the necessary resources, risks involved and constraints that are or should be in place. Only then can we be sure of the minimum set of requirements that should be part of the final design. The sum of all the transactions makes up the service offering.
BSD encourages communication. It will only be through communication between the stakeholders that demand or need for specific transactions originates and is managed. For a transaction between stakeholders to occur, there needs to be a trigger. For example, the questions:
• Are we going to do everything ourselves or are we contracting outside providers? (In other words, does anyone have a clue if we have a sourcing strategy?)
• How can people apply for social security?
• How can we deliver a physical or virtual portal to interface with the users?
• How do we make sure that providers come up with the right solutions that fit our already chosen platform, etc.?
Communications between stakeholders are triggers designed to elicit and deliver transactions or set conditions. Always consider the U-X, the customer experience, when thinking about transactions; what will they be expecting?
To understand what we mean by a transaction, here is a very simple explanation:
• a stakeholder says ‘I want wine’
• the supplier stakeholder replies ‘No worries, here is some wine’
• or ‘What type of wine do you want’
• or ‘Do you prefer dry or sweet, more wood taste or fruit?’
• or ‘Depends on what you want to spend’
• or even ‘No chance, we do not offer alcohol’
• or ‘You can only drink wine we buy from Africa’
• or ‘You can only order wine that is on card’.
Figure 4.1: Transactions between stakeholders: communications that matter to service offering
You get the idea. When it comes to transactions between external (and internal) suppliers at the operational level, it is generally a more concrete statement of need. When it is a customer (board) request it is more ambiguous. Within BSD, all these requests/requirements are examined one by one, and defined as a ‘transaction’.
Here are two examples:
• Providers can ask FOR information or for an action to be undertaken by the user, and users will deliver by providing the information, or taking appropriate action; perhaps business operations need to be suspended before the supplier can make an essential security upgrade.
• Users request a minimum level of working conditions and the board will mandate a standard based on performance indicators. Or users set minimum requirements on working space standards (for example, more than one computer terminal will be needed for each user, necessitating bigger desks). If the Board does not accept the conditions, users will find other jobs or, depending on their levels of patience, inform the Board that work is not possible because everyone is sitting in the lap of another person.
Transactions have several attributes:
4.1.1 Transactions offer something or request something
Communication between stakeholders in a domain leads to questions or offerings. A stakeholder can request portal functionality or can request a budget. A stakeholder can offer policy or strategy on security, or a stakeholder can offer authentication when subscribing to a service.
4.1.2 Transactions have different characteristics
In each domain, there are transactions that come from different requests and deliveries by stakeholders. There are three types of transactions possible between stakeholders and BSC:
1. Physical transactions, for example, those resulting in requirements for applications, platforms, etc.
2. Information transactions, such as guidelines, standards, procedures, information, etc.
3. Relational transactions, for example meetings, conferences, etc. set up to build trust, understanding and reconciliation.
4.1.3 Transactions that are desirable or mandatory
Occasionally, it is not clear whether a need is in fact something that is essential. In exploring all the transactions, it will be necessary to conclude whether a transaction is simply desirable or essential to the service delivery.
4.1.4 Transactions set a condition or a delivery
Mandatory or desirable attributes of a transaction can set a condition or lead to a different manner of delivery in each domain. Most physical transactions can be found in the operational domain (e.g. give everyone an iPhone), whereas in the other domains most transactions are for information purposes (e.g. where possible ISO standards should be used to govern building new IT services) and set conditions.
A transaction must be completed for every requirement; if the transaction is not feasible, it must be explicitly rejected, and the impact assessed, noted and reported. A transaction essentially then becomes one of the requirements, either new, or changing something that might already exist. Transactions passed between stakeholder groups (e.g. from a customer to a supplier) require a response to be passed back so that the value of the response can be assessed. All transactions have equal value because each is a requirement. The value of each transaction is perceived differently by the stakeholder groups. If any of the requirements cannot be met, either the requirement is unclear, it is ambiguous, it is unrealistic, or it has risks too great to mitigate.
The transaction groups are board to customer, customer to supplier, users to suppliers and users to the board (and vice versa, see Figure 4.1).
Reciprocal is the key word when it comes to transactions. We want to emphasise that transactions can be about provision of a service or product, or transactions can be requests for information. Transactions in the quality, governance and demand domain most often set conditions and therefore can lead to dependencies, opportunities, restrictions, mandatory relationships and connections, etc. These conditions can lead to additional provision, for example the wish that a financial service should be Cloud based will result in additional measures to be put in place before the provider can deliver the financial service to the user. You should gather from this example why we posit that business information decisions cannot be separated from technology decisions.
Consider the complexity of the environment when thinking about stakeholder needs and how they must be balanced with delivery of appropriate services. See the following table for examples of transactions in each domain.
4.2 Customer journey
Transactions are the building blocks of the service blueprint. Ideally, in a service offering all requirements within each domain should match with the requirements made by the stakeholders. Also, we can conclude, as explained, that operation leads to delivery. Delivery (and therefore use) triggers users to assess quality. Ideally, ‘experienced’ quality should fit the mandated levels of quality and establish trust with operations (we realise this is a very idealistic situation). For each domain, we must establish the right requirements and, therefore, the right transaction that adds value to the final holistic service offering.
Each transaction can be positioned in the service offering depending on the transaction type, or its visibility to users, or the influence it has on the delivery to users. We use the technique known as ‘blueprinting’ to order the different transactions and create their relationships.
The ‘core’ of your service design offering is the actual delivery (actions leading to service delivery).
However, the requirements influencing the final delivery in each domain result from quality, governance and orchestration requirements. Thus, these are actions that set conditions. See Figure 4.2.
Figure 4.2: Flow of transactions that lead to the desired service offering.
The summation of all the essential transactions makes up the service offering.
When do you know you have enough transactions? By using the service blueprinting method to build up the service delivery and its conditions, you will find that there is a point where you will be satisfied because there are diminishing returns on the discussion points. At that time, no further analysis is beneficial. What remains is a last check, which we will explain in section 5.3.
To build the service design within the constellation, an approach is adapted that first was proposed by G. Lynn Shostack and later explored by others. It will help you structure, design and align transactions as they unfold over time. A standard service blueprint approach does not exist, but there is agreement on two aspects that are always clarified: the user journey over time and the main activities and processes in a service design process.
Use the generic service delivery process to analyse a request. A request is made to the front office that, in cooperation with the back office, leads to service delivery. Service delivery is of course being developed with output in mind. Between the three, there are interactions that must be explored to understand what interfaces will be needed (portal, desk, agent, automated procedure, etc.).8 A certain part of the service delivery will be visible to users that make a request for a particular service. In the blueprint method this is called the ‘line of visibility’.
In Figure 4.3 we show the blueprint template.
On the vertical axis, the time line, or more specifically; the customer journey, is plotted. Services have different stages: awareness (a call to action), the start of the action and a road (often rocky!) to reaching the goals and, then, return to business as usual. Thus, in many respects they are like stories.
Figure 4.3: Service blueprint template in business service design
This provides a simple framework that helps the participants structure the user journey and experiences, and helps them to understand, and perhaps even influence, their behaviour.
It is up to you where to start but the most common starting point is in the operations domain where you work on the actual delivery, building up the high-level service design between the different layers that can be distinguished between the generic service delivery processes. You should begin with having a possible set of outputs and user mandatory and desirable requirements in mind. You probably need to begin by brainstorming and thinking about different possibilities.
In applying BSD, you can use the service blueprint as a scratch-pad for understanding the different attributes of the service under scrutiny during analysis and synthesis. A lot of information that becomes available can be saved in a repository for use later. In the next table you will find examples of questions to be asked in the different segments of the service blueprint template.
Table 4.1: Examples of questions asked in the service blueprint diagram
4.3 Transactions derive from actions and resources
To produce appropriate outcomes, transactions need to occur between different stakeholders. The different transactions are derived from activities and processes. These transactions, as we discussed, can be informational or physical. For example, a policy, an order, a demand, a communication, a delivery, disposal of an existing platform or website, rules, legislation, etc. To solidify these processes and activities (so they lead to viable transactions that can take place between stakeholder groups), the various stakeholders will need resources.9 Resources comprise of capital (assets and money) and people:
• Capital assets may be machinery, applications, the workplace, buildings, cars, official documents, platforms, money, time, space, information, mandate, power, access to decision making, etc.
• People assets may be competences, capacity, knowledge, way of working, agents, etc.
These resources may be available and need to be used, or are not available and have to be acquired. Applying resources leads to activities and all the activities are then fused to shape processes. The processes instantiated will lead to the desired output. Clearly, by encouraging or discouraging the amount of resources applied, the output will be altered. Motivation to achieve an outcome (need and responsibility) leads to a desired output. Or, at least it should.
4.4 Risk management and compliance
In applying resources, you will encounter constraints and, therefore, experience potential risk (see Figure 4.4). Depending on the type of services that you wish to design, potential risk can be severe ranging from dangerous working environments or hazardous working materials, to freak accidents.
A certain amount of risk taking is inevitable, if your organisation is to achieve its objectives and deploy successful services. During the process of analysing the different requirements, you will find that applying resources can lead to risk. The service constellation helps you to identify these risks. Risk analysis is concerned with gathering information about exposure to risk so that later the enterprise can decide whether the risks that belong to the proposed architectural service design are acceptable and which appropriate measures must be in place to manage risk appropriately.
Figure 4.4: Potential risks of delivering services10
There are many useful tools, such as checklists, workshops, questionnaires and brainstorming to support risk identification. The use of techniques, prompt lists, questionnaires and interviews to gather information on the threats, helps to gain insight into the potential risks and agree their severity, or even propose ways of addressing them.
4.5 Instruments for agreement
When we agree on the service offering, we need to draw up the necessary agreements between the stakeholders. This should be done to be clear who will be responsible for the different activities that must be in place to make the service offering a reality. So, for example, if we issue a Cloud service we must be sure that policy guidelines on data protection and privacy are in place. By capturing the different responsibilities that should be in place, the service offering can become reality.
It is necessary then that we bind the responsibilities that come from a specific set of transactions that make up all activities, deliveries, processes, exchanges, etc. which are part of the informational and physical transactions. These are called agreements; where the agreement is legally binding, it is a contract. An agreement can be judicial (contract), a management settlement (service agreement), a wish list for customers (a portfolio), or a promise to the users (catalogue). They sum up all the reasons why all different transactions between stakeholders take place and capture the total service process.
There are four types of agreements:
1. Policy (framework)
2. Service level agreement (internal)
3. Service catalogue
4. Contracts
Figure 4.5: BSD canvas with agreement on the axis, risk’s and transaction-items in each domain
4.5.1 Policy
Between the board and business service coordination, different information is flowing that can be summarised in policy contracts, such as management contracts, principles and guidelines. These will guide the BSC into establishing agreements between the other stakeholders. Policy is often misunderstood in IT; IT policies relate to technical, operational issues whereas enterprise policies refer to much wider issues, such as privacy, compliance, how lines of business will deal with complaints from external customers, HR, and so on.
4.5.2 Service catalogue/product delivery catalogue (PDC)
The purpose of the PDC is to inform the users about the available services of the enterprise. The PDC is the ‘shop window’ of the enterprise for its products and services. Besides a description of a product or service, there is also a description of how and under what conditions the user can decrease the use of services and at what level of quality products and services are delivered. A service in a catalogue is one that exists; it should not be ‘offered’ if it is under construction, or to users not entitled to consume the service (some duties must be segregated, as must some services).
Today, the PDC is often made available through the intranet. In some cases, forms linked to the products and services are supplied so that users can not only refer to the PDC but also directly place an order via the intranet. The PDC is established based on SLAs, the experience of the staff of the service (and sales), in combination with the requirements of clear communication.
The PDC can serve multiple purposes and can act as:
• communication to customers (a window function)
• a marketing tool
• means to make transparent the added value of the facility organisation
• means for collecting and classifying information management
• instruction manual for employees of the service desk.
4.5.3 Service level agreements (internal)
While the PDC serves as a supply list for users, the internal service level agreement is a contract between the (top) management and service orchestrator. This contract lays down conditions under which the enterprise delivers its products and services. In a SLA, we generally find:
• the type of services delivered
• the level of performance achieved
• the conditions under which services are provided
• the availability and accessibility of the facility support
• the associated costs
• the available personnel
• how quality is guaranteed.
Because of its status, the internal SLA has a more formal language than the PDC. The SLA is less detailed and more formulated from the objectives of management. That means that products and services are provided from a vision associated with the business.
An internal SLA provides the tools to provide the required services, considering cost and quality control. Thus, the SLA also provides input for the formation, computation and the connection of the budget. By means of the basic service package and the associated work processes, we can determine a normative budget amount. Coupled with standard numbers, this forms the basis for the calculation of a normative formation.
In addition to products and services, the SLA defines the conditions that the service provider will offer the enterprise, in terms of mandate, the work to be performed, and the way complaints can be addressed.
4.5.4 Contracts
A contract is a legally binding instrument; ask anyone who ever signed one. A SLA is an agreement, but its terms and conditions have no legal obligation. If we fail to deliver then we might apologise, or we might not. Combining the service level agreement criteria within the contract is recommended if the SLA needs to be legally binding.
If we have signed a contract failure to deliver has legally enforceable penalties.
Within BSD, we distinguish between contracts that are legally binding and contracts between internal service providers and the BSC. In the latter case, it is up to the organisational units involved to dictate the level of detail required. We also differentiate between these SLAs and the SLAs created between the service orchestrator and customer. In situations with external parties, there is inevitably a legal obligation. In that case a contract, whether or not it’s in the form of a written agreement, is the result of a multilateral legal act whereby one or more parties to one or more other parties undertake an obligation.
Be careful what you wish for. Your contract may impose a fine (a big one) on a service provider that fails to deliver, but money is not much use if the failure put you out of business because you could not recover lost sales.
In the next chapter, we explain how to analyse the service constellation, aggregate the pieces together and derive the service design statement.
_____________________
8 Practical insight into the service delivery chain based on the front office-back office model and more in depth discussion on the interface between customer and provider can be found in Rouw, L.P. (2015), De service desk; spin in het facilitaire web, tweede herziene druk, VakmediaNet, Aplhen aan den Rijn en Rayport, J.F. & Jaworski, B.J. (2005). Best Face Forward: Why Companies Must Improve their Service Interfaces with Customers. Boston, MA: Harvard Business School Press.
9 There are many definitions for ‘processes’ and ‘activities’. We use Obers, G.-J. & Achterberg, K. (2014). Grip op processen in organisaties. Analyseren, ontwerpen en inrichten van bedrijfsprocessen. Zaltbommel: Van Haren Publishing.
10 OGC, (2002), Management of Risks: Guidance for Practitioners, Published by TSO for OCG Crown Copyright 2002.