Business Processs Design—Completing the DNA
By Harvey Dershin -- Supply Chain Management Review, 5/1/2000
Over the last decade, much work has been invested in developing elegant computer systems to follow transactions and synchronize performance in an attempt to integrate supply chain operations. Such systems, however, are only marginally successful without effective business processes to support them. Companies that try to implement advanced systems without considering the complementary business processes will never achieve full supply chain integration.
A supply chain can be characterized as "the mother of all processes" because it includes the entire collection of activities by which a company plans, produces, and distributes products to customers. These activities may be categorized as:
- Physical processes (for example, manufacturing, transportation, and warehousing).
- Information processes (such as recording transactions, statistical forecasting, synchronized planning, and management support).
- Business processes (including planning, sourcing, deployment, and logistics).
The three process groups are not independent but wind together like RNA molecules to form the "DNA" of the integrated supply chain. And like DNA, the overall entity will not function properly unless the physical, information, and business processes are designed to work in synchronization. This is what an integrated supply chain is—not merely the integration of information but the integration of all three groups of processes.
On its face, this statement seems trivial. How could one think of integrating a supply chain without considering all three groups of processes? But, in fact, it is a common misunderstanding. Companies make huge investments in information technology (IT) processes, for example, without considering the two other elements of the supply chain "DNA"—particularly business processes.
It is easy to see how this can happen. An IT system is something people can put their hands on. It requires hardware, software, programming, and interfaces. It prints or displays reports and data. Business processes are less obvious. People know they are present but often do not think of them as processes per se. Seldom are business processes designed consciously and only rarely are they under control (in the true sense of process control). This situation often results in an information system that is suboptimized or even rejected entirely by potential users. Organizations sometimes interpret this reaction as resistance to change, creating an immediate call for the "change management" consultants. But it is just as likely an oversight with respect to the design and introduction of new business processes necessary to support the IT systems.
This article describes how to design business processes in support of supply chain operations by using a structured team-based method known as Juran quality planning. It is based on the work of Dr. Joseph M. Juran, a world-renowned leader of the quality movement. This discussion is followed by a case study that illustrates the Juran principles in action.
The Juran Approach to Business Process DesignJuran's structure for quality planning is not widely known or used. It is a comprehensive methodology encompassing—as so much of Juran's work does—the technical, managerial, and cultural aspects of process management.1 Juran's method applies universally to product and process design. This article will focus only on the portion of quality planning applicable to process design. Some liberties also have been taken to streamline the methodology. For example, the quality planning methodology relies heavily on spreadsheets, much like those found in quality function deployment, to link the various steps of the design process. The author has found these to be burdensome to the design process and has omitted them. With these and several other small adjustments, quality planning can be used with design teams easily and quickly.
Quality planning entails five essential steps: establish a project, identify customers, discover customer needs, develop a process, and develop process controls and transfer to operations.2
Establish a Project
This essential part of the process includes empowering a team, providing resources, giving specific direction as to mission (and quantifiable goals), allowing the team an opportunity to challenge or adjust the mission and goals, and setting forth a rough timeframe for completion of the work. In addition, since both the chartering body (usually senior managers) and the team have full knowledge of the project content, both groups understand the work that has to be done. Having this understanding up front makes it easier to set a realistic timeframe for executing the project.
Identify Customers
The purpose of this step is to identify and, if possible, prioritize the potential users of the business processes. A distinction initially is made between internal and external users so as to recognize both groups; however, this distinction tends to blur as the design moves forward.
A high-level flow diagram is developed at this point of the methodology, before any design work is accomplished. The purpose is not to jump ahead prematurely to a new design but, rather, to get a rough feel for how the new process might work. The primary purpose of the diagram is to aid the identification of potential customers. It also helps to set boundaries for the new process.
Discover Customer Needs
Most of the needs are collected in face-to-face interviews with prospective users. The output is usually a blizzard of raw information, 20 to 30 percent of which is noise. The art of managing this step is turning this raw feedback into useful information. The following steps are helpful:
- Each interviewer reviews his or her feedback with the rest of the team, extracting individual need statements, writing them on small Post-it Notes, and plastering them on a wall. If five people collect customer needs, it is not unusual to have 100 to 200 Post-its on the wall when this activity is complete.
- Have the entire team review the "wall" of needs, removing the ones that are out of scope or duplicates.
- Conduct an affinity exercise, grouping the needs into major and minor categories. The outcome is usually a half dozen or so major categories of need.
- Attempt to prioritize the major groups.
- Quantify the needs as much as possible. For example, a need might be to "have a report first thing in the morning." Try to put a definitive time to such a statement.
This step results in a set of user needs that should inform and, if they do not conflict with project goals, drive the design of the business processes.
Develop a Process
Teams are usually a bit edgy when they start this activity, not knowing how they are going to develop the process. But here's where the team magic occurs as the creativity of the group kicks in. Exactly how the user needs are converted to business processes will be covered later in this article.
Develop Process Controls/Transfer to Operations
There are two ideas in this step: (1) Any process such as the supply chain must be controlled or it will eventually begin to decay, and (2) Transferring a new design to operational status is a difficult endeavor that must be planned and managed carefully.3 This step may be the hardest part of the design process. Teams are close to the finish line at this point and just want to get the job done. Usually management is pressuring the team to finish up. The power of using a structured approach shines through at this juncture because the necessary tasks already are spelled out; they just have to be completed.
Within these steps, certain considerations are particularly relevant to supply chain design. These include teams and facilitation, creating a new business process, supply chain process control, and change management.
Teams, Facilitation, and SpeedThe heart of Juran's quality planning structure is the project team. Yet project teams are like soufflés—beautiful when they rise and awful when they fall. The business landscape is littered with the carcasses of failed teams. Sometimes whole categories of teams have failed (like Quality Circles). At an individual project level, teams fail for a variety of reasons. These reasons can be categorized under two broad headings: management and team process.
- Management:
- Lack of management support
- Project not aligned with corporate goals
- Unclear mission or goals
- Unrealistic timeframe
- Under-resourced
- Wrong members or leader
- Preconceived notions about the end-product
- Lack of a structured methodology for conducting the project
- Not trained to follow a methodology
- Blind adherence to a methodology
- Do not understand customers or their needs
- No imagination
- Unable to reach consensus
- Preconceived notions about the end-product
- Incomplete design
- Process design not robust
- Process not capable of meeting desired specifications
- Lack of controls
- No plan for transferring the design to operations
Given all these possible pitfalls, it is fair to wonder why project teams should be used at all for business process design. The reason for using teams is that, if they work well, it is possible to design and build a "soufflé" that is unmatched anywhere else.
Even with a structured method such as quality planning, there will be obstacles along the way. To help navigate around them, it is beneficial to have a trained facilitator guide the process. The team facilitator is one of the true innovations of the quality movement.4 The facilitator is like a good baseball manager. He or she guides the team through the design process, intervening as necessary to keep the process moving and on target. A skilled facilitator can help create a better product, faster, by avoiding all the possible pitfalls. In providing this guidance, the facilitator serves in three main capacities: project-management support, process specialist, and teacher and coach.
If this seems like a tall order, it is. Projects as complicated as designing a global supply chain call for tact and experience. The best facilitators guide without being noticed. If they become too heavy handed, the team will simply roll over and mentally turn the project over to the facilitator. This is a recipe for disaster because while facilitators can guide, synthesize, and support, they cannot effectively create.
Creating a New Business ProcessBuilding a new business process demands a high degree of creativity from everyone—the entire team and the facilitator. The following scenario illustrates one effective way of generating that creativity.
Imagine a project team war-room. On the walls, we might find the team's mission and goals, clear statements of customer or user needs, a very high-level sketch of what the process might look like, and perhaps a sketch of the old process (if there was one). Now what? The team looks to the leader and facilitator. "Tell us what to do next." The team leader looks to the facilitator, "You've done this before, now what?" The facilitator starts to sweat. The thing not to do is start drawing flow charts.
First things first ... At this point, the team is searching for the constellation of processes and subprocesses that will be needed to meet customer needs and project goals. The team needs to name these processes first and describe how they might work afterwards. What will the new processes do? What will be their outputs? How many are necessary to achieve particular outputs? What will be their boundaries? Do they have to fit together? If so, how? Are there any key subprocesses that can be imagined at this point?
The creative process starts with conversation among the team members. "How might we deliver this or that customer need?" " Do we need a new process for this?" "Can we think of a way to kill two birds with one process?" "If we do need a new process are there any special subprocesses that will be necessary?"
The output of this sort of dialogue is a list of prospective new processes. Some of these may not survive the first day. Others may be added later.
Then ... Once the processes have been named, the team can begin to figure out how they might work. One by one, each process is talked through and diagrammed. The facilitator lays out the flow chart, at the team's direction, using Post-it Notes and a convenient wall. Team members are encouraged to add, delete, change, or move the notes. The process is active, engaging, and iterative. It can sometimes move with surprising speed. The result is a set of flow charts. These contain enough detail to show the new scheme but avoid getting too cluttered up for easy comprehension.
This effort needs to be digested and followed up with a period of questioning. "Are we meeting goals and needs?" "Is there anything new or different here?" "How is this better?" "Is everything covered?" Do not be surprised to find, at this point, that the flow charts are not yet perfect or that an entire sector of activity has been forgotten.
Finally ... Each process-flow diagram is taken down to fine detail either in flow chart or information format. This last step is particularly useful for identifying the linkages with specific information-support systems and for beginning to identify process steps that might be critical.
Design of Complex Business ProcessesThe team does not stop at diagramming basic or fundamental processes. It also seeks to understand and attempt to control the more complex business processes associated with supply chain design. Early on, it is instructive to talk to people responsible for managing the day-to-day supply chain operations. These are the people engaged in forecasting, production planning, purchasing, manufacturing, deployment, transportation, warehousing, or customer service. From these discussions it quickly becomes clear that much of their time is spent dealing with problems or issues that are "out of the ordinary." "The customer changed an order, I don't believe the forecast, production did not match the plan, a carrier had a flat tire, the warehouse can't find the delivery, and on and on and on ..."
In fact, it is the "out of the ordinary" that is ordinary! Why is this so, and what can be done about it? Note that even the most elaborate information technology would not solve these sorts of problems. While timely and accurate information can help to resolve problems, the details of problem solving will be found by examining the associated business processes.
Management of Complex ProcessesFor the sake of internal consistency, let us define a non-complex process as one that is routine, has few decision points and feedback loops, and is reproducible over time, within narrow statistical boundaries. Conversely, we can define a complex process as one that has many options, decision points, and feedback loops and is reproducible only within a very broad statistical range. An example of a noncomplex process might be moving a routine shipment of finished goods from a distribution center to a customer. A complex process might involve filling a customer order when there has been a production shortfall and the product will be delayed. The first example is a straightforward activity that can be executed almost in its entirety by a computer system. In the second case, a person has to intervene and find or make the product quickly while somehow mollifying the customer.
Supply chains are loaded with complex processes. People who work with and manage supply chain elements become expert at handling complex situations. It is the art of their jobs. But let us introduce some different thinking on this subject. Suppose that a primary goal of supply chain managers was to eventually drive out complexity. This goal requires a different approach.
Managing a complex process differs from managing a straightforward one. For example, one cannot easily draw a flow chart to describe how such a process would be handled. There are too many options and feedback loops, many of which have strange outcomes. A perfect example is the well-known "Beer Game" as described by Senge.5
Complex processes need to be approached based on methods for managing adaptive systems. This author applied such methods in a recent paper, based on a set of ideas from J. H. Holland's book, Adaptation in Natural and Artificial Systems.6 Holland points out that "In seeking to adapt to changing circumstances, the 'parts' develop 'rules' (models) that anticipate the consequences of events. ... [These models] allow a complex adaptive system to respond, instant by instant, to its environment, while improving its performance."7 He offers a three-part general theory for optimizing complex systems:
- Parallelism: "Lets the system use rules as building blocks ... to act upon changing situations."8
- Competition: "Allows the system to marshal its resources in realistic environments ... under a deluge of mostly irrelevant information ... extracting useful, repeatable events [and] ... incorporating them as new building blocks."9
- Recombination: "Underpins the discovery process, generating plausible new rules from building blocks that form parts of tested rules."10
Let us move Holland's theories into the supply chain setting but use terms that will be more familiar to managers. For "parallelism" substitute "general rules," for "competition" substitute "tools and decision aids," and for "recombination" substitute "continuous improvement."
- General rules allow managers to apply priority rules to supply chain management, permitting them to act upon situations that, for the most part, are predictable.
- Decision aids are required in more complex situations. The implication is that the supply chain manager extracts information from the situation as it unfolds and tailors action to move the situation into a more favorable position. Decision aids are devices to assist the manager in moving from point to point under a specific set of circumstances (as opposed to a routine flow chart, which may move a process from beginning to end).
- Continuous improvement provides an orderly process by which managers perpetually review and revise general rules and decision aids based on feedback from the latest experiences. Continuous improvement also stimulates the creative process, generating new guidelines from those already tested.
When faced with a complex process, a company would then follow general rules and use decision aids to help it select from a range of actions. Continuous improvement systems would ensure that these efforts remain on track and that managers learn from each experience. The case study at the end of this article includes an example of a complex process design for handling exceptions.
Supply Chain Process ControlAfter designing the processes, the team needs to identify the necessary process controls. At the outset of this article, the supply chain was characterized as the "mother of all processes" because of its scope and complexity. And yet, for the most part, most of the processes in the supply chain are not under control! How can this be? A supply chain is often the most expensive part of a company's operations. If a supply chain does not work properly, both customer satisfaction and organizational finances will suffer.
First, let us explore what is meant by control. In manufacturing, control means that the product manufactured conforms to specifications.11 If a manufacturing process is not under control, it will produce defective products. Process control and inspection systems are put into place to assure that this does not happen. Similarly, a process under control means that it conforms to specifications. In the context of our discussion, process control would encompass a supply chain's physical, information, and business processes.
Process control in manufacturing is a well-established technique. The concept of controlling IT processes, however, is relatively new and comes as a surprise to some managers. It is customary to think that an IT process, once it is debugged, never changes. Thomas Redman, however, points out the fallacies in this thinking.12 Furthermore, because supply chain systems often are built from an assembly of different systems, they are particularly vulnerable to data quality and system-performance issues.
Similarly, this author's experience is that business processes are rarely controlled. Yet, without such control, unacceptable levels of variability can creep into supply chain business processes, degrading performance measures. This is one of the primary reasons why supply chains seem to be full of complex processes and why supply chain managers spend so much time on crisis management. The methods of process control are well known; it is simply a matter of applying them to the supply chain.
As the team decides upon process controls for the supply chain, it needs to make sure that the controls help the process achieve the desired performance measures or specifications. The performance measures are straightforward. They encompass the needs of both internal and external customers as well as company managers. External and internal customers require defect-free product, timely delivery of product, easy-to-use systems, and accurate shipments. Company managers want low costs for operations and use of assets.
It is simply not possible to achieve high performance in these areas if process control is not in place. No amount of information technology will compensate for out-of-control processes. The physical manifestations of poor control are scrap, rework, excess equipment, excess space, excess inventory, expediting, workarounds, customer cuts, defects, backorders, "complications," and lost revenue.
To make sure that the process remains in control, the team needs to design a control system that:
- Minimizes process variability.
- Provides warning when processes are not meeting—or are trending in such a direction as to not meet—specifications.
- Informs process improvement.
The controls should cover suppliers, manufacturing, distribution, customer service, planning, and information technology.
Managing the ChangeTo implement the new business processes and controls effectively, the team needs to understand two key elements of change management. The first involves providing an orderly method for introducing a new or redesigned process into an organization. Juran's quality planning methodology deals with this in the last step, "transfer to operations." Here, issues of process documentation, training, job aids, facilities, materials, staffing, and audit are addressed.
The second element involves recognizing and overcoming organizational inertia or active resistance to the change. As Michael Hammer points out, "When a process changes ... so do the jobs of the people who work in that process. ... [and] people's styles—the way in which they think and behave ... must also be realigned to fit the new process."13 It should be added that process changes might also alter an organization's power structure, shifting authority from one manager to another. These are two powerful forces to contend with for any type of process change. Given the vastness of a typical supply chain, these forces can be overwhelming. And unless effectively addressed, they can defeat the best of intentions.
All problem-solving exercises start with diagnosis—understanding the nature of the problem. So it is with change management. Hence, the first step in managing change involves understanding the potential effects. A process change does not affect all people the same way. It is useful to clarify who will be affected and to what extent. The diagnostic table shown below can be helpful.
| Organizational Role | Awareness | Acceptance | Ownership |
| A | X | ||
| B | X | ||
| C | X |
The first column lists all those who will be affected by the process change. The next three columns indicate the level of change required from the particular role. For example, position A simply needs to know about the change, while position B needs to accept the change as useful. This person may be expected to use the output of the changed process or may see his or her job or authority altered in some way. Position C is also critical because this person owns a segment of the process or perhaps the entire process.
Clearly, each of the identified positions warrants a different approach with respect to managing change. In the first case, the need can probably be satisfied with some general, but effective, communication. The second case, Position B, requires in-depth information to justify the change. Position C needs to be fully committed to the change because it will be part of the new process.
This powerful diagnostic focuses the attention of the team on the key players and their particular types of needs. The approaches to managing change can then be customized as appropriate. Note that "communication" as an agent of change only adequately serves those in the awareness column. The other two groups require more substantive action, such as those described in Juran and Gryna's "rules of the road" for overcoming resistance14 or Hammer's "key mechanisms."15 Overall, executive consensus is the most important factor in managing change in the supply chain. More process changes have been defeated by disagreements among senior managers than by anything else. Nothing is more destructive to employees—and by implication to the change process—than hearing different messages from different leaders.
A Checklist of Key ConsiderationsAn integrated supply chain must consider physical, information, and business processes. In designing effective business processes, supply chain executives should keep in mind the following:
- Structured methods exist to aid business process design.
- Knowledgeable facilitators are key to speedy and effective design.
- With proper guidance, teams can be used effectively to create a new business process.
- The design and management of complex business processes is fundamentally different from that of noncomplex processes.
- All three categories of supply chain processes should be under control (physical and information as well as business).
- A change-management "diagnostic" should be performed before initiating any activity.
- Senior-management consensus is vital for effective change.
- Multiple business processes may be required to support IT initiatives. These business processes can be identified and developed rapidly.
Understanding these points will keep the business process design effort on target. Another valuable aid is the following case study, which illustrates how one company implemented a successful business design process for product deployment.
CASE STUDY
A Success Story on Deployment
This case from the author's files describes the design of a set of business processes to support a centralized deployment function. The case is disguised to preserve the company's privacy, but the essential elements are intact. The subject company is a manufacturer of consumer products with 10 plants and six distribution centers providing finished goods to retail outlets all over the United States. The company's products encompass a dozen major brands and 15,000 to 20,000 stock-keeping units. Key performance indicators for supply chain executives are to minimize days of finished-goods inventory on hand and to provide a high level of customer service (fill rates in excess of 95 percent).
At the time of the design project, the company recently had purchased a computerized planning and management system capable of synchronizing information throughout the supply chain. The system was intended to improve the organization's ability to plan, produce, and deploy goods significantly. In the context of the case study, the term "deployment" refers to the movement of finished goods from producing plants to regional distribution centers.
The computer system's deployment module combines orders, forecasts, finished goods on hand, goods in transit, planned production, and inventory targets to develop requirements for deploying the product to distribution centers. The module has an added virtue of being able to consolidate planned deployments into efficient shipping loads.
Previously, plant personnel handled deployment of goods to distribution centers. Senior management felt that, with the new computer system, deployment could be done more efficiently and effectively from a central location. Management established a team to design the business processes for the new function, with the author serving as facilitator. The team followed the Juran quality planning process.
During the first phase of the process, the team set its mission as follows: Design and implement a process for shipping goods and balancing inventory between plants and distribution centers via a centralized location, using the new deployment module as the primary tool. A related objective was to improve customer service (case fill/order fill) by having inventory in correct locations at the right time. The company would achieve this by balancing inventory and freight costs better. This balance would be accomplished by reducing freight costs, obsolescence, and unjustified deployments. The project would kick off in early July 1999, and all plants would be fully operational by the first quarter of 2000.
After these initial steps, the team identified its customers and its customers' needs. The team's research indicated that internal customers wanted the new deployment process to identify and rapidly resolve potential service failures and to provide a broader level of accountability. Internal customers also wanted the process to act as a key communication link with others in the supply chain, such as sales, purchasing, transportation, warehousing, planning, and production. They wanted the process to provide feedback to these functions on production and distribution issues that may affect service or costs. It was important to these customers that the processes be available off-hours and reflect the local needs of both plants and distribution centers.
The team then identified six major processes necessary for supporting the new computer module and satisfying the customer needs. Two of these were computer processes—the deployment module and the special stock availability exception report. The remaining four were business processes: deployment, periodic inventory balancing, management integration, and a tracking or control system. The deployment process is made up of three separate subprocesses: routine deployments, handling exceptions, and pre-builds.
Most of the processes that the team identified were noncomplex. Exhibit 1 gives an example of how one of these noncomplex processes, the routine deployment process, would be diagrammed.
The company would arrive at one of those actions after going through a decision process that would be aided by agreed-upon general rules and decision aids, which are listed below:
- General Rules
- Follow customer-service policy
- Communicate
- Adjust inventory minimums first; cut orders as a last resort
- Empower the deployer
- Checklist of questions to ask before taking action
- Communication network
- Specific tools (e.g., deployment module, freight cost matrix)
The team also created a tracking/control process to ensure the ongoing high performance of the new centralized deployment process and to help continuous learning.
The new business process design resulted in some organizational realignment for the company as well as new roles for the deployer at the centralized location. The deployer is now in charge of, among other things, getting products to the right place at the right time to meet customer-service and cost targets, using the new computer module to deploy products and identify problems, handling exceptions, and monitoring key performance indicators.
The entire design exercise was accomplished over a period of two and one-half months, amounting to approximately 100 hours of team time.
| Author Information |
| Harvey Dershin is a former vice president of the Juran Institute. |
| Footnotes |
| 1 Juran, J.M., Juran on Quality by Design, Macmillan Inc., 1992. |
| 2 Quality Planning Ready Reference, Juran Institute, Fifth Printing, 1994. |
| 3 Juran spoke to this difficulty in transferring a design to operations decades ago. (See, for example, Juran on Quality Improvement, Video Tapes, 1981.) Michael Hammer also addressed the change process in his 1995 book The Reengineering Revolution. (See Hammer, Michael and Stanton, Steven A., The Reengineering Revolution, HarperCollins Publishers Inc., 1995.) |
| 4 Main, Jeremy. Quality Wars, The Free Press, 1993. |
| 5 Senge, Peter M. The Fifth Discipline, Doubleday, 1990. |
| 6 Dershin, H. "Nonlinear Systems Theory in Medical Care Management," The Physician Executive, May–June, 1999. |
| 7 Holland, J.H. Adaptation in Natural and Artificial Systems, Cambridge, Massachusetts: MIT Press, 1992. |
| 8 Holland. |
| 9 Holland. |
| 10 Holland. |
| 11 Gryna, Frank M. "Manufacturing Planning," Juran's Quality Control Handbook, Fourth Edition, McGraw Hill, 1988. |
| 12 Redman, Thomas C. Data Quality for the Information Age, Artech House, 1996. |
| 13 Hammer. |
| 14 Gryna, Frank M. Quality Improvement, Section 22, Juran's Quality Control Handbook, Fourth Edition, McGraw Hill, 1988. |
| 15 Hammer. |
|
View All Blogs
