The Enterprise Canvas, Part 2: Market and Supply-Chain

In the previous section we looked at how the broader extended-enterprise is defined by its vision and values, how every part of the enterprise is made up of interdependent services, and how the enterprise vision and values pervade through every service. We ended up with this description-so-far of the structure of a service, which summarises that ‘vertical’ axis of value:

We now need to link that to the ‘horizontal’ axis of the supply-chain:

To make sense of this, we first need to look in some depth at what actually happens in a market.

Even at a first glance it should be evident that markets are transactions – there’s a lot going on, and on the surface at least, most of it is about deals, about supply-and-demand, about ‘things’, and those ‘things’ being exchanged. (And paid for, of course, in a commercial market – a point we’ll need to come back to later.) This is the most visible part of the content of the supply-chain channels.

Yet as the Cluetrain Manifesto famously observed, markets are conversations. Information is being exchanged in many different ways – sometimes as the content of the transaction itself, but some of it with little direct import for the transaction at hand. Sometimes a conversation is just a conversation – yet it’s also evident that it’s an essential component of the workings of the market.

And as Doc Searls, one of Cluetrain’s authors, discovered in an airplane conversation with a Nigerian pastor named Sayo, markets are relationships too:

[Sayo] went on to point out that, in his country, and in much of what we call the developing world, relationship is of paramount importance in public markets. Transaction still matters, of course. So does conversation. But the biggest wedge in the social pie of the public marketplace is relationship. Prices less set than found, and the context for finding prices is both conversation and relationship. In many cases, relationship is the primary concern, not price. The bottom line is not everything.

Transaction rules the Industrialized world. Here prices are set by those who control the manufacturing, distribution and retail systems. Customers do have an influence on prices, but only in the form of aggregate demand. The rates at which they buy or don’t buy something determines what price the “market” will bear — in a system where “market” means aggregated demand, manifested in prices paid and quantities sold. Here the whole economic system is viewed mostly through the prism of price, which is seen as the outcome of tug between supply and demand.

Price still matters in the developing world, Sayo said, but relationship matters more. It’s a higher context with a higher set of values, many of which are trivialized or made invisible when viewed through the prism of price. Relationship is not reducible to price, even though it may influence price. Families and friends don’t put prices on their relationships. (At least not consciously, and only at the risk of cheapening or losing a relationship.) Love, the most giving force in any relationship, is not about exchanging. It is not fungible. You don’t expect a payback or a rate of return on the love you give your child, your wife or husband, your friends.

Even in the industrialized world, relationship has an enormous bearing on the way markets work, Sayo said. But it is poorly understood in the developed world, where so much “comes down to the bottom line”.

Finally, markets are purpose – as we saw in the previous section, the market is actually defined by the shared-purpose of the enterprise vision, the overall descriptor for its “common set of missions or goals”.

So there are four distinct strands here, each in rough correspondence to one of the four distinct classes of assets:

  • physical – alienable ‘things’ – if I give it to you, I no longer have it
  • virtual – non-alienable items such as information – if I give it to you, I still have it
  • relational – a person-to-person connection that cannot be directly exchanged with or transferred to anyone else
  • aspirational (‘spiritual’) – a personal connection to an idea such as a brand or enterprise-vision – again, cannot be directly exchanged with or transferred to anyone else

As Sayo says above, “Transaction rules the industrialized world”. By that, we typically mean the transfer of ‘exchangeable goods’ – through what is most often described as the ‘supply-channel’ or main-channel – and, separately and in return, payment or its equivalent – through what we might describe as the backchannel. And in its simplest form, ‘profit’ is the difference between the value-return that comes in from the backchannel from the customer-side, compared to the value-outlay that goes out on the backchannel on the supplier-side. Once we also subtract the value-outlay for internal costs of running the service itself, the result is the ‘bottom-line’ net-profit that is the near-obsessive focus of so many business-folk.

Yet those transactions of ‘exchangeable items’ are only one part of the overall activities of the market; and all of those transactions – and the resultant profit – occur only at the tail-end of what we might call the market-sequence:

reputation > trust > respect > attention > conversation > transaction > exchange > profit

And the whole structure is a complex feedback-loop: for example, reputation – which itself is a kind of third-party precursor to trust – depends in part on whether the transactions are perceived overall as ‘fair exchange’. Hence before any transactions can take place, the relationships need to exist: and those relationships – and conversations too – are strongly linked to and dependent on the service’s value-proposition. Likewise after the transaction, there not only needs to be the backchannel exchange that completes the ‘fair exchange’ of the transaction, but that too also needs to link back to the value-proposition and the relationships, tying everything together in terms of the various definitions of what ‘value’ actually is within the overall enterprise.

So we have three distinct stages:

  • what happens before transactions of ‘exchangeable items’ – an emphasis on relations, which link most strongly to the service’s value-proposition
  • what happens during (and with) transactions of ‘exchangeable items’ – an emphasis on actions, which link most strongly to the service’s value-creation
  • what happens after transactions of ‘exchangeable items’ – an emphasis on value-transfers (payments and receipts etc, as ‘value-outlay’ and ‘value-return’) and other follow-up and overall integration, which link most strongly to the service’s value-management

