General background on the technologies, applications, and business implications of EC Detailed, specific information in the form of answers to common questions Discussion of EC within particular industrial sectors EC resources organized by relevance to parts of the implementation lifecycle Search this and other sites chosen for their relevance to EC in manufacturing Ask advice of experts at the Center for Electronic Commerce Definitions for common EC terms



Managing Change in a Socio-technical Environment



Contents

Sections

Tools

Introduction
Implementing Electronic Commerce is almost always an exercise in the concurrent engineering of organizational and technical change. To assure that the organizational component is handled well, we present this Guide. Our intention is that by reading it you will:
  • Know how to derive fast, useful results from a minor investment in using a systematic change process
  • Be able to design and manage simple change efforts
  • Understand how complex a change process is needed to fit your particular situation
  • Find other resources when your situation requires more expertise than can be derived from this chapter.

A great deal of benefit can be derived from a small investment in systematic change management. The key is to understand how rigorous a change process is required.

To understand this principle, consider the example of Acme Auto Parts, a company of 300 employees and sales of $21M, mostly, but not exclusively, to the automotive industry. Acme feels a strong need to lower its cost of doing business and improve its response time to its customers. Acme's plan for achieving these goals is to re-engineer its business processes. To do so, it is willing, as necessary, to change its internal structure, hire talent or train its present employees, and bring in technology to support Electronic Commerce. This is a familiar situation. Now, consider two different contexts in which Acme might be operating.

Scenario #1

  • The technology base is antiquated. Networking is minimal. Some important functions (e.g., order entry) are not automated. Aside from a System/36 for accounting, all other computers are low-power stand-alone desktop computers running DOS.
  • There is a history of distrust and turf wars among critical departments—Accounting, Information Systems, Materials Management.
  • Personnel are worried that automation and change may cost them their jobs. This fear is reinforced by recent reductions in the work force.

Scenario #2

  • Acme is well on the way to completing a long-term plan to update its information technology. A Local Area Network is in place. Although major applications are not yet integrated, they have recently been redesigned for integration. About half of Acme's desktop computers are running Windows and are connected to the LAN. Employees are getting used to communicating with each other via electronic mail.
  • While some turf wars are inevitable, major departments have a history of working with each other and achieving success on joint projects. Materials Handling, Accounting and Information Systems have cooperated in putting in a bar code system; all were pleased with the results of the cooperation.
  • Employees have a sense that if Acme can adapt to changing business conditions, the company is in an excellent position to capture new markets and increase sales. Automation is seen as a way to assure work for all. Although few people are understandably worried about their jobs, this fear is not endemic.
  • Because of the recent technology upgrades and experience with developing new systems, employees have a reasonably sophisticated understanding of what is needed to shop for technology and bring about change. While some outside consulting will be necessary, the amount needed is minimal, and employees are confident they can apply whatever advice they get from the outside.
Under scenario #1 Acme is in a double bind. On one hand, error in change management is both likely and costly. At the same time, managing change is particularly difficult. In a situation like this, careful and detailed change management is necessary.

Scenario #2 represents the other end of the spectrum. The changes required have less impact, and Acme's fundamental ability to manage change is greater. Here, general attention to basic principles of change management may be all that is required. Of course, many other possibilities exist, but the general lessons are clear. Investment in careful change management is always desirable, but the extent of that investment depends on such factors as:

  • Constraints and uncertainties in the business environment
  • Internal difficulties in the areas of technology, organization, and people
  • The cost of failure
Assuming that moderate levels of change management will suffice, attention to basics will allow companies to manage their own change processes. These basics are discussed below, along with a brief explanation of how they operate, and indicators as to when their application may require outside help.

Top

Approaching Change With the Proper Mind Set
Successful change begins with a set of beliefs that must be recognized by everyone in a company.

Top

Principles of Change Management
Many discussions of change management and Business Process Re-engineering (BPR) tend to be complex and abstract. In some ways this is appropriate because change does involve many factors that interact in ways that are subtle, complex, and profound. Further, it is difficult to plunge into practicalities without an overall conceptual sense of why things should be done in particular ways and how pieces fit together. On the other hand, much change management is very practical and can be done successfully with careful attention to a few principles. This chapter will help provide you with an instrumental understanding of those basic principles.

Know Your Business Objectives
Acme is in trouble, and it knows why. The innovative products it used to sell are evolving into commodities, putting the squeeze on market share and price. Acme also knows the possible ways out of this difficulty. It could:

One, or any combination, of these tactics may be reasonable. What is important is that Acme's choices will affect the kinds of changes it must make within itself, and with its trading partners. Unless Acme knows what it wants to do, the company may make inappropriate choices about change. To take an obvious example, new product development calls for an infrastructure to support innovation, complete with design skills, CAD systems, good market research, financing, and a management mind set that encourages creativity and risk. If all involved do not understand that greater innovation is the primary objective, Acme may find itself with higher costs, lower efficiency, static profits, and no ability to develop new products.

How much help does a company need in determining its business objectives? While there is no precise answer to this question, we recommend that management apply the items in Table 1. Higher scores imply a greater need for external assistance or systematic analysis and planning.

1 = Irrelevant for our making choices about business objectives.
2 = Some relevance for our making choices about business objectives.
3 = Important for our making choices about business objectives.
4 = Major factor in our making choices about business objectives.
(All tables in this section are filled in. These ratings will be used at the end to work out a specific example.)

Table 1: ASSESSING ABILITY TO DETERMINE BUSINESS OBJECTIVES

 

Situation

Irrelevant

(1)

Some Relevance

(2)

Important

(3)

Major

Factor

(4)

Considerable effort will be needed to achieve a strong consensus among management about new business goals.

     

X

It is hard to obtain validating information (e.g., market research, knowledge of economic trends) to test ideas for new business directions.

X

     

It is desirable to pursue multiple new business objectives simultaneously. (There is great uncertainty in the business environment, any single objective is not sufficient, etc.)

 

X

   

The nature of our choices is such that we cannot pursue several at the same time. Hard choices must be made.

X

     

There is great disparity in the cost/benefit ratios (or absolute costs and benefits) of the various new business objectives that we could consider.

 

X

   

We are not sure we know all the options available to us.

X

     

We are uncertain about the business trends that will affect our business.

 

