AllenWeb
AllenWeb
Jun
98
We seem to have run out of words in the English language. Each new buzz word that appears is current for about a year before taking on ever broader meanings, until it is all things to all people. At that point, there is no word to describe the original concept. Reengineering falls into this category. A receptionist recently reported that "they" had reengineered the front lobby where she works. She now has new furniture, drapes, and artwork. This example takes the meaning of the word to new depths, but illustrates the way common usage overuses new words until they become meaningless. For this reason, we will start by defining our terms.
What Is Reengineering?
The term reengineering originally described significant changes to basic business processes that yield 50-100 percent rates of improvement. That is, it creates step function changes in such major corporate metrics as sales per employee, cost to produce goods, cost to administer the company, cycle times, inventory turns, and the like.
A business process is the group of activities required to produce something for a customer. The product development process, for example, may be thought of as starting with an idea and ultimately producing a working model to meet a customer need. Manufacturing is the process of taking raw materials and combining them to produce a product which is then shipped to the customer. In order management, a company takes in a customer order and ultimately receives money for the delivered product. When looked at from this perspective, any company, no matter how large, will be comprised of approximately eight to twelve core business processes. Each process is subdivided into smaller and smaller processes ‡ la Frederick Taylor, the king of task decomposition. Due to the complex nature and interdependency of these processes, companies often define a portion of a process as their target for reengineering, simply because taking on the whole is an immensely difficult undertaking.
A few years ago, a computer manufacturing company decided to reengineer its customer liaison function. This process was carried out by a group of individuals located in the manufacturing facility, with the object of ensuring that orders were correctly configured and shipped to customers. While the redesign project team developed some useful recommendations to enhance the effectiveness of the process, it became clear it was such a small cog in a large wheel that effective change had to occur several levels above. At one point, the consultant asked the team how it could be more effective if it were located outside of the facility. The team immediately assigned, in theory, the bulk of its duties to others either in manufacturing or in the product line administration group. One man, realizing what he had just said, spoke for the group, "Oh look, I've just given away my whole job!" In fact, he had suggested the elimination of his organization and a reassignment of the essential duties to accomplish the function. This realization, of course, stopped the group cold. In this case, the team attempted to appeal to management to raise the scope of the project, but to no avail. When properly scaled, attention to a business process can pay rich rewards; however, the company has to be aware of the implications prior to defining a project. When the scale of the effort is too small, little can be accomplished beyond incremental improvements.
Business process activities are generally accomplished in a sequential manner. An extremely useful exercise in understanding a process is to follow its paper trail, even if segments of the process are no longer actually paper-based. At IBM Credit, senior management did this by asking the first person in the process to describe how an application for financing was processed. They proceeded from desk to desk, and observed each person performing his or her job regarding the financing request. This process is what Symmetrix, a management consulting and reengineering firm, calls chasing the rabbit. Symmetrix uses this phrase because the paper often goes down unexpected holes.
The Many Faces of Reengineering
The term reengineering was originally applied to such sweeping changes as a new sales and delivery mechanism that increased sales by 60 percent, reducing the cycle time to process an order from 10 days to 10 minutes; or a new manufacturing facility that delivered 10 percent more products in 25 percent of the space using 50 percent of traditional employees. Hammer and Champy in Reengineering the Corporation describe it as fundamental, radical, dramatic business process change. Davenport used the term innovation in Process Innovation to distinguish it from incremental improvements.
Symmetrix, one of the pioneers in business process redesign, believes strongly in reinventing only the critical business process. To make this 80/20 cut, it focuses on a deep understanding of the economic implications of the proposed changes. By so doing, it concentrates its efforts on the changes that will substantially improve the business.
The word reengineering today often implies changes from the most mundane to the most significant. The term most commonly used is BPR " \t " "(business process redesign).
Not all companies wish to make massive changes to their business processes. The changes companies require are on a continuum from streamlining to reinvention (Figure 5-1). Streamlining a business process implies making incremental changes to the current process to increase quality, decrease cycle time, or reduce cost. Reinventing a business process means scrapping the current one and creating a process that truly meets the needs of the company. This usually requires a fresh look at the purpose of the business and the core competencies needed to serve that purpose.
Change continuum-- streamline to reinvent
Projects are often identified at points along this continuum. While some companies engage in massive full-scale reengineering, many are content to solve major business problems that plague them today while setting the stage for future efforts. Thus many reengineering efforts, especially those that are combined with the implementation of R/3, are grouped somewhere in the middle of the streamline-to-reinvent continuum. As such, the effort may be a combination of solving old problems and creative redesign of selected processes.
Many companies identify changes that are meant to streamline their business processes and find that to implement change successfully, the project team will need to reinvent the corporate approach, and that change will have major implications for individuals, jobs, and structures. One organization made up of several divisions decided to centralize its accounts payable. On the face of it, management reasoned, centralization was not a change in the way the process operated, only a change in location. When the business owners considered the change, they realized its value, but identified numerous changes they would have to make in their operations to extract accounts payable. The organizational impact of the change pushed it in the direction of reinvention on this continuum.
R/3 is well suited to efforts anywhere on this continuum, although a company should develop a high-level design prior to the implementation of any project at the far right (reinvent) of this line.
There is another dimension worth noting--the scale of the change effort involved (see Figure 5-2). Projects at any point on the streamline-to-reinvent continuum can involve small to large portions of the business. The more departments and people involved in the change, the greater the scale and therefore complexity of the effort.
Scale continuum-- small to large
A company can decide to start a BPR project with a small element of the business for any number of good reasons such as:
•The project may be a pilot to test the changes prior to involving the entire corporation.
•The purpose may be to test a hardware or software product, or to gain the skills needed in the long term.
Though small, a project can have high leverage. SAIC (Scientific Applications International Corp.), a corporation made up of a number of companies, began its R/3 implementation in its commercial sector, using this as a pilot case for the rest of the company. It implemented financial accounting, a project system (basic data, planning, and forecasting), controlling, materials management, and human resources for a group of 100 users. Lessons that were learned were passed on to the next project, which had an enterprisewide scope.
Projects that include major sections of the company will be undertaken by those who feel they are ready for a larger scale project, or who feel the larger scale is essential.
We can align these two dimensions in a matrix (Figure 5-3) that will give us a sense of the size--and thus difficulty--of the undertaking. The indications of possible projects within each quadrant are examples to illustrate the concepts.
Scale/magnitude matrix
In the lower left quadrant, a company may decide to automate the cash application process, increasing the speed and quality of this relatively minor process. In the upper left quadrant, a company may implement a process to standardize the human resource services. In this example, the change will streamline the collection and delivery of information to employees across the entire corporation.
Moving to the lower right quadrant, a company may decide that its highest-leverage move is to completely reinvent the lead management process, a minor segment of the business.
And finally, the effort with the greatest amount of change across the largest portion of the company may be to implement a new business model across all the strategic business units, which might entail changing the order management, the sales and distribution, and the supporting financial processes.
Identifying the correct quadrant helps the project team and the executive sponsor choose the appropriate project process and appreciate the amount of change required. This knowledge will positively influence their success rate. This is a critical point that will be emphasized throughout this book. The larger the scale and the closer to reinvent the project is, the more attention must be paid to the critical success factors and the change management issues. Nothing will cause a project to fail more spectacularly than less-than-full attention to these matters.
Reengineering Process
How does one go about reengineering a business? The process will depend upon your goals.
If you wish to streamline a process, you will engage in detailed analysis of the current approach, seeking to understand, for example, the gaps in time between each value-added action. An order may enter the company and go to one department to be checked for availability; to another group to check that all the pieces of equipment being ordered actually work together; to sales, in the case of a custom order, to apply the correct price and relevant discounts; over to the accounts receivable department for a credit check; back to the order desk to identify the funding source; and so forth. Many companies have discovered numerous handoffs in their process and inevitably the customer order, in this case, waits for the next person to be ready to add their value to the paper. Eliminating those gaps when no value is added, by grouping activities together or by automating some or all of the process, will shorten the overall process time and usually lower the cost.
At the other end of the continuum, to reinvent a process you may spend some time to understand the nature of the current process, but you will quickly move to look at the business problem. It is useful to start, in the case of a sales order, with the end of the cycle--a satisfied customer. Understanding what the customer wants and needs from you will begin the process of looking at how your company processes orders. In this case, you may discover the customer is very familiar with your product line and can be equipped with the ability to send in orders electronically. The entire process may be automated with a few individuals available to solve problems, should they occur. The system should detect these exceptions early rather than waiting until the customer takes receipt of the product.
The process for reengineering consists of four basic steps: choose a process, understand it to the extent needed, redesign it, and implement the change.
Nothing about this simply stated process is easy. The entire process must be identified by executive management as essential to the company's success or survival; else why do it at all? Each step will take considerable deliberation, and will be broken into several components. Along the way, the ultimate recipients of the changes must be kept involved and informed. The process requires a combination of attention to detail, and creative out-of-the-box thinking, which is scarce.
For more information about the details, there are numerous books written about this process. All major and most smaller consulting firms have their own approaches and methodologies. A cursory examination will show most of their approaches to be well thought-out. The challenge inevitably comes in managing the process of change.
The Case of Hill's Pet Nutrition
Hill's Pet Nutrition is currently in the process of implementing nearly the entire suite of R/3 modules. Hill's develops, manufactures, and distributes nutritional products for companion animals. The company has been in the forefront of progressive change for many years. Their story is illustrative of the approach taken by many. It falls roughly in the middle of the scale/magnitude matrix shown in Figure 5-3.
In early 1994, Hill's convened a task force charged with identifying the information system needed for future growth. The executive team realized that the company's recent substantial growth meant it had outgrown the infrastructure that had supported it in the past. In particular, it was hampered by a lack of useful and up-to-date information. The company had originally used a mix of third-party and direct sales and delivery mechanisms. The requirements of the business shifted, and today Hill's deals more directly with its customers--veterinarians, pet store owners, and large scale retail outlets. The development of the products is, of course, focused on the pets and their owners; however, the distribution channel is through experts in pet care who recommend the product.
Because Hill's systems had been built to support the earlier structure, it realized its information system was a barrier to future growth. The company found it difficult to evaluate the effectiveness of marketing campaigns; the financials had to be pieced together; and its reporting systems didn't easily line up with its parent company.
The company has multiple manufacturing and distribution facilities. In the past, each functional area had been encouraged to utilize the systems that best supported its various needs--a best of breed approach. The multiple systems, however, were inefficient in their ability to talk to one another, and the company could not wait for that problem to be fixed by the various vendors. Instances of employees taking information from one system and hand keying it into another were discovered.
Hill's chose SAP for the robust, integrated nature of the system. Early on, the project team developed a mission statement and a set of guiding principles. It also identified four key enablers. This early focus proved to be extremely useful during the course of the project. The project team divided into several functionally based subteams to assess the current environment. These teams evaluated the processes in place and generated ideas that would provide significant improvements in the bottom line. They were rigorous in reporting back to the business areas that would be affected (most of the company). For example, they developed a communication grid to identify key business individuals and groups, along with team members responsible for sharing information and progress reports. They tracked who was to keep whom updated and when was the latest contact. (This tool helps the team to organize its one-on-one communications.)
With the results of the assessment and external information regarding best practices in hand, the team entered the design phase. It divided this process into two parts: first, divergent thinking, wherein it collected as many ideas as possible; and second, convergent thinking, wherein it collected the ideas that survived scrutiny and organized them into possible process tracks for the company. The teams developed event-driven flowcharts of the major business flows, and again they returned to the business owners for feedback. Using SAP experts, they mapped their ideas to R/3 to ensure there was a match and began to construct the pictures (literally covering the walls) of how the new business processes would look.
When asked if he would consider this true reengineering in the radical, dramatic sense of the word, Steve Whitney, Hill's Pet Nutrition's director of change management answered, "It's a matter of perspective. We're probably in the middle ground, but many of the changes seem radical to some of the business owners."
The Role of Information Technology in Reengineering
In the past several years, information technology has been recognized as a major force in reengineering. It is typically identified as an enabler of the changes required. That is, reengineers develop a conceptual approach to changing the business processes expecting that IT will make it possible. For example, reengineering the sales order process means providing a wide range of product, scheduling, customer, and financial information online to the order entry people. This is not possible without an integrated networked information system.
R/3 has changed the nature of the reengineering process in two ways: First, it provides a system that is integrated and based on best practices. It makes available, as a matter of course, many of the improvements that companies identify in the process of reengineering. In this respect, it serves as the technology enabler identified by most reengineers and writers on the subject.
Second, and more importantly, R/3 is a driver, not merely an enabler of substantive change. R/3 forces the implementation team to specify how it wants to organize and run the business in an integrated way at a detailed level. Many companies have not done this and continue to operate with mixed, and often conflicting organizational structures, processes, and standards. This lack of clarity and integration is often based on history or on culture. The successful implementation of R/3 requires you to define these elements.
R/3 will not actually conduct the reengineering for you, but will trigger you to do it for yourself. With this force in hand, even companies who simply wanted to replace their 20-year-old legacy systems that cannot communicate with one another, will do some level of reengineering because of the structure of R/3 itself, and probably more than they imagined was needed.
With the advent of R/3, information systems have, more than ever, become a major force in creating efficient and effective business processes. This change in status, from support function to key driver of change, carries with it several significant implications:
•You must decide when to reengineer your business. IS and user roles change-- dramatically. •The IS implementation process changes-- dramatically. •Implementation skill becomes a new, distinct competency.
When to Reengineer--Before, during, or after R/3?
When companies have chosen R/3, the question arises, "When should I do reengineering?" The approach you take will, of course, depend upon your business situation and thus your motivation for choosing R/3. To provide some structure for answering this question, let us return to the scale/magnitude matrix and add to it an indication within each quadrant of the type of approach that is most successful. (See Figure 5-4.)
Scale/magnitude matrix, with indication of reengineering timeline
In the lower left quadrant, the project team can successfully undertake reengineering during their implementation. The system will require identification of the structure, procedures, relationships, and standards, and will provide the latest in best practices for the modules selected.
In the upper left quadrant, the project team should engage in a BPR process to identify the problems and issues caused by their current processes (streamlining). It should define a high-level design for those changes, but move onto the system as quickly as possible to identify the details of the changes. Thus it will do reengineering both before and during the R/3 implementation.
In the lower right quadrant, the project team is tasked with reinventing one of its business processes. It should begin by designing in some detail the changes the company wishes to implement. As Hill's Pet Nutrition did, team members should assure themselves they have not strayed too far from what R/3 will provide; however, the focus of the effort will be to change completely the process in question.
Many customers report that having followed this approach, they were pleasantly surprised at how much of what they needed was supplied by R/3. In some cases, the system did not provide some functionality, and they were faced with the decision as to whether to eliminate it from their design or to provide a systems work-around that they would have to maintain in the future. The outcomes of these decisions depended upon the criticality of the missing feature. Many companies have accepted a somewhat less-than-perfect solution to save themselves the time and expense a "fix" would entail. A senior partner at CSC stated, "Yes, you will modify the business to fit the system." He goes on to say that this is usually only in minor cases, and the alternatives are generally not worth the trouble.
The upper right quadrant identifies efforts that are focused on reinventing significant portions of the business. These change projects will take significant time and effort, and are usually accomplished with the help of a consulting firm having expertise and experience in managing major changes. A successful effort here will focus on the dramatic, radical changes that are essential to long-term survival and growth. Major reengineering projects should be undertaken prior to implementing R/3. As in the lower right quadrant, some relatively minor decisions may be impacted when R/3 is implemented.
This matrix provides some indication of what type of process redesign to attempt under various circumstances. In any case, it will be counterproductive to delve too far into the details of the new business environment without understanding something about R/3. Several project teams reported they had to back up, in one case losing three months of work, because they had defined the new environment too tightly, and the work had to be redone when the R/3 implementation started.
What about reengineering after the implementation? Some companies assume they will implement R/3 without going to the trouble of a BPR project and address any needed changes after the fact. In cases where the corporate structure and processes fit well with R/3, this approach is possible, though not recommended. In cases where R/3 requires greater or different structure than the company possesses, the project teams will find themselves making decisions that will affect the company for years to come. Thus they may reengineer their company without the benefit of a structured process for doing so. We strongly advise against this approach, although one potentially successful example will be presented in Chapter 15.
NEC Technologies has implemented R/3 and is beginning a reengineering effort based upon the assumption that the system will provide the capacity to change whatever might need to be changed. It is too soon to tell whether this approach will provide the freedom to consider radical corporate changes.
Companies that have implemented R/3 in several different projects may find their staff has become very experienced with certain modules. There is so much richness inherent in R/3 that it takes considerable experience to even begin to understand what it will do. A representative of one manufacturing company stated that they were starting to use the system to suggest improvements they might make in the future. This approach is a creative use of reengineering after implementation.
IS and User Role Changes
It is useful to note here that the change in status of IS that results from R/3 will mandate a change in the skills and attitudes of IS individuals. IS will become increasingly considered by line management as belonging to the business.
The difference in the words and concepts used by business people and IS has already changed dramatically with the introduction of R/3. Business people talk offhandedly about line speeds, data feeds, response times and good or bad GUIs. R/3 project teams are typically made up of more business people than IS people. A business person is the best choice to carry out the detailed customization, to make entries in the tables, and to define how the system should collect and report the data.
Correspondingly, IS people, more than ever, speak of the business process flow, and creatively introduce ideas to reduce costs or improve cycle times. The IS department is responsible for ensuring that the technical architecture is appropriate to the business needs and that it can expand as those needs grow. It must track interfaces, revisions, and system performance. The IS department will provide the individuals who will write the ABAPs. These are the customized reports and interfaces between R/3 and other systems, and must be written in ABAP, SAP's proprietary language.
IS Implementation Process
In the old days (five years ago or so), system users applied to their IS department when they wanted a new system or a fix to an old one. The business analysts and programmers assigned would confer with the business owners as to their requirements. They then began a long, involved process of analysis, design, coding, testing, and, finally, implementation. Assuming the business needs stayed the same during this process, the system was developed with little involvement by users. Usually those needs changed, delaying implementation and causing universal frustration. Eventually, the system would be unveiled, to cries of delight, amazement, or possibly consternation.
This process has generated an increasing level of frustration by business managers and executives who generally know little about the technical issues and who only want the pain to stop.
Enter SAP stage left.
R/3 demands a new process, one that takes far more resources from the user community than ever before. It is typically user driven, is based on reengineering approaches, and will usually drive greater change than any system developed the traditional way. It also costs a great deal and may be delayed if insufficient attention is paid to the political and organizational shifts occasioned by the magnitude of change. The ability to successfully implement R/3 becomes a critical skill. The traditional IS systems implementation process must be augmented to reflect the broader focus and skill set demanded by an enterprisewide integrated information system such as R/3.
Implementation Skill Becomes a New, Distinct Competency
If everyone were to implement R/3, where would there be an IS competitive advantage? Companies have astonishingly varying degrees of success with implementation. The difference is in their abilities to address each of the critical success factors.
A company's ability to select a project it can support and manage, to appoint the right people to the various positions, and to walk the line between energizing people and calming their fears is no small task. More than ever, the ability to manage change must become the job of everyone involved, not just that of a consultant or the project leader.
Thus, successfully and skillfully managing change is the distinctive competency that emerges from the integration of reengineering and information technology. This skill has been required in the past, but has been ignored or given lip service. It is needed even more today and is still given less attention than required. Companies that recognize this factor will be more successful than those that do not. The issue is not the technology. Technology, as ever, is neutral. The issue is the ability to make creative use of that technology and to manage the massive change the system produces. Managing the change process with the same degree of discipline and rigor as the technology will begin to happen more regularly when organizations see this as a core competency and start to manage it as a competitive advantage.
Reengineering is Organizational Change
Reengineering (and implementing R/3 is a form of reengineering) must be seen as a mechanism for organizational change. Teams that approach the implementation of R/3 with this mind-set are more successful than those that do not. With R/3 implementation comes the need to help employees cope with massive changes in their jobs, their organizational positioning, their decision-making processes, even their pay.
This is true at all levels of the company. It includes the order entry clerk who is now asked to make decisions that commit the company to a course of action, and the operations manager who discovers that his or her empire has grown or shrunk by 50 percent, and that he or she is required to manage in a vastly different way.
Pay attention to helping people see the potential in the redesign for themselves and for their company. Again, it is the "people" in projects that make the difference between success and failure.
- END - See "Building Effective Processes" and "The Global Marketplace and the remaining weakness in the ERP systems today - international trade logistics IS the missing link."