Business Simulation
February 10th, 2008Business Simulation
Simulation
The Key to Designing and Justifying Business Reengineering Projects
One way to save money is not to spend as much of it. If you are a business owner or a project manager that is involved with organizational change management, there are some proven ways to reduce your risks of creating the wrong organizational design or the wrong business processes. One of these methods is called Business Process Reengineering or BPR.. One of the key activities in BPR is modeling and simulation.
If you are a consultant or a programmer, becoming a BPR facilitator can be a very lucrative career move right now as there is an increasing demand for people that can support the analysis and process improvement of businesses - collectively known as being a “change agent” for “organizational change management”.
Today’s global economy, enhanced and hastened by rapidly changing technologies of all types, is putting pressure on companies to increase the efficiencies of all their business processes. Likewise, budgetary constraints are putting similar pressures on government administrative processes. Many organizations around the world have turned to business process reengineering (BPR) as a methodology to achieve these efficiencies. A majority of BPR projects really do not do any “engineering” at all. That is, many BPR practitioners are not using proven quantitative analytical techniques to analyze and design business processes. This defeats the entire purpose of BPR and results in few BPR projects that actually implement new process designs based on a consideration of reliable performance metrics or reliable expected differences between competing alternatives. Instead, all too frequently, BPR projects tend to have decisions based on subjective notions of “what should work well.” This is wrong and often does not work. When it doesn’t work, BPR is blamed for the failure. In fact BPR dictates the “proper” method.
Stumbling Between Vision and Implementation
Intuitive notions about what would work well for a business process can provide excellent frameworks for creating the “vision” of the new process. Every BPR project should have a clear vision (see Barrett, “Information Systems Management”, Spring 1994). However, the vision has to be implemented successfully to realize the benefits. This is where many BPR projects stumble badly - not because implementation is so difficult, but because careful analysis of exactly what to implement has not been done. There are an infinite number of ways to “achieve the vision.” The problem is in selecting the “right design for the new process that, once implemented, can be expected to achieve the desired results with a high degree of confidence.
Unfortunately, most BPR analysts select a design based primarily on intuition or “best practices correlation” (e.g., ABC company implemented a similar process and they are a market leader) without thinking through, and certainly without carefully analyzing, the dozens of details and alternatives associated with implementation inside the subject organization. Some would argue that considering a number of alternatives and/or significant details takes too long and costs too much compared to the benefits received. On the contrary, we argue that considering such alternatives and details is not costly and does not take a long time. In addition, the benefits are enormous - especially when compared to the often hidden cost and risk of project failure.
Lack of Analysis Contributes to Lack of Executive Commitment
End-to end business processes (e.g., customer order fulfillment) are comprised of many (maybe dozens) activities and tasks, utilize a myriad of the organization’s scarce and costly resources, are managed (and non-managed) by a host of written (and unwritten) policies and form the basis for most corporate culture existing in the organization.
Aeronautical engineers prototype their airplanes. Why shouldn’t you prototype your business process planes?
When an aeronautical engineer prototypes an airplane, she must use calculus. She can take pictures of other airplanes and make drawings of her new airplane. She might even use algebra for answers to her design questions. Eventually she must prove to herself her design will produce an airplane that will actually fly. Why? Because top management will want to have a high degree of confidence her airplane will fly before committing time and money to go ahead with the project. Any aeronautical engineer will tell you she must use calculus to help her prove her airplane will actually fly. This is because calculus is the only proven tool telling her how all aspects of her airplane design will interact during simulated flying time. She has no choice if she wants detailed answers with a high degree of statistical confidence.
Exactly the same reasoning applies to a business engineer who wants a reliable business process plan. She must use simulation (actually, real-time discrete-event simulation, as we explain later). She can study designs of other business process planes, make static sketches of new ones with drawing or diagraming tools and personally visit similar business process planes of other organizations. She will also use algebra or spreadsheets to try and get answers to her design questions. She too must prove to herself her design will produce a business process plane that will actually fly. Why? Because top management needs to be confident her business process plan will fly before committing the organization’s time and money to build the business process plane and operate it with real customers.
Now anyone truly understanding simulation will tell you she should use real-time discrete-event simulation to help prove her business process plane will actually fly. That is because real-time discrete-event (RTDE) simulation is the only proven tool telling her how all business process design aspects will interact and behave during simulated operating time. She has no choice if she wants detailed answers with a high degree of statistical confidence, and neither do you.