And all this needs to be symmetrical, in the sense that – within the overall market – this service that is our current focus is both a customer of other services, and a provider to other services, hence all of the above will apply in similar ways on both ‘supply side’ and ‘customer side’. We need ‘supplier relationship management’, for example, just as much as we need ‘customer relationship management’. And the value-transfers and follow-up need to be in terms of all forms of ‘value’ defined by the overall enterprise – and not measured solely in monetary terms, for example, no matter what the shareholders may demand! :-)

When we put all of this together, what we end up with so far as a summary of the structure of any service – and the core of our Enterprise Canvas – is this:

A comparison with the Business Model Canvas would be useful at this point:

The Business Model Canvas [BMC] (upper) applies to a single context – the business-model for the overall organisation, at the ‘logical’ level of abstraction (relationships and attributes, as will be described in a later article in the series). The prototypic Enterprise Canvas [EC] (lower, cross-mapped to the BMC’s cell-labels) applies to any type of service, at any level of abstraction. There are also a few differences in the detail: for example, I’ve deliberately bundled the equivalents of the BMC’s ‘Key Activities’ and ‘Key Resources’ together into the EC’s ‘Value Creation’ cell, for reasons that become clear when we do a Zachman-style analysis of what actually goes on in there. The BMC’s ‘Cost Structure’ and ‘Revenue Streams’ are generalised in the EC to cover all forms of value-exchange or value-transfer, not solely monetary exchanges. And the EC’s symmetry of supply-side versus customer-side is absent in the BMC, which instead bundles several distinct types of activity into the one ‘Key Partners’ cell. But beyond that, they are quite similar – and need to be so, for the simple reason that both BMC and EC describe much the same entity, the activities of a service in delivering a value-proposition to the enterprise.

What’s also not covered in the BMC, and that we do need to include in the EC, is the structure and content of the flows between services. It’s useful to separate these out for the ‘before’, ‘during’ and ‘after’ phases of transaction, because they’re often handled by different groups of people and/or different sub-services within the overall service. And in some cases – as with the service’s interactions with its ‘non-customer/supplier’ stakeholders, such as government, non-clients, the local community or the general public – only one or two of the before/during/after categories of flows will apply. In addition, there are also some important differences in the emphasis of each flow:

  • ‘before’ flows link primarily with supplier/customer relations, and must always be regarded as bidirectional
  • ‘during’ flows link primarily with supplier/customer channels; whilst there are always some bidirectional components, the main flow is along the supply-chain (i.e. left to right in the EC diagram)
  • ‘after’ flows link primarily with value-outlay/-return; whilst there are always some bidirectional components, the main flow is opposite to the supply-chain (i.e. right to left in the EC diagram) – hence ‘backchannel’

We could typically illustrate these flows respectively as two people talking (‘before’), a package (‘during’) and a small pile of coins (‘after’). But since I couldn’t find the right icons, I’ve used symbols from the keyboard character-set as follows:

All of these flows may be usefully described in terms of the VPEC-T frame:

  • value/values: that which defines the flow – the overall values that frame the context of the flow, and in which the quality of the results will be assessed
  • policies: that which directs the flow – the decisions, rules and reasonings that will guide activities that would (in principle) add value to the content of the flow
  • events: that which triggers the flow – the triggers that mark the initiation and/or completion of action on the content of the flow (and that themselves often contain information and other content as part of the event-trigger)
  • content: that which informs the flow – the core ‘content’ of the flow, consisting of a context/role-specific mix of asset-types
  • trust: that which dominates the flow – the feedback on the perceived value of the flow, and belief in future efficacy (effectiveness: efficient, reliable, elegant, appropriate, integrated) of equivalent future flows along this pathway

V (value) initiates the conditions in which the flow may take place; PEC (policy, event, content) represent the actual transaction, and actions taken subsequent to the transaction; T (trust) represents the feedback that adds to or subtracts from the expected V of further transactions of this type – and hence enables or disables future flows on this path.

Although all flows incorporate all of these elements, the respective VPEC-T emphases in each cell within the unit may be summarised as follows:

It’s important to note that the ‘value-creation’ cell is the core of it all, and also – as we’ll see later in the description of layering – is the only cell without direct external interfaces. More explanation on that in subsequent posts, anyway.