X

   

Question Assumptions
All organizations are guided by assumptions that are so well accepted that they fade into the background of peoples' consciousness. To illustrate, consider some of the assumptions that are guiding the document you are now reading.

These assumptions may be true, false, or, most likely, true to a degree. The important point is: if NIST/MEP wishes to have an impact, it must question these assumptions and take appropriate action. For instance it may turn out that without rich interaction among experts and users, sites like this have only minimal utility. If so, plans for interactivity must be accelerated.

Similar logic applies to a company that wishes to improve its competitive position. What are its assumptions? Let's go back to Acme and look at some of the assumptions that may affect its ability to change.

  • Most of our business will remain in automotive no matter how hard we try to open up new markets.
  • Staff are competent.
  • If we tried hard enough, costs could be lowered an appreciable amount.
Consider what would happen to Acme's analysis of new business objectives if it did not first question the assumption about business in the automotive sector. Acme might downplay that objective because it failed to consider the extent to which it really could expand. Similarly with the assumption about costs. A decision to compete in the "commodity market" might be predicated on the assumption that costs could come down enough to provide a significant competitive edge. But maybe Acme's costs are already extremely low compared to industry standards, and the company is in a situation where order of magnitude improvements are not practical.

As a practical approach to finding assumptions, we recommend the following steps.

  • Form small teams representing each functional group within the company.
  • Members of each team engage in two exercises.
    • First, brainstorm the assumptions that drive their own group.
    • Second, act as "outside observers" to the other groups and brainstorm their assumptions.
  • Meet as a group and compare notes.
  • As practice is gained in looking at the assumptions underlying specific groups, begin to apply those skills to assessing the company as a whole.
  • As assumptions are discovered, log them and refer to the list as business objectives or change strategies are developed.
As a way to structure this exercise, it may help to direct attention to assumptions in several distinct categories. In each case these should be examined relative to the group in question, whether it is a specific department or the company as a whole.
  • Mission/fundamental goals
  • Impact on the outside environment
  • Strong and weak characteristics of the group
  • Beliefs about technology, how the group works, and its human resources
Performing this analysis without any outside help at all can be difficult. To paraphrase Robert Burns, few of us have the gift to see ourselves as others see us. The critical indicator is whether the process works for you without special help. Begin with two assumptions.
  1. All organizations have implicit assumptions.
  2. These assumptions can be discovered.
If, as you work through the process, either of these assumptions seem to fail, it's time for an outside facilitator.

Use Teams to Guide Change There is so much talk at seminars, the trade press and popular media about the importance of teams that a belief in their value has almost become cliche. Powerful teams, however, really are important in guiding a change process, and it is important to always remember why this is so.

