BPM Strategies – August 2006
Written By: Performance Design Lab
CEO observations on the utility of the Business Process Architecture (BPA)*
The BPA Framework provides all the executives with a common view of all the components/processes of our organization – on one page. The complete document set* is a concise summary of the value-add work that must be performed and managed to provide value to customers – the operative word being work. The picture is a work-centric picture and does not reflect who does the work – so the primary focus of our dialogue, our troubleshooting, our decision making stays on the work and does not descend into fiefdom focused discussion. Developing the BPA was a key step in breaking from our traditional silo-view of the company.
It provides everyone involved in delivering value to our customers with a common vocabulary for describing processes – from executives to summer interns and engineers to sales reps. In the past, we were constantly talking past each other when citing processes – different interpretations of the level being discussed, ranging from procedures, to department level activity flows and large cross-functional business processes. You can imagine how difficult this made life for our support functions like IT and HR that needed to understand the business processes in order to support them.
The BPA has been a very useful strategy implementation framework. Whenever we consider a change in our strategic direction, we look at the BPA and determine what would have to change in the output requirements and/or capabilities of what processes in order to successfully implement that strategic change. That relatively quick exercise has resulted in tabling several efforts that we otherwise would have pursued. And in the case of the several efforts we have initiated, the BPA helped generate a clear roadmap of what had to be done, when, for successful implementation. No more “Ready, fire, aim”.
As part of a larger strategy formulation effort, we are currently looking at the Primary Processing Systems (Launched, Sold and Delivered) and processes therein, to see where we have or should have competitive advantage built into our Value Creation System. The IT organization is showing us where technology developments are heading and where those can be used to advantage in our processes. The plan is to have a “future state” BPA, from which we can create a summary of future capability requirements. We will then leverage every opportunity to be building in the future capabilities we need whenever we touch a process or IT system.
The BPA provides another strategy – operations link by helping us evaluate how/where processes are performed. For example, there may be processes we would be better off outsourcing rather than expending internal resources.
*Document Set consisting of:
- BPA Framework
- Cross-Functional Value Chain Maps
- Select Cross-Functional Process Maps
Since these are maps of the value-add work that must be done to meet customer expectations, we use them to assess the impact of proposed changes on that work system. As a management team, we ask what will be the impact on the total organization system of:
- A reorganization of functions?
- Increasing/reducing the resources in an area?
- Increasing/reducing the amount or rate of throughput in an area?
- Altering the requirements (quality, cycle time) in an area?
The BPA has been a God-send for managing initiatives. We map all major initiatives on the BPA. At a glance, we can see where every Six-Sigma, process improvement, IT or training initiative in the company is focused. Now, before any major initiative is OK’d, the executive teams ask, “What part of the work system are you impacting, in what way? How will that proposed initiative impact work necessary upstream and downstream?” (Frequently, we drill-down to the relevant cross-functional maps to get a better understanding of the impact on work.) In addition to the use of the BPA by the executive team, our Process Excellence group has a copy of the BPA on the wall of their “project central” command center. There are numbers all over the map representing all the initiatives going on that impact each of the processes. They stay on top of potential issues of sub-optimization between projects and processes. (The two preceding uses of the BPA deal with one major, on-going concern; AVOIDING SUB-OPTIMIZATION!)
The BPA was a real beacon, showing us where we needed measures to help manage the “white space” between the key processes. A combination of the BPA and these measures makes it possible for the various executive teams to systematically “troubleshoot” poor organization and process performance and identify and correct root-causes. In a sense, the BPA is a giant “fishbone diagram” of our business, guiding our problem analysis. But we don’t have to draw a new diagram with each problem – we already have the relevant organization level diagram on the wall.
The BPA has helped us immensely in the wise management of the various processes. Unlike so many organizations that see the power of process management, we did not just assign process owners to a list of processes. We used the BPA and the cross-functional Value Chain maps to make intelligent decisions around which value creating work needed to be managed at which level. Did we need a “Sales process management team” or was the existing sales function management structure sufficient to manage that part of the work? (The answer was “yes”, the existing sales management structure was adequate.) Did we need some group that could monitor and manage across the Sales Process and Delivery Processes – looking at engagement lifecycle from sales lead to installation? (The answer was “yes”, we did need such a mechanism.) What we have ended up with is management roles and responsibilities that really manage our value chain. I am confident that all the critical work is being managed – that the real-time tradeoffs are being made in the right context, by the right managers, at the right level, looking at the right data.
Our IT function has a version of the BPA that ties our work processes to our data and systems architectures. The CIO can tell you more about how they are using the BPA to their advantage. But going forward, I know that before every IT-related intervention is launched, it is evaluated as to its impact on the total Value Chain and possible contribution to sub-optimization.
We are also getting better collaboration between HR and IT regarding the impact of technology changes on human performers within our processes. We are hiring, training and equipping our people better because both functions have a better idea of what the other is doing and how critical it has become for them to work together on changes to processes that affect how people perform.
Developing the BPA:
I was intrigued with the notion of “business process architecture” for some time before we began our effort here. But most of the examples I saw were either too high a level (knowledge maps, etc.), too low a level (process inventories that identified hundreds of processes), or fundamentally flawed (like those that were organized around data or systems instead of the work). Those views had no value to me as a manager of a business. They certainly didn’t represent how I looked at my organization and I couldn’t see how I could use them to manage my business. But nevertheless, it still seemed like a good idea.
So we moved ahead and we asked a consulting firm for some assistance. Their approach was to bring in a process reference model based on industry best practices. It seemed reasonable at first, but then I learned that one of our biggest competitors used the same model and approach. The more I thought about it, the more I began to question the wisdom of creating a process architecture that was a duplicate of my competitors. It seemed to fly in the face of Michael Porter’s theories of creating competitive advantage through performing processes uniquely and performing unique processes. So we didn’t pursue that approach any further.
Then I contacted a consultant who I knew looked at organizations the same way I did, and they worked with me, my executives and some internal IT resources to bang-out a picture that achieved exactly what I wanted – a giant “Aha, that’s what we need to manage”, from my management team. Our IT folks then went to work to make the necessary connections between our view of the business and what they needed in the way of data, system, etc., requirements. That has lead to the final, big utility of the BPA – it has helped us bridge the business – IT-speak chasm.
To read a case study on a company that we engaged in helping define and use their Business Process Framework (aka (Business Process Architecture), click here.
For a presentation on the topic of the Business Process Architecture, click here.
For information about PDL’s consulting service, where we assist organizations in defining their Business Process Architecture, click here.