4. Phase II. Analyze the Problem
The second phase of a redesign project begins when management approves the work that the team did during the Understand phase. This phase ends when everyone agrees on the nature of the problem that the To-Be process will need to solve. The team may pass from Phases II to III without a formal approval or the team may ask management for formal approval before proceeding.
Figure 24 identifies where Analysis 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.
An Overview of the Analyze Phase
Activities in this Phase
2.1 Model and Measure As-Is Process
2.1.1 Confirm Project Approach & Standards
Reconfirm the project approach for process improvement; establish/confirm process modeling and documentation standards such as process naming/numbering and documentation tools. (Use Analysis Planning Worksheet as needed.)
2.1.2 Model Existing Process
If the Process-in-scope is a high-level process, determine the need to further decompose the process into its sub-processes before creating a BPMN process flow diagram (“swim lane diagram”). Sometimes for selected sub-processes a scoping diagram (IGOE) may have to be created as well. (Create As-Is Process Flow Diagrams (BPMN) and extend the Relationship-Measures Worksheet as needed.)
We usually follow a 7 step procedure as we work to model an existing process
- Describe Top-Level Sub-processes
- Define the Interface with the Customer
- Review Activities and Flows (Lean and Six Sigma)
- Decompose Specific Sub-processes
- Define Decisions
- Define Employee and Management Performance
- Analyze Resources and Support
2.2 Assess As-is Process
2.2.1 Measure Process Performance
Gather data on process measures and determine gaps in performance by comparing to the desired measures. (Extend the Relationship-Measures Worksheet as needed.)
2.2.2 Analyze the Process
Conduct root cause analysis to determine issues and opportunities using process analysis methods such as reengineering, Lean, Six Sigma, as appropriate. The objective is to identify problems that inhibit the desired performance of the process. (Use detailed Process Flow Diagrams, Root-Cause Diagrams, Business Decision/Rule Worksheet, Manager, Employee, Process Alignment, and Human Performance Problem Worksheets as needed.)
2.2.3 Identify & Prioritize Improvement Opportunities
Any Quick Wins that require less effort and cost but provide desired business benefit are identified along with other potential solutions. Opportunities for Redesign Phase are documented.
2.3 Update Redesign Phase Plan
Update project plan, identify pre-work for the Redesign Phase and assign responsibilities. Assign post-Analyze Phase action assignments (for example Benchmark Trends role for process and its enablers need to be done prior to the next phase). These assignments are prerequisite to the next phase. (Use Redesign Planning Worksheet as needed.)
2.4 Decision to Proceed to Next Phase
Package and present phase findings to the sponsor and other relevant relationships; gain their approval. Update communication plan and communicate status to relevant relationships.
2.5 Initiate Any Quick Wins
Develop plan; assign team responsibilities to implement agreed solution. Sometimes the quick win solutions can be an interim solution only until the To-Be design is implemented.
Once management has approved the scope and the basic plan for the Analyze phase, the process improvement team undertakes several tasks, usually in parallel. One major effort involves defining the inter-workings of the process-in-scope. We usually do this with a flow diagram that pictures the activities, the flows between activities, and who is responsible for managing each of the activities that make up the process-in-scope. Depending on what we find, we may selectively drill down, diagramming key subprocesses, sub-subprocesses and even very discrete activities or tasks. Or, if a specific subprocess is very problematical, we may even do another Scope Diagram for the subprocess.
At the same time, the process improvement team will probably define ways to gather measurement data for specific activities and flows and gather that data. How long does it take for employees to complete a specific activity? How many rejects occur? This data is used to help define problems and, also, to serve as a baseline we can use to determine if the process is improved when we introduce changes.
Here is a quick overview of the worksheets and diagrams we use in the second and third phases of a process redesign project.
1 and 2. Throughout the Analyze Phase of the effort we continue to update the Relationship-Measures Worksheet and the Problem Analysis Worksheet as we uncover additional things to measure or additional problems to address. The Analysis Planning Worksheet we completed during Phase I suggests things to study during the Analyze Phase. In many cases this will require gathering data for several weeks or months and analyzing it to determine if there is a problem. As problems are confirmed their descriptions on the Problem Analysis Worksheet can be updated.
3. Early in the Analyze Phase we usually develop a flow diagram (BPMN diagram) of the current (As-Is) process-in-scope. The Scope Diagram provided us with an understanding of how the process-in-scope relates to other external stakeholders and processes. The BPMN diagram lets us dig inside the process-in-scope and explain how its subprocesses work together to achieve the results we expect from the process-in-scope.
4. In some cases, one flow diagram will provide all the information we need about the internal workings of the process-in-scope, but if the process-in-scope is complex at all, we will often find we need to analyze subprocesses into their component sub-subprocesses. We would never, automatically analyze all of the subprocesses we find within the process-in-scope into their sub-subprocesses. We analyze the subprocesses and then only go deeper if it seems really important to do so. Our goal is not to do analysis for its own sake, but to use analysis techniques, sparingly, to identify the problems with the process-in-scope that we will want try to fix. Recall that we will likely achieve 80% of the improvement by fixing about 20% of the problems. The other problems are “nice to fix” but not critical, especially if time and budget are limited. (And time and budget are nearly always limited?)
5. One way we avoid doing unnecessary diagrams of subprocesses is when we encounter subprocesses that involve decision making. Rather than look at the sub-subprocesses involved in making a decision, it is often easier to analyze the business rules that employees use to make the decision. In these situations, we use a Business Decision-Rule Worksheet to record information about how the decision is made.
6. As when you conclude the Understand Phase and prepare a worksheet to document the problems you will want to examine in more detail in Analysis, so when you finish Analysis and prepare to enter Redesign, you prepare a Redesign Planning Worksheet to identify the specific problems that you have decided you want to deal with in the redesign. This may be a subset of all the problems you identified, but these are the problems that your team decides will give you the kind of change you want from the project.
7. Once you enter the Redesign Phase, the team will focus on exactly how you might change the existing process to generate a new, more effective process. If the changes are extensive or difficult to explain, you will probably want to generate a new flow diagram (a To-Be BPMN diagram) to show exactly what the process will be like, when the changes are implemented.
With this overview in mind, let’s look at some of the artifacts the Make Copies Redesign team generated.
4.2 Modeling the Make Copies Process
So far we have talked about the Make Copies process in terms of how it is perceived from the outside. We have considered the outside stakeholders and processes that interact with the Make Copies process. And we have defined the problems, as they are perceived by those who interact with the process.
As the team enters the Analyze phase, they will continue to consider some of the problems between the process and outside groups and processes, but they will now also begin to look inside the process to determine how effective and efficient the process is and to identify internal problems that might cause the external problems. Thus, during the Analyze phase the team will usually begin by developing a flow model that shows how the subprocesses work together to create the Make Copies process work.
We usually follow a seven step procedure to analyze a process in detail. The steps include:
- Describe Top-Level Sub-processes
- Define the Interface with the Customer
- Review Activities and Flows (Lean and Six Sigma)
- Decompose Specific Sub-processes
- Define Decisions
- Define Employee and Management Performance
- Analyze Resources and Support
Step 1. Describe Top-Level Sub-processes
The first step simply involves dividing the process in scope into its top-level sub-processes. Occasionally there will be some disagreement as to names and the scope of the sub-processes, especially if the process-in-scope crosses departmental boundaries. Similarly, there will be those who prefer more sub-processes and those who prefer fewer. As a rule of thumb, there should be from 3-7 sub-processes. The important thing, however, is that the entire team agree on the sub-processes and their overall scope. One way to think of it is to think of the sub-processes linked in a flow, and to ask what input starts each sub-process and what output concludes that sub-process and initiates the next one.
Recall that when we did our Scope Diagram, we listed sub-processes to help define the boarders of the process-in-scope. In that analysis, the group decided to include Take Order, Prepare Copies and Set-Up Delivery within the scope of Make Copies, but didn’t include Deliver Order. In the final analysis, as a result of our Scope Diagram, however, we drew a red boarder line that included Deliver Orders, since we decided we wouldn’t be able to improve the Make Copies Process without also analyzing and redesigning the Deliver Orders process. Thus, when we draw our Make Copies Process below, we include Deliver Orders.
Figure 26 suggests one way we might conceptualize our Make Copies process.
Step 2. Define the Interface with the Customer
Step 2 involves defining the broad interfaces between the process and the customer. This can get quit complex – there can be multiple customers, for example, or many different interactions. When we are looking at the major sub-processes of our process, we usually try to keep it as simple as is reasonable. In the Make Copies case, we simply note that the Customer places and order, and then later receives the copies.
Another way of thinking of what the customer does is to think of the customer as working through his or her own process – in essence, a customer’s Order Copies process. When we show the interactions between the Make Copies process and the Customer’s Order Copies process, we are, in effect, showing what the customer has to go through to do business with our organization. Most organizations are quick to assert that they value their customers and want to make things as easy as possible for the customer. This is a chance to really identify with the customer and to think about how to simplify things for the customer. We can imagine being customers. Can we imagine there is a better way for the customer to obtain copies? Could we modify our business process to make it easier on our customers?
At the high level of analysis we are at now, we don’t see the details. For example, what information does the customer need to provide, and how long does it take the Order Taker to check the information the customer provides? Could we simply things by establishing credit in advance, for repeat customers, so they didn’t have to provide credit card information each time they call? Or could we store their address so they don’t have to provide that each time they place an order?
At this point, we have defined the basic customer interfaces for our Make Copies Process. As you will recall from our earlier analysis of the Make Copies Process, when we developed a Scope Diagram, there are some customer interfaces we haven’t shown here. There were walk-in orders and there were complaints. We could add these additional activities, but we probably wouldn’t do so at this level, but would wait till we drilled down a bit. Also recall that when we did our Scope analysis, we found that Deliver Orders was a serious problem we decided needed to be analyzed and changed, but internal pick-ups and complaints were not listed as serious problems.
Step 3. Review Activities and Flows (Lean and Six Sigma)
Let’s assume that we now have a basic set of large-scale sub-processes, each linked by a flow, and they we understand how our high-level sub-processes interact with our customers. We should look, next, at each sub-process and asking ourselves if the sub-process is necessary. In essence, each sub-process begins when some input occurs and ends when some output is produced. Take order begins when a customer calls in and asked for a pizza, and it ends when the Take order clerk sends an approved order to the Make Pizza sub-process. One starts by asking if that work really needs to be done. Once satisfied, one moves on to the next sub-process. Our Pizza example is rather trivial, and each of its sub-processes is, in fact, required. Often, however, when one examines large, complex business processes one uncovers activities that are more questionable. Reports are generated, or inventories are maintained, and it isn’t clear why these things need to be done. The process analyst should challenge each sub-process, one at a time, to assure him or herself that the sub-process really is required to accomplish the goals of the process-in-scope.
Each sub-process has some inputs and generates one or more outputs. In each case we ought to define the outputs of each sub-process, and then arrange to measure the quality and the consistency of the outputs. This will require a knowledge of data collection and statistics as taught in most Six Sigma classes, although whether the team insists on consistency that reaches six Sigmas will depend on the specific process and the goals of the overall sub-process.
In a similar way, one should look at sub-processes to determine if they need to be separate. Wouldn’t it be easier to have a single delivery activity, instead of one called Schedule Delivery and another called Deliver Pizza? In fact, the scheduling activities take place at the Pizza Shop and involve checking maps to plan the best delivery routes. Delivery itself is undertaken by young people in cars who simply follow the directions provided by the delivery schedulers. One involves planning, scheduling and grouping deliveries, while the other simply involves manual activity on the streets. They could be grouped – at a high level the boundaries of a set of activities is rather arbitrary – but given that they involve different tasks done by different people, it’s certainly OK to leave them separate in this case.
One reason to leave them separate is that you usually want to measure the quality and consistency of sub-process outputs. Determining if the scheduler is doing a good job is rather different from determining if the delivery drivers are consistently doing a good job.
Figure 24 suggests some of the checks we might make as we look that the basic activities and the flow of our core sub-processes.
Waste
Many of the checks we make at this point can be nicely described by Lean, with its idea of Waste. In essence, Waste occurs when we do something we shouldn’t. Here are some of the types of Waste that Lean advises we look out for.
Overproduction. This refers to the production of too many units. In the case of Pizzas-R-Us, the bakers only prepare a pizza when they get an order. Hence, every pizza is “pulled” through the process. That is to say, a customer, is waiting for the pizza and a given pizza is developed only because a customer is waiting for that specific output. Hence, there is no overproduction at Pizzas-R-Us
Waiting. Waiting is also known as queuing and refers to a period of inactivity that results when an upstream process doesn’t deliver an adequate supply of input to a downstream process. Ideally, you’d rather not have employees standing around with nothing to do. If the Pizzas-R-Us store opens at 4pm, for example, and people only begin to call up to order pizzas after 5pm, then employees are standing about for an hour. In this case it might be better to open the store an hour later. If most orders come in after 6pm, it might be best to have one order taker and one baker arrive at 5pm and others arrive later, when volume increases.
Similarly, if orders pile up waiting to be baked, then customers are going to be waiting longer than necessary. It’s important to have enough bakers to assure than the customer wait time doesn’t become too extensive. A process analyst examines each activity to determine if there is waiting.
Transport. Transport usually refers to moving things an unreasonable distance between stations. Assume that supplies, including floor, pepperoni, and tomato sauce were all delivered by truck on Mondays and stored in a room at the back of the building, near the loading dock. Further assume that in the course of an evening, the baker was forced to run from the kitchen area to the loading dock area to acquire ingredients as they ran out. Better to move the appropriate ingredients to the kitchen at the beginning of the shift. But this would still require transport each evening. Better still to redesign the work area so that ingredients were stored on shelves on one side of the kitchen, so that a baker could reach for a needed bottle without moving from his or her cooking location.
Extra Processing. This refers to rework. It could happen, for example, if a baker put the wrong ingredients on a pizza and a customer sent the pizza back and asked for one that matched the order. It could also happen if the order taker entered a wrong address, and then got a call from delivery saying that there was no such address, and asking the order entry clerk to call the customer and get the correct address. All issues like this should be captured in ongoing measures of the output of each sub-process. In essence, this is a quality control failure and, if it becomes common, will require personnel or process changes to rectify it.
Inventory. This refers to the accumulation of inventory that is not required for the current orders. Since the pizza shop is entirely controlled by Pulled activities, its hard to imagine this happening in this particular case. You might argue that having too many delivery drivers at work at a particular time, and having two cars idle, waiting for pizzas to delivery is a kind of inventory and should be address by reconsidering the driver’s schedules.
Motion. Motion refers to people having to move. If one located the order takers in one room, and the bakery some distance away, and then required the order takes to write out an order and hand deliver it to the bakers, you would have a very inefficient process. Computers have gone a long way to minimize the transport of information. In a good pizza shop, the order taker creates the order on a computer screen, then presses a button and the order instantly shows up on the screens of both the baker and the delivery manager, minimizing transport.
Defects refer to any output that is unacceptable. As discussed above, this could take many forms, from orders lacking enough information, or pizzas without the right ingredients. It’s important to define measures for quality for each activity and then begin taking systematic measurements to assure that quality is consistently met.
Quality and Consistency
As when we looked at the sub-process, so as we drill down. We examine each activity to define its output(s) and we then establish measures to determine if the output is of sufficient quality and if it is consistent. (Quality is concerned with whether or not a specific output instance is adequate. Consistency is concerned with whether the average output instance is adequate.) Every time we drill down to look at sub-sub-processes or activities, we consider, again, if each of the sub-sub-processes or activities is performing as desired.
Sequence or Flow
At the same time that we consider the necessity of each sub-process, we also consider the overall sequence in which the sub-processes are done. Occasionally, it’s possible to reorder the events and introduce efficiencies. On other occasions, it’s possible to divide a single flow into multiple flows and perform tasks in parallel. If one has a situation in which most items flow through the system quickly and without difficulty, but a few items prove difficult and require special handling, it’s often useful to divide the flows and set up a special team to handle the difficult items. In effect, by dividing the flow, one distinguishes between “regular” employees who handle the regular items, and “specialists,” usually more experienced employees, who handle the more complex tasks. Breaking flows into parallel tracks, in cases like these, usually results in a faster average processing time, and less mistakes.
Step 4. Decompose Specific Sub-processes
The four sub-processes of our Sell Pizzas process are relatively high-level processes. At some point, once we decide which sub-processes have the most need of further attention, we will probably want to decompose some or all of the sub-processes into their constituent sub-sub-processes. (We usually term sub-sub-processes “activities” to avoid the rather awkward terminology. Or, if the analysis involves a very complex process, we term the highest process (Sell Pizzas) the Level 1 Process, the sub-processes that make it up, Level 2 Processes, and the sub-sub-processes that make up individual Level 2 Processes, Level 3 Processes, and so forth.)
For the purposes of this example, let’s assume that we decided to look into the constituents of the Take Order sub-process in more detail. We begin with a large box to represent Take Order and start by working out the major inputs and outputs and what occurs within the process to handle the inputs and generate the outputs. In this case we can see that there are some branching points – as for example, when a credit card is rejected by the credit card agency. As we proceed with our analysis we develop not only an analysis of the Take Order sub-process, but we refine our understanding of the Customer and Support processes used by the Take Order sub-process. (See Figure 29.)
In fact, what we discover from conversations with managers and employees from Pizzas-R-Us is that the Entry Clerks enter orders directly into their computers, and that it is the existing computer application that checks with the credit card company to approve credit cards and, once the clerk approves a given order, places the order on the baker’s queue. We don’t want to confuse the activities done by people taking orders with work done by the computer, such as creating a new order, so we create a new pool below the Take Order pool and list the activities that they computer application handles in that pool, as shown in Figure 5. (If we wished, we could use small BPMN adornments to show which activity boxes pictured manual activities and which were automated.)
More On Activities and Flows
Once we have defined the activities within the Take Order sub-process, we return to Steps 2 and 3 and review how the customer interacts with each sub-process and we examine each activity and the flows between them to see if we can identify any opportunities to eliminate waste or smooth the flow.
If appropriate, we may decompose other sub-processes, or we may even decompose some of the sub-sub-processes we identified in our analysis of Take Order. We are not interested in any unnecessary process modeling, which takes time. We are, however, interesting in identifying potential problems with the process and follow any hints that there are problems.
For certain processes, its worth defining the flow of a sequence very precisely and running simulations with a BPM tool that includes simulation capabilities. Simulation requires quite a bit of work, but it can identify bottlenecks or opportunities in flow plans that people would probably not identify without the simulation. In addition, simulation provides a strong test of assumptions is the flow is really complex and minutes and seconds are really important.
Types of Subprocesses or Activities
Assuming we are satisfied with our understanding of the essential names and the flows between subprocesses or activities, before proceed further, its often useful to define the essential nature of each of the subprocesses or activities. BPMN provides symbols that can be inserted into a BPMN diagram as adornments to subprocess or activity boxes (See Figure 30.) Some teams will consider this and others will simply identify the nature of the subprocesses or activities without feeling the need to add the adornments. However its done, its useful to be clear about the essential nature of the activities before proceeding with further analysis, as it will suggest the type of analysis tools that one should consider as seeks to better understand the process and identify potential problems.
The BPMN symbols or adornments we most commonly use are shown in Figure 26. A small stick figure of a human means that a human performs the activity. A gear means that the activity is performed by a machine, a robot or a computer. By default we assume that the activity is made up of a series of procedural steps, unless we have a small symbol of a matrix, which means that the activity is made up of a decision of some kind.
Recall, in addition, that we have already been using “stop” and “caution” signs to indicate where we suspect problems. Thus, when we look at our BPMN diagrams, we see processes with known problems and we can also see the nature of the activities that are probably generating our problems. This gives us a good place to start as we consider what addition analysis activities we will need to undertake.
Step 5. Define Decisions
If we indicate that an activity involves a decision, and we are concerned with the performance of that activity, then we need to inquire as to the nature of the decision and consider whether we could structure or automate it to make it better, more reliable or more consistent.
Before considering decisions in detail, we need to make a distinction between Flow Decisions and Activity Decisions. Figure 31 pictures a sequence of activities that are linked by decisions. In this case, we refer to the decisions shown as “Flow Decisions.” The nature of the question is shown, and the answer to the question is provided over flow arrows that show what happens next. In some cases this kind of analysis is sufficient, and merely providing employees with a diagram like the one shown in Figure 31 – or converting the diagram into a decision table which might be easier for employees to read – would suffice.
In other cases, however, we need to dig a little deeper and ask what likes behind the “Flow Decisions” pictured in a diagram like the one shown in Figure 31. Consider the first decision pictured: Can we do the job? At a copy center this might be a simple decision. The customer wants 10 pages copied, and needs 20 copies. That’s exactly the type of work we do, and we have a precise way of estimating the cost, etc. Assume instead, however, that the customer wants the 10 pages copied to some kind of foil paper. We don’t normally do this and the order clerk might need to check to see if the copy machines would work on foil paper – assuming we even have any foil paper.
Or, stepping away from a copying example, assume this process describes a complex engineering task. The job is to design and construct a railroad intersection that will involve trains being able to cross over other tracks and the entire project would cost millions of dollars. An engineering firm might have several engineers spend several days defining exactly what might be involved in designing such a railroad intersection, and determining whether or not their firm could make a reasonable bid on such a job.
Flow decisions are defined on flow charts and indicate how a flow decision is made. In the first instance shown on Figure 27, the flow decision involves deciding whether or not we can do the job. Activity decisions are decisions made within the activity itself. They may require an employee to make calculations or employ hundreds or thousands of rules to determine the correct answer. In the case of international bank loans to foreign countries, a loan committee made up of a number of managers may meet for hours or weeks to determine if the bank is prepared to make a multi-million dollar loan to a country applying for it.
If the decisions involved in a particular instance can be defined with a few flow decisions, then we can elucidate them and use them to structure future decisions. If the decisions involved in another instance involve complex decisions that are the essence of the activity, then we much work a bit harder to define the nature of the decision and the knowledge and rules required to make the decision.
Figure 28 provides an overview of the approach to decision management recommended by the Object Management Group’s (OMG) Decision Management standard that is emerging as the standard in dealing with Decisions.
The approach begins with a BPMN diagram and the identification of activities that involve Activity Decisions. From there, an analysis team need to proceed to define the actual decision in more detail. Some decisions take place in the course of a series of steps, and in that sense are procedural. Most decisions, however, are not procedural in nature, but logical or declarative. They involve determining facts that add up to a conclusion. Consider the following rule that a bank loan officer might use:
If the company applying for the loan has:
A good management team, and
A solid financial position, and
A good plan to repay the loan, and
The bank has available funds, and
Isn't over-exposed in the specific industry,
Then fund the loan.
In effect, each clause of this rule is a condition that must be met, before the funding decision can be made. The order in which you determine that each clause is true isn’t important. If you can check the financial position more quickly than checking on the quality of the management team, you might start your analysis there. This is the sense in which it isn’t procedural.
Now imagine that the loan officer has another rule that runs:
- An executive team (CEO, CFO, COO) that has been in place for more than 5 years each, and
- Each member of the executive team is in good health, and
- Each member of the executive team is under 60 and has no plans to leave
Then the company has a good management team.
In effect this rule guides the analyst in determining what the bank means when it talks about a good management team. Moreover, since both rules use exactly the same phrase, a good management team, there is no ambiguity about the terms.
Without going into too much more detail at this point, you can see that we define a decision by creating a rule that concludes with the decision we wish to make, and defines the facts that we will need to determine to reach that conclusion. We work backward into the problem, by then defining rules that conclude each of the facts that we will need to reach our final conclusion, and so on. As we develop this system of rules, it is important that we are unambiguous about the terms we use. This is easy to say, but often very difficult in practice. Large organizations often use common sense or technical terms in vary different ways. For one department a “customer account” may mean one thing and it may mean an entirely different thing for another group at the same company. Thus, defining a complex decision process can take quite a bit of time. One needs to determine the overall structure of the decision (using rules as we have suggested). As one develops rules, one encounters terms or phrases that need to be precisely defined.
Decision Requirements. At the same time, as one develops all this, one divides the rules and the clauses or facts that make them up into sets, and determines individuals or documents that define, and ultimately manage, the terms and rules that will be used. All this is pictured in the OMG’s Decision Requirements Diagram in Figure 28.
Figure 29 pictures a data model or semantic net drawn from a detailed example in the OMG’s DMN Specification. This approach, which is often required when analyzing large sets of rules, defines exactly how a group of business terms are to be used and pictures their relationships.
This may all seem rather complex, but its one of the reasons that organization’s frequently make poor decisions. No one has spent the time to be precise about the terms or rules used, and there is too much ambiguity about too many of the terms. (A decision analyst can gather data and do some calculations. What return does the person who makes the best decisions usually get on his or her effort? What return does the average employee who makes decisions get? If you could improve the average decision results by 50% what would that earn or save your organization in the course of a year? The savings or earnings are often very impressive.
The Decision Logic. Finally, we need to document the actual business rules that will be required to make the decision we are concerned with. Obviously this is a iterative process: We develop rules as we define our final conclusions and as we seek to identify the terms we need to define in our data model and vice versa.
We provide a worksheet (Figure 34) that can be used in class when we first introduce the idea of rules, but we strongly recommend that real decision analysis teams use a software tool that makes it much easier to keep track of business rules and terms or clauses.
A Decision Service. So far, we have not said anything about who will use the rules to make decisions. In some cases we may want to package our rules as a decision table, a checklist, or in some other format that employees or managers can use. In other cases we may want to place our rules in a software tool that can automate the decision process, or turn them over to software developers who can incorporate them into applications. However its done, defining the rules used in an important decision-based activity, is one of the best ways of improving how a business process works.
A special problem that we don’t usually consider in introductory courses is a process analysis that involves determining that a subprocess or activity is very dynamic or complex and needs to be analyzed using a collection of techniques that increasingly go by the name “Case Management.” The term “Case Management” is derived from the healthcare industry, where each patient’s arrival for medical care associated with a specific medical problem is termed a “case.”
Imagine a patient arriving at a hospital emergency room complaining of a chest pain. It could be anything from an upset stomach and gas to a heart ailment of some kind. The receiving clerk “opens a case.” In essence a process is initiated: “Diagnose patient problem” without our knowing precisely what steps will follow. What follows will depend on what we find along the way. A physician meets with the patient and asks questions. Depending on the patient’s age, medical history and his symptoms, the physician will probably call for tests. As test results arrive, the physician may very well call for follow-up tests. At some point the process may be defined more precisely as the physicians decide what is probably wrong with the patient and prescribe a treatment routine.
In the past, most processes that process practitioners analyzed were procedural in nature. They involved assembling cars or toys, or they involved processing packages and delivering them to specific destinations. Increasingly, however, processes are more complex and they change more often. Today’s processes are often service processes, and are adjusted to deal with the needs of specific customers, as our hospital example illustrates. In any case, increasingly, process practitioners are being asked to analyze and design processes that are appropriate for “case management” situations. It’s rage that large processes require “case management” techniques, but increasingly, as one drills down into a process one identifies sub-processes that are best treated as “cases” rather than conventional workflows. The symbol we use on BPMN diagrams to indicate that a specific subprocess or activity is a “case” is to replace a standard activity box with a file folder, as shown in Figure 35.
As we have already mentioned, one major feature of case management problems is that they typically don’t come with a clear cut path. Instead, one does some initial examination and then prescribes the next step, or in some cases, the next several steps. As new data is gathered, however, the process may change, to continue to be responsive to the particular patient and an evolving understanding the of the nature of the problem.
The OMG team working on defining a notation for case management has proposed treating a case as a file folder and then including sets of activities within the folder, without linking them. (The dotted lines shown in Figure 32 do not represent a path, but rather logical links between sets of rules.) Each rule set has a trigger – represented by a diamond on the boarder of the activity. The trigger is a rule: If something… then use this activity. The activities may be rule sets, to make further decisions, or them may be procedures, as one would find if a specific test, or heart surgery were called for.
In essence, we define a case rather loosely, as a set of activities that might be used. In an actual case only some of the activities are actually used. Some activities are procedural, but many others involve decisions, often about what to do next, or how to do it with respect to a particular patient.
Case Management is a more flexible approach to specifying a process. Moreover, the Case Management approach relies rather extensively on the use of decisions and rules, which is why we have included it here.
Step 6. Define Employee and Management Performance
Returning to our analysis of the nature of activities, if your analysis of a process flow suggests that there are processes in which people play a major part, then you have to ask if the people are performing as they should. Assuming you have established some measurements that allow you to judge the output of the subprocess or activity, you can refer to your data. Something as simple as the Scope diagram, however, may already have indicated that a team of managers and employees agree that some process output is unacceptable. The team may have concluded that reports due to an outside agency are consistent submitted late and are often rejected because they are improperly completed. Thus you may have a red stop sign on the subprocess or activity, Prepare/Submit X Form, and, since its an activity done by employees, have already determined that the employee performance is unacceptable.
People performance problems derive from two intertwined considerations. In some cases the employees who are expected to perform the tasks don’t know how, or simply choose not to do what they are expected to do. In other cases, employees don’t do what they are supposed to do as a result of some activity or lack thereof on the part of the supervisor or manager who is responsible for the employee’s work. A good manager can get good performance out of most employees. A manager using poor practices can degrade employee performance. In some cases the solution may be retraining or even firing an employee, but in most cases, significant employee problems suggest that we need to change the management practices of the person responsible for the process. We will consider these two possibilities independent of each other.
In trying to analyze employee performance, there are two ways we can think about it. If we have established measures, then we check to see if the employee is, in fact, meeting the established measures. Is he or she producing the number of units expected per hour? Do customers complain that the employee is impolite or unhelpful? The other way we approach the problem is to look at average employee performance and compare it with the results achieved by the best employee. The gap between average and the best performance suggests how much improvement we might achieve if we could move all performance so that it was closer to the best performance.
Employee Problems
There are various approaches to analyzing human performance. The approach used by BPTA derives from ISPI (the International Society for Performance Improvement) that has formalized the model shown in Figure 33. This model suggests that employees work well, or fail to work as well as they should, for a variety of reasons, which are defined in the model. In each case we will be considering the work that is expected of the specific employee. In a well-organized situation, the specific employee’s work will probably be specified by means of a Job Description, and one usually starts one’s analysis be examining the Job Description and then visiting the employee’s work environment and making observations and interviewing the employee.
Some might find it easer to think of the Human Performance Model as a Cause-Effect or Fishbone Diagram. In this case, we use the categories we have already identified and put then into the Fishbone format. Next, we add tertiary “bones” to enumerate specific examples of each type of problem.
No matter which way we conceptualize the model, to analyze human performance problem, we consider each of the factors illustrated in Figure 37 in some detail.
1. Activity Specifications. Do activity standards or specification exist? If measures exist, then one assumes they measure whether the activity meets one or more standards. Obviously if one is a new manager and there are no existing measures or standards in place, then one of the manager’s first tasks is to create them. It’s always useful to check to see if standards are documented and to ask performers how they interpret the standards. It’s always possible that someone provided performers with standards, then established measures. Later they might have changed measures without realigning the standards that the employees are using. Similarly, it’s worth checking on what standards software developers used when they created any software component used in the activity and assure they are current and aligned.
Does the performer know the desired output and standards? Once the manager knows that standards exist, he or she should next determine that the people or systems performing the activity know what the standards are. Obviously people can’t systematically achieve a standard they don’t know about. If performers don’t know about a standard, it’s the manager’s job not only to assure that they learn about the standard, but also to devise an arrangement to make sure that they don’t forget it and that other, new performers learn of the standard. Moving the standard from a line of text in a manual to a sign posted in the workplace is one way to accomplish this.
Do performers consider the standards attainable? Few people persist in trying to achieve something they can’t achieve. When systems designers are asked to create components that are expected to achieve results the designers know they can’t achieve, they tend to create components that simply do what can be done. Unattainable standards shouldn’t happen, but occasionally they are established by someone who isn’t being realistic. A manager needs to check to see that everyone agrees that the standards are, indeed, attainable. If they aren’t, either because no one could achieve that standard, or because an existing performer can’t, the manager needs to make changes. In the first case, one changes the standard. In the second, one changes the performer or system.
2. Activity Support. Can the performer easily recognize the input requiring action? Consider a situation in which salespeople are wasting their time on unqualified prospects. The manager should begin by determining if the salespeople know what a “qualified prospect” is. If the salespeople don’t know the difference, then one step in solving the problem is to teach them how to recognize qualified and unqualified prospects. There are lots of problems that arise from similar causes. Diagnosticians don’t check for certain potential problems because they don’t recognize the signs that suggest they should make such a check. Developers create systems that respond to one set of inputs but don’t build components that respond to other inputs because they don’t realize that those situations could occur.
Can the activity be done without interference from other activities? Sometimes one activity will interfere with another. Consider, for example, a salesperson under pressure to obtain more sales and to provide documentation for past sales. These are two separate activities, and in a good situation there would be time for both. Sometimes, however, achieving one activity might preclude the successful completion of another. Or consider that one person may need to answer phones right next to someone who is trying to write a report. The report writer is constantly distracted by the person carrying on phone conversations. Or consider that a given activity may require a forklift, which someone else is always using for some other activity. In an ideal workplace none of these things happen, but in the real world they often do. Managers need to check the environment in which the work is to take place to assure themselves that one activity isn’t interfering with the performance of another.
Are adequate resources available for performance (time, tools, staff, information)? Are needed resources available to those performing the activity? Do they have the time required? Do they have the tools needed for the job? If staff support is required, is it available and adequate for the job? If information is needed, is it available? These are obvious sorts of things, but more performance failures can be tracked to environmental problems than to lack of trained employees or employees who willfully choose not to perform some task. This is an extension of budgeting—assuring that employees and systems have the resources needed to perform their jobs.
3. Consequences. Are consequences aligned to support the desired performance? Motivation can be turned into a complex subject. In most cases it’s really quite simple. It involves knowledge of the task to be performed, consequences, and feedback. Consequences refer to whatever follows the performance of an activity. Salespeople who make sales usually expect praise and bonuses. Every sales manager knows that a good incentive system gets good results. If people perform and only get complaints that they didn’t do even better, in most cases it results in even less adequate performance. Imagine two activities: sales and entering information about sales. Imagine that the salesperson has less time than is needed to perform both tasks well. Further imagine that he or she gets a significant bonus for every sale but only gets complaints at the end of the month if all the system entries haven’t been made. Which is the salesperson likely to do? It’s always important to not only consider the consequences of each task by itself, but to also consider the effect of asking one individual to do several tasks with different consequences.
Are consequences meaningful from the performer’s perspective? Different individuals respond to different types of consequences. It’s important that the consequences be appropriate to the individual. Bonuses usually work, but in many situations, a day off will be more appreciated than a small bonus. Some employees look forward to the opportunity to do some travel, and others regard it as punishment. The good manager should have a clear idea about the consequences that will be valued by different employees.
Are consequences timely? Lots of research shows that consequences that immediately follow an activity are more likely to affect performance than those delayed. This doesn’t mean that you need to hand salespeople money as soon as they return from a successful sales call. It does mean that the reward system should be clear so that the salesperson can calculate what bonus he or she made on that sales call. Making an effort without knowing if there will be consequences isn’t a good practice. Giving someone a big, surprise bonus at the end of the year isn’t nearly as good as giving smaller bonuses that are clearly associated with excellent performance. Best is a system that makes the consequences clear so that employees can mentally reward themselves when they succeed. The same thing is true in reverse. Punishment should be closely associated with the action that deserves punishment. Waiting for a yearly evaluation to tell someone he or she is not performing up to snuff is a bad policy.
4. Feedback. Do performers receive information about their performance? Forgetting more explicit rewards, every manager should ask if employees receive information about the outcomes of their work. Assume the manager collects information about the number of chairs that arrive at the distributor’s site undamaged versus with defects. As soon as the manager gets such information, he or she should pass it along to the employees involved. If defects go down, employees should learn about it (and receive praise as a consequence). If defects go up, employees should be informed immediately. Similarly, if chairs arrived damaged as a result of poor packaging, the employees in shipping should learn about it immediately, and vice versa. In too many companies, employees try to do their jobs, and month in and month out no one tells them if their work is adequate or not. After awhile, most employees will take a little less care if, as far as they can tell, no one notices or cares if they take more care. This is an area where the process sponsor plays an important role. Often the feedback needed by people in one subprocess isn’t immediately available to the functional manager managing that subprocess. Care taken in packing may only pay off in reduced customer complaints, which go to sales and service and never directly to manufacturing or packaging. It’s the process sponsor’s job to design a process-wide feedback system that assures that subprocess managers have the information they need to provide their people with timely feedback.
Is the information they receive relevant, accurate, timely, specific, and easy to understand? As with consequences, there is more useful and less useful feedback. It’s important to tell the packaging people that chairs are getting damaged in transit because chairs aren’t properly packed. It’s much more useful to tell them exactly how the chairs are being damaged so they will know how to change their packaging process to avoid the problem. Many companies provide managers with accounting data that is summarized in ways only accountants can understand. This isn’t useful feedback. (This is one of the reasons for moving to an activity-based costing system to assure that cost information can tell specific employees about whether specific activities and subprocesses are contributing to the value of products or costing the company money.) A manager that yells that a subprocess isn’t performing up to snuff without being specific about what’s wrong is only creating anxiety and increasing the problems facing the people in that subprocess.
5. Skill, Knowledge, and Capability. Do the performers have the necessary skills and knowledge to perform? In many companies, the solution to all performance problems is to provide more training. For many employees, one of the worst features of a job is having to sit through training courses that drone on about things one already knows. The performance of a task requires specific information and the skills needed to evaluate the information, make decisions, and perform tasks. In most cases the place to begin is to identify the performer who is doing the job right, and then ask what is missing in the case of a performer who isn’t doing the job right. If the deficient performer needs to learn specific items of knowledge or specific skills, then some kind of training is appropriate. Before training, however, be sure you really are facing a skill/knowledge problem. If employees have performed correctly in the past, it’s very unlikely they have forgotten what they knew. It’s much more likely in that case to be an environmental problem or a problem arising from a lack of feedback or consequences.
Do the performers know why desired performance is important? The importance and effort we assign to a task usually reflects our understanding of the importance of the consequences that result. If employees don’t realize that some seemingly minor shutdown procedure, if left undone, can, infrequently, cause a major explosion, they might tend to skip the shutdown procedure. On most days, indeed for months or years, there may be no consequence. In these situations it’s important that employees have a good overview of what’s important and why it’s important.
Are the performers physically, mentally, and emotionally able to perform? Finally, it’s important to assure that performers can actually perform the tasks assigned. If employees can’t reach a shelf or can’t read English, there are tasks they simply can’t perform. In some cases changes in the environment will help. Steps can be provided or signs can be posted in another language. In some cases, however, an individual simply isn’t able to perform a task. In those cases another performer needs to be assigned to the task.
If one has employee problems, one begins by examining the work environment and the employee and answering the questions outlined above. The Human Performance Worksheet provides a way to capture information gained by considering the model pictured in Figure 34. In effect, one considers each employee working within the process, in turn, and asks the various questions suggested in Figure 33.
As the analyst thinks about the problems he or she observed when they considered employee problems, they will begin to divide them between those that are definitely the responsibility of the employee, and those that may well be the result of decisions taken by the employee’s manager. Some problems can be addressed, with changes in employee job descriptions or new employee training programs. Other changes will require that the redesign team interview the manager responsible for the activities/employees in question and consider changes in the way the manager operates.
Managerial Problems
Figure 40 shows how we might think of how a process manager related to the process and employees that report to the manager.
The Process Management Model is a different way of looking at the employee/management problem. In this case, we assume that employees are working to execute the process, and we focus, instead, on what the operational manager responsible for the process is doing. In Figure n, the tasks of the manager responsible for the process are pictured in the blue rectangle labeled “The Job of an Operational Manager.” As you can see, we have divided all of the operational manager’s tasks into three groups.
Figure 36 suggests that process management activities consist of three major subprocesses: Plan and Organize Work, Lead and Communicate Work, and Control Work. Each of these subprocesses, in turn, includes a variety of different activities. Some of the activities, like Establish Plans and Schedules, are quite complex and could easily be classified as processes in their own right. Thus, we stress again that this overview of the process management process is only one possible representation.
Plan and Control Work. If you are on a project redesign team and are asked to analyze a process, you will usually begin by figuring out the basic activities or steps that make up the process. Assuming the process has been performed for some time, you can assume that goals, plans, schedules and a budget are in place. As you talk with employees and managers concerned with the operational aspects of the process, you should remain alert for complaints that suggest that employees don’t understand the goals of the process or that well-understood plans or schedules are missing. Similarly, you should listen to see that needed resources are provided. If an activity fails to function correctly because it is understaffed or because needed resources are unavailable, you will want to note that, and it will suggest that you will want to talk with the process manager about why he or she thinks those problems have occurred. In an ideal world, when a new manager takes over the responsibility for a process, he or she ought to review all the assumptions and assure that plans, budgets and schedules are adequate for the objectives of the process. If they aren’t, they should be altered. Unfortunately, too often a new manager will simply use the scheduling and budget assumptions of a predecessor and this will lead to misalignments as time passes and procedures change.
Plans and schedules may assume resources, but then the manager needs to proceed and organize the resources. The steps in the process need to be defined. Jobs and roles need to be defined. Needed equipment and technical resources need to be put in place and coordinated. Once again, in most cases, a new process manager inherits a process that is already functioning. If the manager is sharp, he or she will review all the inherited assumptions. There are two guiding principles that the process manager will want to pursue. First, to be successful the process must meet the output requirements reflected in the contract negotiated with the downstream process. Thus, the first goal of any organizational effort will be to assure the process is organized in a manner that assures that the output requirements can be achieved. Second, once the output requirements are being achieved, the process manager should focus on improving the efficiency of the process itself. If the output requirements can still be met as a result of a process reorganization that reduces the number of employees, or increases the productivity of existing employees, or consumes less resources, that is invariably desirable. This is the time to look for waste and eliminate unnecessary activities. Since a major source of waste is rework, this is also a time to consider how the consistency of the output can be improved.
Put a different way, the first task of the process manager is to design or redesign the process to assure it meets its output obligations. The second task is to work to constantly improve the internal working of the process.
Lead and Communicate. So far we’ve described the process manager’s job in rather analytic terms. In fact, of course, process management involves working with people. Some would term this leadership and others might term it teamwork. We simply use the term “communicate” to refer to all of the activities that a process manager must undertake to assure that the process runs smoothly and achieves its objectives.
A quick glance back at Figure 36 will suggest some of the types of communication that the process manager has to master. The process manager needs to communicate with the managers of the upstream and downstream processes and with the managers and employees of key support processes. The process manager needs to communicate with his or her functional or unit manager and with any process manager with responsibilities for a value stream that includes the Make Copies process. Finally, the process manager needs to communicate with the employees of the process. Employees function best if they know why they are doing what they are asked to do. The process manager needs to communicate reasons for the process work and, to the degree possible, communicate commitment to achieving the goals of the process. Once again, there is a large literature on communication and managerial leadership. It’s easy to be glib about it, but it’s very important and it’s usually quite obvious if it’s missing or defective when you do an analysis of a process and interview employees and up- or downstream managers.
Consider only one of the many types of communication that’s required of a process manager. We have already suggested that the process manager needs to look for opportunities to improve the process and make changes in organization of flow and the tasks performed to assure that the process becomes ever more efficient and effective (or better, faster and cheaper, if you prefer). At the same time that the process manager is looking for opportunities to make changes, he or she should be aware that most people hate to change. Change causes discomfort. It requires learning new things and it results in employees making mistakes as they try to implement new procedures. (The author of this book, for example, does everything he can to avoid upgrading to new software, knowing, as he does, that it will reduce his efficiency and increase his frustration when he tries to figure out a new way of doing things.) The process manager not only needs to identify opportunities for change, he or she needs to be sure the change will really result in a benefit to the organization, and then he or she needs to sell the change to the employees who will be affected by the change.
Monitor and Control Work. Finally, we come to measurement and the work a process manager must undertake to assure that goals are met. Obviously, monitoring and control are related to the goals set in the Plan Work process. Similarly, all of the measures used in the process should be linked to the external measures developed during the Plan Work process when the project manager negotiated a contract with the “customers” of the process. In essence, the contract defines process success and, indirectly, it defines the process manager’s performance.
The Monitor and Control subprocess relies on the external measures to define internal process measures. Where the external measures focus on the quality, quantity, and timeliness outputs, the internal measures focus on the cost and the efficiency of the activities, and, in some cases, on the ability of the process to make changes in the internal process to ramp up output or reduce output in appropriate circumstances. At the same time, the smart process manager will develop some leading indicators to make it possible to anticipate output problems.
Obviously the manager can only provide good feedback to employees if he or she has good data about what happens downstream from the Make Copies process. Establishing good feedback channels is part of the manager’s job. Similar, establishing consequences for on target and off target behavior is very important. Too many managers fall into focusing on mistakes rather than spending a good bit of their time rewarding effective performance. In the long run, you get the best results from rewarding effective performance.
Step 7. Analyze Resources and Support
In step 7 one is really returning to a concern that we originally faced when we developed a Scope diagram of the process. We are asking if the resources adequately support the process work the process is working to accomplish. When we do a Scope diagram, we consider anything that is used, over and over again in the course of doing the work as a kind of resource. Thus, employees are a resource, just as desks, tools, machines, and computer systems and the data they provide are all resources that we need to perform processes.
When we consider resources and support from this perspective we are primarily concerned with whether the resources provided are adequate for the activities to which they are assigned. Do people have the skill and knowledge they need to deal with particular situations? Are computer screens easy to read? Do they provide spaces for all the information that needs to be entered. Is required data easy to access on computer, or via smart phone access, for example, if sales people need it for an activity requiring smart phone access? Are there enough desks and chairs, computes and other tools required to perform tasks?
The Problem Analysis Worksheet
When the team finished the Scope Diagram during the Understand Phase of the project, they completed the first four rows on the Problem Analysis Worksheet, identifying problems encountered with the Input, Output, Guidance and Enabling interfaces to the process-in-scope. Now, having nearly completed the Analysis Phase of the project, the team revisits the Problem Analysis Worksheet and adds additional problems.
There are two rows for new information about internal problems, but it is also likely that the team will add other problems or comments to the first four rows on the worksheet.
No matter where you locate the specific step, the team needs to examine the Problem Analysis Worksheet they completed as they concluded the Analysis Phase and then prepare a Redesign Plan Worksheet. In the process of transcribing each cause/problem should be examined to see if it should be included in the redesign. In some cases specific problems will be omitted from the Redesign Plan, either because they are too trivial or because they are too expensive or risky to tackle in this specific redesign effort. As a rule, 20% of the problems you identify will result in 80% of the actual performance defects that make the existing As-Is process unacceptable. That means that even if you only address about 20% of the problems you have identified, you can make a major improvement in the process. This is the time to prioritize and select the actual problems to be addressed in your redesign. Those are the one’s you actually enter on your Redesign Plan worksheet.
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.
Redesign Planning
As they reach the end of the Analysis Phase, the team begins to consider a plan for the Redesign Phase of the project. If the two phases are going to be run together, without a meeting to gain management approval, then you might consider the shift from the Problem Analysis worksheet to the Redesign Planning worksheet as the first step in the Redesign process. In most cases, however, the team will want to work up a plan for the Redesign Phase, and then submit that plan to management to gain approval. In those cases, the shift from the Problem Analysis worksheet to the Redesign Planning worksheet takes place at the end of the Analysis Phase as a way of preparing a proposal for management.
We recommend a meeting, not because we think the team should need approval, but primarily because it gives the team an opportunity to meet with manager and sound them out about the project. In other words, the meeting, and subsequent interviews and negotiations is an exercise in change management. It provides the team an opportunity to communicate with management, to identify potential objections or individuals who are resistant, and to lay the groundwork for the new process approach.
No matter where you locate the specific step, the team needs to examine the Problem Analysis Worksheet they completed as they concluded the Analysis Phase and then prepare a Redesign Plan Worksheet. In the process of transcribing each cause/problem should be examined to see if it should be included in the redesign. In some cases specific problems will be omitted from the Redesign Plan, either because they are too trivial or because they are too expensive or risky to tackle in this specific redesign effort. As a rule, 20% of the problems you identify will result in 80% of the actual performance defects that make the existing As-Is process unacceptable. That means that even if you only address about 20% of the problems you have identified, you can make a major improvement in the process. This is the time to prioritize and select the actual problems to be addressed in your redesign. Those are the one’s you actually enter on your Redesign Plan worksheet.
Figure 44 shows a Redesign Planning Worksheet that shows some of the problem elements the team has decided to focus on. This worksheet is completed near the end of the Analyze Phase and it sums up the changes that the team will try to make in the Redesign Phase when they begin to consider how the As-Is process might be converted into a To-Be process.
Speak Your Mind