User Experiences with the Implementation and Use of Application Package Software

by Erica Wagner, Assistant Professor, Information Systems, School of Hotel Administration, Cornell University; and Sue Newell, Cammarata Professor of Management, Bentley College

INTRODUCTION

In the past, companies have designed systems to support work activities unique to their organization. Such systems were implemented at the level of department or business function in order to effectively meet specific needs. However, this functional approach to development often led to the creation of "islands of automation," where a depth of information about a single domain was available through a standalone data repository, but there was little or no potential for sharing information across the firm. Furthermore, isolated development led to disparate data formats, multiple operating systems, and various interpretations of data. These variations contributed to a systems environment that was difficult to maintain, made integration across business processes inefficient, and failed to meet user expectations.

This situation has changed dramatically, with companies moving from custom-made systems to configurable packaged enterprise software. These products supposedly embed best practices so that, through their adoption, the firm receives the gold standard for accomplishing particular business processes. This is attractive to businesses not only because of the ability to benchmark current processes against those designed into the software templates, but also because packaged software promises to cut down on inhouse IT development resources by offering a prebuilt framework around which to make configuration choices. Increasingly, vendors have begun to offer preconfigured packages for different industries and organizations of different sizes (e.g., packages specially designed for SMEs). This has been done to speed implementations by reducing the complexity of the configuration process, and it is beneficial for the vendor. For example, Oracle took its government/public-sector product and retooled it as a higher-education solution. As a result, Oracle successfully entered an emerging market.

When choosing packaged software products, adopting organizations are encouraged to first install the "vanilla" version of the software -- that is, with minimal or no customizations to the actual software program. Doing so is expected to ensure benchmarking standards and save unnecessary local development. Organizations are then encouraged to "configure" the software from a catalog of options and then to simply transfer existing data and processes to mirror those supported by the software. Consequently, buying instead of building software means that the normative practice is to change organizational processes and structures to match the vanilla design supported by the software. In addition, organizations must be willing to upgrade the software at regular intervals if support by the vendor is to continue (vendors argue that such upgrades are necessary to ensure that the market is supported with a state-of-the-art product).

Enterprise resource planning (ERP) is the most prominent packaged software of this kind and arguably the most popular of the 20th century. The market reach of ERP is mirrored in the Cutter survey; 70% of responding organizations have adopted such a product (see Graph 1 in the Survey Data section). Historically, ERP products were confined to support system modules, but today they are being extended to include options for customer, supply chain, and human resource management -- a trend that is evident from the survey. In this article, we use the generic "enterprise system" (ES) as an umbrella term to reference packaged software products that are designed to support different business processes.

Benefits typically associated with adopting an ES are that it can support integration of business information across an organization, thus potentially enabling smoother and more efficient workflows around business processes. Yet evidence mounts as to the difficulties of achieving these benefits. The basic premise that an ES product can effectively meet the diverse needs of various organizations is questioned, as is the extent to which their sale in the marketplace enhances competitive advantage. This latter point relates to the question of whether the best practices that are embedded in the software are indeed the best choice, a point we will discuss later. Here, we draw upon the data collected from the Cutter benchmarking survey of ES package adoption and implementation to consider these issues.

ES DEPLOYMENT: PARTIAL VS. FULL DEPLOYMENT

The Cutter survey results support the notion that ES in general are difficult to exploit fully, but nevertheless, organizational actors are working with the products. Only 28% of the organizations have fully deployed an application package meant to support business processes (see Graph 2). Yet only 7% have failed to deploy or have deployed and then later pulled their software product out of production. This means that the majority of those who purchased an ES are in production with the software but are operating at less than full deployment. One reason for this are escalation costs related to complex software projects, where it becomes expensive quickly and the implementing organization is unlikely to completely pull the plug -- so they try to make it work in spite of the difficulty associated with its implementation. Thus, while most of the responding organizations are operating an ES, over 90% of those that implemented one claim the organizational changes associated with implementation had a degree of difficulty (see Graph 11).