Constructive change requires cross-functional, hence, collective decision making. Three examples illustrate this point.
  1. Designers make choices which affect manufacturability, price, and product appeal.
  2. Pricing decisions by Sales and Marketing affect a company's ratio of market share to profitability.
  3. Technology acquisition managers make decisions that profoundly affect the work load of installation and maintenance personnel.
  4. The problem is that unless done well, the value of working in groups can range from difficult to catastrophic. Two metaphors describe the situation. If done well, group activity is akin to the coherent beam of a laser. If done poorly, it is more like herding cats. Fortunately, the rules for successful group management are fairly simple.
    • Make sure the right people are involved in the team. Relative to the task at hand, make sure participants are cross-functional, cross-level, and representative of all relevant stakeholders.
    • Teams must be given a clear mission, and the boundaries of their activities carefully defined. Without such clear definitions, coordination among teams becomes extremely difficult.
    • Teams must be empowered. Within the boundaries of their mission, they should be left alone to act as they see fit.
    • Keep team membership to a workable number. If "having all the right people involved" requires more than ten people, there is probably a need to establish sub-groups.
    • People's roles in the group must be clear and well defined. We have found it useful to assign one of four roles to each individual.
      1. Authority -- Implies that the person has the decision making power and legitimacy needed to commit to action.
      2. Responsibility -- Conveys major responsibility for the conduct of an activity. Whether personally or through delegation, those with responsibility must make sure a job gets done.
      3. Support -- Provides important support for an activity. This support might be in the form of providing information, resources, or performing specific delegated tasks.
      4. Inform -- People who must be informed about the progress of an activity, even though they are not taking actions directly affecting outcome of the activity.
    As with the importance of clear group boundaries and missions, the value of this topology for decision making serves to reduce ambiguity in the process, paving the way for effective communication and coordination.
    • Set up rules which:
      • Remove the possibility of inappropriate vetoes by individual group members
      • Assure all group members a legitimate role in decision making
      • Guarantee that once a group arrives at a decision, all group members will support that decision
    In order to make this happen, there must be guidelines for how discussions are carried out and how decisions are made.

    Discussion: We recommend that groups balance two modes of discussion, both of which are legitimate and necessary for good decision making. In one mode there are "arguments" in which people with strongly held opinions attempt to convince others of the correctness of their views. Argument is important because good decisions depend on rigorous comparisons of the advantages and disadvantages of different points of view. The second mode sets confrontation and argument aside. In this mode group members commit themselves to truly listening to each other, and to trying to understand why particular views are held. So doing will promote understanding that lead to consensus. More important, this non-confrontational mode surfaces assumptions and beliefs that provide important insight as to the correct course of action.

    Decision rules: It is unlikely that when important issues and strongly held views are involved, any group will reach a state in which all group members completely agree with a single course of action. What is needed is a method to assure concerted action without 100% agreement. The solution is an operational rule for groups that recognizes the difference between "comfort" and "buy-in." One useful rule is that if a group member is 70% comfortable with a decision, he or she will agree to 100% "buy-in," i.e., support for the decision. If groups are to be effective, the "100% buy-in" criterion is critical. Experience shows the "70%" comfort criterion to be useful, but the exact number (as if such a concept can actually be quantified) can be determined locally. In determining a comfort level criterion, however, keep the trade-offs in mind. Higher levels make for longer decision times and more arguments. Lower values lead to dissatisfied group members.

    • Assume that groups are temporary, and always be ready to reconstitute them in light of changing circumstances. Because your company's environment is dynamic, so too must be the group structure you establish for decision making.
    Can you do all this by yourself, or do you need outside consultants? Rating the items in Table 2 will help in making this decision. Again, the higher the score, the greater the likelihood that outside assistance will be useful.

    1 = This statement does not describe our situation.
    2 = This statement has some relevance to our situation.
    3 = This statement is highly descriptive of our situation.

    Table 2: ASSESSING ABILITY TO USE TEAMS

     

    Situation

    Not Descriptive

    (1)

    Some Relevance

    (2)

    Highly Descriptive

    (3)

    It will be difficult for us to agree on a common set of rules for group process.

     

    X

     

    We have a history of failure in efforts at group decision making.

       

    X

    We are characterized by "turf wars" and many groups who negotiate on the basis of hidden agendas.

       

    X

    Collectively, our employees have minimal experience working with each other in groups.

     

    X

     

    We have little in-house expertise in leading groups.

     

    X

     

    Key people will have difficulty accepting roles below the "power" level of "authority" or "responsibility."

       

    X

    We tend to have difficulty in partitioning complex problems into separate components.

    X

       

    There is little successful history with cross-functional or cross-level problem solving.

     

    X

     

    It is unlikely that management (or the work force in general) will accept the idea of empowered groups.

       

    X

    Tools of Change
    Change managers can choose from seven tools. Their challenge is to apply those tools in appropriate and powerful combinations. We review those seven tools below.

    Leadership in support of a common vision—Because successful change requires a common view of goals, it is critical for participants in a change process to share a common vision. It is one thing to agree on such a vision at some particular point in time. It is quite something else to establish an atmosphere in which a common vision affects what people do on a day-to-day basis. Without "practicing the vision," agreement on the vision will quickly become an interesting group exercise that fades as an ongoing determinant of decision making and behavior. Consequently, leaders at all levels and all parts of your company must visibly demonstrate their commitment to a common vision.

    Leadership in support of organizational culture—We view "organizational culture" as a set of collective (and usually unspoken) norms and beliefs that affect daily activity within an organization. Culture is a critical concept because it is impossible for formal procedures, or even informal but overtly negotiated rules, to cover all activities that make up organizational life. Although extremely powerful, culture is subtle. While one can make and enforce rules about vacation policy or promotions, one cannot simply decree a new policy about "respect for others" or "trust among departments" or "the importance of quality." As with a common vision, leadership, i.e., a commitment to showing by example, is a critical element in promoting any cultural changes that are needed to align a company with a new set of objectives.

    Formal and informal reward systems—Both or these are powerful determinants of behavior, and as such must be carefully constructed to support desired outcomes. As examples, consider:

    • Are raises tied to performance at the level of the individual, group, department, or company?
    • Do rewards for "product quality" take precedence over rewards for "on time delivery"?
    • Are rewards tied to what the company cares about? If so, is that connection clear in people's minds?
    Authority—Whether as individuals or groups, organizations have "centers of authority" that can make things happen. As examples: meetings can be called, tasks can be assigned, purchase orders can be approved, and new departments can be established. Think of "authority" as the distribution of this decision making-ability across an organization. Successful change management requires looking at the total authority system within the organization, and applying that authority in support of common objectives.

    Human resource management—Moving an organization (or a part of it) from one state to another may require new talent. As an example, a greater reliance on Electronic Commerce may require a new EDI expert in an Information Systems department, and also a greater understanding of electronic commerce in departments such as Sales, Accounting, Manufacturing, and Materials Management. As with "authority," companies undergoing change must consider the distribution of talent across their organization, analyze how that talent must change, and then use hiring or training to close the gap.

    Information infrastructure—Coordinated change requires shared information. As an example, the implementation of a "Just-In-Time" system requires shared information among Information Systems, Materials Management, and Manufacturing. Thus, one "tool for change" is analysis of what information is needed, and taking the steps to assure that valid information is available to all concerned parties.

    Information technology infrastructure—Much change cannot take place without supporting technology. One obvious example is the case of a company that wants better communication among departments, but has no Local Area Network, no shared data bases, and few desk top computers. Critical to thinking about technology infrastructure is an appreciation of the need to combine the virtues of two quite different views of technology.

    One view holds that business objectives are determined first, and technology is then deployed to help meet those objectives. The advantages here are the avoidance of "technolust" and maintaining a focus on business.

    The second view holds that the potential of technology should help determine business objectives. The advantage here is that desirable possibilities may come to be seen as viable. As an example, a company may wish to provide additional design services for its customers, but may not be able to do so because of a lack of sophistication in the use of CAD and CAD data exchange.

    In order to determine your present in-house ability to use these tools constructively, we recommend filling out Table 3. Again, higher scores imply a greater need for outside assistance.

    1 = This statement does not describe our situation.
    2 = This statement has some relevance to our situation.
    3 = This statement is highly descriptive of our situation.

    Table 3: ABILITY TO USE LEVERS OF CHANGE

     

    Situation

    Not Descriptive

    (1)

    Some Relevance

    (2)

    Highly Descriptive

    (3)

    LEADERSHIP IN SUPPORT OF A COMMON VISION:

    We have no experience in deploying this tool.

       

    X

    We have a history of failure in deploying this tool.

     

    X

     

    We have minimal existing talent deploying this tool.

     

    X

     

    LEADERSHIP IN SUPPORT OF ORGANIZATIONAL CULTURE

    We have no experience in deploying this tool.

       

    X

    We have a history of failure in deploying this tool.

    X

       

    We have minimal existing talent deploying this tool.

       

    X

     

    REWARD SYSTEMS

    We have no experience in deploying this tool.

     

    X

     

    We have a history of failure in deploying this tool.

    X

       

    We have minimal existing talent deploying this tool.

       

    X

    AUTHORITY

    We have no experience in deploying this tool.

     

    X

     

    We have a history of failure in deploying this tool.

         

    We have minimal existing talent deploying this tool.

     

    X

     

    HUMAN RESOURCE MANAGEMENT

    We have no experience in deploying this tool.

     

    X

     

    We have a history of failure in deploying this tool.

    X

       

    We have minimal existing talent deploying this tool.

     

    X

     

    INFORMATION INFRASTRUCTURE

    We have no experience in deploying this tool.

    X

       

    We have a history of failure in deploying this tool.

    X

       

    We have minimal existing talent deploying this tool.

    X

       

    TECHNOLOGY INFRASTRUCTURE

    We have no experience in deploying this tool.

    X

       

    We have a history of failure in deploying this tool.

    X

       

    We have minimal existing talent deploying this tool.

     

    X

     

    Coordination In Support of Change
    Both explicitly and implicitly, this chapter places a heavy emphasis on coordination among diverse activities. While nobody can argue against the value of coordination, it must also be recognized that achieving coordination can be difficult, time consuming, and expensive. It is not hard to imagine a situation in which so much effort is spent coordinating that not enough time is spent working on tasks. The problem is that coordination can be seen as necessary but expensive overhead. The challenge is to have just enough to do the job, no more. The key is to begin with two assumptions.

    With these assumptions as a basis, we recommend the following guidelines for proper coordination.
    • Minimize coordination requirements by identifying and focusing on critical activities coordination, minimizing the overall investment needed in coordination.
    • Decentralize responsibility for coordination via:
      • clearly defined team boundaries
      • clearly defined task definitions
      • making responsibility for coordination a team function
      • insisting on each team's commitment to the boundaries of its mission
    • These tactics are valuable because they will:

      • decrease the complexity involved in centralized control
      • allow a greater level of effort

    • Use common processes and terminology, thus assuring that:
      • coordination is not lost due to simple misunderstandings or miscommunications
      • effort does not have to be wasted (or error increased) as a result of needing to translate from one frame of reference to another
    • Choose appropriate coordination mechanisms for each task. Important tools for coordination include:
      • informal meetings
      • formal meetings
      • informal communication (e.g., e-mail)
      • formal communication (e.g., reports)
      • data and information repositories
      • co-location
      • telephone or video conferencing
    In order to analyze the state of coordination efforts in your company, it is useful to fill out Table 4.

    1 = Happens infrequently or never.
    2 = A common occurrence.
    3 = A frequent occurrence.

    Table 4: ASSESSING COORDINATION

    Situation

    Infrequent or Never

    Common

    Frequent

    Activity that should be coordinated is not.

     

    X

     

    Effort is put into coordinating activities that are not dependent on each other.

    X

       

    Coordination is the responsibility of groups who are removed from immediate responsibility for the activities being coordinated.

     

    X

     

    Coordination is made difficult by lack of commonality in vocabulary, business process, or technical solutions.

       

    X

    Mechanisms of coordination do not result in appropriate linkages among activities.

     

    X

     

    Metrics
    Any time a company undertakes an improvement process, it must be able to measure change in order to determine mid-course corrections and whether changes actually result in improvements. This chapter cannot specify particular metrics because the choice of those metrics is so dependent upon individual circumstances. As an example of this dependency, consider two companies, one of whom is attempting a long term change in products and markets, and one of whom is attempting to bring about short term improvement in customer satisfaction with an existing product line. Not only will the goals of a change process differ between these companies, but so too will the process needed to effect the change. Since measurement criteria must match processes and goals, metrics that would work in one case would certainly not work in the other.

    It is, however, possible to articulate general principles that should apply to any set of metrics. These principles are important because the use of metrics can be equally constructive or destructive. These principles constitute a quality assurance process to ensure the constructive use of metrics.

    • Set up a system that tries to jointly optimize between 3 and 5 metrics. Never use only a single metric because so doing will cause people to optimize that metric to the great detriment of the organization as a whole. As an example, consider what would happen if "on time delivery" were used exclusively, while ignoring "functionality," "cost," or "maintainability." On the other hand, too many metrics will result in an unwieldy system, or worse, will allow individuals and groups to pursue their own agendas.
    • Reward problem solving. When metrics are used for punishment and blame, powerful forces are sure to develop which will subvert the intent of setting up the measuring system.
    • Base reward systems on metrics, and link their application to reward systems for individuals and groups.
    • Integrate assessments into ongoing activities. Without integration, metrics loose much of their value, i.e., their ability to guide mid-course corrections.
    • Metrics must be:
      • easily observable
      • reliable
      • well defined
    • Data must be available to groups who can act.
    The question of whether your company can institute a system of metrics without outside assistance depends on its ability to implement each of the above principles. As a diagnostic instrument, turn each of the above principles into a rating scale as depicted in Table 5. In keeping with our convention, the higher the score, the greater the need for outside assistance.

    1 = This statement does not describe our situation.
    2 = This statement has some relevance to our situation.
    3 = This statement is highly descriptive of our situation.

    Top

    Table 5: ASSESSING ABILITY TO IMPLEMENT METRICS

     

    Situation

    Not Descriptive

    (1)

    Some Relevance

    (2)

    Highly Descriptive

    (3)

    We would have trouble agreeing on a small set of metrics that we could all "live with."

     

    X

     

    If we had metrics, it would be difficult for us to avoid using them to punish failure.

       

    X

    It would be hard for us to change our reward systems.

       

    X

    Even if we could get the data, it would be hard for us to use common metrics to guide everyday activities.

     

    X

     

    If we chose the most powerful metrics we could, they would be difficult to assess or use during routine activity.

     

    X

     

    The way we would have to collect and distribute information would make it difficult to provide metric-based information to the groups best able to use that information.

    X

       

    Strategies of Change: Business Process Re-engineering and Continuous Improvement
    The previous section provided an overview of the principles that must be applied to any change process. In this section we present two types of change that can be managed with these principles:
    • Business Process Re-engineering (BPR)
    • Continuous Improvement (CI)
    Business Process Re-engineering (BPR)
    The concept of "engineering" connotes careful attention to detail within a context of a well thought-out overall goal. We engineer cars, turning centers, and software. In each case there is an artifact involved, a "thing" whose finished look is well understood before design begins. Business is not like that. Business tends to grow by adaptation to circumstance. We think we can enter a new market, we go after it; it makes sense to merge two departments, we merge them; and so on. Although vision and planning are important in business, we seldom take the time to think of our business as an organic whole, to consider how the pieces fit, and to make deliberate changes. BPR is a countervailing force to opportunistic change. It is a method which can be systematically applied to an analysis of how business activities can be designed for maximum value. A sense of how BPR works can be developed from an overview of some of its key concepts.

    As-is analysis—The concept of "re-engineering" implies a change from some existing state of affairs. One large problem that many companies have is that its staff has an unclear idea of what that "present state" is. Ask yourself these questions:

    • Outside of my immediate group, how much do I really know about how my colleagues do their work?
    • Do I understand how they do routine business?
    • Do I know what exceptions and emergencies they have and how they handle those problems?
    • Do I have a feel for the concerns and priorities of levels of the organization that are above or below me?
    • If someone asked me to explain what other groups did, how good a job could I do?
    • Now ask:
    • How well do I understand my own work and how it affects the productivity of others?
    • When was the last time I collected information on my colleagues' views about how I can be improve what I do?
    • How well do I communicate to others how changes in their activity could improve my value to our company?
    • Of all the work I do, what are the essential functions that I perform?
    While you probably have better answers to the second set of questions than to the first, the overall quality of your information is likely to be relatively low. Consider your level of ignorance about these questions, then multiply that lack of knowledge across all the people and groups in your company. The picture that emerges is one of a considerable lack of understanding of what is going on, and hence, lack of a common foundation to plan change. One critical concept of business process re-engineering is to develop a common understanding of the status quo, i.e., an "as-is" analysis.

    To-be analysis—Once change is contemplated, it is easy to envision many different futures. Some of these futures may be compatible or even synergistic, as in the case of improved manufacturing efficiency and high levels of customer service. On the other hand, incompatibilities are also possible, for example, with a company that wishes to increase both market share and profit per item sold. Effective change requires taking full advantage of mutually beneficial goals while recognizing and minimizing incompatibilities. Further, productive action requires that all involved in effecting a change share a common vision of that change. Two requirements apply to visions of change: (1) their critical elements must be compatible and (2) there must be agreement on what those elements are. Neither of these requirements can be met without a carefully worked out "to-be" analysis.

    Models—Pictures are useful both in describing complicated business processes and in assuring common understanding of "as-is" and "to-be" situations. These pictures may contain greater or lesser amounts of information, be detailed or general, automated or hand drawn. In any form, they are valuable because of they represent a library of information about "as-is" and "to-be" states.

    The critical issue is to make sure that the model has a level of detail that is appropriate for its intended use. As an example, consider how "payment history" may play a part in processing new orders. In terms of the concerns of a Vice President of Finance, the model in Figure 1 may be entirely adequate for understanding the advantages of a proposed new business process. As far as the Vice President is concerned, all the essential information is available. Under the present system:

    • The Accounts Receivable department checks all incoming orders to assure that the customer is viable.
    • If no problems are found, Accounts Receivable passes the order to Manufacturing.
    • If the customer has a credit problem, the decision about filling the order is passed to Sales, who then has to make a judgement call about what to do.

    Figure #1

    Under the proposed new system:

    • The order entry function is automated.
    • Accounts Receivable is out of the loop, except in cases of a bad credit report from the order entry system, because its other routine activities feed an automated order entry system with credit information.
    This viewpoint, however, hides a considerable amount of detail. What does the Sales Department do when an order is questionable? How is information fed from applications used by Accounts Receivable into the order entry application? And so on. Each of these questions requires models of greater detail than the one presented above. The essential point is that detailed models are critical to people in Sales and Accounts Receivable, but useless to the Vice President. Whether done as visual models or verbal descriptions, the process of BPR must collect data at great levels of detail, but present the data differently to different groups.

    Cross-functionality—What makes one business process better than another? One important factor is the extent to which a business process meets the requirements of all who depend on that process. Consider for example, two scenarios in which a company's sales function could be redesigned. In case number one representatives of the company's market research group are present when the sales function is redesigned. In case number two those representatives are missing. Clearly, the different group membership will result in a different "look" for the redesigned sales group. In one case a mechanism is likely to be established that will transfer useful information from sales to marketing. In the other case such a mechanism is likely to be absent.

    Designing process to add value—Two of the above elements—"to-be vision" and "multiple levels of detail"—combine here. The existence of a vision implies that alternate changes will be made. The multiple levels imply that the notion of "vision" manifests itself differently in different parts of the organization. The trick is to assure that multiple visions remain compatible, and that they are pursued in an effective manner.

    As an illustration, consider the example of Acme Widget, who has developed a "to-be vision" of greatly increased market share. Working from that vision, various departments and subgroups within departments may develop the following visions:

    • Sales and Marketing—Acme will be first in the minds of customers whenever they experience a need for Acme's products.
    • Sales and Marketing's marketing group—Acme Widget will always have the best possible information on trends in the widget market, on potential new customer groups, and on the evolving needs of Acme's present customers.
    • Market Liaison (a two person group within the Sales organization)—All information collected by the sales force that provides market research information will be organized and provided to the Marketing group in a timely fashion.
    Many designs, however, may be equally effective while differing greatly in required resources. Hence, the requirement to balance the need to meet objectives with a requirement to minimize the use of people, time, and money. As an example, consider the goal of the Sales and Marketing department. To meet that goal the department may employ personal visits of sales people to customers, the delivery of informational seminars, or various forms of advertising. Further, the Department may use only its full time dedicated personnel, or leverage resources from other groups that have customer contact, e.g., technical and maintenance personnel. The challenge is to be creative, to remove preconceived notions, and to come up with the best possible balance of goal attainment and efficiency.

    Data based—Business process re-engineering requires people to put considerable energy and time into making important decisions. To assure that good decisions are made, it is important to have as much reliable information as possible. Three guidelines are useful:

    • Everything you believe is based on an invalid assumption.
    • What you believe is wrong.
    • Data to validate your assumptions is always available.
    Assuming the truth of these exaggerated over-generalizations can be extremely useful in assuring good decision making during a BPR exercise. As an example of why data gathering is so important, consider two examples where beliefs may be plausible but incorrect, and where acting on those beliefs might have catastrophic consequences.
    • Acme believes its customers base their decisions on price, while in fact delivery time and customer service are more important.
    • Acme personnel have a belief that their "Research and Development" department wants to act unilaterally, when in fact that department is starved for input and closer cooperation from groups such as Marketing and Manufacturing.
    So far we have described a change process that is powerful, systematic, coordinated, and customer driven. But we have also described a process that seems complicated and so "connected" that it cannot be undertaken without a frighteningly heavy commitment to large scale organizational change. BPR is difficult and it does require commitment. On the other hand, the process does not have to be a company-wide, all-or-nothing undertaking. The key is to bound the effort in reasonable ways. While it is true that "everything is connected to everything else," it is also true that the degree of connection can vary widely.

    As an example of varying degrees of connection, consider the likely set of relationships among: product design, manufacturing, marketing, sales, human resources, finance, information systems and facilities. It would be difficult to re-engineer product design without a major redesign in manufacturing. Also, changes in product design may affect other functions. Human resources may need to change their hiring or training activities. Information Systems may need to improve networking and common data bases. Marketing may have to provide more consistent information to design groups. Still, it is clear that re-engineering of design must involve the re-engineering of manufacturing, but may not require a similarly heavy commitment to the redesign of other functions.

    Continuous Improvement (CI)
    CI is based on the assumption that no process or product is perfect, and that one can always make improvements. CI further assumes that great gains in overall productivity can be obtained from the aggregation of incremental, ongoing improvements. Essentially, CI is the ongoing application of small experiments and innovations in support of broad organizational goals. The essence of CI is that it is not special, it is not an "add on" to routine. Rather, it is a fundamental part of the daily routine, driven by:

    • Common goals
    • Management and employee commitment
    • Incentive systems
    • Empowered groups
    • Useful information
    Usually CI is described as a critical approach to increasing shop floor productivity. By no means is CI restricted to addressing just shop floor problems. It can be just as useful for management problems, both day-to-day and long-term. While the individual changes brought about by CI may be small, the implementation of CI can require major changes in:
    • Organizational culture—The culture must encourage the identification and solution of problems, often in creative ways driven by the people directly involved.
    • Organizational structure—The organization's structure may need to change to support greater flexibility and the empowerment of the personnel to identify and address problems.
    • Management policies—Managers need to support their personnel, helping them identify and solve problems rather than dictating actions to them.
    • Labor relations—Existing labor agreements may not support the concept of management working with the shop floor personnel to identify and solve problems; the relationship cannot be confrontational if CI is going to work.
    • Data systems—Many problems stem from weaknesses in Information Systems, and the CI approach is likely to highlight weaknesses in the information flowing to and from the company's different activities.
    Plan-Do-Check-Act—In the CI model, incremental changes are brought about through the repeated application of "plan-do-check-act" cycles practiced throughout the organization as part of daily life. The approach is:
    1. Plan—determine what specific problem you are going to address and propose a solution
    2. Do—implement the proposed solution
    3. Check—measure the improvement gained from the change
    4. Act—base your next planning process on the previous solution, modifying the solution, if necessary, or expanding its application
    From that point, go on to the planning stage for the next improvement. Key to the CI philosophy is that by undertaking small, well-defined steps, the cost of failure is kept low, so greater experimentation can be risked.

    Top

    Relationship of Continuous Improvement and Business Process Reengineering
    CI is designed to be routine and fully integrated into daily life within a company. Business process re-engineering on the other hand is radical. It pulls people away from their daily routine, it requires a heavy commitment of resources, and it forces people into the creative but uncomfortable position of questioning dearly held assumptions. It is not a process to be undertaken frequently or lightly. Good planning requires a sense of how these activities relate to each other, and when each is appropriate. The situation can be described as in Figure 2.

    Important issues summarized in this graph are:

    • Without CI, change is uneven and difficult to sustain.
    • Without CI, even when improvement is obtained, lack of maintenance to innovations will result in a loss of value. The CI process sustains change and minimizes disruption.
    • Interrupting the elegant process of CI are discontinuities. Market conditions may change, for instance, moving a company from being in a highly competitive position to an uncompetitive one.
    • At these times more radical change is necessary, as represented by the discontinuity in the graph's solid line. Imagine that the solid line up to the discontinuity represents two separate companies, each equal to the other. At times, "X" market conditions change. One company adapts to the change with BPR, while the other goes on with CI only. Note how the competitive positions of the two companies diverge.
    • Even after the market change, CI is needed to sustain competitive advantage.

    Figure #2

    CI and BPR are also related in that the former can be used to improve the latter. This is particularly the case in the implementation phase of BPR, when many complex changes are being managed. As an example, imagine a company that is implementing both EDI and the internal integration needed to profit from that EDI. This change is likely to require new technology, training, business process change, and system integration. A CI approach applied to these changes may show that training schedules are too tight, that revised plans should be published every month instead of every three months, that a larger number of trading partners than anticipated can be included, or that some extra microcomputers would be useful. None of these are major deviations from the original implementation plan. Rather, all are small improvements which, in the aggregate, will make for a much more successful implementation.

    Top

    Managing the Change Process
    At this point it may be useful to put all the information above in context by showing how it fits into an overall process of change. Two different pictures give complementary views of the change process. Figure 3 shows how tools of change are translated into an action plan.


    Figure #3

    The critical point here is that in order to develop and carry out an action plan, the tools of change must be used to design activity in the domain areas detailed in this document, e.g., coordination, teams. Successful action plans derive from asking the following type of questions:

    1. Given a particular action plan, what do I need in the way of teaming, metrics, CI, etc?
    2. Given my requirements for teaming, metrics, CI and the like, what tools of change do I need, and how should I deploy them? The second view of change takes a life cycle perspective, and can be depicted in Figure 4: Important elements of this model are:
    3. There is a high degree of concurrency and feedback among stages.
    4. There is a heavy emphasis on data and analysis.
    5. External benchmarking is important. It is necessary to find out how others succeed.


      Figure #4

      Benchmarking need not be prolonged or elaborate, but there must be some mechanism for learning from success in the "outside world."

    6. The change process must be continuous because outside circumstances are dynamic and because internal changes affect future possibilities.
    7. Integration of Technology, Organization, and People
      Any change process can be viewed as an effort to concurrently engineer three systems in support of business objectives: Technology, Organization, and People (TOP). When considering TOP integration, two concepts are important, i.e., that TOP elements can
      • Substitute for one another
      • Interact with each other
      A common example of the first is the entry of EDI data into an MRP system. Technology can be employed for automatic data transfer, or people can be used to do manual key-entry. The critical issue is that the right choice depends on individual circumstances. As examples, the following questions may be relevant:
      • Does a company have labor available to do the data entry?
      • Would integration have an economic benefit to the company?
      • Would a change from manual to automated data entry put a strain on a company that has already undergone too much change?
      The point is that the company has an objective to get EDI data into its MRP system, and must weigh the pros and cons of a technical and human resource method of reaching that objective.

      The second point (that TOP elements interact) can also be illustrated by assuming the automated option was chosen in the previous example. Given that choice, the company would have to consider new human resource needs in their IS department to support that integration. Once developed, however, those resources would add to the general depth of IS skills in the company, opening up a new set of possibilities for change. Further, moving to the automated solution may free up data entry time, providing an opportunity for people to move from data entry to higher value-added work within the company. The essential point is that change in one of the three TOP elements is likely to affect the other two. Successful change requires a sense of how those effects will play themselves out, and to manage changes in all three for maximum benefit to the company as a whole.

      Top

      Example: Application to a Specific Case
      In this section we present an illustrative (and hypothetical) example which draws on the information in this chapter. To begin we present a scenario which describes an EDI challenge faced by a first tier supplier in the automotive industry. The scenario is described in Figures 5 and 6.


      Figure #5

      Acme is already doing EDI with its customers. It is not, however doing EDI with its suppliers, nor are its internal applications particularly well integrated. Acme's vision is a well integrated EDI system that can take input from customers, efficiently process the data internally, and pass EDI data on to its suppliers. By so doing Acme hopes to decrease costs, increase efficiency, and decrease lead time.

      Applying Principles of Change Management
      In preparing for the change, Acme's "EDI Feasibility Team" has rated itself on the basic principles of change management. (Recall that the X's in the tables refer to the ratings Acme has given itself.) Let's see where the company stands.


      Figure #6

      Know Your Business
      As Table 1 shows, Acme is in a pretty good position to understand its business objectives. It can obtain necessary information, pursue multiple objectives at the same time, and it understands how its business may change. The big problem, however, is Acme's ability to achieve a consensus among interested parties about business goals. In terms of EDI, this means that the priorities of different functional units may compete, and that agreement will be difficult. From what we know about Acme, we can guess that two kinds of arguments may occur. The first emerges from the weak links among Acme's internal operations. People concerned with these weak links are likely to argue that the first priority should be integration of internal applications because internal integration is the fastest way to noticeable improvement. Others may be more sensitive to the problems caused by not getting timely information to and from suppliers, and who will push for getting EDI in place first, using the information as best as possible, and then doing internal automation.

      Given this situation, Acme does not need consulting or outside assistance in understanding business needs. It will, however, need some process consulting help to guide staff toward agreed-upon priorities and goals.

      Question Assumptions The essence of questioning assumptions is the ability to brainstorm in group settings. Some group process consulting may be useful here, but for three reasons may not be necessary. First, these group meetings will not result in decisions that require committing to action. Unlike setting business priorities, discussions here are unlikely to result in major arguments. Second, we know that Acme has already implemented EDI with its customers, and has at least some experience understanding the group process in support of technology implementation. Finally, meetings to question assumptions are inherently interesting and challenging to people, and so are likely to elicit much discussion. In sum, as long as Acme has some staff with experience in leading groups, the information in this section may well suffice in leading to the necessary discussions.

      Use Teams to Guide Change Acme's situation here is consistent with the conclusions obtained from Table 1, i.e., that Acme needs help in running groups whenever hard decisions have to be made. As Table 2 shows, Acme has a history of "turf wars" and problems with group decision making. Given these problems, it is not surprising that Acme's key people will resist accepting low power positions in group decision making. These problems are exacerbated by the fact that the change Acme wants to initiate will touch a large number of its functions—accounting, order processing, purchasing, sales, information systems, and manufacturing.

      Change Levers Acme is in reasonably good shape with respect to information and technology. (See Table 3.) One reason for this is their prior experience doing EDI with their customers. Also, Acme's Information Systems group has managed to develop reasonable links to several other departments—strong links to order processing and medium links to Sales and Accounting. We can assume a reasonable degree of skill and competence here.

      A caution, however, must be observed. It is likely that the level of technology change sought by Acme may be many times larger than what was done to implement EDI with customers. This is because the strong ties to be developed will require networking, interfaces among diverse applications, and (probably) some redesign of the systems themselves. Despite its abilities, Acme should keep a careful watch on its needs for consulting in these areas.

      Acme does need to train key executives and managers in exercising leadership. This training is important because the changes Acme is making, i.e., moving to an automated and integrated information flow, will require radical and often threatening change.

      Acme will also need consulting in developing reward systems that will support the changes to come.

      It is true that Acme rates reasonably well in its experience and history of using reward systems. On the other hand, their expertise in developing reward systems is small. The dichotomy between history and expertise makes sense because, like many suppliers in the automotive industry, Acme is a traditional company which has always done business pretty much the same way. Now that large changes are in the offing, expert help will be needed.

      Coordination in Support of Change As Table 4 shows, Acme's single largest coordination problem is a lack of common vocabulary and process. In a way, this is fortunate because the changes Acme wants to institute will require BPR, an activity that by its nature emphasizes developing the kind of commonalities that Acme lacks. Considering the coordination problems that are endemic to almost all companies, the rest of the picture for Acme looks good. Unnecessary coordination is minimal. While coordinating mechanisms and the assignment of responsibility could be improved, these do not result in frequent occurrences of missed coordination.

      Metrics The data on metrics reflects what we already know about Acme's need for help with reward systems. As Table 5 shows, Acme would find it difficult to change their reward system to reflect new metrics, indicating that changes in how rewards are structured must go hand-in-hand with identifying what should be rewarded. The data are also consistent with what we found out about Acme's need for assistance with leadership. Even if appropriate metrics were developed, they would be used for punishment rather than problem solving. That shift requires a change in organizational culture, and changes in culture require strong leadership.

      Table 5 also indicates that Acme will need help in implementing a CI system. This conclusion emerges from the "moderate relevance" attached to three items: (1) getting consensus on relevant metrics, (2) using metrics to guide change, and (3) choosing powerful metrics that could be collected during routine activity. While each rating shows only moderate difficulty, in their totality they indicate difficulty in the routine use of data. Such routine use is a critical element of CI.

      On the other hand, Acme's ability to collect data is in reasonably good shape, a situation that reflects its human resource and technological strength in information technology. As long as the Information Systems group is not swamped by the scale of change, they should be able to provide good information to those who need it.

      Strategies—Business Process Re-Engineering and Continuous Improvement Over and above being a collection of sub-components (e.g., modeling, process design), BPR is an integrated approach to change. Given the weak links we see among many of Acme's departments, we can assume that the company has not previously engaged in a BPR exercise or that, if it has, the results have been disappointing. Thus, Acme will require training and consulting assistance in BPR.

      Both the "as-is" and "to-be" elements of BPR require common understandings and agreements on action items based on those common understandings. We have already established that Acme has trouble in reaching consensus on action items, thereby reinforcing the previous conclusion that Acme needs group process consulting assistance.

      Modeling is also important in BPR. To be useful, those models must reflect Acme's as-is and to-be states, and must do so at appropriate levels of detail. As a typical automotive supplier, we must assume that Acme does not have the technical knowledge to do effective process modeling. Therefore, Acme will need technical consulting here.

      BPR's emphasis on careful assessment reinforces the previous conclusion that Acme will need help in developing and implementing metrics.

      Acme must also plan to maintain and improve whatever changes it puts into place, i.e., it must have a well functioning CI system. It's safe to assume that because of CI's wide-spread popularity, Acme already has some CI-like quality improvement system in operation. Given what we know about Acme, however, we can also assume that the company does not have a rigorous system in place. Why can we make this assumption? CI requires empowered groups who can commit to action and Acme has trouble in group consensus building. CI requires delegating activities and Acme personnel have trouble accepting low power roles. CI requires data based decision making and Acme has trouble with data. Further, even if Acme has been applying CI to routine operations, they do not have experience applying CI as a quality control mechanism for large scale EDI-related change management. (We know this because their previous experience is confined to customer-driven EDI that is only weakly integrated into existing applications.) Another area requiring training and consulting is in the implementation of CI, particularly as it applies to major EDI-related innovations.

      Action Plan
      With the above information in hand, the Acme EDI Implementation Team is now able to recommend an action plan. To be successful, that plan must have five characteristics. It must:

      Many such plans might be developed. One example appears below.

      As a beginning, the team establishes an overall vision and specific objectives for the first year of operation.

      Vision:

      A well integrated EDI system that can take input from customers, efficiently process the data internally, and pass EDI data on to its suppliers.

      One year objectives:

      1. Purchasing and Materials Management-based EDI in place with the five most important suppliers
      2. Full integration of EDI with a bar code-based receiving system
      3. Detailed implementation plans for complete internal system integration
      Next, two events must occur. First, the EDI Feasibility Team must get agreement from the Steering Committee to proceed. Second, a team must be assembled to implement the action plan. To succeed, this team must be:
      • Cross-functional
      • Publicly sanctioned by upper management
      • Driven by business need
      • Competent
      • Influential within the company as a whole
      • Influential within each of the departments involved
      • In order to assure continuity, comprised of many members of the original EDI Feasibility Team
      Our recommended action plan for this group is based on the implementation life cycle (Figure 2-6), as follows.

      1.  Problem Definition: As-is Analysis
           1.1  Assess size and composition of implementation teams
                1.1.1  Recruit additional members as necessary
                1.1.2  Break into sub-teams as necessary for efficient operations.

           1.2  Obtain training in BPR as a change process
           1.3  Obtain training in business process modeling
           1.4  Contract for group process assistance
           1.5  Perform as-is analysis
           1.6  Assess EDI capability of supply base
           1.7  Assess capabilities of existing EDI software, software vendor, and Value added Network
           1.8  Assess likely outside assistance that might be obtained (e.g., Manufacturing Technology Center, Electronic Commerce Resource Center, regional economic development agency, for-profit consultants).

      2.  Requirements: To-be Analysis

           2.1  Revisit vision and objectives, revise as necessary
           2.2  Develop to-be plans at intermediate level of detail (greater than in "objectives" but general enough to direct specific technical and business change activity)
           2.3  Develop priorities within boundaries of plan (number of suppliers, specific transaction sets, critical aspects of integration, etc.)
           2.4  Obtain feedback from the Steering Committee
           2.5  Obtain feedback from others within the company.
           2.6  Finalize plans
           2.7  Adjust team structure to assure that appropriate people are involved as implementation proceeds

      3.  Planning and Implementation

      These elements are separated in figure 2-6 to emphasize the importance of planning prior to action. In fact both planning and implementation consist of many sub-tasks with multiple dependencies and a need for much concurrent activity.

           3.1  Determine budgets and other resources for all critical activities
           3.2  Search for existing useful models of best practice, implementation guidelines, etc.
           3.3  Select transactions which fill business requirements
           3.4  Select conventions which meet business requirements
           3.5  Benchmark supplier EDI in other settings and companies
           3.6  Select small group of trading partners to test EDI transactions
           3.7  Develop plan to bring all selected suppliers on-board with EDI
           3.8  Contract and set schedule for needed training and support—group process, modeling, BPR, CI, etc.
           3.9  Develop and negotiate EDI Trading Partner Agreement with suppliers
           3.10  Select and contract with automation vendors for modifications to Information Systems in support of integration
           3.11  Select and contract with EDI vendor and VAN for expanded use of EDI
           3.12  Develop plan to support suppliers, e.g., implementation guides, referrals to assistance agencies, help desk, supplier conferences
           3.13  Develop metrics to assess changes.
           3.14  Set schedules for all internal innovations—technology, training, organizational change, business process change, etc.
           3.15  Implement Continuous Improvement program to support changes
           3.16  Implement data collection (based on metrics) to support business case for continuation of program
           3.17  Implement high priority internal innovations
           3.18  Implement supplier assistance plan
           3.19  Test EDI with selected suppliers
                3.19.1  Revise as necessary
           3.20  Review test results
                3.20.1  Make needed changes
           3.21  Start production ramp-up

      4.  Routinization and Maintenance

           4.1  Apply CI to manage and improve implementation process
           4.2  Continue business case analysis and reporting to management
           4.3  Monitor changes in business and technological environment that may signal need for revised plans
           4.4  Adjust group structure as necessary
           4.5  Train new group members

      Top