Who is the customer?
Who is the customer, in a business model?
That’s perhaps not as simple as it sounds. I’ve been working on a long how-to post on using Business Model Canvas in a non-profit context, and realised that even in a commercial context it can get very messy once we move outside of the relatively simple ‘world’ that the Canvas usually describes.
Business Model Canvas is great for describing a business-architecture. Its structure of Value-Propositions for distinct Customer Segments works very well at the abstract layer. Separation of Customer Segments also allows us to describe a complex multiway business-model, such as in the classic three-way newspaper case: content-providers paid to produce valued content; content-consumers who consume the content, often at no direct cost; and advertisers, who pay to have their messages embedded in the content.
Yet once we move from business-architecture to enterprise-architecture – the overview of the implementation and execution of that business-model – complexities can emerge that could render the business-model non-viable, or at least introduce new ‘gotchas’ that have to be resolved. To make it work, we need to ensure a good balance between business-architecture and enterprise-architecture. One clear example of this is that the meaning of ‘customer’ may be quite simple in a business-architecture, but can suddenly become a great deal more complex within the enterprise-architecture.
In the case typically described on Business Model Canvas, each Customer Segment represents a single type of ‘customer’: such as ‘content-provider’, ‘content-consumer’ and ‘advertiser’, in the newspaper business-model. We assume a single supply-chain for each of those customer-types. And yes, that often is what happens in the simple case of ‘consumer in the marketplace’ (a business-to-consumer or ‘B2C’ model).
But in a typical enterprise-type ‘B2B’ (business-to-business) model, that single ‘customer’ itself splits into multiple sub-customers. The person who buys, the person who deals with the order, the person who receives the item or service, the person who uses it, the person who verifies that it was ‘fit for purpose’, and the person who pays for it – they can all be different people, with different job-titles, all with different roles, responsibilities and authority, and in different parts of the client-organisation. To make our ‘simple’ business-model work, we need to be able to identify and describe all of these sub-models, make sure that each one of them will work properly, and link all of them together into a unified whole.
So whilst it’s valuable to sketch out the business-model on Business Model Canvas, this is where transferring that model onto Enterprise Canvas can help a lot. Enterprise Canvas draws clear distinctions between three types of flows: that which happens before, during and after the ‘main transaction’ of a business-model, such as its delivery of a product or service.
For example, most of the interactions with the buyer and the order-department take place before the main-transaction.
Interactions with the receiver and the user take place during the main-transaction – in effect define the main-transaction.
Interactions with the quality-check and payer (accounts-receivable) take place after the main-transaction.
This applies symmetrically both to ‘customer-side’ (for which we are ‘supplier’) and to ‘supplier-side’ (for which we are ‘customer’).
All of these are ‘customer-segments’ within the one simple Customer Segment on Business Model Canvas. Implementation and execution of the business-model means that all of these need to link together into a unified whole.
To do this, we’re likely to need distinct functions or capabilities within our enterprise-architecture to manage each of these flows and sub-transactions.
This gives us a structure from which to translate from Business Model Canvas.
We can also view that integration in terms of transitions over time. This is where another aspect of Enterprise Canvas – its linkage to the Five Element market-sequence or market-cycle – can help to clarify what needs to happen, when, and in what order, so as to make the business-model work.
The left-hand side on the diagram above is inward-facing, what we do to deliver our own value-proposition; the right-hand side is outward-facing, dealing with those ‘before-‘, ‘during-‘ and ‘after’-transactions with others. In an enterprise context, each node in the zigzag sequence often reflects a change of sub-customer, and hence a different type of ‘business model’ within the overall business-model. Each ‘customer’ is typically dealing with two or more ‘providers’ within our organisation, in order to keep the overall flow moving; and each ‘provider’ is typically dealing with two or more ‘customer’-types, too. Quite a juggling-act to make all of that link together: but that’s what has to happen, to make that business-model work in the real world.
A few more ideas to play with, anyway. 🙂
Over to you: comments/suggestions, anyone?
Tom. Two things. First you appear to regard Business Architecture and Enterprise Architecture as disjunct. I would have expected at least intersection. Well in fact I’d have expected inclusion – if one accepts that Bus Arch is more than just what TOGAF defines. And one does, doesn’t one? So either I have misunderstood or I’m missing something. Help me. Oh wait, I see a link below. I’ll read that first.
Second thing. Your treatment of customer segments is unlike any I have seen before. Doesn’t make it wrong. Nonetheless I have difficulty seeing what you describe as other than roles. In the B2B situation the customer is the other B – seen as a whole. Any entity performing a role on behalf of the customer is merely a representative (or proxy) of the customer. If a customer is an entity you sell to (regardless whether cash changes hands), a segment can only be a class of entities to which you “sell” something. That something is then different from or packaged or priced differently what you sell to another segment. But you don’t sell a different package to the buyer than to the user, approver or payer. I would also argue very strongly from the identity management point of view that you neither want to or should be entitled to know anything about the entity performing a particular role at a particular point in time – other than that the customer, whom you trust , has authorized that entity to perform the functions associated with the role.
Why does this matter? Well partly because there are sufficient well established models such as the IdM one I just mentioned or the TMF’s Frameworx (and in particular the SID), which are founded on the interpretation I just gave. That in and of itself is going to make it difficult to use your approach to segmentation.
And I don’t see why this is necessary to support that complex nature of relationships you describe between supplier and customer. That’s surely the central aspect of your post. It is at least the part which speaks to me the most. In fact it’s the contextual nature of the role each party plays that makes a role based model a better reflection of your semantics than a segmented customer model. Obviously your interpretation is arguable but why invite dispute (and people will dispute it) about something, which is not, as far as I can see, central to your argument.
I was going to say “thing three” and announce that no one expects the Spanish Inquisition but I think this is enough for one comment. But be warned:)
@Stuart Boardman – Stuart – thanks, of course! I’ll reply to this in two parts, because there are (at least) two separate questions.
First, enterprise-architecture and business-architecture being disjunct. To me, yes, they are: biz-arch is a domain-architecture, ent-arch is a whole-scope unifying-architecture, hence biz-arch is in effect a more detail-oriented subset of ent-arch.
Business-architecture is the architecture of business, hence for a single organisation it’s the architecture of ‘the business of the business’: the domain-of-interest for people who would typically describe themselves as ‘the business’, namely those dealing with pricing, products, services, business-relationships, often also positioning, marketing and brands. It’s also often focussed around the organisation of the business – a focus on rules, roles and responsibilities.
Enterprise-architecture is the architecture of enterprise, hence for a single organisation it’s the architecture of how everything links together across the whole shared-space, both within and beyond the organisation’s boundaries. (As I’ve said elsewhere, the enterprise in scope for an organisation’s enterprise-architecture is typically at least three steps broader than the organisation itself: i.e. organisation, supply-chain/customer, market-context, overall business-context (including community, government, anti-clients etc). It’s not a domain-architecture: its emphasis is on how everything connects with everything else and ‘plays nice’ so as to create the greatest overall effectiveness.
Many (most?) domains may and will and extend beyond the organisation’s boundaries: security is an obvious example, also end-to-end links in IT infrastructures and processes. Part of the role of enterprise-architecture is to provide a clear understanding of where the organisation’s own locus-of-control will end, and shift over to direct-via-influence instead.
In that sense, an organisation’s business-architecture is just another domain – hence a subset enclosed within the overall set covered by an organisation’s enterprise-architecture.
When ‘business-architecture’ is mislabelled as ‘anything not-IT’ (or, more generically, ‘anything not-us’, we’re forced into a really crude set-division where enterprise-architecture is simply the sum of ‘us’ and ‘not-us’.
Where enterprise-architecture is misperceived as part of IT-architecture, we end up with a really messy and misleading structure in which business-architecture is ‘above’ enterprise-architecture. We then either have business-architecture forced to take on what is actually the enterprise-architecture role (blurring the domain-architecture function with the unifying-architecture function); or, worse, using the business-oriented domain-architecture as the ‘enterprise-architecture’, limiting the scope of ‘the enterprise’ to the organisation’s own boundaries, and/or providing no unifying-architecture function at all.
More detail on that in two other posts:
– Business architect and enterprise architect;
– What do we mean by ‘business-architecture’?
@Stuart Boardman Stuart, on your second question.
The short answer is yes, they’re roles within a single customer; and no, it’s not a simple as that. In fact those ‘roles’ are often as different as the ‘customer segments’ in a multi-part business-model such as the Google model described in Business Model Generation.
(At this point I’ll freely admit my ignorance and say that I don’t know IdM, and whilst I have worked with TMF’s eTOM/SID, the last time I did so was around seven years ago, so I don’t know its current Frameworx incarnation and I may well be out of date anyway – hence please advise if what I say doesn’t make sense in those terms? Thanks.)
The purpose of this post was to explore what happens when we decompose a BMCanvas business-model towards real-world implementation, and pick out some fundamental ‘gotchas’ in that implementation. One of them was that the B2B model you’ve described often turns out to be a lot more complex in practice than just ‘Customer Segment’ – so much so that we often need to treat them as structurally distinct yet interlinked ‘business-models’ in their own right. And a lot of complexities arise because we need them to be interlinked, both on our side and on the customer-side. (The exact same linkage needs to occur on supplier-side relations, by the way.)
You work for a large IT-oriented consultancy, so you live this multi-part business-model in practice. There’s the business-model of relationships with the decision-makers: most of that ‘business-model’ operates in the more-abstract realms, the kind of interactions that sit in the ‘before’-space of the market-cycle. Then there’s the business-model of the implementation-space – for example, the very different role of technical-sales staff compared to the people who are described as ‘sales-staff’, or the very different roles of senior-consultants (with clients’ decision-makers) versus junior-consultants (implementation-space). Most of that ‘business-model’ operates in the ‘during’-space of the market-cycle, around the main transactions. And then there’s what is structurally a different business-model that deals with contracts and payments and progression and so on, which operates mainly in the ‘after’-space (or ‘completions’-space) of the market-cycle.
Once we understand these as separate but interlinked subsidiary-business-models, we can immediately see some of the classic failure-modes for B2B business-models. For example, often only the ‘sales-staff’ get the sales-commissions, which means that they override the technical-sales staff who may well warn that at the implementation-layer it would not be a good sale – a very important point that can lead to serious ‘gotchas’ in whole-model integration). Then there’s the classic big-consultancy not-quite-scam, where the experienced consultants link with the decision-makers, whereas often barely-competent ‘junior-consultants’ then ‘deliver’ in the implementation-space, often doing little more than following a rule-book are parked in the implementation-space, with no support and no ability to handle real-world complexities. (Disclosure: my first major business was in effect destroyed via exactly that kind of not-quite-scam by a well-known large accounting-firm, so that’s a very sore point for me. 🙁 ) Or there’s the collapse-into-litigation failure, where the payment side (the ‘after’-space in the market-cycle) runs on automatic, without any linkage to the services actually delivered (loss of linkage to ‘during’) or to what was nominally intended (loss of linkage to ‘before’).
So yes, in a sense, they’re all just roles within the one business-model. Yet it’s very useful indeed to use a recursive approach, and view them as if they’re also ‘business-models’ in their own right – because that way we can unearth and pre-empt a lot of potential action/interaction-problems that we don’t want to discover only at run-time or later.
All I’m really saying here is that the simplicity and clarity of BMCanvas can sometimes fool us into thinking that the business-model is a lot simpler than it really is in real-world practice: what I’m aiming to describe here is a systematic process to bring out those hidden complexities and booby-traps before they get embedded in a real-world implementation.
Tom, thanks for both answers. It’s pretty clear we’re on the same track on all the fundamental content (plus you’ve given me some new ideas). We probably still differ on the formality of how that is expressed. So that’s good news.
I still think it will be worth taking the formality (formalism?) further, if only to reduce the risk of being criticized for something not central to your argument. I’ll come back on that soon but today is incredibly busy at work, so I won’t get round to that before this evening at the earliest.