Bill Ulrich's article highlights this finding as well, and he argues that management should adjust its expectations and realize that this is the way things are when it comes to ES deployment and use. We agree and argue that practitioners need support that extends beyond implementation if they are to manage these behemoth project initiatives. Practitioners should take solace that nearly 95% of the organizations represented in the survey have managed to create a system that is in production. Too often, when we visit organizations and talk with project teams trying to implement ES products, we hear disappointment and failure stories because they were unable to fully deploy the product, to realize every last benefit of the software. Evidence in this survey suggests that it is standard practice to deploy rather than give up -- but to deploy with less than what one might have initially hoped is possible. Perhaps not surprisingly, the findings also indicate that when less functionality is deployed, fewer goals are satisfied. For us, this indicates that expectations can be raised over time. It is important for management to persevere after deployment in order to exploit more of the functionality from the system.

IMPLEMENTING ES: IMPROVING EFFICIENCY VS. FOLLOWING THE COMPETITION

The survey results suggest that internal efficiency factors are more important than external competitor factors in influencing adoption decisions (see Graph 4). Many respondents do not feel that their organization chose to implement an ES as a way of benchmarking against the competition, that is, "keeping up with the Joneses" so as not to lose competitive position. Yet when we've asked practitioners why ERP, the repeated response is a blank stare followed by the statement, "No one builds their own systems anymore." This indicates two things. First, that humans like to attribute decision making to a rational assessment of needs, rather than to a desire to be like others. Second, it points to the "ERP bandwagon" effect, where we hop on board because there doesn't seem to be another wagon coming along anytime soon that can get us where we need to go.

ERP advocates have done an exceptional job at clearing the field of viable options and making it appear as though enterprise systems are a prerequisite for business success. This is not to discount our respondents' perceptions that they are motivated by internal efficiency factors more than external competition, but rather to offer an alternative interpretation based on our knowledge of the management "fads and fashions" literature. This literature indicates that the copycat trend is pervasive when it comes to management ideas and is illustrated by data on a diverse range of new technologies (including IT) that demonstrate an S-shaped adoption curve: innovative early adopters being copied by an increasing number of followers, leaving a few laggards or late adopters who refuse to "follow the fashion." The BlackBerry, for example, is indeed a nifty tool for accessing e-mail, but it certainly isn't the only tool, and yet its sales to businesspeople far exceed other brands. We see this in all kinds of consumer products, where trendsetters are followed by the masses, who essentially adopt to try and "be like" them.

Adopting technologies because others have done so is not necessarily a bad thing. Indeed, one could ask the question, why adopt a best practice software if only to improve organizational performance and secure data, when inherent within an ES is the idea that one is connecting up with state-of-the-art practices as defined by others? Fashions offer advantages since they can provide powerful symbols for efficiency and legitimacy. In addition, ERP became a management fashion at a point in our history when issues of globalization dominated. The end of the 20th century brought with it the dot-com era, the rise of the Internet, outsourcing, and global competition. No longer did it feel safe to opt out of that which others were opting in to -- in this case, ERP. What the management fashion literature reminds us, however, is that new technologies can diffuse very widely even though they are not necessarily more technically efficient than preceding technologies. For example, many of us remember the Beta versus VHS video recorder choice; the fact that VHS "won" the consumer vote was despite the fact that it was actually technically inferior to the Beta technology from Sony. Indeed, the very notion of "best practice" is inherently problematic, and we argue that what is actually best is determined by context and can never be captured by industry-wide best practice solutions because of the uniqueness of each organization and its history, environment, culture, and so forth. We next consider in more detail this issue of best practice.

SOFTWARE "BEST PRACTICE": A PROBLEMATIC CONCEPT

The idea that adopting the package would enable the organization to adopt best practices is strong, with 70% of respondents citing this as a primary or important motivator (see Graph 3). Nevertheless, respondents have varied ideas of exactly what the concept of best practice refers to, suggesting ambiguity of this term. As illustrated in Graph 5, only 39% of our respondents believe that best practices have to be external practices, indicating that if an internal practice is perceived as superior to the proposed external practice, then one might choose to retain this internal practice as the best choice. Thus, we can define software-based best practices as:

