CIOS often face difficulties justifying their requests for investment in information systems (IS). Clear, simple, definitive evidence that investment in IS will benefit the total organization is hard to come by, and the evidence that is available requires the kind of knowledge and training that the CIO (and perhaps his or her staff) possess but that few other managers are likely to have. Other executives, unaware of the real value of IS, quite naturally resist investing portions of the "organizational pie" in IS. They prefer to invest the money in their own departments and attribute any improved performance gained through IS to their own actions. Information Technology and its management are regarded as commodity with no unique attributes appreciated, as highlighted in Carr's controversial article, "IT Does Not Matter."6
To better understand this gap and find ways to bridge it, we followed a series of ERP operations and customizations at a large automotive supplier in the US, and came to an "amazing" conclusion: If you are not involved with operating and customizing IS, you probably do not understand the IS, and do not appreciate it, especially so if the IS operates in a faraway department. This supplier managed to overcome the problem through a two-pronged approach. The supplier had the IS managers and employees learn how to understand the operation and management of the business, and let the other managers know that the IS personnel really care for them and support their activities. Thus, the idea of a united team educating and training program emerged. The automotive supplier we studied is not an exception. Our experience in the industry indicates that the problem we found is quite common. Managers and IS experts typically know how important such joint activities are during implementation.2 But in many cases it has been a long time since they learned this at school, and routine and habit had time to settle in and overshadow this lesson. Consequently, after the implementation, a gap is created between the groups. This article discusses a project aimed at addressing this problem and its consequences for an automotive supplier and shows the importance of maintaining such joint educating and training during the ongoing maintenance of the system. This approach of an ongoing shared training of managers and IS experts is not expensive and can be easily conducted by many companies.
A key to the success of this project was the realization that creating intrinsic user motivation is crucial but cannot be done through traditional training alone. The success of this joint educating and training project reiterates the need to increase the intrinsic motivation and commitment among IS users, and it shows the viability of doing so through active partnerships based on education and the creation of teams and their resulting social networks with the IS experts.8 The case study also highlights the importance of creating a sense of ownership over the IS among the users through interaction and the effect this has on increasing the value of the IS to the company.1
The automotive supplier is a $2 billion company with seven plants. It has a central ERP group at headquarters consisting of a manager and several programmer-analysts (ERP experts), each of whom is in charge of ERP package operation and customization at one or more of these plants. But this management system was faulty. As the CIO stated, "We had various manufacturing facilities that had different levels of technology and levels of technology use." There was a disparity in the degree managers and users in different plants utilized the ERP some of the plants were moving quickly ahead, while others hardly took advantage of the ERP. Part of the problem was attitudinal, with some plants projecting "we just get things done, we don't need a computer to tell us what to do," while other plants relied heavily on the ERP and gained value from it.
In theory, such discrepancy could be the result of different technology maturity levels because of the different evolution of the different plants.11 Indeed, as the CIO said, this was part of the problem. But this was not the whole story either.
A common by-product of the separation among company units along functional lines is a strengthening of the "us versus them" perception employees have about other departments.9 This typical response to grouping increases the negative bias against the other groups while artificially inflating a positive bias towards one's own perceived group.12 Simply artificially grouping people into two groups will create such bias.5 This is precisely what happens in many companies where IS is managed by a dedicated team that does not mingle closely with the users.7 It is almost inevitable that when there is a strong departmental classification, if something goes wrong it will be blamed on the other department, and if something goes right the other department will receive less credit than it deserves.4
Needless to say, this bias does not contribute to the successful implementation of an IS or to the dissemination of the knowledge needed to utilize it. Social integration is critical: if the IS team does not interact enough with the users, their training will suffer and the users will have more difficulty understanding and gaining the most out of the IS.8 It is also a matter of group psychology and the psychological barrier it creates that is often a major reason for underutilization of an IS.7 During the early years of IS application development such social distance might have been tolerated because the technology was so complex and the users were so removed from it that programmers could have been regarded as specialists, but this does not apply today in a world where users are acquainted with technology.3
This psychological barrier is unfortunately common in many companies, precisely because the IS experts concentrate on doing what they are hired to do, to address user requests as specified by the users. As we found in this automotive supplier, the primary reason for the underutilization of the ERP in many of the plants was that the ERP experts spent most of their time trying to be as responsive as possible to unavoidable problems and new requests brought to them by line managers and users at the plants. This dedication has a cost. It deprives the ERP experts of time that could have been spent developing relationships with the line managers and users, relationships which could have given the experts the status to verify the actual need and business value of the requests. This dedication might also be detrimental to the successful use of an IS, but this type of dedication is quite rational: It is about letting the non IS managers decide what they need, because they know best, and letting the IS experts decide how to develop it, because that is their expertise. The result is a nice division of labor, with no one questioning anyone else. But this approach is outdated.
The CIO was aware of the gap between the ERP experts, on the one hand, and the managers and other users, on the other. This gap created a "silo" problem in which the ERP experts saw the technical side of things and the managers and users saw the business side of things, but neither side was sufficiently aware of how the other saw things. The CIO suspected this phenomenon could have been created because of the level of maturity in the use of the various IS and differences in culture, both based on the way the company had evolved. The automotive supplier was composed of several companies and several production lines and plants. These different units had the ability to be somewhat autonomous, and that autonomy, the CIO suspected, may have contributed to the conscious or unconscious resistance some managers and users had to the standardization that the IS division wanted to enforce.
Another reason for the miscommunication and misunderstanding between the two groups was that the ERP experts were too busy fighting fires. They tried to be as responsive as possible to problems and requests raised by the users at the various plants. As a result, the ERP experts did not have the time and ability to conduct detailed feasibility studies about the added value of each request and its impact on the plant and the entire company. They also did not have adequate knowledge of the business aspects and cost/ benefit analysis. Moreover, some of the ERP experts had not even met all the managers in the plants they supported. Hence, some of the ERP experts felt uncomfortable in dealing with some of the managers and tried to avoid it. On the other hand, some users had not had an opportunity to express their needs either because the ERP experts had no time, or because the users did not know what to ask for. As a result, sometimes users did not know about options that were available to them in the current IS. Consequently, some users conducted manual calculations when the IS could have done it automatically.
The Company's CIO realized that something had to be done. "The IS department must understand the business and the perception of the technology that the business has," he said. It was necessary to "ensure that the relationship of our department and the business were based upon the perception and needs of the business, not the technical view" and "We wanted to ensure that the department understood that the business was empowered to change the technology, rather than force the business to use the technology as it is given to them. Our department must understand this thought process, and assist the business in achieving their objectives." Addressing this was an imperative. In other settings7 the unintended result of the division of responsibilities was an enforcing of the silo atmosphere and mutual lack of appreciation with IS experts frustrated because their endeavors were not appreciated, and users, unaware of the pressure the ERP experts were under with the constant changes, not satisfied with the pace of adaptations.
The CIO contacted an outside expert with over 30 years of experience as an IS professional, CIO, and consultant. The outside expert also had extensive experience in teaching Management of IS in universities. It was important that the project leader provide the ERP experts and the managers and users with a new vision, and that he be unbiased. And so, a training project was designed.
The goal of the project was threefold. First, the project aimed to train the ERP experts how to interact with the managers and other users at the plants, to understand the business processes and activities, the customers, suppliers, performance measures, individuals roles, activities, and to support all of these by the IS. Second, the project aimed to improve users' and managers' understanding and appreciation of the IS, and to encourage them to use the ERP to support their individual and collective activities and performance. Finally, the project intended to evaluate the use of the ERP by the plants and identify opportunities to increase the benefit from using it.
These three goals were addressed together based on the methodology described in Ragowsky et al.10 Initially, to help the ERP experts and the managers understand each other, an exercise was conducted to identify the costs of producing the product. These costs were classified by components, such as cost of raw material as a percentage of the total product cost, costs of labor, machinery, and others as a percentage of the total cost of the product. Having done this, it was then possible to evaluate each IS application or request based on its contribution to performance measures, such as overall cost reduction. Typically, the highest return on investment is gained from IS support in areas with high production costs, shortening production and lead time and increasing sales.
The first phase in this project was to train the ERP experts in the ways an IS can solve business problems and address value-added opportunities. This step included value chain theory, critical success factors (CSF) and the way to support them through an IS, and IS business practices. It also included teaching experts how to communicate with managers and end users in analyzing business problems and identifying problems that can be solved with an IS. The second phase of the project involved teaching the non-IS managers and users about IS applications in general, and the way an IS can help them individually and the organization as a whole. The third phase of the project focused on working together with the two groups and training them to communicate with each other and so improve their mutual understanding of each other to achieve better application of the IS for their individual benefit and for the organization as a whole.
After the course, the ERP experts, along with the training project leader, visited each of the plants. At the beginning of each plant visit, the training project leader made a presentation to the plant managers about the nature of the training project, IS applications in general, the difference between transaction processing, decision support and executive information systems, and the role of each. In addition, the training project manager explained how IS applications can improve both individual and organizational performance.
Along with an ERP expert, the training project manager then met with each manager individually to have them describe their job, responsibilities, and decision-making processes. The managers then discussed the use or non-use of IS applications to support individual and plant activities as well as their perception of their specific IS. The project team with the managers then identified ways to utilize the IS to better support each manager's activities, decision support processes, and individual performance. Throughout this process the ERP experts made it a point to show their interest in these managers, to show them that they sincerely wanted to understand the roles, activities and needs of the managers, and that they planned to help them. This was a very important element for gaining the managers' trust. As was stated by the CIO, "in order to motivate the managers to better use the IS, you have to gain their trust, help them, educate them and let them learn, see, and move forward."
To encourage the managers to participate and support the IS, the training project leader asked each manager how he/she was evaluated for merit purposes. While most of the managers were surprised by the question, they were forthcoming about it after the training project leader told them that if the IS experts understood the performance measures these managers were evaluated on, the IS experts might be able to find ways to support the managers' performance on these measures by using the IS. If so, the managers will be better appreciated and the plant will perform better. The training project manager did try to accommodate these measures, although some could not be accommodated. As a result, these managers were more supportive of the IS in general.
Based on the interviews, the ERP experts, with the assistance of the training project leader, prepared a report for each plant describing plant activities, measures for success, critical success factors, recommendations for improved IS usage and its benefits. Another report was presented to the CIO by the training project leader with recommendations on potential improvements in operating and managing the IS applications across the company and recommended changes to the IS division processes.
Following the project, the CIO made several procedural changes, including setting up a priority project list to track all of the projects and set priorities. The responsibility for project reporting in each of the plants was also changed so that the plant manager and not the ERP expert reports when a project is completed. While this may seem a small change, it did create an effective partnership in action between the IS experts and the users1, 8 and its impact was huge. As the CIO put it,
"Now what is reported on is what the plants see, not what IS people say they did. What we thought was a high priority suddenly became a low priority to the plant. What we thought were their low priorities suddenly became their high priorities. That dramatically changed what we worked on and how we worked on it. When the plants saw something completed and closed, they were the ones that judged it was closed, not us. Pushing that onto their side gave them ammunition to say I control the project list; you're not going to tell me what you're doing, when you're doing it, and that you're done with it, I'll be the judge of that."
Another major benefit achieved through this training project was better and mutual appreciation appreciation by the managers and users that the IS department was trying to improve and be proactive and appreciation by frustrated ERP experts that their work was finally being understood and appreciated.
The tangible benefit was a cost saving of over $200,000 through identifying redundant and duplicate IS projects. The CIO summarized the project outcome by stating,
"Initially the project was perceived as a training exercise. As the project materialized, most business managers, and several key IS personnel understood the concepts and the reasons behind the project. Our company gained the knowledge and understanding of the role IS play in the business. By showing the actual situations where technology is perceived differently between the business and the department, we were able to align our overall objectives to address these perceptions. The cultural gap between the technical world and the business world was lessened because of our project. We have re-organized some positions, and established stronger relationships with our key business personnel. These relationships have proven to be invaluable to changing the actions and the perceptions from both the business and the IS department. We also gained a lot of trust from managers and users, and we learned how to make our IS services more beneficial for the different users. The project allowed us to see these differences and make these changes."
Silos might seem inevitable because of the type of work being done, but they create unnecessary misunderstandings and bias. Mutual education is one way of reducing this bias. This is especially pertinent in the case of ERP because technology should not be forced on a business lest support for future projects be hurt. As the CIO put it:
"[I]n order to motivate the managers to better use the IS, you have to gain the trust, help them, educate them and let them learn, see, and move forward."
The idea of educating IS experts about the business side of things and managers about IS in order to bridge the gap between IS experts and the other managers has been around for a long time and is extensively discussed in the literature.1, 2, 8 Nevertheless, many companies still face this problem. As we discovered, this may be the result of habit settling in and resulting in each manager optimizing the part of the system each is in charge of without seeing the overall picture. This paper presents one solution: joint educating and training sessions to reinvigorate mutual understanding and doing so not only during implementation but throughout the systems' lifetime. A key to the success of this project was to go beyond education in a formal course or presentations to create an interaction between the two groups, ERP experts and the managers and users, through the guided mentoring and moderation of an unbiased external training project leader. This interaction was crucial in making the project successful.
The CIO recommends this project to other companies. He said:
"It is a very worthwhile concept to undertake a cultural analysis to understand the perception differences between the IS department and the business it supports. Technology must not be forced upon the business, and if the perception is such, the relationship for future projects and support is diminished. This project forced us to see exact issues and how their perceptions dictated the successful resolution. I highly recommend companies assess their support staff and the business perception to determine the gap and try to minimize through training."
1. Avital M., and Vandenbosch, B. Ownership interaction: A key ingredient of information technology performance. Sprouts: Working Papers on Information Environments, Systems and Organizations, 2, 1 (2002), 1632, http://sprouts.case.edu/2002/020102.pdf.
2. Barki H., and Hartwick, J. Interpersonal conflict and its management in information system development. MIS Quarterly 25, 2, (2001), 195228.
3. Bassellier, G., Benbasat, I., and Horner, R. B. The influence of business managers' IT competence on championing IT. Information Systems Research 14, 4, (2003), 317336.
4. Brown, J. S., and Duguid, P. Organizational learning and communities-of-practice: Toward a unified view of working, learning, and innovation. 1991, Xerox PARC; http://www.parc.xerox.com/ops/members/brown/papers/orglearning.html
5. Brown, R. Tajfel's contribution to the reduction of intergroup conflict. W.P. Robinson, ed. Social Groups and Identities: Developing the Legacy of Henri Tajfel. Butterworth-Heinemann, U.K. 1996, 69190.
6. Carr, N. G. IT doesn't matter. Harvard Business Review 81, 5, (2003), 4149.
7. Gefen, D., and Ridings, C. IT acceptance: Managing user - IT group boundaries," The DATA BASE for Advances in Information Systems 34, 3, (2003), 2540.
8. Henderson, J. C. Plugging into strategic partnerships: The critical IS connection. Sloan Management Review 31, 3, (1990), 718.
9. Hogg, M. A., and Terry, D. J. Social identity and self-categorization processes in organizational contexts. Academy of Management Review 25, 1, (2000). 121140.
10. Ragowsky, A., Stern, M., and Adams, D. Relating benefits from using IS to organizational characteristics: Comparing results from two countries. Journal of Management Information Systems 16, 4, (2000), 175194.
11. Rogers, E. M. Diffusion of Innovations, Free Press, New York, NY, 1962.
12. Tajfel, H. Experiments in Intergroup Discrimination. Scientific American 223, 5, (1970), 96102.
©2009 ACM 0001-0782/09/0200 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2009 ACM, Inc.