Enterprise Canvas and the Service Cycle

How do we make sense of a service, for service-review and service-design? How can we usefully partition the service-activities to help make sense of that service? And how do we link those activities to the various forms of value that flow through the service?

This is another follow-on to the slidedeck for my ‘Backbone and edge‘ presentation at the IASA UK Summit in London last week. Looking at the section ‘Everything-as-a-service’ (slides 18-31) and, specifically, slide 29 ‘In more detail’, Oliver Baier commented:

• OliverBaier: @tetradian 9 cell #enterprise canvas is very useful. However, the 3 rows may not consistently be related to before/during/after periods… // …example: Value return is b4 value creation in prepaid scenarios. Relationship mgmt better continuous for long-running svcs… // …Nonetheless, consideration of pre-/in-/post-service periods as relevant in #entarch as in #servicedesign.

This one’s gonna take some explaining… but first, here’s the Enterprise Canvas graphic in question:

So, start again from the top, much as in the slidedeck. In a service-oriented architecture, we’d say that the reason anyone does anything at all is that there’s a tension between what we have, versus what we want. In other words, a tension between realised-ends versus desired-ends, which we could visualise as follows:

A service provides a means to resolve (part of) that tension. In relatively-rare contexts, it can do so on its own:

[Note that we use the terms ‘value’ (singular) and ‘values’ (plural) to mean different things here: the vertical axis is driven by values (plural) linked to the enterprise ‘vision’, whereas the horizontal flow is an exchange of value. Somewhat confusing, I know, but that’s just the limitations of English for you…]

Or, to put this in visual form:

Looking ‘horizontally’ at that value-flow, this gives us an effective partitioning of the service in three ways:

• inbound: interactions on the ‘supply-side’ – consuming others’ services
• this: identifying, creating and managing its own value
• outbound: interactions on the ‘customer-side’ – providing services to others

We then look at how those exchanges and activities actually work – the effective sequence in play. For that, we can turn to Tuckman’s classic Group Dynamics project-lifecycle sequence:

• Forming (Purpose): create the context, idea, intent and purpose for a project (in this context, a mutual exchange) – aspirational stage
• Storming (People): build the connection between people to set the ground for possible exchange – relational stage
• Norming (Preparation): establish the details of how the transaction will proceed – conversational stage
• Performing (Process): do the actual transaction of exchangeable-value – transactional stage
• Adjourning (Performance): complete the project, establish benefits-realisation and lessons-learned for future interactions – completions stage

Or, to reframe it in Cluetrain terms:

• markets are transactions (service-Process)
• markets are conversations (service-Preparation)
• markets are relations (services serve People)
• markets are purposeful (services serve a Purpose)

And also:

• markets continue (services need continual confirmation, review and refresh of Performance)

Which we can visualise in circular form as the Service Cycle:

Or in a more linear form as:

The catch, though, is that most business-models only acknowledge the setup for the transaction and the transaction itself – the conversations stages (‘marketing’) and transactions stages (‘sales’) – and all solely from the organisation’s perspective at that. Not a good idea…

To make the service viable, we need to acknowledge and incorporate all of the interactions between the service and its service-partners – and include proper completions for each of those interactions, too. In the diagram below, a conventional transaction-oriented model would acknowledge only the ‘operations’ and ‘tactics’ interactions – but we need to include all of them:

One way to make sense of this is to partition the service’s activities in terms of that service-cycle: the interactions that happen before the setup for transaction; the interactions during the setup and the transaction itself; and the various completions that are needed after the transaction. Which, when we combine this with the previous three-way partitioning, gives us this nine-cell grid:

And if we explore what actually happens within a service, we can assign generic labels to each of those cells as follows:

Which brings us back to where we started – but I hope it’s now rather more clear as to how we got there!

So, to get back to Oliver’s questions:

• OliverBaier: @tetradian 9 cell #enterprise canvas is very useful. However, the 3 rows may not consistently be related to before/during/after periods… // …example: Value return is b4 value creation in prepaid scenarios. Relationship mgmt better continuous for long-running svcs…

The first point here is that we shouldn’t need to worry too much about the labels – it’s the grid that matters here, not the labels.

