The interest in Lean in the US was initiated by the publication, in 1990, of The Machine That Changed The World: The Story of Lean Production by James P. Womack, Daniel T. Jones, and Daniel Roos [1]. Since then, those engaged in process change have not only learned a lot more about Lean, but have also explored a variety of complementary perspectives. The idea of process maturity, for example, has evolved as a popular way of describing the steps that organizations tend to go through as they learn more about processes and acquire more capabilities.
The best known overview of the process journey that most organizations follow is provided by the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) which is illustrated in Figure 1 [2]. What research and assessments have shown is that organizations spend years developing their process capabilities, and that they tend to acquire their capabilities by means of a rather consistent sequence of steps. For examples, organizations new to process begin by focusing on core processes within specific departments. Only after they have developed some experience and success at redesigning these processes do they venture to try to understand the broader processes that cross departmental silos and define the organization as a whole. And, later still, only after organizations have even more experience in process change, do they begin to create good process measurement systems or assign managers to manage processes. Only mature organizations create enterprise-wide systems in which processes and measured and managed and every employee knows how their work fits into the enterprise wide system.
In hindsight, we can see that Womack, Jones, and Roos, in describing Toyota, were describing practices and techniques being used by a CMM Level 5 organization. On the other hand, their initial emphasis on Muda (waste) makes good sense, since that technique is particularly appropriate for CMM Level 2 and 3 organizations, which is where most organizations, worldwide, find themselves.
Business Process Management
Leaving Lean and Process Maturity, for a moment, let's consider an alternative approach – Business Process Management (BPM). Broadly defined, BPM has always been a part of process change initiatives, of course, but it has recently received much greater attention. BPM was probably given its first contemporary definition in 2001 by Roger Burlton in his book Business Process Management, which focused on how organizations needed to treat processes as assets that are managed in a centralized, systematic manner [3]. Business Process Management seeks to pull together all of the various threads of process change into a single approach that can be managed has become increasingly popular as organizations focus on developing organization-wide business process architectures and comprehensive process measurement and management systems.
In 2003, a book by Howard Smith and Peter Fingar, Business Process Management: The Third Wave, offered an alternative way of using the term “BPM,” and suggested that the Internet, Internet protocols like XML, and new software languages like Pi Calculus made it possible to create a new generation of workflow software products that could not only model processes, but automate the execution of the processes and provide managers with detailed information about each process [4]. In essence, these new software applications provide a much more flexible way to approach the development and ongoing management of Enterprise Resource Planning (ERP) applications. After some confusion, the market seems to have reached a general consensus, and has agreed to term these new software products as “BPM Software” (or BPM Systems, BPMS), leaving the shorter acronym, BPM, for the broader process management effort that embraces all aspects of process work [5].
BPM, as it is currently used, includes not only the work of managing an organization's process efforts, but is also concerned with maintaining various methodologies and technologies that managers use to monitor processes and to effect process change.
Today, many BPM theorists would say that there are three broad approaches to changing an organization's processes [6]. There are (1) top-down approaches that emphasize an organization-wide process architecture, process measures and process management, there are (2) bottom-up approaches that emphasize specific processes or activities to be improved, and there are (3) IT-based approaches that tend to focus on using software applications to automate processes. As a further generalization, top-down efforts tend to focus on projects that lead to major changes, while bottom-up approaches tend to focus smaller, incremental changes initiated by employee teams. IT process automation efforts usually fall somewhere in the middle, alternating between major projects and incremental continuous improvement efforts. (See Figure 2)
There is, of course, no one correct approach to process change. As CMM has suggested, organizations evolve as they learn more about processes and their needs change. Similarly, Michael Hammer, in his talks on process reengineering, often used the chart shown in Figure 3 to emphasize that each specific business process, in the course of its lifecycle, required different approaches at different times [7]. When a process is created, or when major changes in technology are taking place, a concentrated top-down effort is often required to make many changes, quickly, or to assure that incremental changes to different processes don't cancel each other out. In between, incremental improvement becomes the preferred strategy.
Although BPM practitioners are interested in and support all process approaches, they often focus on top-down approaches because they are particularly concerned with understanding how all the processes and measurement systems can be managed in a holistic, systematic manner.
In this chapter we will provide an overview of the approach that some leading BPM process practitioners take to defining the processes in an organization. We will show how an organization can be conceptualized, from the top-down, in terms of Value Chains, Stakeholders and Value Streams. Later, we will consider how IT can be described in these terms.
Value Chains and Value Streams
Lean practitioners have tended to focus on the concept of a Value Stream, which is an evolving concept. The best known definition of a Value Stream was offered by Mike Rother and John Shook in their book, Learning to See [8]. Figure 4 provides an overview provided by Rother and Shook. A key feature of the Value Stream approach is that a stream is initiated by a stakeholder outside the organization, and the stream shows the steps the organization goes through to provide a response to the stakeholder. This is exactly how Steve Bell describes a Value Stream in Part One of this book.
BPM practitioners are more familiar with the concept of a Value Chain, as defined by the Harvard Business School professor, Michael Porter, in his popular book on strategy, Competitive Advantage, published in 1985. Porter was focused on costing the production of a line of products or services when he created his definition, hence he argued that “Every firm is a collection of activities that are performed to design, produce, market, deliver, and support its product. All of these activities can be represented using a value chain…” [9]. Figure 5 is taken from Porter's book.
Small organizations tend to only have a single Value Chain, so that the definition of the goals of the company and the Value Chain are essentially the same. Most large organizations, however, support more than one Value Chain. That means that they produce more than one product or service which they sell to different customers. Figure 6. pictures the situation at Michelin where the same organization produces tires and researches and sells restaurant guides [10]. The first step in defining the process architecture of any large organization is to agree on the number of Value Chains the organization maintains, and, thereafter, to analyze each Value Chain, independent of every other.
A Value Chain is defined by a Customer Value Proposition – a description of the value a group of customers expect to obtain from the Value Chain [11]. Focusing on the Customer Value Proposition, which is abstract, rather than on specific products or services, or existing lines or units of business, makes it easier to assure that one is focusing on what customers actually want, and to assure that one won't be blindsided by competitors who might seem to be selling a different product or service, but who are, in fact, satisfying the same customer need. For example, it is better to say that a customer needs information or entertainment rather than to imagine he or she needs paperback books. If you focus on selling paperback books, you may be surprised to find that a digital book seller is taking away your customers.
If we think in terms of Value Streams, we can define multiple customer Value Streams. Thus, for example, there is (1) a Value Stream that describes how a customer decides to purchase a product/service; how he or she inquires, buys and receives something in return. Assuming it's a service – say a checking account – the customer continues to interact with the company once the account is established. Thus, every transaction, from depositing a check, to writing checks, to transferring money from a checking account to a savings account, online, are instances of (2) a second, transactional Value Stream. Then there is (3) a third Value Stream which occurs when a company monitors customer behaviors and new technologies, and determines that a new product is possible. This is a more abstract Value Stream but you can, in essence, assume that the stream begins with a customer need, that the company figures out how to fulfill that need, and then generates a new product or service and then proceeds to offer it to the customer.
Figure 7 pictures three Value Streams, all within a single Value Chain, that would each begin and end with a customer.
Customers and Other Stakeholders
Notice that in Figure 7 we have reduced each Value Steam to a process box. One way to think about a Value Stream is that it's an important Level 1 Process of the Value Chain. A Value Chain, has, in essence, one major Level 1 Process for each Value Stream it supports.
Many have spoken as if the customer was the only stakeholder who had an interest in whether a Value Chain succeeded or failed. In fact, every Value Chain has multiple stakeholders. Shareholders who buy stock have a vital interest in the success or failure of a for-profit organization's Value Chains. Government regulators often have an interest. Similarly, employees, in deciding whether to continue to work for an organization or not, are key stakeholders. Figure 8 pictures some of the stakeholders who have an interest in a Value Chain. Figure 9 reformats the stakeholder diagram and suggests some of the Value Streams that exist to support the stakeholders of a Value Chain. In essence, a Value Chain should have one or more Value Streams for each stakeholder who has an interest in the success or failure of the Value Stream.
To clarify our vocabulary, value chains, value streams, and subprocesses and activities are all types of processes. Process is the generic term. Value Chains and Value Steams are processes that have external stakeholders. Value Chain theorists usually subdivide a Value Chain into level 1 processes (subprocesses of the Value Chain) and then divide level 1 processes into level 2 processes (“fractal” sub-subprocesses of the Value Chain) and so on. It's not unusual, in a large organization to find 5-7 levels of processes. We argue here that the Level 1 processes of a Value Chain are Value Streams. The subprocesses that make up a specific Value Stream are, from the perspective of the Value Chain, Level 2 processes. Other authors in this book prefer to decompose Value Streams, and would, in effect, speak of a Value Stream as having sub-value streams, but we prefer to refer to subprocesses of a Value Stream as “processes” – simply to underline the idea that the subprocesses of a Value Stream do not provide outputs directly to external stakeholders – although we will see, in a minute, support processes are an exception to this.
We understand that Figure 9 may look rather complex on first sight. Keep in mind that this type of analysis would only be done when a team was trying to understand the process architecture of an entire organization – a situation in which complexity is unavoidable. Our approach has the advantage of defining a Value Chain in terms of Value Streams, thus actually reducing the complexity one ordinarily encounters in Value Chain analysis, while unifying BPM and Lean in a systematic manner.
In Figure 9 we pictured the IT group as an outsourced group that nevertheless provides processes that are used to produce value for the organization. Thus the IT group is a stakeholder – it has an interest in the success of two major Value Streams. The company wants applications and later changes and the IT group provides them. Similarly, the company wants day-to-day support for customer transactions, which the IT group also supports. Note in the case of these two value streams, they originate with specific business processes that exist in the value stream. In essence, in these cases Value Chain processes are the stakeholders that need services from IT.
A slightly different situation occurs in the case of Human Resources, where the stakeholders are employees who work for the company and expect pay and benefits in return. In this case it's helpful to represent the employees as stakeholders of the organization who receive pay for the work they perform as they undertake work for one or more processes within the Value Chain.
If we begin to define the subprocesses (Level 2 processes) in particular Value Streams we often find that there is overlap. A subprocess that plays a key role in a Provide Services process value stream is monitored by finance and thereby also plays a key role in Value Streams that support management decision making, regulatory and shareholder reporting. Thus, while each Value Stream can be conceived as a flow beginning with a need of the stakeholder and ending by satisfying the need of the stakeholder, the activities (Level 2 processes if you prefer) may be used in more than one Value Stream. In other words, once one reaches level 2 processes, one finds that a Value Chain is, in fact, a network and not a simple linear or even a simple circular flow.
This approach, as we suggested, is more complex than normal Value Stream representations usually suggest, but it actually clarifies a number of issues. First, Lean practitioners have always had problems with the distinction between Value Adding activities (VA), Necessary but Nonvalue activities (NNVA), and Nonvalue activities (NVA). Considered from the perspective of the Value Chain, and multiple stakeholders, NNVA activities vanish. All activities either add value for one of the key stakeholders of a Value Chain, or they are NVA and should be eliminated. What is NNVA, from the customer's perspective, is never-the-less required to create value for regulators and for shareholders of the organization. Similarly, other activities, like hiring new employees, or accounting for their pensions, which are also of no value to customers, are value adding activities for employees. And without the ability to attract and hold good employees, an organization's Value Chain will fail just as surely as if it fails to attract and hold customers.
An Aside on Support Processes
In passing, it's worth noting that support processes sometimes reverse the pattern normally found in the other Value Streams we have been discussing. Real support processes are recognizable because (1) they are not part of the direct flow of any Value Stream, and (2) they tend to support all or nearly all of the processes that are involved in every other Value Stream. The value of Support Processes lies in their support of core or Value Stream processes that could not proceed efficiently without them. In Figure 10 we have suggested some possible support processes for a set of core processes at a major oil company. We do not normally include support processes on process flow diagrams, because they would turn the more or less clear flow into a tangled network that would be hard to read. When we try to create organization-wide process architecture, however, it is necessary to have a conceptual approach that can account for these complex interactions.
In many cases the “stakeholder” for a support process is a process within another Value Stream. Thus, we have a Value Stream that Sells Financial Services to bank customers. That Value Stream has a variety of Level 2 processes, including Plan Sales Call, Make Sales Call, Prepare Offer, etc. At any time, the manager of this Value Stream might decide he or she needed a new salesperson, and contact Human Resources to initiate the Hire New Employee Value Stream. Similarly, any of the Value Stream processes might want to use corporate application services, such as email, in conjunction with a process and that service would, effectively be provided by an IT Value Stream called Provide Corporate Application Services designed to provide corporate applications services to employees. Just as a regular Value Stream might service many different bank customers, the Support Value Steams serve many different Value Streams or Level 2 processes throughout the organization.
This whole approach might be easier to think about, if you considered that IT and HR might be outsourced, in which case your organization would be the customer of the outsourcer, and pull services as needed.
Process Performance Measurement
So far we have focused on understanding the overall process architecture of a Value Chain and determining the stakeholders and the activities involved in providing value to each of the stakeholders. We mentioned in passing, however, this approach would also help systematize defining our Value Chain goals and measures – which we usually speak of as Key Performance Indicators (KPIs).
Organizations capture KPIs in different ways. Unfortunately, too many capture KPIs only in the context of their functional departments, and lack good measures of how successful they are in providing value to customer. Moreover, having captured KPIs using traditional departmental approaches, they lack a systematic strategy for working back from results to causes and thus identifying sources of problems.
This Value Chain/Value Stream architecture works well when one sets out to create a systematic process measurement system. Different organizations use different approaches, but one common approach is a scorecard system that monitors a mix of measures to assure that an organization is serving all of its key stakeholders. Using this approach, it is common to divide a balanced scorecard into four cells: Financial, Customer, Process and Innovation measures [12]. If one were to try to relate all of these measures to the creation of value for customers, one would have a hard time.
Once one determines that a comprehensive set of performance measures for a given Value Chain should satisfy all key stakeholders, then the problem becomes much clearer. One creates a matrix, lists each stakeholder on one axis, and asks what measure or measures the organization should track to determine if the stakeholder is being satisfied. If you have three Value Streams associated with Customers, you should expect three sets of measures (Figure 11) one monitoring Customer satisfaction with opening a new account, one or several monitoring Customer transactions on a day-by-day basis as the service is used (e.g. check cashing, auto loan payments, withdrawals), and still another set of measures that monitor the organizations ability to introduce new products that please existing customers or attract new ones. In a similar way, there should be financial measures that monitor the organizations ability to provide a good return on capital acquired from banks or shareholders, and still others that determine how well the organization succeeds in hiring and retaining key employees, etc.
Some stakeholders are more concerned with certain types of goals and measures that others. Thus, shareholders are interested in market share and customer satisfaction, but they are especially focused on the organizations financial position and on ROI. Similarly regulators may be interested in financial issues, but some are only interested to know that particular regulations are followed in the course of specific activities (E.g. that milk is properly pasteurized or that prospects are notified of certain rights.)
Working from a comprehensive description of the stakeholders in a Value Chain, a team can identify goals and KPIs for each key stakeholder and then use them to assemble a comprehensive set of scorecard measures [16].
Once the scorecard for a value chain is defined, it can be used to determine if the value chain is, in fact, working to maximize corporate goals and strategies (upward alignment) and it can be used to define the goals and measures for specific Value Streams and for the Level 2 processes that compose each Value Stream. This downward alignment focuses the organization on assuring that Level 2 processes support Value Streams. Moreover, if the Value Streams have process managers, then the scorecards also serve as a performance measurement system for the process managers. (See Figure 12)
Lean, BPM and IT
IT is usually conceptualized as a functional or departmental unit of an organization. In other words, IT is a source of capabilities and techniques. The head of the IT group is assumed to be an expert in hiring, training, and overseeing IT development and operations.
Until recently, IT has often been conceptualized as a source of support processes. There were the core processes of the organization that generate a product or service of value to customers, and then there were support processes, like IT and HR that provided support for core operations. Recently, it has been popular to outsource IT, or to at least conceptualize IT as if it were outsourced. In this case, one then reconceptualized IT as a unique Value Chain (as an outsourcer does) that generates services that are sold to various clients. Neither of these options is really optimal when thinking about a process architecture in a modern service organizations.
First, considering the example of our hypothetical bank, it's almost impossible to separate a bank service from its implementation as a software application. Imagine a new savings account service that will provide customers with daily interest on their balance. Talking about such a service is only possible because someone in IT has figured out how to create a software program that can monitor customer savings accounts and efficiently calculate and transfer interest to each account on a daily basis.
From a process management perspective, where the activities originate or where the employees reside is irrelevant. You manage a process to assure that the process generates the value required. Every activity that is involved in generating that value should be under the control of the process manager. Thus, if we have a bank manager who is in charge of Provide Financial Services, and one activity is, in essence, a software application that manages the transactions for savings customers, that application is part of one of the key Value Streams and should be under the control of the process manager.
Process Management
We have touched on the importance of a process architecture and on defining a good measurement system. The third element that any BPM practitioner would consider is how one organizes the process management system within an organization. As with measurement, there is no one answer, but most organizations end up with some kind of matrix organization, where departments or divisions continue to exist and are responsible for particular capabilities, while Value Chains and Value Streams are managed by other managers who are responsible for seeing that every activity involved in the creation of a specific type of value is considered as part of an overall process. Figure 13 suggests how one might organize a process management system.
As you can see by glancing at the Figure some software applications may be staffed by IT people, but the activity is also part of the Provide Financial Services Value Chain, and hence also a concern of the Value Chain manager. In this example, one process, Develop Product/Service Operations, has two managers, an IT Development Manager and the manager for the Provide Financial Services Value Chain. How issues like reporting, salaries and bonuses works out for employees involved in these activities varies greatly from one organization to the next.
Separately, however, you can see that real support processes, like those that provide enterprise software, email or that upgrade operating systems, are entirely under the control of the IT Group manager.
For most organizations, creating a systematic process management system is something they approach only after they have an organization-wide process architecture and a process measurement systems in place. Most organizations focus on having Value Chain and, perhaps, Value Stream managers, but rarely go below that. In essence, mid-level managers often wear two hats and function as both departmental and process managers.
If an organization has a balanced scorecard system that embraces both its departmental organization and its major processes, mid-level managers often find that they have goals and metrics assigned by both departmental heads and Value Chain managers, as illustrated in Figure 14 In effect the organization scorecard has both process and departmental measures. They are subdivided for the different managers, but come together again, in the narrower and more concrete scorecards of middle managers.
Most organizations that undertake Lean projects are at Level 2 on the CMM maturity scale. In essence they are focused on improving specific projects. This is where most organizations begin the process journey. As time passes and projects are successfully completed the organization becomes more knowledgeable and is capable to creating an enterprise-wide architecture. Some do this, and then proceed to move on the enterprise measurements systems and, ultimately to enterprise-wide process management systems. Unfortunately, too many organizations, whether they use Lean or some other process approach, remain at CMM Level 2, focusing on specific projects and not developing an organizational awareness of how to integrate, measure, and manage processes throughout the entire organization. An awareness of BPM can help Lean practitioners think about issues they need to address if they want move their organizations toward a more comprehensive approach. [13]
Although we don't have time to discuss it here, most organizations, when they reach Level 3 or 4 on the CMM maturity scale, set up some kind of group to coordinate process management work. In many organizations this same group may function as the coordination point for Lean and Six Sigma efforts. An effective BPM Center of Excellence depends on having a comprehensive organization-wide process architecture and good process metrics. If they are available, the center can be very systematic in monitoring which processes require improvements and in assuring that changes to optimize one subprocess don't suboptimize other processes.
Summary
Figure 15 suggests some of the relationships between organization process maturity and architectural and process management activities. Level 2 organizations are just getting started on the process journey and focus primarily on fixing broken processes. It is only as organizations gain more experience in process work that they realize that they need to think more broadly about processes. This usually occurs when people in one process or Value Stream complain that they aren't able to do their job because they are getting the wrong or deficient inputs from some external processes. Once an organization begins to think in terms of Value Streams and proceeds to organize all their processes in a systematic manner, they usually proceed to define good metrics for evaluating the success of each of the Value Streams and the Value Chain, as a whole.
Once senior managers have a clear picture of how processes define the work that the organization does to meet stakeholder expectations and have good metrics for evaluating Value Streams and Chains, they naturally tend to want someone to be responsible for achieving those metrics. Good process metrics are rarely the kinds of things that departmental managers want to be responsible for – from a departmental perspective there are too many things that are out of their control, that happen in different departments – and this leads naturally to the idea that the organization needs a manager for the entire value chain – someone who is in a position to coordinate all the activities, no matter where they occur, that provide value for a particular group of stakeholders.
Consider Figure 15. SEI has been conducting studies of companies for over a decade. What they consistently find is that most organizations are at CMM Level 2. They have some core processes defined, but do not have an integrated process architecture. In essence they are (1) focused on improving specific processes. As companies run into problems that arise when specific processes are uncoordinated, they tend to move toward trying to understand how all of the processes in the organization fit together. This leads them to consider large processes, like value streams and value chains, and, ultimately, (2) to begin to specify an organization-wide architecture. Once an organization has a reasonably good overview of its major processes, it (3) tends to define process metrics and to think about how to organize its management system to assure that its value chains and streams achieve the metrics. We think of these two levels, which are approached rather differently in various kinds of organizations, as laying the foundation for serious Business Process Management. In essence the organization creates the assets it needs for serious BPM. These assets, in turn, (4) are used by business executives and by practitioners in a BPM Center of Excellence to manage, coordinate and support ongoing process efforts in the organization.
Even when BPM is being practiced, there is still (5) the need for the continuous improvement of specific processes. The main difference is that before BPM was established, processes were chosen and improved in a somewhat random manner, and after the organization has made a commitment to BPM and developed resources, it is more systematic in identifying processes with problems and prioritizing its efforts. And, perhaps more important, it has metrics and management systems to follow-through to see that changes are fully implemented and maintained.
We have tried, in this chapter, to discuss Business Process Management in terms that will be more familiar to Lean and IT practitioners, although there have no doubt been places where a Lean or IT practitioner would have preferred a slightly different term. The fact is that there are a number of different types of process practitioners today – from different traditions. Each of us, as we deal with the problems we face, gradually realizes that we have much to learn from those in other traditions. And each tradition is gradually expanding the concepts and techniques it includes within its boundaries. Hopefully a new, broader process profession is in the making.
It won't make much difference what we call the new approach, but it should embrace some top-down concepts, some incremental, bottom-up concepts, and concepts from other domains like Lean, IT, business rules, process mining, and change management. We'd like to call this emerging “big picture” Business Process Management, but, ultimately, it isn't the name that's important. What's important is that we create a comprehensive approach to improving the performance of our organizations and increasing the value our organizations deliver to our stakeholders.
[1] Womack, James P., Daniel T. Jones, and Daniel Roos. The Machine That Changed The World: The Story of Lean Production. HarperCollins Publishers, New York, 1990.
[2] Paulk, Mark C., Charles V. Weber, Bill Curtis, and Mary Beth Chrissis, et al. The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley, Reading MA, 1995.
[3] Burlton, Roger T. Business Process Management: Profiting From Process. SAMS, Indianapolis, IN, 2001.
[4] Smith, Howard and Peter Fingar. Business Process Management: The Third Wave. Meghan-Kiffer Press, Tampa, FL, 2003.
[5] Probably the best way of tracking the evolution of BPM and BPMS is to read The State of Business Process Management, 2010, written by Celia Wolf and Paul Harmon. This report on three surveys undertaken in 2005, 2007 and 2009 provides a clear picture of the evolution of the use of BPM and BPMS. The report on these surveys is published and available without charge from www.bptrends.com.
[6] See Paul Harmon “The Scope and Evolution of Business Process Management,” a chapter in the Handbook on Business Process Management, 1: Introduction, Methods and Information Systems, by J. Vom Brocke and Michael Rosemann (Eds.) which is published by Springer, Heidelberg, 2010.
[7] Figure 3 is modeled after a figure used in a talk by Michael Hammer attended by the lead author, circa 1995.
[8] Rother, Mike and John Shook. Learning to See: Value-Stream Mapping to Create Value and Eliminate Muda. Lean Enterprise Institute, Brookline MA, 2003.
[9] Porter, Michael E. Competitive Advantage: Creating and Sustaining Superior Performance. Free Press, New York, 1985. Figure modified from Figure 2-2 on page 37.
[10] This diagram is a variation on an Organization Diagram that Geary Rummler has popularized in his work. It puts the emphasis on picturing an organization as a system (or process) with inputs and outputs. See, for example: Geary Rummler, Alan J. Ramias and Richard A. Rummler. White Space Revisited: Creating Value Through Process. Jossey-Bass, San Francisco, 2010.
[11] Anderson, James C., James A. Narus, and Wouter Van Rossum. “Customer Value Propositions in Business Markets,” in Harvard Business Review, March 1, 2006.
[12] Kaplan, Robert S. and David P. Norton. The Balanced Scorecard: Translating Strategy into Action. Harvard Business School Press, Boston, 1996.
[13] When Steve Bell read this chapter, he noted “In my experience, most organizations I see taking the lean journey do so from a bottom up perspective, lacking the systemic view to create a rational process orientation and ownership. I believe this is one of the key reasons why many well intentioned Lean transformations fail!! The fundamental premise of Lean is that organizations manage their activities along value stream alignment, but few seem to be able to work themselves through to the matrix management relationships that are part of a Business Process Management and Measurement System in a sustainable and rational way. There is a significant opportunity for Lean programs to leverage the power of BPM process architecture, process ownership and measurement.” We agree.
[14] This and other diagrams from this article were originally created for and are used in the Business Process Trends Associates BPM methodology, in course taught worldwide.