Superior business processes from both within and outside an organization that are applied in order to create routine uses of knowledge. These practices are judged to be superior by those making the software and are then included in a catalog of software templates from which one can configure ES.

The selection of those practices to include in a catalog is at the crux of what we see as problematic about best practice software claims. In our fieldwork, this has been played out as a tension between the view that superior processes are embedded in the software versus the view that any given business has learned over time how best to handle its unique situation. Companies often resent having to change their processes to suit the software, processes that they have strived to hone over the years. As one interviewee said to us, when talking about how their software vendor was pressing them to change their business processes rather than accept that they knew best how to operate in their particular market niche: "We had spent 15 years developing something that is successful to become the number one dealer in this industry -- we must have done something right. Give us credit for doing something right."

While this interviewee was critical of the idea that the software represented best practice, we have found that this is not always the case, especially among the senior decision makers who are often removed from day-to-day practice. Assuming that superior processes are embedded in software relates to what we have observed in our field research when decision makers assume that adopting some kind of information technology will enable them to change the business; thus, the oft-touted view that adopting an ES will "transform" the organization. There is an assumption that the presence of so-called best practice software templates will enable an organization to achieve superior business processes as a result of implementing software. In other words, the crucial step is in the acquisition of the product; after that, it is just a matter of doing the legwork.

The problem with this mindset is the lack of criticality that would normally precede a decision of this magnitude. Anyone who has ever trained for an athletic event or been a member of a sports team knows that there are a variety of coaching styles, multiple training plans considered optimal, and recommendations for rest, cross-training, hydration, and nutrition. Yet one becomes an athlete when one is able to critically discern for him or herself what works and what is suboptimal. To just "do the legwork" suggested by an outside expert might in fact be detrimental. Case in point, a five-time marathoner was never able to run under 3:40:00 despite reading multiple books on training approaches. Against all the wisdom culminated from "real" runners, the marathoner began to take walk breaks every three miles during training and abided by this on race day. Real runners don't walk; yet he finished in a shorter amount of time than ever before. The difference here was not in the execution -- hard work was consistent across all his marathon trainings -- rather, it was his point of departure. He redefined what was the best practice in terms of marathon training, and he learned that by letting his body recover every three miles with a short walk break, he had more energy in reserve when he got to the 18-mile mark. Where previously he was running on empty and his time slowed dramatically, through his run/break training, he was able to ramp it up for the last eight miles to finish faster.

The point of this example is that organizations, too, need to consciously develop an ES that works for them and, while the configuration options provide for some flexibility, this may not be sufficient for their specific business needs. This is because the menu of configuration options is limited so that, for example, the run/break training option, or its equivalent in organizational process terms, may not be part of the menu. Developing an ES that works for you will entail experimenting with and continuing to adapt both the technology and the organization in the post-implementation environment. It is very unlikely that the "best practice configuration," even one tailored for your specific industry, will be the ideal fit for your particular organization.

In this way, functional deployment can gradually be built up. The message to companies, then, is not to regard the implementation as completed at the point at which deployment is achieved and there is an information system in production. As we have seen, most companies at this point will be using only some of the potential functionality of the ES. You would do well to not simply stop at this point and bemoan the fact that all the functionality has not been exploited. Rather, you need to see the ES implementation as an ongoing process of continuous learning and adaptation. This means that there will need to be an allocation of resources for these post-implementation developments. In his article, Bill emphasizes the importance of being realistic about the budgetary implications of an ES implementation. We agree with this point and would add the importance of recognizing the need to allocate resources for these post-implementation developments.

REALIZING THE BENEFITS OF ES: THE TENSION BETWEEN EFFICIENCY AND INNOVATION