The second point – and this one’s really important – is that this nine-cell grid is a simple visualisation of something that’s actually recursive and fractal. For example, in a partner-relationship, the partner is both ‘supplier’ and ‘customer’, both at the same time. Quite often – particularly with more distant stakeholders – the interactions will never actually reach the ‘transaction’ stage: it’s all ‘before’ and ‘after’, with no ‘during’, but the interactions still exist and still matter for the overall operation of the service. And transactions and interactions each encompass and incorporate other transactions and interactions, each with their own ‘before’, ‘during’ and ‘after’. In short, think fractally, not linearly.

• OliverBaier: example: Value return is b4 value creation in prepaid scenarios.

Short answer to that one is “No, it isn’t”. To be blunt, it’s a fairly typical example of organisation-centric thinking – thinking of the service solely in terms of the organisation’s view, rather than the service as a whole – and also over-focusssing on money-flow rather than value-flow.

Take this apart again with a bit more precision, thinking fractally rather than linearly. In a prepaid scenario, the sequence involves a recursion: set up the relationship, then an inner loop of prepayment and service-delivery, finalising with overall completion. Service is not complete until the service paid-for is delivered to the customer’s satisfaction: but with linear-thinking, there’s a huge danger that the organisation will tend to think that service is complete once it has been paid. The legal term for that mistake is ‘breach of promise’ – or, in more colloquial terms, ‘theft’. Again, not a good idea… Hence, in turn, important to think of the ‘Value-Return’ and ‘Value-Outlay’ cells not solely in terms of money-flow (although money probably forms part of their concerns) but more in terms of how they handle the full set of completions for the service, all the way through to reaffirmed-trust in and with the respective service-partners.

Oliver came back on Twitter with a valid aside here:

• OliverBaier: re money vs value-delivered: Money is one form of value we seek from customers, right? But true, we need to consider all forms.

Yes, in a commercial context, “Money is one form of value we seek from customers”. Yet it’s essential to remember that the money arises solely in response to service-promise and service-delivery of what is usually not a monetary form of value: in that prepaid scenario, money in, yes, but toothbrushes or breakfast or clothes or cell-phone service or vehicle-repairs are the flows of value that customer is interested in – and the money doesn’t happen without it. Again, forgetting that point is not a good idea.

Going back to Oliver’s initial questions:

• OliverBaier: Relationship mgmt better continuous for long-running svcs…

Again, think fractally, not linearly: yes, relationship-management is key to long-running services, yet even for a ‘one-shot’ service-relationship, we still have to create the context for that relationship before anything else can happen.

Oliver came back again with one more question that, yes, is definitely relevant here:

• OliverBaier: The value proposition cell in the enterprise canvas is somewhat unclear to me. Did you envisage a description of the a) value prop itself, b) processes for establishing it & making/keeping it relevant, c) something else?

The short answer is “All of those”. Think in terms of where it sits in the nine-cell grid: it’s about establishing the relevance of the service’s own story to its suppliers and customers, and thence providing the underlying ‘Why’ for any subsequent interaction or transaction. It links the values (the ‘vertical’ connection to the desired-ends of the broader-enterprise) with a proposition about value that this service can create (the ‘horizontal’ connection with service-partners), which is what creates a shared-enterprise with those service-partners.

The longer answer, in terms of value-proposition in service-modelling with Enterprise Canvas, is in my post ‘What is a value-proposition?‘ – perhaps simplest just to point you to that post, rather than repeating everything here.

One last comment from Oliver:

• OliverBaier: The more we (just me?) actually work with a framework, the more questions etc come up.

Yes, exactly. Enterprise Canvas is often used more of a sensemaking tool or a viability-checklist than a design tool as such: the aim is to elicit questions, from which – once we do get real clarity on those questions – the answers we need tend to arise automatically from the context itself.

Much as with SCAN and most of my other tools, Enterprise Canvas itself is actually quite simple: yet once we learn how to leverage that simplicity – such as by thinking fractally rather than linearly – it also turns out to be surprisingly powerful. A good tool provides good structure and good affordances, but the real trick – the real power – is in how we use the tool, not in the tool itself.

Hope that’s useful, anyway?