Service Design is a set of practises that seeks to optimise and improve customer experience. However, the way that individual practitioners view Service Design depends on their specific experiences and areas of expertise.
Specifically, one perspective places considerable focus on the customer experience, and how businesses can leverage this to promote follow-up sales and brand loyalty.
Another view emphasises the structural elements of Service Design – how services are put together, monitored and improved. This is common in the technology industry.
This is the first of two articles that will explore these different perspectives on Service Design and suggest ways that they can align with each other to create an end-to-end approach to the design, implementation and maintenance of services. In this first article we’ll look at the technical perspective.
The IT Infrastructure Library
The technical view has been heavily influenced by the IT Infrastructure Library (ITIL). ITIL is a long-standing set of best practises for IT Service Management (ITSM) that has been evolving since the late 1980s.
Despite the name ITIL’s focus isn’t on technology per-se. Rather, ITIL describes a set of practises that aim to maximise the effectiveness of technology resources and ensure continual improvement over time. Typical problems that get ITIL practitioners interested might include:
Ensuring that technology changes/updates are correctly managed in terms of business value vs risk
Tracking how long it takes to resolve issues raised by customers, and suggest ways that this might be improved
Encouraging customers to use a self-service portal to request business services rather than directly calling the help desk.
ITIL and Service Design
Within the ITIL worldview a “Service” is understood in terms of the relationship between the customer and the business.
The customer is someone who wants a specific outcome, and the business is an entity that has the resources to provide that outcome. These resources may include technologies, products, and expertise that can be combined to make the desired outcome available to the customer.
In this context services are created when businesses bind together resources to provide that outcome. A service is essentially an interface between businesses and customers that meets demand by providing value.
Example: an online insurance claims service
Consider an insurance company that provides a web portal through which customers can make insurance claims. Figure 1 (below) shows this service as a business workflow.
Figure 1: Claims processing: a workflow view
The user experience is that they fill out a smart form, then submit their claim. As their claim is processed the customer receives feedback:
If the customer isn’t recognised in the system, or doesn’t have a current policy they will see an error on submission: “Display Failure to User”
Once identified, if their claim isn’t approved, they receive an email notifying them of this outcome – either a follow-up email (this would request additional information or suggest ways they can rectify their claim) if they aren’t approved, or a confirmation email letting them know the claim has been approved.
After this the workflow ends, and presumably some additional process would kick off to pay the claim.
The Process View
Assuming the portal form is well-designed, the customer’s experience is relatively straight forward. However, to create this experience a complex process plays out behind the scenes. This consists of:
An Azure service account authorises system access – in our example this is accessed via a simple integration
Once the request is authorised an automated workflow orchestrates the decision points and approvals to enable the service
Managers review approved claims via a single manual task - in reality this would probably be a subclass of approvals – perhaps those over a certain value
We have three third-party systems involved – Azure Entra (for service account authorisation), a Postgres database holding policy details, and a bespoke .NET Core application that runs business rules to assess claims.
This process view is how developers and business analysts typically view applications. It is a critical step in mapping out the solution, understanding key dependencies for its development, and communicating the proposed service to key stakeholders. But it is only part of the picture.
The Business View
Once the service is up and running additional concerns come into play. The would include:
Performance metrics – for example, the average time taken for claim requests to be completed, and where bottlenecks exist
Systems, people, and experts required to maintain the service over time, and
The dependencies between them – essential for diagnosing problems in the service, whether complete outages, errors or performance issues.
Figure 2 (below) shows the business’ view of the service once it is established. The focus here is on dependencies – that is, what systems does the service depend upon to keep running. In this example the claims service depends primarily on the user interface.
Figure 2: The business view of the claims service
In turn, the elements of the user interface (including error messages and email updates) are displayed is governed by the workflow engine. As shown in Figure 1 (above), decisions taken by the workflow depend on outcomes from the Azure Integration, Policy Database and the Claims Evaluation app.
Configuration Management
Understanding the service from this perspective is the key driver behind Configuration Management. ITIL advocates for Configuration Management as a discipline to maintain awareness over the way that the individual elements that underpin a service are configured and linked, with a view to diagnosing problems and improving performance.
When implemented, this is one of the more technical aspects of the ITIL framework, with network monitoring tools pooling data into a unified source of truth, the Configuration Management Database (CMDB). The CMDB provides a virtual view of the real-world technical environment.
Configuration Management interfaces closely with Change Management – with the CMDB feeding into evaluations of the risk and impact of planned (and, sometimes, emergency) changes to the environment. Temporary outages may be required on individual systems to introduce changes, and having an accurate map of dependencies on those systems with front end business services is an effective way of determining impact.
Service Value
In ITIL terms, the value of the service to the customer is that the business can provide the outcome they want without them having to invest in the infrastructure, training and time, to do it themselves.
In our example of an insurance claim the value is that the customer can do it without going into an insurance office, filling out a form, taking that form to the evaluation department, waiting for a response, etc. Customers get an outcome without being players in a Kafka novel.
Conversely, the service must also have value to the business for them to invest time, effort and resources into creating the service. The value to the business is basically the amount of demand that the service satisfies. In our example above, if requests for server space are only made (say) once a year, creating a dedicated service might not be worth it. However, if they are more common – and significantly increasing the workload on staff who respond to those requests – it might be.
Conclusion
In summary:
ITIL is a well-established framework which seeks to align technology, people and processes to the services the business provides
Services here refer to packaged activities that the business will perform for to achieve the outcomes that their customers demand
The focus is on creating, maintaining, and improving services within the business.
In our next article for this series we'll take a look at the customer experience approach to service design, then consider ways in which we can align it with the technical approach.
Kommentit