Realizing the benefits from their package implementations has been quite difficult or extremely difficult for 40% of the companies surveyed (see Graph 18). As shown in Graph 6, the benefit most realized relates to operational efficiencies. This is not surprising in the context of ERP products, which provide an integrated infrastructure for the organizational support systems. However, with products sold to help improve value-added activities, such as customer relationship management (CRM), we would expect to see evidence of improved competitive positioning within the marketplace as a cited benefit.

One reason that efficiency is more strongly enhanced than competitive positioning can be linked to the fact that there is tension between efficiency and flexibility/innovation. This is because efficiency is obtained by standardizing processes, with individuals then undertaking specialist tasks within those processes that are prescribed by rules and procedures. Some organizations, such as McDonald's, have grown to be very successful based on a rule-bound orientation to promote efficiency. Such bureaucratic work design, however, is not flexible nor is it conducive to innovation, as we can all attest to when we have tried to get a call center operator to respond to some unique circumstance that does not comply with the norm. Thus, innovation requires more organizational slack and a less rule-bound environment, where people can experiment with new ways of working or with new product designs. Today, there is some discussion that an organization can be ambidextrous; for example, with some parts of the organization being designed to support efficiency (e.g., the R&D function), while other parts are designed to support innovation (e.g., the production function). However, with a standardized ES penetrating all parts of an organization, a potential tension between efficiency and flexibility is one that organizations need to consider; more specifically, organizations need to consider how they are going to be able to respond quickly to the dynamic environment when their complex ES is very difficult and expensive to modify.

Importantly, a contradiction arises when analyzing the two survey questions related to ES benefits and the usefulness of the best practice software model (see Graphs 6 and 7, respectively). One might expect to find high correlation between the usefulness of the best practice software and organizational benefits. However, this was not the case; with the exception of operational efficiencies, the majority of respondents were able to realize limited organizational benefits (ranging from not at all to neutral). When juxtaposed against the perceived usefulness of the best practice model, most respondents found the model to be useful (ranging from very to neutral). Along with Bill, we interpret this to mean that while the best practice models embedded in software products are considered useful, the software still isn't benefiting the organization as much as it should. As Bill notes in his conclusions, there is a serious gap between the promise of best practice software and what it ultimately delivers in practice. This worrying finding is further substantiated with the 40% of respondents who claim that it was quite or extremely difficult to realize the benefits that were anticipated when the choice was made to adopt the packaged software, and another 42% were neutral about the level of difficulty (see Graph 18). This begs an answer to the question -- what is the point of so-called best practice enterprise software? If the models are helpful, then shouldn't they also help the organizations to achieve expected benefits? This reflects some of the problems previously discussed with the very concept of best practice.

THE CHALLENGES OF ORGANIZATIONAL AND TECHNICAL CHANGE: THREAT OR OPPORTUNITY

The majority of organizations had modified their organizational and business processes to fit the application package software (see Graph 8), and there is a correlation between those modifications and the meeting of organizational goals (see Graph 9). This stresses the importance of being willing to modify process flows and existing roles and responsibilities. Nearly 50% of respondents rate the challenge of making these changes as either quite or extremely difficult and time-consuming (see Graph 11). Our experience suggests that achieving the organizational change necessary to support the processes embedded in the software is especially difficult when there is limited representation on the ES implementation project team from different office locations. For example, in one organization we observed, the project team was staffed with members from the central office, with very little departmental representation. This meant that the ES was configured to suit the needs of central administrators. When rollout began, the departmental administrators protested that the new system made their jobs more, not less, difficult and thus they resisted the suggested organizational changes.

Technical challenges were also prevalent (see Graph 12). The most effort was expended on the migration and integration of existing data, demonstrating the challenges of cleaning up existing databases. Integration with other applications also required significant effort. Our previous research has also identified these technical difficulties. In one large global organization we were observing, for example, migration of data from legacy systems was difficult because, in Spain -- where people often have double-barreled surnames -- a field in the legacy system had been used for putting in the second part of the name, while in other countries, this field was used for something else. Integrating the data from different countries was therefore very challenging, taking much longer than had been anticipated.

