Introduction
Designing services for the digital age
Digital services define the age we live in and everyone is doing digital. But digital often falls short of its promise. Digitization is the process of using tools and technology to improve business services. Some digitization efforts fail to realize any real improvement in service quality or efficiency. A common mistake is to add a ‘digital service’ on the front-end of a tired and inefficient internal process – like erecting an enticing new façade in front of an old and decrepit building. A key objective of digitization is improving the customer experience and the journey they take through their interactions with a business. Customer-facing journeys are where many digitization efforts start and place most of their attention. Unfortunately, many digital projects end there as well.
The digital entrepreneurs, who achieved astonishing success in the last decade or so, achieved a new internal operating model by creating an entirely new business. Although this option is not available to an existing business, a major reworking of the established operating model is necessary if the business is to survive and thrive in the digital age. But it’s plain hard work, and, what’s more, it’s very easy for things to go wrong. Frustration, confusion, anger, agitation, and open revolt can arise in several different ways. These are outlined in the following paragraphs.
Your colleagues are weary of the constant change initiatives that do not seem to achieve much. Everyone is aware that the pace of change is accelerating. There are many factors that drive this acceleration, not least technology innovation and constant drives for cost savings. But the cumulative effect of change after change on staff is often great fatigue and – ironically – less efficiency and fleeting benefits. How can we manage change initiatives that really ‘stick’ and make a lasting difference?
Your staff are tired of the clumsy computer systems that they are forced to use. Most of your staff have joined the workforce since computerized business systems became ubiquitous. They don’t remember the card systems and paper-based processes of older times. They do not understand why they can order their groceries online on their smartphones with a few finger presses, yet at work they must use a complicated and unfriendly business system. They must learn from others, or by trial and error, how to really use the system. They devise off-system work-arounds and unplanned manual tasks to get their job done. Digitized services will not be successful if you rely on such awkward systems and processes in the back-office.
Your managers are frustrated by the lack of up-to-date information about the state of their team’s workload. They are tired of finding out about tasks that have been misplaced or forgotten via a call from an angry customer. They want to know when a task has not been performed to the correct service level before the target service level expires, not afterwards. They want to know what tasks need to be reprioritized or reallocated because of staff absences, at the start of the day, not at the end. Digitized services need real-time management information.
Your experienced staff, who know and understand the business well, protest about the barriers that IT folk create when new requirements are explored. They struggle when technical jargon is the only language that their IT colleagues can express themselves in. They cannot believe the long delivery lead times, even when the developers use ‘agile’ methods. And they quickly lose heart when faced with features that are promised but never delivered.
Your board and chief executive baulk at the spiraling cost of computer systems, and repeated failures of IT projects to deliver benefits to the business. In the rapidly changing landscape of digitization and disruptive business models, digital services need to deliver a return on investment quickly. The board must be confident in the ability of digitization to rapidly realize benefits, or further investment funds will not be forthcoming.
From all directions, attempting to digitize your business and overturn your old operating model is a recipe for serious and uncontrollable disaster. To avert disaster, a different approach is needed. The stage is set for a revolution. Leaders who drive successful digitization projects understand that there are, not one, but two aspects to doing digital. Whilst allowing customers to transact with your business digitally is obvious, the second – and equally important – aspect of digitizing a business service is the internal process journey. The responsiveness and quality of your operational processes in the back-office should mirror the expectations raised by the improvements to the customer-facing journey. They are two sides of the same coin. A recent report emphasized the potential benefits resulting from considering both aspects of digitization:
Digital tools have the capacity to transform customer-facing journeys in powerful ways, often by creating the potential for self-service. Digital can also reshape time-consuming transactional and manual tasks that are part of internal journeys, especially when multiple systems are involved. 1
The customer-facing and internal process journeys are distinct but aligned
The alignment between the customer-facing journey and the internal process journey is illustrated in Figure 1-1:
Figure 1-2 shows a simple example, of applying for a driver license, illustrating how the customer-facing journey must align to the internal process journey. For most of the activities within the customer-facing journey there is a corresponding activity in the internal processes within the driver licensing authority.
A new self-service customer journey should improve the customer’s experience and efficiency. However, if the journey takes your staff through time-consuming internal processes, this will limit the efficiency within your operations, raise the level of frustration and boredom of your long-suffering staff, and ultimately affect their level of engagement.
If your goal is to create an excellent digital service, the tasks that operational staff perform every day must also be redesigned. This deserves at least as much care and effort as redesigning the customer-facing journey. By attending to both these aspects of digital service delivery, you will create a ‘win-win’ outcome for the business as well as for the customer.
In summary, offering a ‘digital service’ to your customers is not merely putting your front counter onto your customer’s computer at home. Delivering service in the digital age requires a new operating model inside the business as well.
The Requirements Black Hole
The fashions in computer system development circles swing between methods that we can describe generally as ‘requirements up-front’ and ‘requirements as-we-go’. Both approaches have their merits – but likewise, both have their dangers.
In the early days of computing, systems analysts needed to know “what the users want” in great detail – enabling specification of every business rule, data item, and process step – before any build work was done on the computer system. This ‘requirements up-front’ method came to be referred to as a ‘waterfall approach’, in which each step of the method, when completed, flowed irreversibly to the next step, like water in a waterfall.
Many failures of ‘requirements up-front’ IT projects eventually led to the advent of Agile development methods, in which business and IT worked more closely and iteratively, building a component of software quickly, allowing the business to add or change requirements at relatively low cost. The idea of Agile development is that a one-sentence user story is enough to get the software developers going on something. The rest of the requirements emerge during continuous engagement with a business expert and iterative refinement of the software. That is, the industry swung towards building software without knowing very much at all about the business needs at first, in a ‘requirements as-we-go’ approach. Agile development was revolutionary and is still widely used today, often very successfully when done well.
Both extremes of fashion lead us dangerously close to the irresistible forces of a requirements black hole. The ‘requirements up-front’ approach encourages never-ending analysis of requirements. In the meantime, business people tend to focus on the faults of the current system – often relatively trivial defects – because these are the things that cause them pain. Consequently, they find it difficult to imagine an entirely different system that will properly support a more efficient way of processing work. The IT experts complain that the business cannot make up its mind.
On the other hand, the ‘requirements as-we-go’ approach leads to an impatient, “are we there yet?” mindset. That is, multiple cycles of building enough requirements into the software to ensure we can show progress and quickly release something that works. At some point, the software is declared to be a ‘minimum viable product’ suitable for testing by real users, which we refer to as beta testing. Unfortunately, beta testing does not place focus on the everyday usage of the software in a business context; as such, undiscovered requirements will emerge late in the project. Meanwhile, the management pressure to ‘go live’ increases as time and money run out.
A problem with the ‘requirements as-we-go’ approach is that it is difficult to know whether the team has delivered a complete, coherent product from all the disparate pieces they have built. The software lacks architecture. It resembles a shanty town more than a structurally sound building. The ‘requirements as-we-go’ approach is akin to building the foyer of an office block with only a vague concept of the rest of the building.
A solid understanding of the future business journeys, and how they will operate in day-to-day reality, rarely emerges from these contrasting approaches. Neither the voluminous but impractical demands of the ‘requirements up-front’ approach nor the atomized user stories and working software fragments of ‘requirements as-we-go’ approach quite fit the bill. What ties these requirements together and ensures that they conform to the business strategy?
Lately, the fashion has swung towards incorporating ‘design thinking’ and user research into the ‘Agile’ method. This approach gives us an important perspective on the journey of the customer and enables us to recognize that we must deliver a transactional experience for the customer that completes the journey coherently. This is a refreshing change from the inward-looking focus of previous methodologies. At last we are placing importance on the front-office and facilitating the best approach for the customer.
However, design thinking focuses on the touchpoints or interactions between the customer and the business. There is less emphasis on the full intent of the business and how the internal business processes should be organized to operate efficiently. This is a back-office concern: the internal process journey that should mirror the customer-facing journey, as discussed earlier.
The internal process journey is not as readily designed as the customer interactions – there are a great many factors to consider and bring into balance. What data do we need in the back-office to process this transaction? What are the minimal process tasks required to fulfil the customer’s request? How can we apply what we know about one type of transaction to another transaction? How will the team manager know how much work is building up, how many transactions are waiting to be processed? How do we know which team is causing blockages in the business’s throughput?
One important factor that helps to clarify our thinking when defining business requirements is that transactions result in a change to the business’s master data. An order is fulfilled; an account is opened or closed; an invoice is sent; a payment is received. These activities are recorded in our data. The change that a transaction causes to the master data is what is most important and enduring – it creates a record of the activities of our business. The processes by which these master data records are created and updated are of less long-term significance than the records themselves.
There are recurring patterns to the business activities that process the transactions. If we think about transactional business processes as patterns of business activities that update master data, we open our minds to a different way of defining requirements.
Keeping a project in the safe zone, away from the dangers of the requirements black hole, can be done. It requires good management, good design, and active engagement with both the customer journey and the internal process journey. And Emily’s fresh perspective on the internal journey is the key.
How Emily’s rebellion can become a revolution
There is comfort in walking a well-trodden path – you know that others have walked that way, and you know that it leads to somewhere good. Ancient walking paths crisscross landscapes where people have travelled for centuries. However, new obstacles, like fallen trees and landslips, can make it necessary to divert off the old path and forge a new track, maybe through unfamiliar country. A new village arises, and we need to make a more direct path to connect it to other places where people live. Sometimes people have made several paths over a landscape and it is not clear which way is best to get to your destination. Such disruptions and alternative pathways are happening to businesses with increasing frequency these days. The old ways are changing rapidly. The old ways of designing and building business systems are now not as useful as they once were, or they don’t take you to the correct destination. Emily is keen to understand which development path is the best, the fastest, the most sustainable?
This book provides a guide for business people like Emily to engage in a new revolution. Our guide will help you to think about your business in a different way. It will teach you to design your business’s services in some detail, and not to leave design to the business process and IT experts. You will understand and be able to communicate why the front-office experience of your customer journey must be supported and counterbalanced by the experience of your process journey in the back-office.
This book will reveal how all your business services conform to a common pattern. Although it doesn’t seem so at first glance, your online customer performs a similar sequence of steps, no matter whether they are placing an order, applying for a driver’s license, or updating their address. The generic pattern in these different transactions goes like this: they discover the thing they want, enter the information needed, submit it, and receive an acknowledgement.
Similarly, you will see that the internal process journeys follow a similar pattern. Your operators receive and validate the information from the customer, evaluate this information, make a decision about the request, and notify the customer of the outcome. Although the content, business rules, and outputs are different for each journey, many business operations follow this pattern, whether it is fulfilling an order, or deciding whether someone is fit and proper to drive a motor vehicle.
The design method presented in this book will help you to leverage these common patterns to design successful digital services. Emily’s Rebellion will equip you with a method for defining business requirements for both the front-office and the back-office facets of a service. Our design method is particularly applicable to the design of digital services when complemented by a customer journey design or service design approach. The pattern-based structure will make services easier to design, communicate, and implement. Your customer-facing and internal process journeys will work together seamlessly.
Utilizing this pattern, you will be able to design the structures of your transactional services rapidly and comprehensively. This pattern-based perspective will equip you with the tools to express how you want digitized business processes and customer-facing journeys to be structured.
These tools will release you from dependence on IT professionals to help you with the design of your digital services. Our approach will enable you to take control of digital initiatives, rather than allowing them to be led by IT experts. Despite the term ‘digital’, doing digital services well is fundamentally not a technology problem. As in the 20th Century Modernist way of thinking about the architecture of buildings, form follows function in computer systems. The intended function of a building is a significant determinant of its shape and size. The form of your computer system is determined by the function that you decide it needs to perform. That function is, in turn, determined by the design of the business service that the system is to support.
We will cover the following topics:
- How do customer journeys comprise of individual transactional and information services, and how do I identify them?
- Why do transactional services conform to universally applicable patterns of business tasks that are performed during the processing of a transaction? How does this lead to an implementable workflow?
- How do I use the Transaction Pattern to discover business requirements (e.g. data, rules, routing) quickly and collaboratively?
- Why do transactions always change the data records of my business (i.e. the master data)? How should I store the data about transactions separately to the master data?
- How does using common pattern-based transactions help my business to centralize the management information needed by operations managers to run our internal process journeys smoothly?
- How do I ensure that some business tasks (such as tasks for approval, notification, and identification of the customer) are designed and built once, so that they are reusable across multiple transactions?
- How should I document the design of a transactional service using a pattern?
- How do I help the computer system designers to understand how to implement a pattern-based transaction?
With this knowledge at your disposal, you and other revolutionaries in your business will soon be creating digital services that everyone – your customers as well as your internal processing staff – will love.
Concept map
Figure 1-3 provides a map of the concepts covered by Emily’s Rebellion and shows how the concepts are related. Readers could use this map to see at a glance how a particular topic under discussion fits within the overall picture.
Emily’s glossary
Emily quickly finds that people throw terms into their conversations without really knowing what the terms mean. Business words and phrases are easily misunderstood and then reused by someone else but with a slightly different meaning based on what they understood the term to mean. Pretty soon everyone is using the term, but it now has several meanings.
Emily hears several terms of which she does not have a clear understanding. What is a transaction? An interaction? What is a data model? What is workflow? Emily needs some clear definitions so that she can make good use of these terms. Here are her definitions of the key terms used in this book.
