AllenWeb Site - since 1995
Business Process Re-engineering - SAP R/3 - Jun 1998
| Automation |
Plan for Re-engineering
--------------------------------------------------------------------------------
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."
| Disclaimer: This is Paul Allen's personal business library. Articles and papers contained therein are for his use and reference. While this information is being made public by being published on the internet, any use of any material or guidance contained herein is at one's own risk. Neither the author Paul Allen nor Project Executive Group have any responsibility if anything is taken from this website and utilized. While we believe these articles and papers make a significant contribution to learning, beware that anyone who uses this information does so at their own risk. We make no representations to accuracy or completeness. |
| Return |