Analysis of the survey results indicates that perceived benefits and goal achievement are tied to the degree of organizational and technical change experienced during a project. The more challenging these changes, the less stakeholders were able to extract benefit from their ES, and they had also been less successful in achieving their goals. In addition, the timing of such changes impacted the perception of benefits achieved. Unanticipated post-implementation changes that had not been budgeted for made realizing benefits from their ES deployment a challenge. In addition, 57% of the organizations made changes both before and after implementation (see Graph 10). This, we argue, indicates the need to change the lifecycle/rhetoric of successful software implementation. We think it is important for practitioners to hear from researchers and consultants that post-implementation modifications are a normal and expected part of the process rather than to conceptualize such activities as indicative of failure. Moreover, these results stress the importance of understanding the reasons why these organizational and technical challenges are so prevalent and difficult to manage in ES projects, an issue we address next.

Technical and organizational challenges occur because of the ways in which users improvise with any technology -- for example, fields get used for things that were not originally intended (as with the double-barreled surnames), and users adopt workarounds in order to maintain legacy practices even when the new ES no longer supports these. This means that it is extremely difficult to maintain an integrated database when it is used across so many different user communities, each with its own local practices, which continue to evolve long after the ES has been first implemented.

Such user improvisation can be perceived as either a problem or an opportunity -- a problem because it leads to resistance but an opportunity when it helps bring about unanticipated benefits. Respondents indicate that users resisted removal of their legacy systems and thus continued to use shadow systems to accomplish their work (see Graph 19); they also attempted to add to the package software. Yet seeing these user improvisations as only a problem undermines the potential to transform a system from a copy of what other organizations are doing to a unique system that can actually provide some competitive advantage. The number one reason for project failure is user rejection of the system. The notion that a for-profit company can force acquiescence to a particular system is dangerously false. People are at times recalcitrant and can always find a way to subvert formal policies/processes.

CUSTOMIZATIONS: THE MIDDLE WAY

Interestingly, a high proportion of respondents had made either a great deal (24%) or some (54%) customizations to the vanilla ES (see Graph 14). The reason for such customizations links to the previously discussed issue of valuing local practices. If we accept that much organizational knowledge resides in the day-to-day practices of those undertaking the work, then we should be attempting to develop systems that blend the automating and integrating power of an enterprise platform with grounded knowledge. This depends, however, on users understanding enough about the ES to consider how to exploit its functionality. Unfortunately, given the complexity of an ES and the typical "press button" approaches to training, this interaction between user knowledge and ES functionality is often not easily obtained, especially in the short term. Alternative and longer-term approaches to training therefore may be usefully considered. We consider specific alternatives in the final section of this article.

Organizations are both customizing the software and changing organizational business processes and structures. This would indicate that it is false to assume customizations occur only when companies are being "stubborn" and not wanting to change their organization to fit the software. Rather, both are happening, reflecting the tension discussed above between best practices embedded in the software and best practices that companies have developed based on their unique experience in the market. Moreover, there is no relationship in the survey data between customization and benefits realized and goals achieved, belying the idea that customization is inherently bad. In fact, new consultancy services are being offered that help clients decide when to tailor ES products. The market sought such expertise, and the consultancies responded with project methodologies, which take the customization of software seriously.

IMPLEMENTATION METHODOLOGIES: PLANNING VS. FLEXIBILITY