Tagged with: , , , ,
Posted in Business, Complexity / Structure, Enterprise architecture
4 comments on “The Enterprise Canvas, Part 2: Market and Supply-Chain
  1. Pat says:

    Is it “shared vision” or cooperative “visions” between the enterprise and suppliers?

    I agree that buyers/customers join the community because of a shared vision during the first 2.5 stages of influence. .

    The latter part of the market influence come along because of the low risk or because their are no other options.

  2. Nick Malik says:

    I do not agree with this statement:
    The Business Model Canvas [BMC] (upper) applies to a single context – the business-model for the overall organisation, at the ‘logical’ level of abstraction (relationships and attributes, as will be described in a later article in the series). The prototypic Enterprise Canvas [EC] (lower, cross-mapped to the BMC’s cell-labels) applies to any type of service, at any level of abstraction.

    I do not see the BMC as limited to cover only the entire organization. To the contrary, it is quite useful for any business service. Once you remove that “advantage,” then I’m unconvinced of the utility of creating another canvas.

    I do agree that the BMC does not illustrate the interactions between business models and the services needed to support them in the context of a single (potentially extended) enterprise. But I’m having a hard time seeing how your model addresses that problem.

  3. Tom G says:

    Pat – on ‘vision’, perhaps see the later post on ‘A structure for enterprise-vision’ may help to clarify some of this.

    Following the logic of Hagel, Seely Brown and Davison’s ‘The Power of Pull’, in part the adoption-pattern would be closely related to the ‘pull’ factor, which in turn is leveraged by (or from?) the enterprise-vision (see the description of a ‘push’-based model in Part 7 of this series). And of course it’s very unlikely that there would ever be 100% adoption anyway (unless there’s an imposed monopoly, in which case neither ‘pull’ nor ‘push’ would actually apply :-| ).

  4. Tom G says:

    Nick – I take your point, and it would certainly be true if we were only covering the same scope as the BMC. But the point here is that the BMC is very tightly linked to business-models in a fairly abstract sense: there are literally just two pages in the whole book (pp.272-3) that deal with deeper-level implementation.

    You can kludge the BMC to work down into more-detailed Zachman row-3 and thence to row-4 and row-5, but that means we’d be using the model well outside of its specified scope – and in case you hadn’t noticed, I’ve suffered a great deal of attack from a certain party for doing just that with another model. :-( Much better to start again from not-quite-scratch, re-leverage everything that we already have – including the BMC, your EBMM, Zachman, VSM, Archimate, SCOR, VPEC-T, ITIL and all the others – and create something that’s designed from the start to use service-oriented principles across a true whole-of-enterprise scope.

    And importantly, the BMC as standard doesn’t deal with flows, doesn’t cover the full market-sequence [as in the article above] and non-monetary value-relationships (though yes, the topic has a brief mention on pp.264-5 of the book), doesn’t extend across the full supply-chain (it’s concerned solely with this organisation) and doesn’t cover VSM-style whole-of-enterprise integration. If you don’t have those in place – especially when you start to look in detail at actual implementation of a business-model – you’re going to get stuck fairly quick, and/or find yourself with all manner of yawning gaps labelled ‘magic happens here’… not a good idea, surely?

    To illustrate the point, try using the BMC in its present form to describe a business-model based on outsourcing of IT via cloud-computing. At the surface level, it’s actually quite easy to describe via the BMC, though the why – i.e. the deeper parts of the reasoning behind the value-proposition – will be a lot trickier than they seem at first glance. But what happens when you start towards implementation – and the impacts of that implementation back up at the business-model layer? That’s where things start to get really messy – and you can’t do that properly unless you have something that deals with all of the flows, that deals with whole-enterprise integration, that deals with all the complexities of those top-down/bottom-up transitions between abstract and concrete. And if you don’t deal with all of that properly – as so much of the cloud-hype doesn’t – you end up with business-models that look great in theory but fall over in a very expensive heap in practice.

    To give a more concrete example, try using the BMC to describe the business-model for the role, use, structure and implementation of a CMDB (Configuration-Management Database), in the context of the business-model for ITIL-style service-management. There are solid business-models there: the core logic of the BMC actually works quite well for that purpose. And you can use business-model concepts to describe usage, structure, implementation, deployment and so on. But if you try to do any of that by following the text in the BMGen book, you’ll find it’s a horrible kludge: the emphasis is completely different, the terminology is completely different, and there are a whole swathe of gaps that, yes, a competent enterprise-architect and/or service-architect should be able to fill from their knowledge of other models, but overall it’s pretty fragile, and not an approach any sensible architect would recommend. If we use the EC, by contrast, it’s already designed to work at those levels, with all of the flows and integration and so on.

    In short, the BMC is unquestionably excellent for what it was designed to do: business-models at the abstract level (mainly the Zachman row-2/row-3 transition). It’s a specialist model, optimised for that one purpose. You can sort-of use outside of that range, but it’s not designed to do it, and there are all sorts of risks that come with using it outside of that range.

    The EC is a generalist model: it’s not especially optimised for any one task at all. But it does cover the whole extended-enterprise scope, from most-abstract (‘above’ the BMC’s main range) to most-concrete (far ‘below’ the BMC’s main range); and it leverages other models to deal with any specialist concerns in any specific part of that scope.

    Of course the two model-types are related, and (in the case of EC) deliberately designed to be compatible with each other, but they are different, for different purposes, and with somewhat different user-groups, too. That’s all I’m really saying here.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Books by Tom Graves
Ebooks by Tom Graves