1. An Overview
Copies-R-Us is a Boston area company founded in the mid-Nineties. It began with a large downtown copy shop set up by Steve Lowe and Mary White and quickly grew into a company that now manages over 80 copy shops located throughout North Eastern region of the United States.
From the beginning, Mary and Steve positioned Copies-R-Us as an efficient, fast, professional place to get copies. They always expected their supervisors to dress for business and be polite and business-like. They always bought large, top of the line copiers and paid to have them well maintained. They operated the machines 16 hours a day, using a night shift to assure that they could get orders turned around faster than most of their competitors. Their logo was a copy machine with wings. Copies-R-Us also invested heavily in a variety of binding machines so that they could produce a wide variety of bound reports. Small businesses often ask Copies-R-Us to prepare important presentation documents.
Early on, Steve and Mary created a special category for “Established Customers” who they went out of their way to satisfy. Established Customers are individuals or businesses with an established credit account with Copies-R-Us. They often have standard, repeat orders, like the restaurants that change their menus each week. They often order via email or via the Copies-R-Us website, and have their materials delivered by a delivery service company. They constitute about 20% of a typical store’s customers and they provide nearly 70% of their business. Other customers are referred to as “Off-the-street” customers. These are customers that walk in and ask to have copies made. In essence these customers need to establish their credit by offering a credit card, although they are welcome of pay cash when the actual order picked up and the estimated cost is less than $500. Either type of customer can arrange to have the completed order delivered, although “Off-the-street” customers must pay in advance if they want to use the delivery service. Copies-R-Us rapidly developed a reputation for quality, reliability and professionalism, and has become very popular with small and mid-sized businesses in its area.
Copies-R-Us, today, is a corporation run by a board of directors. Mary is the chair of the board and the CEO. Steve is chief operating officer. The company has always looked for strong store managers and encouraged each to be very independent. Thus, for example, each store manager is expected to hire their own local employees and to contract with local companies to provide cleaning and delivery services.
The Corporation manages the brand, markets services, sets standards for each Copies-R-Us store, handles finances for the corporation, raises capital by offering stock, and recruits store owners. Mary and Steve put a lot of time into recruiting new store managers who are willing and able to support the overall branding and positioning of Copies-R-Us.
The Corporation has a master contract with a major vendor of copying equipment and arranges to have machines placed in new stores as they are established. The vendor leases machines directly to the individual stores, conforming to the terms of the master contract, and provides maintenance services for the machines. Similarly, the Corporation buys supplies in bulk, stores them in a central warehouse outside Boston, and delivers them to the various stores, when requested by the store. The Corporation runs a small fleet of trucks for such deliveries.
When the customers want their orders delivered, the delivery is handled by an outside delivery service contracted by the local store. In addition to a CFO, a lawyer and a marketing manager, the Corporation also has a small IT group that supports the Copies-R-Us website, and a corporate-wide email network. The group also creates the PC application that the stores use to create customer accounts, track orders and payments.
Figure 1 provides a very high level overview of the corporation. Artie Smith manages the warehouse and the delivery trucks and reports directly to Steve Lowe. The Corporation sets standards, but many common activities are agreed to and jointly funded by the Corporation and the store owners who meet quarterly as the Stores Management Committee.
1.1 The Corporation and the Copies-R-Us Stores
To think about how operations might be improved and to ensure consistency wherever possible, Steve Lowe maintains a model for an ideal store. When in doubt, he experiments with one of the stores. Once an improvement is worked out in one store, Steve communicates it to all the other store managers and enters the changes into the on-line Copies-R-Us Standard Operating Procedures Manual. In a similar way, store managers are encouraged to try making changes to improve operations and to report any improvements to Steve who then considers them and, if appropriate, adds them to the SOP Manual.
Figure 2 is an organization system model that Steve originally developed at a meeting of the store managers and now uses as a generic model of a typical Copies-R-Us store. It provides a high level view of an organization as a business system. In this case, since his system is made up of two entities: the corporation that manages the stores and the stores themselves, we show two organizational layers, one yellow (the corporation) and the other blue (a typical store). It shows some of the external relationships between a store and the Corporation, suppliers, and customers. It also pictures the competition and reminds everyone that Copies-R-Us stores compete with competitors for capital, customers, employees and technologies. In addition, Figure 2 shows some (but not all) of the major functions or processes performed by the Corporation and those that lie within a store.
Steve and the store managers have always assumed that Copies-R-Us was based on a single value chain – the store creates value by generating copies for customers. They have always called the value stream, Make Copies, and the three core subprocesses of Make Copies: Take Order, Prepare Copies, and Set-Up Delivery. The diagram in Figure 2 also shows some external (or outsourced) activities provided by other organizations, including Cleaning Service, Equipment Vendor, and Delivery Service.
Figure 3 shows a typical organization chart for a Copies-R-Us store.
One of the problems in drawing organization charts is how to represent functions or processes that are outsourced or done outside the organization-in-scope. In such cases, the manager in charge does not directly control the external activities, but has a responsibility to monitor them and determine that they are functioning correctly. In this instance, the Copies-R-Us stores do not actually manage procurement and distribution or software development. These are managed by the Corporation and provided to the stores as a service. Similarly, equipment maintenance, facilities cleaning, and delivery services are provided by outside firms. At the same time, however, the store manager is responsible for the processes being available, and thus manages them indirectly. If the delivery service isn’t working, the manager needs to recognize this and possibly replace the delivery firm. In effect, the manager is responsible for the availability and quality of all of the processes needed by the value chain, even if he or she does not directly manage them.
To show important services for the stores, we have represented them in dotted boxes with reporting lines on the right, and indicated who actually manages them on a daily basis.
1.2 Some Problems at Copies-R-Us
Every year Copies-R-Us hires a survey firm to call an appropriate sample of its customers and ask them about their experiences and their overall satisfaction with Copies-R-Us. Overall, most customers remain happy, but the number with complaints is growing and Steve thinks its time to launch a major effort to assure that the stores are constantly doing the best possible job.
Here are some notes that Steve made as he reviewed the latest survey. He organized his notes by process.
Take Orders
Experienced customers are more satisfied because they are more experienced and know exactly what they want. They often send email orders and specify paper weight, color, punching and binding, and so forth. They also know what the charges are likely to be. Stores have more trouble with off-the-street customers who don’t understand the options. The clerks on the front desk often have to walk the customer through a series of steps, explaining options and costs. This takes time, and creates a wait if several new customers are in line. Sometimes to speed things up, clerks don’t ask enough, make assumptions, and end up generating orders that customers sign, but which don’t result in products with which customers are happy.
The clerks on the front desk aren’t able to prioritize or assign orders. Only a supervisor can do that and there is often a bottleneck if the supervisor is elsewhere when orders come in, especially if the customers want the orders quickly and the clerk is unable to tell them exactly when the order will be ready. Under pressure, clerks sometimes promise off-the-street orders too soon, and they get complaints when the customer shows up and the order isn’t ready.
Produce Copies
Operators are trained to use specific machines. Only the most experienced are trained to use the high speed copier that can be programmed for fancy orders involving two sided copying. They sometimes have delays because too many orders are waiting for the large machine(s). On the other hand, if one runs small orders on the large machine, it costs more. Ideally small orders should be run on the small machine. Quality drops if the machines are not properly maintained, and they get complaints. The key is having the operators keep careful track and clean and change ink as needed.
Set-Up for Delivery
Part of this job is seeing that the masters, the copies and the bill are all together in a package. Sometimes it also involves actual packaging for the delivery service. (No copies should ever be sent out loose in a folder! It only takes one slip and the copies are on the floor and out of order!) The other part of this job is quality control. They need someone to double-check to see that the resulting product meets the customer order. Any complaint that an order is incomplete or incorrect – that it doesn’t match what is on the order – points directly to the set-up clerk – and only secondarily to the operator. Complaints on complete and correct orders are still low, but they are slowly rising and they need to get on this. The Set-Up people are also responsible for working with the Delivery Service and grouping the orders so that the service doesn’t have to keep sending people over for small runs. It costs more and upsets the delivery people.
Internal Operations
Both the customers and the employees are happy with the new web/email contact system. Clients spend the time checking boxes and specifying exactly how they want an order set up. If only they could explain the options to walk-in-customers as effectively as the web seems to explain it: No problems with administration issues such as bookkeeping, reporting or accounting.
Customer Perceptions of the Brand
In addition to other problems revealed in the customer survey, the firm reported that Copies-R-Us had a good reputation for professionalism and efficiency, but that their customers didn’t rank Copies-R-Us significantly better than their leading competitor, Nationwide Copyshop.
This upset both Mary and Steve, as they always thought that they were small, but nimbler, and more professional than Nationwide. In fact, much of Copies-R-Us advertising was based on the idea that Copies-R-Us was the store that business people trusted with important jobs. Mary asked Steve to think about the standard practices that Copies-R-Us teaches and requires of its stores, and to recommend how they might be changed to improve the local store operations.
1.3 Redesigning the Make Copies Process
Steve has been charged with fixing the problems that were reported at the recent survey. He decided that the place to start was with a hard look at the Make Copies process. In essence this process is the value stream of core processes that extends from when an order is taken to when copies are delivered and paid for.
Steve proceeded to assemble a Redesign Team. He assigned a variety of managers and employees from several stores to a redesign advisory committee, but to assure that the effort was concrete, he set up the actual redesign team at a specific store – the Waban, Massachusetts Copies-R-Us store. This team consisted of the staff daytime supervisor and several employees, plus an outside consultant, and two advisors from Corporate (one IT specialist and one HR specialist.) Steve suggested that the team begin by identifying an approach and, after surveying several approaches, the team decided to go with the BPTrends Associates (BPTA) approach to process redesign. The decision was based on the fact that the company seemed to face a number of different problems and BPTA seemed to offer a very comprehensive approach.
2. The BPTrends Associates Process Redesign Methodology
The BPTrends Associates Process Redesign Methodology has been developed over the course of the past two decades. The methodology is designed to help process practitioners analyze and solve complex process problems. It is a “best practices methodology” in the sense that it does not claim to reinvent process redesign, but strives, instead to structure an approach that will allow a practitioner to use all of the techniques available to solve problems in the most efficient manner. Thus, for example, the methodology recognizes values in Rummler’s performance improvement approach, in Lean and Six Sigma, in the OMG’s BPMN notation and in business rules. It employs techniques from each of these approaches, when and where appropriate.
In other words, BPTA posits that there are many approaches to business process problems, and that a good methodology ought to take a very broad view, identify all possible problems and then zero in on changes that will provide the biggest impact. Sometimes this will involve changing process flows or eliminating waste. Sometimes it will involve formalizing and improving decision making processes or working to improve product consistency. At other times it will involve changing employee performance, changing the way managers control business processes or automating selected tasks. Typically, a complex process will involve a combination of different approaches.
Figure 4 provides an overview of the BPTA approach to business process management. The center row focuses on improving specific business processes.
The entire BPTA BPM Methodology encompasses a Business Process Architecture layer, a Process Redesign layer and a Resource Implementation layer, but in this case study we are going to largely ignore architecture and implementation issues and focus only on what is involved in redesigning a specific business process.
In a similar way, the BPTA Methodology considers both the redesign project (to the left of the bold vertical line) and the ongoing execution of the redesigned process. We will touch on execution, but only briefly. The main focus of this case study is on the five phases involved in analyzing and redesigning an existing business process.
3. Phase 1. Understand
The Understand phase begins as soon as management makes a decision to redesign a business process and is undertaken by a sponsor, a project manager, and eventually a process redesign team. The phase ends when the team has prepared an initial description of the problem, a vision of a To-Be process, and a proposal for the scope of the probable analysis and redesign effort is submitted to senior management for approval.
3.1 An Overview of the Understand Phase
Figure 5 identifies where Understand lies within the over redesign methodology, and then shows the specific activities within Understand and uses swimlanes to show who is involved in each activity. It also uses colors to suggest if the activity is primarily a project management concern, and analysis and design concern, or involves communication about the process redesign with other individuals.
Steps
1.1. Plan the Project. An initial project plan is created to conduct the Understand Project Phase. This includes the process goals, project objective, known issues and opportunities. A team from among process relationships is identified to participate in the analysis and design initiative.
1.1.1 Understand Process Context. To understand the context, the start and end of the process-in-focus, extract a view from the existing process architecture, or if architecture does not exist then list the sub-processes and lay out a process map (simple process icons–rectangles and arrows showing the process work flow). (Use Vision Statement Worksheet, Basic Process Diagram, and Simple Process Architecture Diagram, as needed.)
1.2. Identify Relationships and Define Process Vision Statement
1.2.1 Identify Stakeholders and Other Relationships for Selected Process. Identify all relevant relationships and then identify “key” relationships to formulate process vision. Stakeholders and Relationship entities are those who have vested interest in the success of the process performance. (Use Relationship Diagram and Relationship-Measures Worksheet as Needed.)
1.2.2 Formulate Process Vision & Performances Indicators. The vision describes the stockholders perspective of what the process should be in its future state (“begin with end in mind”). For each of the key relationships, identify future-state statements that would reflect their expectations. Extract a vision statement that summarizes all relationships entities’ expectations (write in present tense). (Use Vision Statement Worksheet and Relationship-Measures Worksheet, as needed.)
Identify Key Performance Indicators (KPIs) for the process-in-focus. The KPI’s are a measure by which a determination is made to ensure that the process is achieving the stated vision. (Use Relationship-Measures Worksheet and Scorecard Worksheet, as needed.)
1.3. Scope the Project
1.3.1 Create a Process Scope Diagram. Gather information using the Inputs, Guides, Outputs and Enablers (IGOE) method. Start with Outputs first to ensure that inputs are not over specified. This scope represents a macro-level view of the process. Outputs are the end outcomes of the process; Inputs are those items that get “consumed” or “transformed” by the process; the Guides are the process reference that control/govern the process transformation; and the Enablers may be classified into three areas: Organizational Roles, Systems (IT and other Mechanisms), and Infrastructure such as facilities, hardware, communications etc. Also identify the Process Triggers, if appropriate. (Use Scope Diagram, Root-Cause Diagram, Relationship-Measures Worksheet, Problem Analysis Worksheet and Problem Analysis Checklist, as needed.)
1.3.2 Conduct Process “Health Check” & Establish Scope. Gather information about the problems on all aspects of the scope diagram: Inputs, Guides, Outputs and Enablers. This is typically done for the current state (as-is), however information is recorded for known/planned opportunities such as implementation of some new system. Considering the project objectives, constraints, and priorities, identify items on the Scope Diagram that will be in the scope of the process improvement for next phases in the methodology. (Use Scope Diagram and Analysis Planning Worksheet as needed.)
1.4 Develop an Initial Business Case. Start developing a business case driven by the gaps in process goals and project objectives. This should include vision elements, KPI’s, problems and opportunities identified during the process scope, and “health check”.
1.5 Develop Plan for Communication and Analysis and Redesign
1.5.1 Determine Human Change Program Approach. If organizational roles are likely to be impacted, then an initial plan is needed to address potential considerations which include role profiles, skills and competencies, alignment of people to the roles. This specialized discipline needs Human Resource Organizational Design expertise. (Use Human Performance Problem Worksheet as needed.)
1.5.2 Develop Communication Plan. From the list of process relationships, identify groups that need to be communicated. The communication plan includes the message, mechanisms and frequency of delivery, schedule and assigned responsibility.
1.6 Obtain Approval to Proceed to Next Phase. Update project plan, assigned post-Understand Phase assignments for agreed actions, obtain approvals for project/process sponsor and relevant relationship entities. Plan for Analyze Business Process Phase.
3.2 Structuring the Understand and Analyze Tasks
Figure 6 illustrates the basic diagrams we use to help structure the Understand and Analyze Phases of a BPTA process redesign effort. It also shows the worksheets we may use. In many cases, we simply do the diagrams to get information that we then record on the worksheets and which we subsequently elaborate on the worksheets. Thus, for example, the Relationship Diagram is prepared to provide an overview of all of the relationship entities that have an interest in the success or failure of a given process-in-scope. Having identified those relationships, however we proceed to record the information on a Relationship-Measures Worksheet and then enter other information about how we would measure the success or failure of each relationship. The real outcome of the effort isn’t the diagram, but the manual or automated worksheet with its more extensive information.
Note in passing that BPTA uses worksheets as a way of teaching students about the kinds of information they should collect as they proceed through a redesign project. If a redesign team was using a software tool designed to support the BPTA methodology – which we recommend — and created the diagrams in the software tool, and then added lists at various points, the team would have all the information required and would probably generate it, as needed, by generating tables from the software tool’s repository. Thus, if the team used the tool, they would probably not need the worksheets that are used in classes.
Here is the way we usually use core diagrams and worksheets during the Understand phase of a project:
0. We usually do not need to define a vision for the organization-in-scope, since it usually already exists. What we do need to do is be sure we understand what management thinks it is trying to achieve by means of the organization-in-scope, or the process-in-scope. We record it on a Vision Statement Worksheet.
1. We do the Basic Process Diagram just to be sure that we all agree on the name of the process, its key inputs and outputs, and when it begins and ends.
2. We then define the Organization-in-scope and identify other processes that occur within the Organization-in-scope that are of similar granularity to the process-in-scope. We record this information on a Simple Process Architecture Diagram.
3. We proceed to define the entities or relationships that interact with the process-in-scope and identify some of the things the entities provide the process and that they get from the process. We record this information on a Relationship Diagram.
4. The Relationship Diagram leads directly to our initial entries on the Relationship-Measures Worksheet, on which we record measures that will let us know how we will evaluate the health of each relationship with the process-in-scope
5. Next we prepare the Scope Diagram, which shows how the process-in-scope interacts with external stakeholders, internal relationships and other processes that occur within the organization-in-scope. At the same time we identify where there are problems in the way the existing process-in-scope interacts with the relationships and processes it interacts with. We also explore the measures we might use to determine if the interaction is occurring in an acceptable manner. Eventually, this results in a more definitive statement of the exact scope of the process improvement project we propose to undertake.
As the Scope Diagram is created, additional relationships and processes that interact with the Process-in-scope are sometimes identified. In each case we ask what are their expectations of the process or in what the process-in-scope needs from them and how we would decide if the process was succeeding in satisfying these needs or receiving what it needs from them. We add these additional relationships and processes to the Relationship-Measures Worksheet.
6. If we need to explore any of the problems we encounter as we create our Scope Diagram, we might develop a Root-Cause (or Fishbone) Diagram, which works backwards to explore the causes of problems.
7. The Problem Analysis Worksheet, captures the problems we identified on the Scope Diagram and links them to measures we will use to let us know if we have eliminated the problems we identified on the Scope Diagram.
8. In some cases we will identify too many problems to fix in a single project effort. In other cases, we will identify possible problems that we know we will need to define in more detail. All this information is captured on the Analysis Planning Worksheet, which basically lays out the tasks we will need to accomplish during the Analyze Phase of the project in order to be ready to think about how we might improve or redesign the As-Is process. Some teams prepare this as part of the Understand phase, since it prepares them to explain to management what they hope to do in the Analysis Phase. Most wait to do this till they are in the Analysis Phase and use it as a way to kick-off that Measure & Evaluate activity (4.2).
9. Once in the Analysis Phase, the team begins to gather data and to explore the internal activities that make up the process-in-scope. We do this by creating a Process Flow (BPMN) Diagram. Once we have prepared a high level BPMN diagram, we may choose to generate additional diagrams to define the internals of various subprocesses. We can drill down to any level of detail we need to, but should avoid any unnecessary analysis. The goal is not to understand how everything works, but to understand what we need to, to solve problems and improve the process-in-scope.
10. One way to avoid unnecessary BPMN diagramming is to use the Business Decision/Rules Worksheet to define how decisions are taken. If you arrive at a subprocess or activity that involves making a decision, defining the business rules that generate the decision is usually easier than trying to define the steps or tasks in the decision process.
As you learn more in the Analysis Phase, you will want to update or extend the Relationship Measures Worksheet and the Problem Analysis Worksheet.
A different way of summarizing this overview is shown in Figure 7. In essence, BPTA uses five core diagrams in process redesign: a Basic Process Diagrams, a Simple Process Architecture Diagram, a Relationship Diagrams, a Scope (or IGOE) Diagrams, and various BPMN Process Flow Diagrams.
The diagrams are usually created in the order suggested above, moving from left to right. Information from earlier diagrams is often used in the creation of later diagrams, although there is no precise relationship between the successive diagrams, and each emphasizes slightly different aspects of a process.
We have colored the process-in-scope yellow in the figure above. Note that the Relationship and Scope diagrams are mostly focused on how the process-in-scope relates to things outside the process while the flow diagram is primarily focused on the internals of the process-in-scope.
The Simple Process Architecture Diagram pictures the organization-in-scope and defines all of the processes within the organization-in-scope that are of approximately the same granularity as the process-in-scope. (We will consider this issue in more detail when we consider the Simple Process Architecture Diagram.)
3.3 Some Examples from the Copies-R-Us Effort
We can not consider every step or activity from the Copiers-R-Us Understand effort, but we can mention some of the more interesting steps to illustrate what the redesign team did.
3.3.1. The Copies-R-Us Vision Statement for the Stores
The process improvement team started by reviewing documents that the Stores Management Committee had produced in earlier meetings and recorded their understanding of the vision, mission and goals for the Copies-R-Us stores on the Vision Statement worksheet pictured in Figure 8.
3.3.2 Defining the Scope of the Process to Be Studied
One important thing any process change team needs to do is to determine the overall scope of their effort. To put limits on the effort they need to do two things: Define the organization-in-scope, and then, within that organization, define a process-in-scope.
One could imagine a group focusing on the entire Copiers-R-Us organization – the corporation as well as its various stores – and considering all the processes and problems occurring anywhere in the organization. In reality, unless we had an organization that was relatively mature as concerns process management, that effort would be very large and confusing and potentially a political minefield.
In the case of Copies-R-Us, Steve Lowe, working with the process redesign team and an outside process consultant, Roger Wright, decided to focus on the Copies-R-Us stores and the Make Copies process.
3.3.3 A Basic Process Diagram for the Make Copies Process
Within a store, the process redesign team decides to initially focus on what everybody termed the “Make Copies” process – in effect a value stream of core processes that involved everything from taking orders to handing finished copies to customers. To formalize this choice, Roger Wright prepared a Basic Process Diagram. (See Figure 8.)
A process transforms inputs into outputs. In this case the Make Copies process transforms a manuscript or an original document of some kind into a set of copies, perhaps bound in some way. There may be other inputs and outputs but the two we picture in Figure 7 provide a good idea of what the Makes Copies process does.
Another way to characterize a process is to say it starts when some event occurs, and runs until some other event occurs. In this case, the event that starts the process is a customer contacting the process – either by coming into the store or sending and email – and requesting copies. In a similar way, the process ends after the Make Copies process receives a payment and closes the account created when the order to make copies was initiated. We always show key inputs and outputs on the basic diagram. We often show, in addition, the starting and ending events – and put them slightly above the process box to the left and the right, as shown in Figure 6.
3.3.4 Defining a Simple Process Architecture
The information about processes that was captured in the Organization Diagram, in Figure 2, is also shown by means of a Simple Process Architecture Worksheet, which is pictured as Figure 10. The Simple Process Architecture Worksheet should only show processes that are within the scope of the organization on which you are focused. It is not to be confused with a comprehensive process architecture covering all store activity. In this case we said that we are focused on a store, and not the corporation, as a whole, so we are only interested in processes that are executed within a store.
Architecture Frameworks
There are a number of architecture frameworks, as for example, the Supply Chain Council’s SCOR framework, the eTOM framework used by telecom organizations, the COBIT and ITIL frameworks used for IT architectures and the APQC’s various frameworks. If the organization in question already has some relationship with an organization with a framework, this may provide a ready source for a simple architecture.
3.3.5 Developing a Relationship Diagram
In addition to determining the other processes that occurred at the stores, the team also asked if there were any important interactions between the process and relationships or processes that might help define how the process-in-scope is to be judged. To record that information they then developed a Relationship Diagram.
The Relationship Diagram is not, strictly speaking, an elaboration of the Basic Process Diagram. The Basic Process Diagram maintains a clear distinction between things external to the process and things that occur within the process, while the Relationship Diagram does not. The process-in-scope can have relationships with individuals, organizations, or other processes that have a vested interest in the success of the process-in-scope. External stakeholders are typically individuals or groups outside the scope of the process that give or expect something from the process-in-scope. A customer is an external stakeholder. Internal stakeholders are individuals or groups that participate in the process, but also expect things from the process. Managers and employee are examples of internal stakeholders.
Figure 11 gives you an idea of some of the questions the process team might ask as they consider whether individuals, groups or processes might have a relationship to the process-in-scope.
As they talked about the various possible relationships that are directly involved and their interests, Steve and Roger gradually arrived at the Relationship Diagram that is shown in Figure 12.
3.3.6 The Stakeholder-Measures Worksheet
The key information about the various people, organizations or processes that have relationships with a process-in-scope is recorded on the Stakeholder-Measures-Worksheet shown as Figure 13.
3.3.7 Some Additional Problems with the Operation of the Store
The Waban, Massachusetts process redesign team, working with the consultant, Roger Wright, proceeded to ask a lot of questions at their store. They asked managers and employees about the problems they faced. For two weeks they gathered data by looking at complaints that had been submitted, by observing the processes and by arranging to interview customers. They used this information to prepare a Scope Diagram and, later, a flow diagram. And they recorded this information on both the Relationship-Measures Worksheet, and then on the Problem Analysis Worksheet.
The team noted that “established customers,” who have established credit with the store, had few complaints about estimates and prices. They know how to use the company’s website (or in some cases send emails) to order a job. They are usually more knowledgeable about what they want and check options on the website to indicate what they require. In a few cases, a Front Desk Clerk must call to check on some specific detail before the order can be processed.
“Off-the-street customers,” on the other hand were usually less familiar with the options offered, and it took more time to explain paper quality, types of bindings, and so forth. An off-the-street customer talks with the Front Desk Clerk, the clerk fills out the order form, then goes over it with the customer and requires the customer to sign it. On orders of less that $500, no initial credit needs to be established. For orders for more than $500, a credit card check for the amount must be “tried” before the order is approved, or a check must be provided in advance.
Either type of customer may request that the order be delivered. In the case of off-the-street customers, an order that is to be delivered must be prepaid.
Front Desk Clerks are asked to try to identify repeat customers and customers obviously representing companies and to ask them about becoming Established Customers. Data shows that stores with more Established Customers get more business. The stores would like the Corporation to change the order tracking software that the Corporation’s IT group prepares and puts on the store PCs so that it could print out a list of possible customers for sales campaigns, but so far it’s been left to the stores to identify and recruit their own Established Customers.
When an order is taken, a pick-up or delivery time is agreed. This is the time and day at which the order will be at the Front Desk, ready for pickup, or when it will be delivered by the delivery service.
The Front Desk Clerk must define exactly what must be done, calculate the cost of each item, and tell the customer what the order will cost and when the order will be ready. The latter requires some knowledge of how many jobs are in shop at the moment, and on how quickly the customer wants the order.
The Corporation keeps data on all stores. Thus, they know that on average, 2% of orders are late, and that 2.5% of the orders are incorrect in some detail. Individual stores track their own results and can see if they are above or below average. At the moment, the Waban store is delivering about 6% of its orders late and 6% of its orders imperfect according to the reports of the Front Desk Clerks.
Once an order is taken, a supervisor must assign the order to an operator and assign a priority to the order. (Priorities include – First, Today, and ASAP.) The supervisor often works the front desk, in effect functioning as the Front Desk Clerk, and in that case the supervisor can both take the order and assign it. Otherwise, the Front Desk Clerk must place the orders in a tray, and then explain them to the supervisor when he or she is available to assign orders.
Each Copies-R-Us store has three types of copiers. One is a large, high-speed copier that is best for large, complex jobs. It can do either color or black and white. One is a color copier. One is a black and white copier. It is more expensive to use a color copier for a black-and-white run and this should be avoided. There are separate machines for punching, cutting paper to special sizes, binding and stapling. Some stores have many machines of each type, but small stores normally have one large copier, and two color and black and white copiers.
Operators who can do simple jobs well are easy to find. More complex jobs, however, require attention to detail and care in ordering the sequence of events required. Back-to-back pages, for example, require that the pages be put in order for two runs (odds and evens) and that blank pages be inserted to assure that certain pages start on the right-hand side, etc. It’s easy to mess up and costly. So, good operators are not easy to find. Moreover, it’s apparently hard to hold on to good operators once they are found. Most of the Copies-R-Us store owners complain about the high employee turnover they experience.
Local store operators have often requested that the Corporation provide a training class for operators. They have also requested that they provide better procedures manuals for both the Front Desk Clerk and the Operators. The Corporation says it will do this, but has not yet been able to do it.
Each store has two shifts, a day shift and a night shift. A day shift supervisor who sees that lots of priority jobs are building up, can suggest to the owner that additional operators be called in for the night shift. Operators who work the day shift would rather not work the night shift, but they understand that it is occasionally necessary. If the night shift supervisor arrives, finds the shift load is too large and extra employees need to be called in, store owner approval is required (which is often difficult) before calling various operators and persuade them to come in. This can be very confusing and time consuming.
Operators get really upset if the assignments require one operator to work overtime to meet a deadline, while other operators have nothing to do. While store managers would rather not run orders on machines that are not optimal for the job in question, compromises are often necessary to meet deadlines.
3.3.8 Scoping the Project
Figure 14 pictures a Scope Diagram for the current Make Copies process. (We sometimes informally refer to this diagram as an IGOE or Inputs-Guides-Outputs and Enablers diagram.) In this case we show all the flows to or from all external people, organizations or other processes to the process-in-scope. In this initial diagram we note the products or services being exchanged and use symbols to evaluate whether or not they currently occur in a satisfactory manner.
In this diagram we sometimes picture external stakeholders (entities described by boxes with square corners), sometimes show internal stakeholders, and sometimes show processes that are within the organization-in-scope. (If you show it as a process on the simple architecture diagram, you show it as a process on the Scope Diagram. Otherwise it’s an individual, group or organization. In the case of individuals and groups, they can be external, and derived from the Relationship diagram, or they might be internal – as the employees of the Make Copies process are.
Defining the Final Scope of the Project
Figure 15 pictures a later version of the As-Is Scope Diagram, with problems and a red line drawn to suggest what will be included in the Analysis and Redesign effort.
The Scope Diagram provides everyone with an overview of some of the problems the team will seek to analyze and redesign.
3.3.9 Updating The Relationship-Measures Worksheet
The key information about the four external Stakeholders was recorded on the Relationship-Measures-Worksheet shown as Figure 13. After doing the Scope Diagram, the team returned to the Relationship-Measures worksheet and added information on the additional entities that they had found to have a stake in the Make Copies process. In additional to the external stakeholders, there were other processes within the stores that interacted with the process and there were other internal stakeholders as well.
Some BPTA analysts speak of the Relationship-Measures Worksheet as a Process Scorecard, since, in effect, the measures of value that the process will provide to each stakeholder constitutes a comprehensive way of stating what the process should do, and, ultimately a good way to measure the performance of the manager responsible for the process.
3.3.10 The Problem Analysis Worksheet
Once they had completed the updates to the Relationship-Measures Worksheet the project team proceeded to develop a Problem Analysis Worksheet where they defined the specific problems they had identified on the Scope diagram. As they did this they considered the measures they had already identified and began to get specific about how they would determine when each of the problems was cured.
The Problem Analysis Worksheet is divided into problem categories. Normally, after completing a Scope Diagram the team will fill in the first four rows: Inputs, Outputs, Guides and Enablers. Later, after the team has done a flow diagram, they will be able to complete the worksheet by adding problems with subprocesses, flows or process management/employee performance.
Problems and Causes
When we prepare the Scope Diagram, we list problems with inputs or outputs to the process-in-scope. Thus one problem might be supplies that don’t always arrive on time. Another might be customer complaints (that seem to keep arriving), or the fact the managerial policies are very difficult to implement, or that needed data isn’t available from the software application that clerks use. As we create the Scope Diagram we keep our descriptions of the problems very brief to fit within the space of the diagram.
Later, we transcribe the problems we identified on the Scope Diagram to a Problem Analysis Worksheet. The worksheet provides more space and we often provide a more comprehensive description of the problem. In addition, for each problem we describe, we enter information into the second column of the Problem Analysis Worksheet that describes how we would know if the problem was solved.
If the problem is that supplies are occasional delivered late, we would know the problem was eliminated if we could say that all suppliers are now delivered on or ahead of time. (Or, perhaps we might say that there are: No late delivery of supplies in the past quarter or year.)
Next, for each problem we identify on the worksheet, we state the cause of the problem. Sometimes the cause of a problem is obvious and we hardly have to think about it, but at other times the cause isn’t obvious and we need to work to determine it.
Consider the failure of a supplier to deliver supplies when they are needed. You might begin by assuming that the cause lies with the supplier and could be any of several things: Slow order processing, bad delivery scheduling, not maintaining adequate stock, not having the parts they need to produce the items when needed, etc.
Investigation, however, might show that we are partly to blame. We might find that the supplier asks for 30 days notice, and, while we routinely provide 30 days notice, when we get special rush orders, we often give the supplier only 10 days notice. In most cases the supplier can scramble and get us what we need, but sometimes they can’t provide the supplies within 10 days.
Identifying that we have a problem is not the same thing as understanding why the problem exists. Finding out why something happens usually requires looking at what occurred before the problem occurred, and it complex cases it may require examining multiple upstream processes to determine which results in the problem.
Before looking more closely at how we might identify the causes of problems, let’s consider the overall nature of the problems that we typically find on the Scope Diagram.
Internal vs. External Problems
We started with the Scope Diagram, and thus, we began by looking at problems that manifest themselves at the interface between a process-in-scope and external processes or individuals.
Consider, for example a situation in which our redesign team identifies an Input problem. Defective materials are being provided by a supplier. One can think about this one of two ways. We could treat this as an external problem, and ask the supplier to solve the problem (or find a new supplier). Or we could treat it as an internal problem and focus on discovering and rejecting the defective materials. In the second case we would be focusing on input-acceptance activities that occurred within the process-in-scope.
The first thing we probably need to do is get more information about the problem. How many defective units are being delivered per hundred units of material? Does a defective package of material that’s rejected cause flow problems, or do we receive enough materials that it’s simply a matter of returning the defective package aside without suffering any side effects? How easy would it be to get the supplier to fix the problem? How important is our order to the supplier? How easy would it be to replace the supplier with someone who we are sure would be more reliable? Finally, how hard is it to detect the defective items?
Obviously if we could get the supplier to solve the problem, it would be cheaper. Some large companies like Toyota insist that their suppliers take responsibility for assuming the quality of all deliveries. If large volumes are involved and we are a key customer, that may be possible. On the other hand, if the consequences of simply returning defective materials are low, it might be as well to set up our own input control system so that we control the quality and can consistently monitor our suppliers.
In Figure 18 we’ve shown how the team entered the defective supplies problem on the worksheet. The decided to approach the problem as both an internal and external problem. They didn’t worry about the external cause – that’s for the supplier to determine. They assumed the internal cause of the problem was a lack of quality control which allowed defective materials to get into the process.
Consider another example. Management policies are not being implemented correctly. Assume we examine the situation and find that the cost of complying with the management policy is very expensive, and the consequences of not complying seem to be trivial. (If you want a good example of this, consider that every so often, US aircraft unions have had disagreements with the US Air Traffic Control Authority. To express their grievances, the pilots proceed to comply, precisely with the Air Traffic Control rules regarding time periods between plane take-offs and landings. The effect is to slow traffic at airports to well below their normal rates, which throws off national airline schedules, and causes complaints from both passengers and Air Traffic Control administration. In essence, this tells us that airports do not normally comply with the letter of the law as to time periods between take-offs and landings. Normal practice, which is apparently acceptable, is to ignore the law regarding exact times between take-offs and landings.) Again, there are two approaches. One is to treat this as an external problem, and ask management to change their policy (or to at least ignore its non-enforcement). The other approach is to treat it as an internal problem and restructure the job environment and enforce exact compliance to the policy.
The process redesign team will encounter lots of examples like the ones just cited. In some cases their recommendation will be for management to negotiate with an external partner, provider, or other process owner. In other cases their recommendation will be to change an internal activity to solve the problem.
In a similar way, when the redesign team prepares the Problem Analysis Worksheet, they will either be identifying an external cause and suggesting that management deal with that situation, or they will be identifying an internal cause and recommending a specific change in the As-Is process to deal with the problem. If the latter, then the specifics of the recommended change will probably not be defined in detail until the team has examined the internal structure of the process (with a BPMN diagram, for example), observed decision process and human performance, and arrived at changes in specific activities that can result in the desired changes. Put another way, when you look at the Scope Diagram, you identify problems that fall in the top four rows on the Problem Analysis Worksheet. When you proceed to the Analysis Phase and look at the internal operations of the process you often identify internal problems that will fall in any of the six rows on the Worksheet.
As with our first example, we begin by identifying the problem – that defective materials are being supplied. If we know the cause we indicate it. At the same time, we indicate if it’s an internal or an external cause. If we don’t know the cause, we either leave the column blank, or we hypothesize one or more likely causes. Later, when we enter the Analysis phase, we seek more information and return to define the cause of the problem. We may determine, for example, that we don’t have any procedures within the process-in-scope designed to check new supplies to determine that they are correct. We may further decide that we don’t have employees trained to do that job, and that we will need a decision procedure to structure how employees analyze defective materials when they are encountered. We may also need to train managers in the importance on input quality control and provide them with measures to use in evaluating the work of employees assigned to that activity.
Note that the Problem Analysis Worksheet has six rows. We typically make entries in the first four rows as a result of creating a Scope Diagram. The final two rows, which focus on (5) flow problems, on the availability and organization of subprocesses or activities, and on (6) process management issues are usually completed after the redesign team develops a BPMN diagram and understands the inner workings of the process-in-scope. In a similar way, as we study the inner workings of the process-in-scope we typically find problems that are added to the first four rows. For example, we may determine as we do the Scope Diagram that we have a problem with customer complaints, but not understand much about why we are getting complaints. During the analysis phase we may gather data on the nature and timing of complaints and determine that over half the complaints result from customer-employee interactions. Further study of customer-employee interactions may suggest that employees aren’t employing good procedures. They don’t greet customers, for example, or ask questions to assure that they understand what the customer is asking about, etc. This, in turn, means we have an employee performance problem associated with our customer interface, which we list on our problem worksheet under either Inputs or Outputs, since that were most customer interactions occur.
In a similar way, customers may complain that decisions made by employees were incorrect. In that case we have a problem which is caused by a lack of a structured decision-making activity, which, again, will usually get listed under inputs or outputs since the decisions impact our interactions which customers that occur at those interfaces.
More on Root Causes
Let’s return to the broader issue involved in defining the cause of a problem. One simple technique that can often help is termed the “5 Whys” technique.
The 5 Whys Technique
To use 5 Whys, you begin by stating the obvious problem. Then you ask Why it’s a problem. Once you answer that question, you ask again, why that “cause” is occurring. You proceed in this way till you have asked “Why” 5 times or until you have reached what you assume to be the ultimate root cause of the observed problem.
Here is a nice example of the 5 Whys techniques provided by the Wikipedia entry on 5 Whys:
My car will not start. (the problem)
- Why? – The battery is dead. (first why)
- Why? – The alternator is not charging the battery. (second why)
- Why? – The alternator belt has broken. (third why)
- Why? – The alternator belt was well beyond its useful service life. (fourth why)
- Why? – I have not been maintaining my car according to the recommended service schedule. (fifth why, root cause)
In essence, we get to the root cause by drilling into the problem in a backwards manner, always asking why the problem occurred, until we reach the activity (or non-activity) that begins the chain of events that results in the problem. Put a different way, you want to solve the problem. To do that you need to identify something you can do differently that will result in a different outcome. Consider the example above. You can imagine that once the person determined that his or her battery was dead, they might assume that they could solve the problem (get the car to start) by replacing the battery. In fact, they might do so and it might work for awhile, but after a short time, the new battery would also fail, strongly suggesting that the cause was more fundamental than the battery. In a similar way, the person might next identify that the alternator wasn’t charging the battery and think of replacing the alternator, etc. Finding the root cause takes some investigation and usually some data gathering to be sure you have the root cause and that the change indicated will actually solve the problem.
Sometimes the 5 Whys works very well. In more complex cases, as when we need to consider multiple, simultaneous causes, we need a more sophisticated approach.
The Cause-Effect or Fishbone Diagram
To create a fishbone diagram, you begin with a statement of the problem. Then you back-up and hypothesize major potential sources (causes) of the problem, and put each one at the end of a major diagonal lines (fishbone) that slants toward a “backbone” leading to the problem box (effect). In the diagram that follows we are interested in determining why service is slow at a restaurant. We identified Attention, Beverage Service, Number of Tables, etc. as the major possible causes of waiter service that is slow. Next you identify more specific causes and list them on lines at right angles to the initial fishbones. Tertiary causes can be listed on lines slanting from those lines, and so forth.
An here is an example of an actual Cause-Effect Diagram
We use Scope Diagrams, Process Flow Diagrams, and the Problem Analysis Worksheet to capture problems. We use Cause-Effect diagrams to explore specific problems in more detail. In some cases we will create a Cause-Effect diagram, then realize that we still don’t know enough to determine what is wrong. In that case we set the problem aside and return to it during the Analysis Phase of the effort when we can design experiments and gather data to explore a problem in more detail.
Impact and Priority
The final column on the right side of the Analysis Planning Worksheet is used to indicate the relative importance of the problem. It is usually left blank during the Understand Phase and completed toward the end of the Analysis Phase when one has more data and understands the causes of the problems involved. In essence, we usually use the impact rating to help us determine what problems/causes we will try to address in a redesigned process. It’s often the case that 80% of the complaints arise from only 20% of the problems you might address. Similarly, some problems are quick and easy to address and some are complex, expensive and risky to address. Company goals sometimes determine that it’s better to address a few problems quickly and efficiently rather than trying to address all the problems the redesign team uncovers. These decisions are usually made during the analysis phase and then reflected in the assignment of Impact and Priority ratings that are done as once begins to focus on Redesign.
3.3.12 The Analysis Planning Worksheet
The team had now reached the point where it felt like it had a good overview of the types of problems that plagued the process-in-scope. The team wasn’t sure, in some cases, exactly why the problems occurred, but they felt that they had a good list of the problems, and were in a position to make some decisions about what the most pressing problems were, and which ones they might try to fix, and what they would want to learn more about during the analysis phase.
Figure 20. shows how the team uses the Problem Analysis Worksheet to create the Analysis Planning Worksheet.
The team uses an Analysis Planning Worksheet, like the one shown as Figure 16, to list some of the problems or issues they encountered in the Understand Phase which they hope to explore in greater depth during the Analyze Phase of the project.
At this point the process improvement team may very well make a presentation to its sponsor and senior management, describing the problem as they understand it at the moment, describing what they plan on doing during the analysis phase, and perhaps estimating what kind of a solution they think possible at this point. All this must remain tentative till more information is gathered, but at least the team should be able to estimate how long the analyze phase will take and describe the types of problems they have found during the understand phase. This is usually enough so that senior management can decide whether or not to proceed with the project.
3.3.14 Preparing a Business Case
At the end of the Understand Phase, the redesign team will often need to prepare a Business Case that they can present to sponsors and managers to convince everyone that it is worth proceeding with the project. Some organizations put this off until the end of the Analysis Phase and then create a Business Case for actually proceeding to redesign. In most cases organizations will want a revised Business Case at the end of the Redesign Phase to justify actually proceeding to Implementation. No matter when it’s done, a business case combines a description of what exists and what is to be created with an estimate of the cost and like effectiveness of proposed changes. A good way to conceptualize the information that ought to be contained in a Business Case is to add information to a Gap Model and then talk through the resulting model.
Figure 18 shows a Gap Model, with information added by the Copies-R-Us design team at the end of their Understand Phase. This model could be extended by adding some estimates of cost, but, even as it is, it provides a quick summary of where the team’s thinking is at the end of the first phase.
3.4. Change Management
So far, we have primarily focused on what the redesign team does to identify opportunities for process improvement. We have largely ignored the various tasks that the project manager in charge of the team must undertake to establish and organize the project. Thus, for example, when the redesign project began, someone was appointed to manage the project. That person, probably working with the project sponsors, chose team members, proposed an initial schedule, and started working on a budget. These activities are well described in various books and project management frameworks. There are specifics that are particular to process redesign projects – for example, it is usually good to have some of the employees who will actually implement the new process on the redesign team, and there are some established metrics for how long various types of interventions will normally take. But, overall, project management is well understood and we don’t pay much attention to it in the BPTrends Associates Methodology. We simply recommend that the person managing the process redesign project be familiar with a popular project management approach and use appropriate software tools to manage the planning, scheduling and budgeting of the project.
A more difficult topic is Change Management. As with project management, there are several popular change management methodologies, and we recommend that members of the project team be familiar with one of the widely used approaches. In essence, Change Management theories promote two basic ideas. First, people are made uneasy by changes they don’t understand, and thus it is important to work to keep everyone informed of what is being done and why it is being done. Second, people resist changes that will make their work harder, even if they think it will be harder simply because they don’t understand the change. Thus, its important to assure that people understand why the changes will help them rather than make things more difficult. (Sometimes, of course, changes will, in fact, make some jobs more difficult, or even eliminate them altogether. It’s important in such cases to communicate this and make provisions for it.)
The BPTrends methodology incorporates Change Management into its overall process approach. We recommend many activities whose essence is to communicate with stakeholders in the process being redesigned. In some cases those stakeholders will be employees and in other cases the stakeholders will be the managers or employees of other processes that interact with the process being changes. In a few chases the stakeholders will be customers or business partners. In all cases, the stakeholders should be interviewed and their concerns defined. As the redesign is evolved, these same stakeholders should be kept informed of developments. Figure 19 shows blue dots at places in the BPTrends redesign phases where meetings are recommended. Each of these meetings represents an opportunity to tell employees or managers what is being planned and to solicit their feedback. If specific individuals are identified that have particular problems, further meetings should be planned to try to find workable compromises.
We will return to this topic during later phases of the redesign when we consider what must be done for the roll-out of the process to help insure acceptance.
Speak Your Mind