Organizational and technical changes were made both before and after implementation, and these changes exceeded project plan estimates (see Graph 17). This illustrates that it is not possible to preplan all activities. This is often not understood in project methodologies that assume it is possible to provide static guides that will direct implementation efforts. Rather, the survey results demonstrate that project teams need to be flexible and continuously negotiate through the project, changing plans and deadlines as certain project tasks take longer than anticipated, while other tasks may actually take less time. This must be expected since implementing an ES is inevitably going to involve a political process of negotiation. While it may be uncomfortable to think in terms of flexibility rather than control, it is a worthwhile shift. Hiring a person to analyze the project plans and work with a flexible time-phased approach to budgeting will be beneficial. Furthermore, we argue that it is human nature for ES users to become engaged in a system when it directly influences their sphere of work -- in other words, at go-live. While we might involve users in the requirements definition and configuration phases of ES, we should expect that they are only partially tuned into what is being suggested. After all, don't you pay more attention to car advertisements and office parking lots when you are on the market for a new automobile? It should not be surprising to find users who seemed to be on board throughout the project later complaining about the system they helped configure when it comes time for them to use it. We cannot force genuine involvement at certain intervals in order to coordinate our project plans. Rather, if we believe that engagement naturally occurs when an issue becomes salient, then isn't it time to change the project implementation story to include and encourage post-implementation modifications?

The scope of ES change involves many people in an organization and in a way that necessitates much closer collaboration than will often have existed previously. Railroading the technical and organizational changes through the project oversight structure may provide an illusion that the initiative is on track, but this is likely to be at the expense of genuine stakeholder acceptance, thereby leading to a much higher probability of negatively motivated user resistance and workarounds. In recognizing the importance of stakeholder negotiation, it is critical to recognize that consensus is unlikely to always be possible, given the different points of view present in an organization. Instead, it is likely to be important to encourage different groups to "give a little" so that each compromises on some aspect of the ES design. In this approach, the ultimate project goal is not to be "on time" or "perfect," but to deploy a system that improves what existed previously and recognize that future developments will exploit the potential of the powerful ES even more.

RECOMMENDATIONS

The message from the survey and from our previous research with companies implementing an ES is that these are complicated initiatives, and organizations need to expect delays and frustrations as they attempt to move a project forward. To do otherwise -- to take unilateral control of decision making, for example -- may result in an ES that gets deployed but then faces considerable user resistance. Instead, the results suggest that it is important to invest time and energy working with these problems, even if it means that the project timetables are revised. Such revisions should be seen as indications of long-term success, not a failure to meet a goal. While Bill's article recommends better planning and budgeting up front, we would argue that instead of having strict milestones and deadlines, iteration could usefully be built into the project methodology, thus recognizing the need for flexibility. Companies want to understand the budgetary implications of an ES project, yet the reality is that budgets are typically overspent. Allowing for a more iterative project planning process may actually encourage a more realistic ongoing assessment of the financial costs of the project if negotiations include discussion of the costs involved as well as the project rationale for a suggested change. There is no simple formula for project success, but recognizing the legitimacy of diverse stakeholder views, even when they may differ substantially from one's own, is likely to be an important factor contributing to success.

With this proviso in mind, we offer the following recommendations, noting that you will need to customize these suggestions to your own local context:

1. Persevere. Move from an acquisition to an implementation mindset that recognizes implementation as a long-term organizational change project. Reward partial deployment and encourage your employees to persevere with the more challenging aspects of the ES. Your project team members might be feeling like they have failed to create the perfect solution. Remind them that this approach is not the goal because the dynamic nature of current business environments means that what is perfect today will not be tomorrow. Rather, teach them that an ES implementation is a long-term initiative that will involve continuous adaptation and learning. If your team perseveres, it will help you to gradually exploit the functionality of this powerful type of software package. Multiple times we have been told that an ES initiative that started off well ended up making only insignificant changes in terms of how work was done, and this was attributed to the project losing momentum after go-live when users need coaxing and the software needs tweaking. The project should not end at go-live; instead, when you backfill employees to work full-time on the project, you should include post-implementation time. Companies that try to make crucial post-implementation changes to the system with only a skeleton crew struggle and thus create political storms with end users who feel their concerns are not being addressed. When team members return to preproject positions and the project central command center is shut down, the project loses momentum even though it is a time when a lot more changes need to be made.

