I was recently asked to give some help to a team working on an operating model for their Finance function. The prime objective was to upgrade the function, so that it added more value and cost significantly less. The particular discussion was about organization structure: who should report to the CFO, how to free up some of the CFO’s time for interacting with stakeholders and for spending more time on business strategy, and how to resolve the overlaps between “controllership”, “FP&A”, “strategy” and “performance management”. In this company strategy reported to finance.
My first recommendation was to do a value chain map. This was not because I expected there to be significant overlaps or common capabilities across value chains, but because the teams did not seem to have made a clear list of the “value propositions” of the Finance function. You cannot do a value chain map without first defining the value propositions for which you need value chains.
The list of value propositions included things like “Provide a controllership function”, “Provide tax services”, “Provide treasury services”, “Produce management accounts”, “Propose changes to the portfolio of businesses”, “Influence performance outcomes”, “Help set budgets and KPIs”, etc. We had a list of nearly 15 value propositions.
When we laid out the value chains, we noted that there was very little commonality across value chains. Yes, a number of value chains involved analysis. But we concluded that tax analysis is a different capability from internal audit analysis or portfolio analysis. Also, most value propositions involved some partnering with the business divisions. But, we concluded that strategy partnering is a very different capability from treasury partnering or risk management partnering. So we concluded that any organization design for Finance should have a person in charge of each of the value propositions, with all the resources needed to deliver the value proposition. This meant that cost cutting would have to happen within each value proposition or some value propositions should be dropped.
We then needed to think about how to group the 15 (or so) value proposition owners for the purposes of reporting to the CFO. Ideally we only wanted 5 or 6 direct reports to the CFO to help free up some of her time.
Some value proposition owners (or departments) needed to report directly: Strategy, Internal Audit and Treasury. So the question became “how to group the rest” and whether some of the rest could report to Internal Audit or Treasury or Strategy. This raised some interesting debates about whether M&A Support and/or Performance Management could report to Strategy. I counselled that I thought that both M&A and Performance Management were incompatible with Strategy because Strategy is about reasoning, creativity and intellectual rigour, whereas M&A is about deal doing and Performance Management is about holding people’s feet to the fire even when it seems unreasonable. But we observed that many companies do put some of these activities together.
A number of logics for grouping departments were discussed
- Operations type activities, like accounting; specialist departments, like tax, treasury and M&A; departments with heavy interaction with business divisions, like FP&A and Strategy
- Activities with an “innovation” orientation, like Strategy and Tax; activities with a “customer intimacy” orientation, like FP&A and Risk; activities with an “operational effectiveness” orientation, like Management Accounting or M&A support
- Activities that are primarily about setting policy, like Controllership and Risk; activities that are primarily about shared services, like Management Accounting and M&A support; activities that are primarily about “influencing”, like Strategy and Performance Management
To date, no decisions have been made. But I thought you might find the process of thinking interesting.
Ashridge on Operating Models 
I wondered if it would be interesting / helpful to outline how I might have responded to such a request? On the assumption that the answer would be yes …
The first question I would ask and explore with them is what is the business model for your finance function?
Why? Because if the business model needs re-thinking, there is no point in exploring the operating model or the value chain.
What would the business model discussion entail? Questions like:
a) What products or services does your finance function offer? What other products or services might you offer?
b) What value do these current or future products and services provide to your “customers”?
c) Who are your customers? Who else might be your customers?
d) How do you differentiate these services? ie. why should they be provided by you as opposed to some other function in the business or by an external provider?
e) What channels do you use to provide these products and services? Are there other channels through which these services might be offered in more convenient, more accessible, more value-adding ways?
Peter, Great contribution. The reason I like the value chain map tool is because it requires answers to all of the questions you are asking. Of course the tool assumes that the leaders have already decided what customers to focus on and what products and services to provide and what channels to use and what sources of excellence to focus on. And, you are correct. When you start asking these questions (in order to complete the value chain map) you often get unclear answers, which pushes you into having a strategy or business model discussion before you can start describing the value chains. We are on the same page …. except, possibly, that once the business model is clear, I then lay out the value chains, whereas you may choose to do a capability map. So maybe you should describe your next step. What do you do once you have clear answers to your business model questions?
Andrew
Short answer is explore their operating model and the extent to which it supports the now clarified business model
Slightly longer answer is that the capability model is after operating model, not before
This is a very significant point Peter – the capability model comes after the operating model. It puts us even more on the same page. I have always felt uncomfortable about capability models because, without a clear operating model, they have a tendency towards “over normalization”, where capabilities are assumed to be similar when they are not. But if the sequence is strategy/business model to decide what we want to do, then operating model (processes, people, organization, etc) to decide how we want to do it, then capability model to decide where we have capability gaps and immaturity, and where, in the operating model, there are duplication of capabilities, we may finally have complete agreement. It is just not my understanding of what is taught to BAs and EAs.
Andrew – I am glad to hear we are more on the same page than perhaps we had each realised!!
You might recall that many of my comments to you have been about not judging the suitability and value of capability modeling on the basis of poor practice. I don’t have any real insight into what BAs and EAs are taught. I would not be surprised that what I have described is not taught to many BAs and EAs.
As you know from the first article of mine that you encountered, I have had a longstanding goal of communicating and practising EA and BA using plain business language – hence, my longstanding articulation of giving attention to:
a) business models
b) operating models
c) capability models
You might wish to re-appraise yourself with the Enterprise Transformation Lifecycle that I have been using as the central means of communicating my thinking and practices – see https://enterprise-modeling.org/concepts/
I can advise that:
a) all clients have indicated that what I outline and do makes sense to them
b) many clients indicate that it does not offer anything particularly new but that it offers assurance to have a more structured approach
c) a key element in my thinking and practice is to ascertain “how best to determine the quality” of any model (I don’t find many others asking and answering this question).
Fully agree with your model Peter, although I might give less attention to the capability modelling element (or give the same amount of attention, but by using a value chain map as my tool). I don’t know how we managed to be in debate all these years! Maybe we have both evolved over the course of the debate. By the way, I could not find navigation to the “bringing it all together” location on you site, so could not access the detailed descriptions of your model elements.
Bringing it all together is the right hand menu item at the top
Two comments:
a) organisations are a complex inter-weaving of capabilities – value chains can being risks of linear thinking
b) capability modeling is more valuable at the capability assessment stage than modeling stage – if you have developed and assured the quality of your value chain (and I would ask you how you do the latter), then capability assessment would follow completion of the value chain mapping.
Note the use of the word “mapping” – whether dealing with capability or value chain – there is an unavoidable mapping / modeling process. It is the quality of the map or model or chain that is critical, not the method or the descriptive technique or the label.
Peter, please expand:
-1) on a). Why do you think value chains can create risk of linear thinking?
-2) on b). For those from the “process world” – we can decompose the value chain into process (business process architecture) – and use those process building blocks in much the same way as you seem to think one needs the concept of “capability” for. From a lean perspective, one would mean much the same with saying “analyze the flow of the process” as you mean when saying “analyzing the process of the capability”. What is you thoughts on this? Thanks 🙂
Hans-Christian
There are several reasons, based on what I have observed around results, more than observation of someone actual developing a value chain, so I am not in a position to comment on the actual thinking that has occurred, per se. There may also be issues around what is assumed to constitute a value chain.
Reasons that come to mind include value chains that I have seen:
a) incorporate a core value stream, which is a linear input / process / output = input / process / output = input / process / output – which in itself is necessarily “linear”
b) have not always considered options where elements of the stream are provided by partners or third parties
c) have not always tested multiple streams where some elements are common and others unique or where an intermediate output is a valued external output in its own right
d) have not explored the inter-dependencies and potential opportunities for greater efficiencies in the support processes that are not part of the core value stream
Perhaps, here I am guilty of the same thing that concerns me with Andrew’s comments – I am making judgements based on poor examples, rather than on high quality value chain expressions?
Hans-Christian
In relation to (b), my primary comments would be that my experience (including some based on leading practitioners) that a process perspective is “fine” as long as it takes account of the possibility that the deficiency is not in the process but in the thinking, behaviour, culture and practice of the people performing the processes. Too many times, I have encountered a process advocate trying to design a “better process” when the primary issues are the people issues not the process issues.
I find that the capability lens helps participants think about multiple dimensions and not just the “process” dimension.
That said, I have often been amused to find the capability and process advocates are actually in violent agreement yet seem to feel that they hold opposing views that need further debate and detailed explanation!
Peter and Hans- Christian, In my view, all frameworks and lenses are a simplification of reality, so they bring a bias with them. If one understands the bias, then one can protect oneself and others against it. I have come across the examples that Peter mentions, which, as he points, out are the result of poor usage or less experienced users.
Yes, Peter, thinking about the inter-weaving is critical to good operating model design. I do this in four ways. First through the value chain or process flow way of looking at the organisation: the most critical thing is to get all the capabilities in a process flow aligned. Then in the way the “operating work” is structured into an organisation: is it a single value chain or units each with their own value chain or a matrix? The inter-weaving is very different in these three different models. Third, in the roles allocated to support work – policy, champion, shared service or core resource. Each role is a different type of inter-weaving. The fourth is in the way that supplier contributions are woven into the organisation.
Andrew, could you link or refer to reading material on more details on “the way the “operating work” is structured into an organisation… The inter-weaving is very different in these three different models.”?
Hans-Christian, The best resource is my blog http://www.ashridgeonoperatingmodels.com. An article on the three types of organisation is https://795bbfb0-d975-4f7e-ba92-1b9e41df44ea.filesusr.com/ugd/6fbdc9_308765c0b8314f02b7abe314de1e9a9f.pdf
Thanks for sharing Andrew! Very interesting to see your thought process, and I am happy to find that mine is very similar.