Swim-lane maps
Getting from a target customer experience to an agile target operating model
Agreeing on a Target Customer Experience (TCE) is only one stage in an organisation’s digital transformation journey. Before the experience can be realised, you must understand the systems and processes that will need to be implemented to deliver it.
Traditional Target Operating Models (TOMs) are typically built from the bottom up, including every process and piece of software that the business uses. These TOMs are detailed, and often not kept up to date as the business’ day-to-day operations change.
An agile TOM (ATOM), by contrast, is focused on providing the bridge between the world of experience design, and the day-to-day nuts and bolts of running a business. It allows you to define an executable roadmap from your current state to an agile organisation focused on the customer experience.
This post looks at a technique to define and refine ATOMs from the top-down that are focused on delivering a great experience for your customers.
What is a Target Operating Model?
A TOM describes how an organisation plans to deliver value to its customers. Together with the TCE, and the supply chain model, it is a key part of the business model for the organisation. I believe that when pursuing digital maturity, it is important to understand how the TOM relates to the TCE.
A traditional TOM can be split into four main components: people, process, applications, and infrastructure. The first two describe the business aspects of the TOM, and how they are brought together as an organisation to deliver value. The second two describe the technical aspects of the TOM in terms of the systems and platforms used by the business and customers to carry out their activities. Both aspects are necessary to understand how the organisation operates.
For me, the first two tiers of this model (vision and surface) define the TCE. An ATOM is defined by the plumbing and capability and how they deliver the vision and surface. Turning the TCE into an ATOM is vital for successfully delivering the customer experience in a digitally native way. At Friday, we believe that putting the customer first, and working from the outside in, leads to the best results.
Mapping the experience to the delivery
The approach we use for defining ATOMs we call ‘swim-lane mapping’. In this method, we progressively add detail starting from the steps of the customer journey until we’ve connected with all the relevant elements of the operating model.
To explain how to use swim-lane maps to describe an ATOM, I’ll be using a (fictitious) example of a bicycle auction company, known as ‘Speedy Bike’. Their current operating model is based around a simple website that is manually updated by a team of matchmakers. Each matchmaker is responsible for connecting buyers and sellers. They receive sale requests from sellers through a simple web-to-email form and, after contacting them and working out the details, they put a listing for the seller’s bike up on the site. They then receive bids, again through simple web-to-email forms, and decide who has won the auction. Their final responsibility is the collection of payment from the winning bidder, and making sure the bike is shipped.
Understandably, the managers of Speedy Bike view this legacy process as a nightmare experience for their customers and want to fix it. After some thought, they draw out a slice of their ideal customer journey below. The light grey swim-lanes represent varying kinds of actors, a seller and a bidder in this case. The green rectangles represent activities or processes these actors perform, such as putting a bike up for sale. Solid arrows with filled heads represent a causal trigger between the source and the target (the ‘search bikes’ activity causes the ‘place bid’ activity). ‘Receive payment’ and ‘auction won’ are events that the actor responds to by carrying out an activity.
We can now begin developing the ATOM by thinking about what areas of outward facing business behaviour, the external business services, are needed to enable this customer journey. I have added these to the diagram below and drawn ‘used by’ relationships connecting them to the activities that depend upon them. For example, the ‘search bikes’ activity requires a service, provided by Speedy Bike, to allow bidders to find the bikes they want to bid on. ‘Services’, in this context, are fairly abstract behaviours, representing things the business can do or provide by executing the operating model without including any of the detail about how they are done or who does them. Other examples of services are a checkout service at a supermarket or a current account service at a bank.
Of course, to define an ATOM, we do need to say how those services are being delivered. We can do that by either defining application features (also known as application functions, for digital systems that will provide some service), or business processes (for when people are involved). We can then relate these behavioural elements to the business services either directly realising them (white-headed dotted arrow), or indirectly using them.
We can add the features and processes to the diagram to give the picture below. We can see that the ‘bike listing service’ uses two features, one for creating an account and the other for creating an auction. The ‘delivery service’ is realised by a human process of someone coming around to the bidder’s home with the bike they’ve just purchased.
Of course, if there is behaviour then something must be carrying out that behaviour. These are the actors of the operating model. For application features, the actors are application components (such as the ‘auction management system’). For business processes, the actors are business roles (for example, ‘logistics manager’). Adding these to the operating model allows us to understand how the behaviour of the model will be organised.
Applications may be used directly by customers, or by internal staff. Both may need to be described (at suitable levels of detail) to define an ATOM that delivers the TCE. The logistics application below is an example of an internal application that may have a significant impact on the customer experience. Another example is an electronic point of sale system: if the journey for a supermarket needs offers to be displayed on the tills, then the software needs to have the right features.
We can now see that we’ll need to work with the logistics managers and couriers of Speedy Bike, if those roles exist. If they don’t, we can define their responsibilities with reference to the diagram we are building up.
Sometimes, particularly in complex or abstract businesses, it can be useful to think about the physical and knowledge artefacts that are acted upon by the model. Below, I have modelled the bike that is associated with the auction. I have also shown the knowledge item (business object) of a shipping note, with its attached delivery plan, and the processes that are accessing it. This level of detail allows us to understand the impact of changing the definition of those items, and better track the purpose of the operating model.
Finally, it is important to recognise that this is an iterative process. Once the first level of plumbing and capability has been defined, it is important to ask the question again ‘what services are required to deliver these features or processes’. By repeating until you are comfortable you understand where the skeletons are buried, but only adding the detail you really require, you can be more confident in making changes to how the business operates.
The best way to learn to draw a swim-lane map is to practice. With experience, you will be able to quickly draw just enough detail to explain to the business how the TCE will be delivered.
Benefits
Swim-lane mapping provides clear, unambiguous pictures of the ATOM that can be easily understood by the business and delivery partners. The lack of ambiguity lets us uncover disagreement early, rather than during implementation, and allows us to be confident the approach can be signed off. By tying everything back to the customer experience, the benefits and risks of the model can be made clear for all stakeholders.
It allows traceability from deliverables to the elements of the experience they support. This allows us to do delivery planning and prioritisation based on the value gained by the customer. We can also analyse the impact that decisions may have on the customer experience.
It produces an operating model that is customer focused. The business can know exactly why a certain role, process, application, or platform exists, and the value it delivers.
You can perform value-based risk management of the operations of the organisation. By knowing the value of each element of the ATOM, you can put in place appropriate risk mitigation strategies that balance cost against impact.
Things to bear in mind
You should build the swim-lane map up from the outside-in. By capturing only what’s necessary to support the desired experience, you can keep the models lightweight and easier to change. The resulting ATOM will also be easier to understand, and communicate. This will make it faster to get agreement with the stakeholders.
Do not model anything out of the control of the organisation that isn’t part of the journey for a customer or partner. Avoiding including things that the business cannot realistically change is another good way to keep the model light. It also allows the ATOM to act as a tool for talking about business change.
Understand your audience, and produce different views of the model for different stakeholders. Many modelling tools support slicing a model into different ‘viewpoints’. Each stakeholder will care about different aspects of the model. Someone in customer services may not be interested in order fulfilment. By showing stakeholders only those bits of the model that they can realistically change, or influence, you can keep conversations with them focused.
Model iteratively, introducing only enough detail to get to the next decision. It is easy, when presented with the opportunity to define every aspect of an organisation’s operations, to engage in architectural astronautism. By only producing enough detail to help advance the conversation another step, you will also produce a tight, customer-focused model. This will also help you bring the business along with you, and encourage a collaborative approach to defining business change.
Conclusions
If the TCE describes what you are going to deliver to your customers, the ATOM says how you will deliver it. An ATOM can be divided into four parts — the people, the processes, the applications, and the infrastructure — and how they relate to each other.
By building the ATOM up iteratively using a swim-lane map, starting from the customer journey and working inwards through the business, we can define a tightly customer-focused operating model. Including just enough detail at each stage allows us to work collaboratively, using rich pictures to bring all stakeholders together.
The details of the ATOM — particularly the processes, application features, and business objects — can be specified in more detail using techniques such as specification by example. This incremental richness, based on concrete information, and targeted at delivering known customer value, gives us better, and more focused conversations. It also provides a lightweight model that can be adapted as new information comes to light.
If the organisation maps out their current state operating model using the same process, it becomes much easier to perform a gap analysis to use as the basis of roadmap planning. I will likely return to this topic in a later post.
Notation is no substitute for notions, and we are still experimenting with the visual grammar we use for our swim-lane maps. As always, I’d love to hear from anyone who uses similar techniques in their business analysis practice.
Friday helps ambitious organisations achieve agility at scale. Our strategic engineers and designers develop digital products, services and platforms.
Further reading
If you are interested in learning more about Archimate, the blog and book Mastering Archimate by Gerben Wierda are good resources. A (slightly out of date) primer that explains the conceptual model underlying the notation is here.
Archimate has a long history, and many diagramming tools (such as Omnigraffle) have templates that can help you put together models using its grammar. However, these tools do not enforce the rules that allow you to reason about your models. There is, fortunately, an open source editor for Archimate models called Archi that I can recommend as a good way to play with the notation.
Once you have defined the basic surface processes that support a customer experience, you might feel the need to figure out the deeper level processes. The technique of Business Activity Modelling can be useful here, and may be the subject of another post.
Friday helps ambitious organisations achieve agility at scale. Our strategic engineers and designers develop digital products, services and platforms.