2. Recognize. ES projects need to be planned iteratively, recognizing that there will be divergent views about what is "best." Don't stifle -- instead, look for these divergent views and focus on a "good enough" solution that meets the needs of multiple communities of practice across the firm. See users' improvisations and workarounds as a source of innovation rather than resistance. Improvisation helps exploit ES functionality and can help users to learn to exploit the technology in the post-implementation environment.

3. Customize. Tailoring your ES should no longer be frowned upon. Vanilla is good, but adding hot fudge and a cherry is all the better for some. While the costs of customization need to be considered, recognize that it can be helpful and possibly crucial to include software modifications since the so-called best practices will not always fit your unique organizational circumstances.

4. Protect. Whether market-based migrations to new releases of ES software are necessary is irrelevant. The complexity of ES makes it difficult to maintain without vendor support. Therefore, when purchasing enterprise software, it is wise to take a protectionist perspective toward your company. Consider long-term organizational goals and their commensurability with your vendor's business plan. For example, what percentage of its total business does your industry represent? How many resources is it likely to allocate to the refinement of the product you purchased? Is the vendor committed to continued development of an industry-specific product? This represents a strategic alliance between yourself, vendors, consultancies, and implementers. No longer are you the master of your own destiny. We have heard it said that buying an ES is like "getting into bed" with the vendor, but the relationship is not merely a one-night stand because you cannot go your separate ways the morning after go-live!

5. Innovate. Consider whether increased efficiency is having any impact on flexibility and innovation in the organization. Consider the idea that another wagon might be more appropriate to hop up on -- and if one isn't coming around, then maybe there is a bicycle that will get you where you are going more effectively.

6. Disseminate. Outsourcing your ES training is a mistake. Your users are your people, and you must take the time to determine the most effective way of disseminating information to them and fostering a learning environment around the ES. Some creative options include:

• Retaining project staffing and infrastructure well into the first year of ES production
• Using intranet and instant messaging as communication mediums
• Encouraging the development of communities of practice where ideas can be shared among people engaged in similar practices
• Utilizing special training teams that visit different locations and encourage broader discussion about the ES functionality once users have started to use the basics for their job
• Providing help desks with "power users" who can help out with transactions that are done so infrequently that one-time training often does not help because users forget the procedures

In sum, implementing an ES is hard work no matter how you look at it, but multiple organizations have embarked on such projects without dire consequences. Perseverance and resilience of organizational stakeholders is necessary if you are going to make an ES work within your organization. The lesson is that you need to recognize that anything worth doing is worth doing until it doesn't need to be done anymore.

ABOUT THE AUTHORS

Erica Wagner is an Assistant Professor of Information Systems at Cornell University's School of Hotel Administration. She earned her PhD from the London School of Economics and has significant practitioner experience in the fields of accounting and budgeting. Dr. Wagner's research interests focus on the ways in which complex software is "made to work" within different organizational contexts. Her research has appeared in numerous academic and applied journals including Information and Organization, Communications of the ACM, Journal of Strategic Information Systems, Journal of Applied Behavioral Science, and the Cornell Hotel and Restaurant Administration Quarterly. For more information on Dr. Wagner, visit www.people.cornell.edu/pages/elw32/index.htm.

Sue Newell is the Cammarata Professor of Management, Bentley College and Visiting Professor of Management at Royal Holloway, University of London. She has a BSc in psychology and a PhD from Cardiff University. Dr. Newell is currently the PhD Director at Bentley. She has worked previously at Aston, Birmingham, Nottingham Trent, and Warwick Universities, all in the UK. Her research focuses on understanding the relationships between innovation, knowledge, and organizational networking -- primarily from an organizational theory perspective. At Warwick, Dr. Newell was a founding member of ikon, and she continues to focus on research that explores innovation processes using knowledge and organizational networking perspectives. She is also involved in research that explores the implementation and use of packaged information systems. Her research emphasizes a critical, practice-based understanding of the social aspects of innovation, change, knowledge management, and interfirm networked relations. Dr. Newell has published over 60 journal articles in the areas of organization studies, management, and information systems as well as numerous books and book chapters.