Docsity
Docsity

Prepara i tuoi esami
Prepara i tuoi esami

Studia grazie alle numerose risorse presenti su Docsity


Ottieni i punti per scaricare
Ottieni i punti per scaricare

Guadagna punti aiutando altri studenti oppure acquistali con un piano Premium


Guide e consigli
Guide e consigli

Business Process Change - Summary (Chapter 1-7), Sintesi del corso di Gestione Delle Operations

Summary of the first seven chapters of the book by Paul Harmon

Tipologia: Sintesi del corso

2019/2020

Caricato il 15/12/2020

federico-casati-2
federico-casati-2 🇮🇹

4.5

(2)

3 documenti

Anteprima parziale del testo

Scarica Business Process Change - Summary (Chapter 1-7) e più Sintesi del corso in PDF di Gestione Delle Operations solo su Docsity! BUSINESS PROCESS CHANGE – SUMMARY CHAPTER 1 – BUSINESS PROCESS CHANGE A bit of history We want to provide managers with several different perspectives on business process change in order to give everyone an idea of the range of technique and methodologies available today. People have always worked at improving processes (archaeologists found that potters gradually refined the pot-making process). Other examples come from the Industrial Revolution: managers focused considerable energy on the organization of manufacturing processes. In 1911, soon after Henry Ford launched the Ford Motor Company, Frederick Taylor published “Principles of Scientific Management”. He sought to capture some key ideas that good managers used to improve processes: simplification, time studies, systematic experimentation to identify the best way of performing a task and control systems that measured and rewarded output. From 1911 on, managers have sought ways to be more systematic in their approaches to process change. Also, new technologies have often led to new business processes. Two recent developments in management theory deserve special attention: the popularization of systems thinking and the formalization of the idea of a value chain. Organizations as systems In essence, the systems perspective emphasizes that everything is connected to everything else and that it is often worthwhile to model businesses and processes in terms of flows and feedback loops. Systems thinking stresses linkages and relationships and flows. It emphasizes that any given employee or unity or activity is part of a larger entity and that ultimately those entities, working together, are justified by the results they produce. Systems and value chain Michael Porter is probably best known for his earlier book, “Competitive Strategy”, but it is in “Competitive Advantage” that he lays out his concept of a value chain – a comprehensive collection of all of the activities that are performed to design, produce, market, deliver and support a product line. What is important in this concept is that every function involved in the production of the product, and all of the support services, from IT to accounting, should be included in a single value chain. Only by this way a company is in position to determine exactly what the product is costing and what margin the firm achieves when it sells the product. Gary Rummler was the second major business process guru of the 1980s. His specific focus was on how to structure processes and activities to guarantee that employees – be they managers, salespeople, or production line workers – would function effectively. Rummler and Brache focused on organizations as systems and worked from the top down to develop a comprehensive picture of how organizations were defined by processes and how people defined what processes could accomplish. He provided a detailed methodology for how to analyze an organization, how to analyze processes, how to redesign and then improve processes, how to design jobs, and how to manage processes once they were in place. This methodology did not launch the BPR movement in the 1990s (popular books written by Hammer and Davenport did), but it became the most widely used, systematic business process methodology in the mid- 1990s. One of the most important contribution was a framework that showed, in a single diagram, how everything related to everything else. They defined three levels of performance: (1) an organizational level, (2) a process level and (3) a job or performer level. We will refer to level (3) as the implementation or resource level to emphasize that an activity can be performed by an employee doing a job, by a machine or robot, or by a computer executing a software application. Rummler and Brache also introduced a matrix that they obtained by crossing their three levels with three different perspectives: goals and measures, design and implementation, and management. Approaches that focus only on processes or on performance level measures or on process management are limited perspectives. Mature organizations must align both vertically and horizontally. Activity goals must be related to process goals, which must, in turn, be derived from the strategic goals of the organization. Similarly, a process must be an integrated whole, with goals and measures, a good design that is well implemented, and a management system that uses the goals and measures to ensure that the process runs smoothly and, if need be, is improved. Prior to the work of systems and management theorists, most companies had focused on dividing processes into specific activities that were assigned to specific departments. Each department developed its own standards and procedures to manage the activities delegated to it. Along the way, in many cases, departments became focused on doing their own activities in their own way, without much regard for the overall process (silo thinking). Typically, one departmental system would not talk to another, and the data stored in the databases of sales could not be exchanged with data in the databases owned by accounting or by manufacturing. In essence, in an effort to make each department as professional and efficient as possible, the concept of the overall process was lost. The emphasis on value chains and systems in the 1980s and the emphasis on business process reengineering in the early 1990s was a revolt against excessive departmentalism and a call for a more holistic view of how activities needed to work together to achieve organizational goals. The Six Sigma movement In the mid-1980s, a group of quality control experts wedded Rummler’s emphasis on process with quality and measurement concepts derived from quality control gurus Deming and Juran to create a movement that is now universally referred to as Six Sigma. As this movement spread, first from Motorola to GE, and then to a number of other manufacturing companies, it developed into a comprehensive training program that sought to create process awareness on the part of all employees in an organization. Organizations that embrace Six Sigma not only learn to use a variety of Six Sigma tools, but also embrace a whole culture dedicated to training employees to support process change throughout the organization. Prior to Six Sigma, ISO 9000 is a good example of another quality control initiative, but it usually brought organizations willing to be compliant to focusing on simply documenting and managing procedures. ISO 9000:2000 is driving many companies to think in terms of processes. In both cases, however, the emphasis is on documentation, while what organizations really need are ways to improve quality. Business Process Change in the 1990s Much of the corporate interest in business process change can be dated from the business process reengineering (BPR) movement that began in 1990 with the publication of two papers by Michael Hammer and Thomas Davenport. BPR theorists insisted that companies must think in terms of comprehensive processes, similar to Porter’s value chains and Rummler’s organization level. BPR theorists urged companies to define all of their major processes and then focus on the processes that offered the most return on improvement efforts. Companies that followed this approach usually conceptualized a single business process for an entire product line and ended up with only five to ten value chains for an entire company, or division, if the company was very large. The good news is that if companies followed this advice, they were focusing on everything involved in a process and were more likely to identify ways to significantly improve the overall process. The bad news is that when one Process redesign and improvement have also enjoyed a renaissance, and Six Sigma has expanded from manufacturing to every possible industry while simultaneously incorporating Lean. It is hard to find a business publication that is not talking about the importance of process change. This interest is not driven by just BMPS or by any other specific technology. Instead, it is driven by the deeper needs of today’s business managers. What drives business process change? In economically bad times, when money is tight, companies seek to make their processes more efficient. In economically good times, when money is more available, companies seek to expand, to ramp up production, and to enter new markets. They improve processes to offer better products and services in hopes of attracting new customers or taking customers away from competitors. Since the 1980s, however, the interest in process has become more intense. Large U.S. companies became more engaged in world trade and, at the same time, foreign companies began to show up in the United States and compete with established market leaders. The automobile market had moved from a continental market to a world market. Increased competition also led to M&A, as companies attempted to acquire the skills and technologies they needed to control their markets or enter new ones. Every merger between rivals in the same industry creates a company with two different sets of processes, and someone has to figure out which processes the combined company will use going forward. During the same period, IT technology was remaking the world. First, the spread of personal computers in the 1980s made it possible to do thing in entirely different and much more productive ways. Then, in the mid-1990s, the Internet burst on the scene and business was revolutionized again. Competitive pressures were increased as customers in one city could as easily buy items from a company in another city or country as from the store in their neighborhood. Then came iPad, intelligent phones, intelligent cars, GPS, and the whole wireless revolution with music, TV, and movies available on demand. The Internet and the Web and the broader trend toward globalization also made it easier for companies to coordinate their efforts with other companies. If another company could provide all the services your company’s Human Resources or IT departments used to provide, and was only an email away, it was worth considering. Suddenly companies that had historically been manufacturers were outsourcing the manufacture of their products to China and were focusing instead on sticking close to their customers, so they could specialize in designing and selling new products that would be manufactured by overseas companies and delivered by companies who specialized in the worldwide delivery of packages. Change and relentless competition call for constant innovation and for constant increases in productivity, and those, in turn, call for an even more intense focus on how work gets done. To focus on how work gets done is to focus on business processes. Every manager knows that if his or her company is to succeed it will have to figure out how to do things better, faster, and cheaper than they are being done today, and that is what the focus on process is all about. PART 1 – ORGANIZATON-WIDE CONCERNS The only way to achieve a significant competitive advantage is to assure that all the processes that make up a common value chain are integrated and support each other. Moreover, as organizations have become more international, they have become focused on assuring that they perform processes the same way in each country or region in which they operate. These insights have led organizations to begin to focus on organization-wide process concerns. In essence, an organization’s focus shifts from trying to improve processes to conceptualizing the entire organization as a system of interacting processes, and working to maximize the effectiveness of the whole system. Once executives shift from worrying about specific processes to worrying about all of the processes in the organization, they naturally want a business model that shows how all of the organization’s processes fit together, a set of business-wide process measures that show how processes support business strategies, goals, and major business initiatives, and models that show all the processes and subprocesses are aligned to achieve the goal of the organization. In this section we will focus on organization-wide concerns and what is involved in developing and supporting organization strategies, goals, initiatives, and all of the various components of a good business process architecture. Organizations that develop a good model of their business processes usually also want to define metrics to evaluate the success of their processes and to specify who will be responsible for managing each of the processes. This entire set of models and measures, and the description of the resources aligned to support them, is referred to as a business process architecture. A business process architecture isn’t a product that can be developed in one push. A business process architecture is usually developed in stages over a period of time. It’s usually easiest to begin with a description of an organization’s processes and then later progress to defining measures and managerial responsibilities. The sophistication of the architecture tends to evolve as managers learn to use it as a tool for strategizing and decision making. Moreover, to be useful, an architecture needs to be maintained and that requires an organization to constantly monitor processes and changes and incorporating them into the architecture. CHAPTER 2 – STRATEGY, VALUE CHAINS, BUSINESS INITIATIVES, AND COMPETITIVE ADVANTAGE It is important that process managers and practitioners understand how an executive thinks about his organization because, ultimately, they will be expected to develop business architectures and processes that support the strategies, goals, and initiatives developed by executives.  Goal: a general statement of something executives want to gather data about, and a vector suggesting how they hope the data will trend (e.g. “increase profits”). Objectives are more specific than goals, they have to be SMART (e.g. “increase profit by 3% by the end of this year”).  Strategy: a general statement of how we propose to achieve our goals (e.g. “our strategy will be to offer the best products at a premium price”).  Business initiatives: a statement of an outcome executives want the organization to accomplish in the near future (e.g. “all divisions will install ERP systems in the coming year” or “each unit will reduce its expense by 3% in the coming year”). They can sound much like objectives, except that they tend to focus on what business units or people will do, rather than results that will be achieved.  Key Performance Indicators (KPI): a KPI is a high-level measurement that organization executives intend to monitor to ensure that related goals, strategies or initiatives are achieved (e.g. “profits” or “completed ERP installations”).  Measures: just as goals can be contrasted with objectives that are more specific, KPI’s can be contrasted with measures, which define not only what is to be measured, but also define the specific, desired outcome and the timeframe (e.g. “division profits for second quarter” or “departments that have completed ERP installations as of the end of the first quarter”). A business strategy defines how a company will compete, what its goals will be, and what policies it will support to achieve those goals. It describes how a company will create value for its customers, its shareholders and its other stakeholders. Developing and updating a company’s business strategy is one of the key responsibilities of a company’s executive officers. Defining a strategy There are different schools of business strategy. Some advocate a formal process that approaches strategy analysis very systematically, while others support less formal processes. A few argue that the world is changing so fast that companies must depend on the instincts of their senior executives and evolve new positions on the fly in order to move rapidly. Porter recommends a three-phase process for strategy formation:  Determine the current position of the company: the formal strategy process begins with a definition of where the company is now – what its current strategy is – and the assumptions that the company managers commonly make about the company’s current position, strengths, weaknesses, competitors and industry trend.  Determine what is happening in the environment: the team developing the strategy considers what is happening in the environment. In effect, the team ignores the assumptions the company makes at the moment and gathers intelligence that will allow them to formulate a current statement of environmental constraints and opportunities facing all the companies in their industry. The team examines trends in the industry the company is in and reviews the capabilities and limitations of competitors. It also reviews likely changes in society and government policy that might affect the business. Then, it reconsiders the company’s strengths and weaknesses.  Determine a new strategy for the company: the strategy team compares the company’s existing strategy with the latest analysis of what is happening in the environment. The team generates a number of scenarios or alternate courses of action that the company could pursue. Finally, the According to Porter, competitive advantage is sustained by the processes and activities of the company. Companies engaged in hypercompetition seek to perform each activity better than their competitors. Companies competing on the basis of strategic positioning achieve their advantage by performing different activities or organizing their activities in a different manner. Put a different way, hypercompetitive companies position themselves in the same manner as their rivals and seek to offer the same products or services for less money while companies relying on strategic positioning focus on defining a unique strategy. Porter remarks that a good position can often be define by what the company decides not to do. It is only by focusing on a specific set of customers or products and services that one can establish a strong position. Once one decides to focus, management must constantly work to avoid the temptation to broaden that focus in an effort to acquire a few more customers. Porter refers to the way in which processes and activities work together and reinforce one another as “fit”. As fit is increased and processes are more and more tightly integrated, duplicating the efficiency of an activity demands that the competitor rearrange its whole process to duplicate not only the activity, but the whole process, and the relation of that process to related processes, and so on. Porter’s strategic themes Porter threw in the idea that strategists ought to create maps of activity systems to “show how a company’s strategic position is contained in a set of tailored activities designed to deliver it”. Porter suggested that strategists create network diagrams that show how a limited set of high-level strategic themes, and the activities associated with those themes, fit together to support a strategic position (e.g. activity-system map of Southwest Airlines). Companies should work hard to align their process measures with corporate performance measures and to eliminate subprocesses that are counter to corporate goals. Different theorists have proposed different ways of aligning process activities and outcomes to goals. Most, however, assume that when executives announce goals, process people will simply create processes that will implement those goals. Porter suggests something subtler: smart senior executives should think in terms of processes. He does suggest that they think of the themes that will be required to implement their strategies, which are ultimately defined by products and customers, and think about the the hard choices that will need to be made to ensure that the themes and key processes will fit together and be mutually reinforcing. Treacy and Wiersema’s positioning strategies In the mid-1990s, Micheal Treacy and Fred Wiersema published a book (“The discipline of market leaders”) which extended Porter’s ideas of generic strategies by focusing on customers and company cultures. Three generic types of customers: (1) those whose primary value is high-performance products or services, (2) those whose primary value is personalized service and (3) those who most value the lowest-priced product. So, the three value positions that companies must choose between are: (1) product leadership (focus on innovation and performance leadership), (2) customer intimacy (focus on specialized, personal service) and (3) operational excellence (focus on having efficient operations). As one can conceive three types of customers, one can also imagine three types of company cultures. Using this approach, we can represent a market as a triangle, with the three value positions as three poles. Then we can draw circles to suggest the emphasis at any given organization. The Balanced Scorecard approach to strategy Robert Kaplan and David Norton are consultants who are closely related to the Harvard approach to strategy. The Balanced Scorecard approach insists that management track four different types of measures: financial measures, customer measures, internal business (process) measures and innovation and learning measures. Using this approach, an organization identifies corporate objectives within each of the four categories, and then align the management hierarchy by assigning each manager his or her own scorecard with more specific objectives in each of the four categories. The executives wanted to apply this new performance measurement system to solve the more important problem they faced: how to implement new strategies. Given our focus on process, we looked rather carefully at the themes, which are, in essence, described as the internal perspective on the Strategy Map. Kaplan and Norton identify four themes, which they go on to describe as “value-creating processes”. Scanning across on the Strategy Map, the themes are operations management processes (supply chain management), customer management processes (customer relationship management), innovation processes (the design and development of new products and services) and regulatory and social processes. The latter is obviously a support process and doesn’t go with the other three, but would be better place together with other support processes like HR and IT. What is missing in Strategy Maps is any sense of a value chain. Perhaps we are to assume that they are only developed for lines of business and that everything shown in the internal perspective always refers to a single value chain. If that’s the case, it is not made explicit. Moreover, the fact that process in on one level and the customer is on another is a further source of confusion. When one thinks of a value chain, there is a close relationship between the value chain, the product or service produced, and the customers. Kaplan and Norton have put a lot of emphasis on measures and alignment, which has certainly led to a more comprehensive approach to strategy. But their approach stops short of defining a truly process-oriented perspective. Due to the shift brought by the Balanced Scorecard approach, we believe that something very valuable from the horizontal perspective has been lost. Kaplan and Norton put too much emphasis on vertical alignment and risk losing insights that derive from focusing on value chains and horizontal alignment. For those engaged in developing business strategies, or developing corporate performance systems, the Kaplan and Norton HBR article is critical reading. Those who want to create process-centric organizations, however, will need to extend the Kaplan and Norton approach. Business Models In the past decade it has become popular to speak of strategic issues as business model issues. In essence, a business model describes how a company plan to make money. Many business models are accompanied by statements that suggest how the company will position itself and use technology to generate a new product or service more efficiently or effectively than its competitors. However, business models are really just a spin on positioning and strategy, as described by Porter and others. If your company prefers to speak of business models, fine. The key, from the perspective of the process practitioners is simply to ensure that you understand what your executives seek to achieve. Business initiatives Executives could conceivably define a strategy and announce goals and leave it at that, content to let middle managers organize their efforts accordingly. In most cases, however, the executive team will begin with strategies and goals, and then define a few high priority initiatives. In essence, the executive team moves from wanting to improve the organization’s profit by 3% a year to mandating that each division will increase its specific profit by some given amount. Or, they will move from wanting to make customers happier to mandating that the sales process be redesigned in the course of the coming year. In most cases business initiatives are associated with KPI’s, which are carefully monitored. In some cases, manager’s bonuses depend on achieving the KPI’s associated with key initiatives. CHAPTER 3 – UNDERSTANDING YOUR ORGANIZATION We will develop an overview of the various types of business process concerns companies deal with at the enterprise level. Companies approach enterprise level activities in many different ways. Some, for example, use the Balanced Scorecard approach to help with the alignment of corporate goals and the evaluation of managers, but do not tie that program to business process in any rigorous way. Others have a business process architecture, but do not tie their architectural models to their ongoing business performance evaluations. A comprehensive business process method To organize our discussion of enterprise-level concerns, we will begin by considering the method taught by BPTrends. This method focuses on structuring two different sets of activities: those involved in creating a business process architecture and those involved in undertaking a specific business process redesign project. These two kinds of activities are connected, in practice, because it is the tools created by the business architecture effort that enable an organization to define, prioritize and manage all of its ongoing business process change efforts. 1. Understanding your business: the first phase focuses on understanding the organization as a whole, it often involves the executive committee and the senior executives of the company. It is absolutely critical that everyone understands and agrees on the basic value chain processes the company supports and the strategic goals each value chain is responsible for achieving. This phase begins with an analysis of the organization to define the organization’s strategy, goals, and key relationships and gradually refine everyone’s understanding of the organization and its stakeholders, including stockholders, customers, suppliers, distributors, and various governmental entities. During this phase, the value chains of the organization are defined. The goals of each value chain and the relationship between core processes and managerial and support processes are also specified. Thus, a specific business process architecture is developed for each individual value chain. As a result of this phase, everyone agrees on the basic value chains and the organization is in a position to proceed to define architectures for each value chain. 2. Defining a Business Process Architecture: this phase begins with the selection of a specific value chain and the commitment to create a business process architecture for that value chain (elucidating the core business processes and subprocesses in it). Using the business processes defined in the architecture, the team proceeds to define how each process will be monitored and measured. Depending on the needs of the organization, resources (like policies and business rules, IT resources, HR ecc.) can then be aligned to the processes in the process architecture. Using a business process framework, the creation of a business process architecture and the associated activity of defining process measures can be considerably accelerated. 3. Define process governance: Once the business process architecture is in place and measures are defined for each of the major processes, the team should move on to the development of a plan to manage their organization’s business processes. Most organizations end up with some kind of matrix that includes both functional and process managers. At the same time, the enterprise process team will want to consider how to measure and monitor the performance of process managers (many companies rely on a BSC-oriented approach). During this same phase, the team will probably also create a BPM Group (or BPM Center of Excellence) to provide the staff to help senior executives monitor processes, maintain the architecture tools, and undertake ongoing responsibilities, such as prioritizing process change projects. 4. The day-to-day management of enterprise processes: once the basic tools needed to create a process-centric organization are in place and a BPM group is established, the ongoing maintenance and use of the tools becomes a matter of execution. operational processes are controlled by external organizations. Organizations are beginning to talk about value chains that extend beyond the traditional boundaries of the organization (value chain system). Another aspect of the value chain concept that many companies find difficult is the requirement that overhead, management, and support processes be combined with primary or core processes. Porter suggests that a company should be able to isolate all of the support activities that are used in a single value chain. Most companies find it easier to organize their management and support processes independent of specific sets of core processes and then use some overhead formula to assign a portion of the cost of the management and support processes to each independent value chain. Some companies outsource their HR or IT processes. In this case, one organization’s support process is another organization’s core process. In recent years, a lot more attention has been focused on management and support processes, but most companies still find it easier to define their value chains only in terms of core processes and to exclude management and support processes. Some organizations use the term value stream as a way of emphasizing that they only focus on core processes, while other firms use value chain and value stream as synonyms. However the concept is defined, each company needs to determine how many value chains it has. A business process architecture describes a single value chain. It is simply too complex to analyze more than one value chain simultaneously. Thus, one begins by defining the value chains in a company and then, thereafter, one always focuses on one specific value chain at a time. The goal of an organization diagram is not to define processes in detail, but to get an overview of the whole organization and to help the team think about customers, value chains, and major stakeholders. We have better techniques for analyzing and picturing processes and subprocesses. Systems and processes As organizations become more complex, traditional organization charts might provide a static way of looking at an organization and they do not provide a good way of thinking about how things are related. Effective managers need an overview that allows each one to see how their work fits within the larger whole. Every manager should cultivate the perspective of systems thinking. The organization diagrams we have presented herein provide an important first step toward developing a systems overview. The alternative is to try to figure out how to assign strategic goals to departments without a clear idea of how the departments work together to achieve the desired outcomes. Process thinking is just a subset of systems thinking. Systems thinking puts the emphasis on understanding the organization as a whole. Process thinking stresses thinking about a portion of the system that produces a specific set of results. The key, again, is to think of the entire process, to understand how a specific process fits within the larger process and, ultimately, within the value chain. Remember, departments do not produce profits; value chains and processes produce profits. An excellent department may not result in a great process or significant profits. CHAPTER 4 – BUSINESS ARCHITECTURE The term “business architecture” can be very confusing. In the late 1970s, when Geary Rummler first begin to give courses on how to improve corporate performance, he would begin an analysis of corporate problems by working with a team of senior managers to create what he initially termed a “relationship map”. Rummler used this map to help senior managers understand how the major processes in an organization related to key entities outside the organization. He wanted to have a broad overview of how everything was connected to everything else. In the early 1990s, Hammer introduced a slightly different approach: he emphasized the idea of “value chain”. In essence, a value chain is a collection of all the processes that an organization uses to generate a product or service that is value by a specific group of customers. Hammer would begin an engagement with an organization by asking how many value chains the organization had. He would work with a management team to create a diagram in which multiple value chains were pointed out and then ask the organization to decide which specific value chain they wanted to work on first. The main difference between the approaches of Rummler and Hammers is the fact that Rummler assumed an organization had one value chain (as most mid-sized organizations do) whereas Hammer assumed that the organization might have more than one value chain (as many large organizations do). There is a modern and simplified way of combining the two approaches by representing the level 1 processes that might make up a single value chain in an organization (e.g. Michelin Corporation: make & sell tires vs research & publish restaurant guides). At a high level of abstraction, the value chains look rather similar, although at the next level down, the subprocesses would look quite different. It’s common to speak of organizations as having a corporate strategy and goals. In fact, they tend to have different strategies and goals for each of their major value chains. Thus, the goal for improving tire sales or reducing the costs of tire production this year is probably quite different than the goal for improving guide sales or reducing guide production costs. In essence, each major value chain has its own business model. When one is trying to think broadly about an organization, it’s very important to determine if the organization has one basic value chain, or has more than one. Each value chain needs to be considered independently since goals, processes and customers will all vary according to which value chain you focus upon. Most early business process redesign work was focused on major processes that management wanted to improve (e.g. “fix the sales process”). Process consultants didn’t want to spend too much time on architecture, which companies did not tend to value, but they did want to get a good overview of the business situation before they started to fucus too narrowly on a specific process. In those circumstances, approaches like those used by Rummler and Hammer tended to work well: the architecture work established a context for the more detailed process analysis work that one did as one zeroed in on the specific process on had been asked to improve. The Supply Chain Council’s SCOR framework The first work on a more modern concept of a business architecture was probably initiated by the Supply Chain Council. The supply chain managers ended up developing a standard architecture for a supply chain that companies could use to define their own supply chains and how their supply chains connected with other supply chains. The Supply Chain Operations Reference (SCOR) model developed by the SCC is a three- level model: they treated the value chain as level 0, and treated a given supply chain as level 1. They subdivided a supply chain into four major subprocesses: Source, Make, Deliver and Return. In addition, they identified a process that they termed Plan, which was required for every other process. In essence, they were saying that each Supply Chain, and each specific Make and Return process required a management process – which they called Plan – to control it. They also recognize that there was a problem if they tried to go below level 3, since the flows became too complex to model. At the same time the SCC team developed their basic models, they also developed a basic approach to performance evaluation ad metrics for each process and subprocess. Working together, the SCC member organizations established a benchmarking service. Earlier business process architectures helped in the redesign of a specific business process that was broken, while the SCC defined a business architecture to allow companies to quickly define how their supply chains worked, and then to assure that they could get good data on the actual performance of their existing supply chain. So, an SCC member could determine which of its processes were working as well as others in its industry, and which were superior or substandard. The supply chain managers were building business process architectures in order to manage their supply chains, to plan and estimate which subprocesses might need work, and to make estimates about what kind of improvement it might be reasonable to expect if they reached certain benchmarks. There are several things about SCOR that are worth noting. First, it was developed by business people – by supply chain managers – not either process people, as such, or by architecture people from IT. Second, it shows why business people might want a business architecture: their first concern was not with aligning software applications with business goals, but understanding how the process they had were performing and then identifying how processes at one company linked with those at other companies, and then identifying which processes would be the most cost-effective to consider fixing. Business Architecture: the IT approach Pagg 79-84 Business Process Architecture We need to discriminate between the use of the term “architecture” to refer narrowly to a process model or diagram, and the broader use of the term that includes not only the process model, but a process measurement system, a process management or governance system, and some way of aligning business process with support resources. In the rest of this chapter we will focus on business process models; in subsequent chapters we will focus on business-wide process measurement, on process governance, and on alignment. Older architectures tended to model the core processes of the value chain, but not do much with the various types of management and support processes. One of the main reasons early process architects tended to avoid building comprehensive models is because they didn’t know how to handle management and support processes. One identified the value chain, and then subdivided into its major processes. Then one divided those major processes into their subprocesses, and so on. It’s a nice idea, and it works reasonably well if you stick with the core processes that make up the value chain, but it doesn’t work very well when you focus on support processes. This section will walk readers through the approach to developing a comprehensive business process architecture model that we recommend. This approach has been widely used by BPTrends Associates in the actual development of architectures and road maps, and represent a practical approach to the problem. Each step consists of two parts. The first step begins with a kick-off meeting in which the consultant explains how the entire effort will be organized, and lays out the work to be done during the first step. The second step begins with a second meeting. At this point, the consultant reviews the result of the first round, and the team discusses and finalizes the work they have done. Then the consultant presents the work to be done next, providing any background concepts the team may require. In a full-scale business process architecture effort, we would have other meetings to define a process measurement system, a process management system, discuss alignment and define a road map to improve regions and product lines. In effect, all supply chains were quickly divided into Sourcing Processes, Make Processes, and Deliver Processes, as well as some additional planning and enabling processes. Once this was done, high-level software application that supported each of these processes were identified. If one line was clearly more efficient than the other, then the Supply Chain IT group tended to simply select the applications that supported the more efficient process. Technical discussions might have become an arena for intense arguments and wouldn’t have assured that the application chosen would be aligned with corporate goals. Instead, the group knew that it was important that their work focused on the value that the various applications delivered to the company. In effect, the group decided to select those applications that supported the most efficient processes, without regard to which company currently supported the application, or which departments were involved. In few cases, two competing regional lines appeared to be equally efficient and the team had to expand its effort and model the processes to SCOR Level 2 or even, in a very few cases, to Level 3. Once the Supply Chain group had identified product lines to maintain, modeling the processes, and then evaluated and selected applications to maintain, it was possible to step back from the specific supply chain processes being evaluated and to identify a generic supply chain architecture for the combined company. In effect, this architecture identified common supply processes, derived from SCOR, and common application that the merged company could eventually standardize on, worldwide. Another approach Another approach to a complete value chain framework is provided by the TeleManagement Forum, a consortium of telecom companies. Their framework is highly tailored to the needs of telecom companies. Thus, it can’t be used by nontelecoms, but it does provide a comprehensive approach for telecom companies. This is a reference architecture rather than an architecture of a specific business. In essence, a telecom sells time on its network to customers. Since the time is sold and monitored by means of computers that track phone access, Service and Resource are important functions. Since almost all long-distance phone calls cross multiple networks, arrangements with other telecom companies – partners – are very important. The key thing is that this business process architecture illustrates a framework that is detailed enough that a telecom process architecture committee that was familiar with its own organization, and could be reasonably efficient in determining just which processes or subprocesses would need to be changed to achieve specific changes in company strategy and goals. We have hardly considered all the existing architecture frameworks available. The U.S. government has one, and several government agencies (Australia, Canada, Sweden, and the cities of Denmark) have others. The insurance industry consortium, ACORD, is working on a framework for the insurance industry, and there are probably others we haven’t heard of yet. The point, however, is that companies undertaking the development of a business process architecture are, today, in a position to greatly accelerate the process by beginning with one of the available frameworks and then tailoring it to their specific needs. CHAPTER 5 – MEASURING PROCESS PERFORMANCE We will focus on organization-wide process performance measurement. Every organization keeps track of its performance in some manner. Performance information is a key differentiator and organizations that can obtain and use information about their markets and their processes in a timely manner can perform better. Thus, it is not surprising that companies are investing large amounts of money in developing new and more elaborate performance monitoring systems. As a generalization, executives were interested in financial reports and in the performance of the company’s stock. Problems arise when the organization tries to translate these measures into more concrete measures that can be applied to marketing, manufacturing, or accounting. Operational managers are more focused on the efficiency and effectiveness of specific activities, on the quality of products and services, and on customer satisfaction. However, the relationship between functional units and measures that most executives track is not so clear. When one looks at an entire product line or a complete value chain, one is in a much better position to see how changes in the work result in increased or decreased costs or sales. Key measurement terms We’ll start with a few definitions of popular measurement terms, and then proceed to a discussion of how processes can be measured.  A unit of measure: a phrase that describes the type of data or the outcomes you are interest in (e.g., cash flow, return on equity, sales)  A target: specifies what will be considered a success (e.g., cash flow equal to last quarter, or cash flow of $28 million/month)  A timeframe: specifies when the measure will be taken (e.g., … last quarter, or monthly)  A goal: describes an outcome. In effect it describes a unit of measure (e.g., profitable, technology leadership)  A key performance indicator (KPI): is usually just another name for a goal. Goals are usually associated with strategy, while KPIs are usually associated with managerial performance evaluations.  A vision statement: describes an outcome and may include a target set in the future (e.g. most profitable in our industry by the end of 2025)  An objective (or measure): combines a unit of measure with a target and a time frame.  Data: are raw numbers or documented events that can be used to describe result to determine if a target is met or not. Good measurement systems describe where, when and how data are to be captured or gathered. Organization have committees of executives that define strategies and goals for their organizations. Process teams interview customers and other stakeholders to determine what they value. In an ideal world, the goals that senior management set for the organization should align with the outcomes that customers or other stakeholders value, although in some cases they may not. An organization can be put out of business if it fails to satisfy any of its key stakeholders, so it is probably more important to emphasize satisfying stakeholders than to emphasize satisfying customers, as such. Internal and external measures Another way of talking about goals or measures is to ask whether the data is derived from within a given process, or if they are derived from sources external to the process you are focused on. External measures (measures from outside) tell you about the results achieved by a process or value chain. Internal data (measures from inside) tell you about how the process is working, but they don’t tell you if the process is satisfying its stakeholders – be they customers or stakeholders. Ultimately, we judge the success or failure of a process by external results. If we are focused on the organization, then the customer is outside the organization. We can apply this same concept inside an organization: processes can be both the supplier of one process and the customer of another. Focusing on the company for the moment, examples of measures we might want to examine include:  External measures: income measures; measures of customer satisfaction; market growth measures; stockholder satisfaction or other external measure of the stock market’s confidence in what the company is doing.  Internal measures: efficiency and effectiveness of specific functions or subprocesses; costs of producing the product or service; quality of internal outputs. It’s usually easier to define or measure internal metrics than to measure external results. Once you “lock down” the external measures, then you can begin to focus on improving your internal measures, confident that any efficiency you achieve will result in a real benefit to the organization. If you fail to lock down the external measures first, however, you run the risk that you will improve internal efficiency or reduce production costs at the expense of customer satisfaction, market growth, or the organization’s stock price. Leading and lagging indicators Another way to think about metrics and measures is to focus on whether they measure something that can suggest action, or whether they simply report on a situation that one can do nothing about. This focus is on using performance measures to help manager make decisions. Leading indicators are measures that report on situations that are causally related to outcomes that you desire. Lagging indicators describe situations that can’t be changed. As a generalization, whenever possible it is good to monitor leading indicators that provide managers with the ability to take corrective actions. Ultimately, of course, you are also going to want to know exactly how many sales you made in the quarter, so you will end up measuring both leads and sales, but the leading indicator will be more useful to the process manager who wants to use the measure to help achieve his or her goals. Developing a comprehensive measurement system Too many organizations don’t bother to pull all their measures together into a system, and they confuse their managers and employees by seeking different things under different heading. At the enterprise level, a major goal of those concerned with process work is to specify a measurement system that can link strategic goals, stakeholder goals and internal process goals into one consistent system. Balanced Scorecard and process measures There are many different approaches to defining a measurement system. One of the popular approaches is termed the Balanced Scorecard system. The system was popularized by two authors associated with Harvard, but there are many variations of the approach that are used by specific organizations. The approach is quite popular as a tool to define an organization’s strategy and even more popular as a tool to define managerial responsibilities and to align the goals and measured used to evaluate the performance of managers. Kaplan and Norton argued that traditional financial account measures can give misleading signals for continuous improvement and innovation. They proposed a Balanced Scorecard that considered four types of measures:  Financial measures: how do we look to shareholders?  Internal business measures: what must we excel at? define the metrics or measures that we will use to determine if the process is accomplishing its goals and if the manager is doing his or her job effectively. CHAPTER 6 – PROCESS MANAGEMENT There are two senses in which we will discuss process management. We will consider process management in conjunction with how managers understand the goals and activities of their organizations. Separately, we will discuss how the activities of managers impact the success of specific business processes. In this section, which is focused on enterprise issues, we will focus on understanding how processes help managers understand their organization’s goals. We will also consider how an organization might organize itself to support process managers. The process perspective Managers are responsible for the ongoing activities of their organizations. To set goals and make decisions about their organizations, they need to understand how their organizations are performing. There are different ways, historically, that managers have done this: the financial/return on investment (ROI) approach, the strategy and goals approach and the leadership/organization chart approach. Most senior executives rely on a mix of these approaches. What these approaches lack, however, is a systematic way of conceptualizing how everything in the organization fits together to produce results for customers. The reason that the process approach to management remains popular is that it integrates everything. In essence, we conceptualize the organization as a system or process that takes inputs and generates values, products or services for customers. If the organization is large, we divide it into multiple value chains, each with its own customers and stakeholders. Departments exist to provide people and activities needed in the major processes that make up the value chain. If a department is doing something that does not contribute to the production of value for the customer or for some other stakeholder, then we need to consider dropping it. Sales may drop, and it may be that the head of sales, or specific salespeople, should be fired. But it is just as likely that the process needs to be changed. Finances are critical. But cutting costs that result in poorer products and the loss of sales is not a win in the long run. A good strategy and goals are important, but once they are selected, the organization needs to have a specific process to ensure that those goals are met. The process perspective is the only perspective that connects everything else together and gives you a concrete way in which to see exactly how those connections lead to positive or negative results. The process perspective is the one perspective that shows a manager how everything in an organization must work together if the organization is to succeed. In this chapter we will consider how the process perspective can improve managerial practices. Similarly, we will consider how savvy managers can improve the results that can be obtained from processes. What is management? Many books have been written about management. This book is about improving business processes, so we will consider how management can be organized to support effective business processes. In the discussion that follows, we are talking about roles and not about jobs or individual. A single individual can fulfill more than one role. Thus, for example, one individual could perform two different managerial roles in two different situations – managing a functional department, but also serving as the manager of a special project team. Similarly, a job can be made up of multiple roles. There are two types of managerial roles: operational management and project management. Operational managers have ongoing responsibilities. Project managers are assigned to manage projects that are limited in time. In the rest of this chapter we will focus on operational management. Operational management can be subdivided in a number of ways. One distinction is between managers who are responsible for functional units, like sales or accounting, and managers who are responsible for processes, like the Widget process. Functional or Unit managers Most companies are organized into functional units. Smaller companies tend to structure their organizations into departments. Larger organizations often divide their functional units into divisions and then divide the divisions into departments. The definition of a division varies from company to company. In some cases, a division is focused on the production of one product line or service line. In that case, the division manager can come very close to functioning as a process manager. In other cases, divisions represent geographical units, like the European division, which may represent only a part of a process, or even parts of multiple processes that happen to fall in that geographical area. If problems arise they occur because functional units often defend their territory and resist cooperating with other functional units. What happens if the manufacturing process doesn’t get the sales information it needs to configure Widgets for shipment? Does the manufacturing supervisor work with the sales supervisor, as one process manager to another, to resolve the problem or does the manufacturing supervisor “kick the problem upstairs” and complain to his or her superior? We need to be clear about the value of the functional approach. As a strong generalization, departmental managers are primarily concerned with standards and best practices that apply to their particular department or function. Functional management preserves valuable corporate knowledge and brings experience to the supervision of specialized tasks. Sometime, however, it results in senior managers who are very territorial and prefer to focus on their special area of expertise while ignoring other areas. Process managers The key point to consider is that an organization is made up of processes and, for each process, there must be someone who is responsible for the day-to-day functioning of that process. At lower levels within an organization, the individual who is responsible might very well be a functional manager who is also wearing a process manager’s hat. At higher levels in the organization, wearing two hats is harder, because value chains and even large processes like new product development and supply chain often cut across functional boundaries. Ignoring organizational issues for a moment, let’s just consider what any process manager needs to accomplish. The process manager is responsible for working with suppliers, customers, and support processes to ensure that the process he or she manages has the resources and support it needs to produce the products or service the process’s customer wants. We divide the process management process into four generic subprocesses: one that plans, schedules and budgets the work of the process; one that organizes the workflow of the process, arranges for needed resources, and define jobs or success criteria; one that communicates with employees and others about the process; and one that monitors the work and takes action to ensure that the work meets established quality criteria. Most process managers are assigned to manage an existing process that is already organized and functioning. If the new manager is smart, he or she will reexamine all of the assumptions to ensure that the process is, in fact, well organized, functioning smoothly, and generating the expected outcomes. If there is room for improvement, the new manager should make a plan to improve the process. Once satisfied with the process, the manager has some managerial activities that need to be performed on a day-to-day basis and others that need to be performed on a weekly, monthly, or quarterly basis. And then, of course, there are all the specific tasks that occur when one has to deal with the problems involved in hiring a new employee, firing an incompetent employee and so forth. At the enterprise level, we will be more concerned with how companies establish process managers, how process managers relate to unit or functional managers, and how processes and process managers are evaluated. When we consider the analysis of specific processes, we will see that it is important to carefully analyze each manager’s goals and motivation. If a process is to succeed, then we need to be sure the manager’s goals and rewards are in line with the goals of the process. Thus, just as it is important to have a management system that focuses on integrating and managing processes, it is important to see that there is a system for aligning the goals and rewards of specific managers with the goals of the processes that they manage. Management processes A company could analyze each manager’s work from scratch, using our generic management model. Increasingly, however, companies find it more efficient to rely on one or more generic models that help analysts identify the specific management processes that effective process managers need to master. Let’s quickly review some of the framework and maturity models that are currently popular.  The PMI project management maturity model: PMI distinguishes between operations management (ongoing) and project management (done in limited timeframe). They describe a body of knowledge about project management (PMBOK) and an Organizational Project Management Maturity Model (OPM3) that organizations can use to evaluate their current sophistication in managing projects and then to use as a methodology for introducing more sophisticated project management skills. They assume there are five management processes that every project manager must learn, including: initiating, planning, executing, monitoring and controlling, and closing. Project management extends our general model of management by adding a process for defining the nature of the specific project to be managed (Initiating) and another that critiques the project and pulls together things that were learned in the course of the project (Closing).  The SEI’s CMMI model: the best known of all the process maturity models is the SEI’s CMMI. Although CMM was originally developed to evaluate IT departments, the extended version, CMMI, is designed to help companies evaluate and improve any type of business process. CMMI supports two way of organizing the effort. You can either analyze the capabilities of a department/group of practitioners or you can focus on the overall maturity of an organization. The first, which focuses on capability levels, looks to see what skills are present and then focuses on teaching managers or process practitioners the skills that are missing. The second, which focuses on maturity levels, assumes that organizations become more process savvy in a systematic, staged manner and focuses on identifying the state the organization is at now and then providing the skills the organization needs to move to the next higher stage. No matter which approach you use, once the basic evaluation is complete, the focus is on either the management processes that need to be acquired by the organization’s managers or on the activities needed by individuals who are responsible for improving the organization’s existing processes. CMMI’s focus is on improving processes, but their major assumption is that processes are improved as they are defined, executed consistently, measured, and, as a result, systematically improved. Ultimately, putting these elements in place and executing them on a day-to-day basis is the responsibility of the individual who is managing the process.  The SCC’s SCOR framework: the Supply Chain Council is primarily focused on defining the core processes that make up a supply chain system. At the same time, however, they have a generic process called Plan. For each supply chain process, like Source, Make, Deliver, or Return, they require the modeler to add a Plan process. In fact they require a hierarchy of Plan processes, in effect creating a picture of the process management effort required for a supply chain process. The SCC decided to focus on management processes that are more knowledge intensive and thus didn’t include things like assigning people to tasks, monitoring output, or providing employees with feedback.  The ITGI’s COBIT framework: the IT Governance Institute developed their process framework to organize the management of IT processes. We have not gone into any of the various process management frameworks in any detail. For our purposes, it suffices that readers should know that lots of different groups are working to define the processes that managers use when they manage specific processes. Some groups have focused on the activities, skills, and processes that a manager would need to manage an ongoing process, and others have focused on the activities, skills, and processes a manager would need to manage a project. Some have focused on the activities of senior process managers, and others have focused on managers who are responsible for very specific core processes. As we suggested earlier, defining process management is hard. Different people have pursued alternative approaches. Some simply diagnose what specific managers are doing wrong as they look for ways to improve the performance of defective process. Others focus on the actual processes and activities that effective managers need to master to plan, organize, communicate, and monitor and control the process they are responsible for managing. Organizations that focus on managerial processes usually tend to establish process management training programs to help their managers acquire the skills they need to perform better. Documenting management processes in an architecture Most organizations do not document management process in their formal business process architecture. If you think of every operational process as always having an associated management process, then it seems unnecessary to document the management process. If the day-to-day management processes are documented, they are usually documented as generic, standard processes that it is assumed every manager will use. If this is the company approach, then using one of the frameworks described as a source of information and definitions is a reasonable way to proceed. Most organizations identify high-level management processes that are independent of any specific value chain, and document them independently. Thus, an organization might document the strategy formulation process or the processes of a business process management support group. Others treat these specialized processes as support processes and document them in the same way they document other support processes. However you company decides to approach documentation, the management processes describe sets of activities that process managers ought to master, and thus they should provide a good basis for a process manager training program. Completing the business process architecture worksheet In our experience, most companies can identify the managers of their Level 2 or Level 3 processes without too much trouble. They have problems while identifying the managers responsible for the value chains and for the Level 1 processes. It’s the process manager who is responsible for processes that cross the traditional boundaries that are harder to identify. In many cases, they don’t exist. Yet they are the only managers who can ensure that your organization’s large-scale processes work as they should. They are the managers who focus on integrating the entire value chain and aligning the value chain with your organization’s strategy. They are the managers who are really focused on the value chain’s external measures and satisfying the customer. Most organizations are just beginning to sort through how they will manage processes at the higher levels of the organization, yet it is at these levels that huge gains are to be made and that competitive advantage is to be achieved. Ultimately, this is the work of the senior executives of your organization. If they believe in process, then this is a challenge they must address. CHAPTER 7 – AN EXECUTIVE LEVEL BPM GROUP Organizations have different way of managing their business process efforts, and there is no one best way. It largely depends on how an organization is already structured. Organizations that are focused on enterprise issues and think of processes and process management as strategic resources that need to be aligned with corporate strategy and company-wide performance measures will tend to locate their BPM group at the enterprise level. In this chapter we will focus on the types of activities that an enterprise BPM group might manage. What does a BPM group do? Different companies assign different sorts of responsibilities to their BPM groups. We’ll consider each BPM group process in turn. Create and maintain the enterprise business process architecture Any organization that wants to exert a systematic, ongoing control over its processes needs to understand exactly what processes it has. The business process architecture in question can be a minimal architecture that simply identifies the major value chains and key processes and the relationship between them, or it can be a more detailed architecture that defines processes, managers, measures, links to strategies and policies, links to IT resources, links to training resources, and so forth. The more elaborate the process architecture, the more valuable it will be as a senior management tool, but only if it is up to date. A BPM group with an up-to-date business process architecture, stored in a repository, is well positioned to provide a variety of management support tasks. Companies without a business process architecture, for example, spent anywhere from a year to three years struggling to analyze their decision flows and developing the means to comply with the required Sarbanes-Oxley reporting. An up-to-date business process architecture allows the members of a BPM group to quickly define the impact of proposed change. Since a well-defined architecture defines the relationships between processes and subprocesses and between processes and IT resources and training resources, among other things, the BPM group can quickly project what a specific business process change will require in the way of changes to IT or training. Thus, the creation of a business process architecture provides the organization with a key tool to ensure the organization’s continuing agility and its ability to deal with change in a rapid and efficient manner. The BPM group should maintain a close relationship with the organization’s strategy group, providing it with process performance data and advice on the opportunities or problems involved in adapting to new strategic directions. If the architecture is well defined and up to date, the BPM group ought to be able to quickly define all of the core and support processes that would need to be changed to implement any specific strategic change. Finally, an up-to-date business process architecture becomes the central tool that a process-oriented company uses to identify needs for process changes. Identify, prioritize and scope business process change projects Using inputs from operations managers, from the strategy committee, from those working with the business process architecture and those maintaining the process performance system, the BPM group is in a position to determine what processes need to be changed. In most large organizations there are more processes requiring change than resources to undertake process change projects. The BPM group should maintain an overview of all processes that require changes, and define the project scope for each possible change project.
Docsity logo


Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved