This action might not be possible to undo. Are you sure you want to continue?
University of Bahamas Nassau, Bahamas
University of Bahamas Nassau, Bahamas
Abstract: Business process reengineering, in response to the adoption of an IT system, poses challenges in any organization, including a university. These challenges are exacerbated when the organizational structure is a strict hierarchy. Unique problems emerge in this type of organization such as total lack of user participation, lack of training in the newly deployed system, and the imposition of a software system by upper management on an unwilling user base. These software systems, which were designed to automate and re-engineer existing business processes, suffer from lack of user familiarity with the software; inadequate requirements capture by management; and lack of user buy-in. A case study of two hierarchically-structured universities, which deployed enterprise-level systems, is used to demonstrate the problems which were encountered and a possible solution. The solution is a systematic methodology of meta-processes that includes full stakeholder consultations, training, and identification of dependent sub-processes and issues. Results of these solutions include better understanding of the system for users and management, higher user buy-in, less negative repercussions for upper management, better network management, and automated replacement business processes that perform all their required functionalities.
processes and to identify dependent sub-processes is lost. This paper presents a case study of two hierarchically structured universities that recently adopted enterprise level systems. Because these universities failed to adopt a systematic methodology including user participation, problems ensued and the IT systems became ineffective. This paper proposes a real-life solution how to encourage management to adopt a suitable systematic methodology along with the benefits to them of doing so. II. Background
Business process reengineering, subsequent to the adoption of an IT system, poses a host of challenges to an organization. Some of the challenges are well known such that these processes must adapt to match the existing functionality of the IT system and that the organization must adapt its processes and culture to that of an enterprise system . In this paper, we argue that these challenges are compounded when IT systems are adopted in a strict hierarchical organization. Due to lack of user consultation and planning, management often imposes this system upon a resistant user base. Because of lack of user participation and lack of training in the new system, users are not able to use the new software system effectively so that they revert to their previous manual processes. Consequently, the amount of work required to perform the same business processes increases, rather decreases, under the new system. In addition, an opportunity to review and refine existing
In the early 1990’s, Business Process Reengineering (BPR) arose when companies tried to use Information Technology (IT) to link business processes, which spanned different departments, together in order to gain a competitive advantage . The goal of BPR was to identify the key business objectives of the organization and to reengineer the underlying business processes to meet these objectives. Instead
of modularizing business processes by strict functional boundaries, such as the “Records Department”, roles and tasks should be grouped around the main business processes regardless of functional boundaries . Although BPR is based on computer science and engineering and, consequently, has powerful arguments for its existence , the real responsibility for BPR lies in management’s strategic business vision and leadership. If an organization lacks a clear business vision that governs its internal decision-making, IT often assumes this leadership role with the subsequent responsibility for failures to transform successfully an organization through implementation of information systems . In fact, failures really lie with strategic management themselves. BPR supposedly is straightforward because it operates under the assumption that people easily adjust to fit their newly reengineered business processes . Yet, this assumption ignores the human dimension and human value in organizational change (19; 7; 15]. Usually, technology has been superimposed on existing work processes rather than adapting the work processes to take advantage of technology. Because the existing hierarchical organizational structures and rigid processes were not reconsidered before technology was implemented, investing in enterprise systems reinforces outdated procedures that effectively block rather than enable needed change. The integrated information needs of the users are ignored in favor of the old segregation of information by organizational structure. In order to achieve significant improvements through technology, organizations must change their core business processes and organizational structures that were implemented in order to fit these changes . As a result, strategic change, including business change, must take into account organizational culture [3; 4]. Although this may seem to be a simple idea, it does not reveal the tremendous underlying complexity and significance that constitutes organizational culture . In order to achieve change, there must be consensus based on the understood and shared values between employees and managers; if this consensus is lacking, a major barrier
to BPR will exist [12; 17]. IT is only effective when it helps people to achieve their goals through work; if resources are simply pumped into a system without working with people to develop its use, these resources will be wasted . In order to achieve BPR effectiveness, full stakeholder consultation followed by consensus is needed. Consultation does have many benefits, including providing employees with the feeling of “empowerment” that with their individual efforts, they can contribute to an organization’s success . They can also see the benefits of reengineering: rather than go through several tiers of management in order to complete a long, cumbersome process as they did previously, employees are able to wipe out bureaucratic delays by accessing the sources of knowledge directly and achieve the same results in minutes . If proper rethinking of processes and full user consultation is not carried out, management of people change is ineffective and BPR suffers a high failure rate [13; 2]. Management of people change is even more critical in higher education institutions where many strong interest groups pose greater resistance to change . Ford’s study of universities showed that their structure is split up into departments where information is restricted to individual academics and departments . In order for universities’ processes to be reengineered, institution-wide processes must be established and dependencies between departments identified . This reengineering of processes often involves removing outdated processes and replacing them with new efficient ones . III. Methodology
We utilized two participatory descriptive case studies  of a Middle Eastern and Caribbean university both of which had recently adopted enterprise systems and both of which were in the process of integrating their business and system processes. Various means of data collection were used such as participatory observation of users and management, interviews with management, and a questionnaire to
and interviews with users. At the Middle Eastern university, the questionnaire was carefully worded to ensure that users were aware that they were important and that they possessed a stake in the software. The questionnaire was followed up with interviews by peer users, which were less intimidating than if conducted by management. At the Caribbean university, input from stakeholders (users, students, and management) was received through interviews and participatory observation. After the data collection process was complete, the data was analysed in order to determine the degree of process improvement and user acceptance. Our initial goal was to determine whether the newly implemented enterprise system significantly improved the performance of the usual student/faculty/administration processes. However, as we investigated the impact of the system on university processes, we discovered that the introduction of the system created duplicate processes rather than reengineering existing business processes for improved performance. Our subsequent research then focused on the reasons why these duplicate processes emerged and why performance was not improved. Based on the information gathered and conclusions formed therein, formal discussions with university management were conducted. University management, alarmed at the rejection of the newly implemented system, was debating whether to retain or abandon the system. Our data gathering, analysis, and conclusions were sought in order to help them make an informed decision regarding this matter. Some differences between the two universities become apparent. IV. Case Study
exacerbated by the hierarchical nature of the university itself. Administration viewed itself as the prime leaders within the organization; they viewed it as demeaning to consult faculty or staff stakeholders when considering a software solution. Hence, they would simply implement a system that they felt served the university well, regardless of its actual outcome. In the case of the Caribbean university, huge sums were spent on an enterprise system in order to help stakeholders with their tasks. However, the faculty still relied on old manual practices such as paper attendance registers, graduation forms, and marking sheets. The Records Office, which needed other departments’ manual records to be automated in order to enable the seamless transmission of information among departments, was stymied by the manual processes still taking predominance. These manual processes had to be completed, in addition to the new processes imposed by the enterprise system. Any dependent sub-processes of a task were not identified and, hence, they were not executed when this task was performed. An example, this enterprise system enabled a department chair to re-assign a class to another lecturer. However, the sub-process of assigning the class resources to the new lecturer was not identified or performed. Hence, the new lecturer could not gain access to the class’ resources such as a class list of students. Due to poor network management, registration for each group of students, by year, was restricted to a two-hour on-line registration time slot. The registrar claimed that if all students were allowed to register at any time, the network would be overwhelmed and the server would crash. No alternative methods to this problem were sought such as load balancing in a Web farm. Because of this small time slot allocation, last year 80% of student registrations had to be done manually at the Record Office. In the case of the Middle Eastern university, the university bought an inexpensive system. The Middle Eastern university adopted an older, cheaper, and non-visual enterprise system rather than purchase a more expensive but modern system. When they bought the system, they lacked a systematic method to acquire software with their needed features and to
In a hierarchical organization, upper management often tries to force an organization to adopt software because they feel that they are implementing an ideal solution with good technology . This case study mirrors this situation. In both cases, administration adopted an IT system, without consulting staff or faculty, in order to reengineer the business processes at the university and then they tried to force their subordinates to use it. When we delved deeper into the situation, we discovered that the problem was
train users how to use them. Due to the lack of a systematic method, they were totally unaware of the features that the system offered, such as its accounting features, and consequently never used them. The Middle Eastern university suffered similar problems to that of the Caribbean university. Manual processes, which were supposed to be reengineered and automated, remained and ran in parallel with the new automated process. An example, previously student grades were manually entered by the lecturer and then these grades were given to a clerk to enter into the student’s paper record. With the new system, the lecturer still manually entered the student grades and then gave them to a clerk. The clerk, however, now entered them into the system rather than into a paper record. This new system caused additional problems. Because the lecturer could not verify the entered grade in the system as being correctly entered, this clerk could easily alter the student grade without repercussions. At present, the clerk has more leverage on the students’ final grades than the relevant faculty. In order to correct this imbalance, a meta-process again is needed to ensure that the subprocess, which enables lecturers to verify their students’ grades, is performed once a student’s grade, the main process, is entered into the system. Due to the lack of network documentation and the constant turnover of network staff, new network staff faced a steep learning curve in working with the university networks and, consequently, many avoidable errors were constantly being made. In addition, at both universities, part of the network management problem was the total absence of a database administrator even though many of the Web applications, such as registration, were directly tied to databases. Consequently, no tuning or maintenance of the databases was performed once they were installed with subsequent derogatory effects on these Web applications’ performance. We argue that software system acquisition, even after the system has been deployed, must follow a systematic methodology that includes meta-processes to handle the reengineering of business processes, network management issues, training, and identification of dependent sub-processes. Because of
the hierarchal nature of the institution, these metaprocesses must be handled in a different way than a more egalitarian institution. Although stakeholders must be involved, the management, at the same time, must be seen to be in control of this process in order to maintain their status and to ensure that priorities are set at the university rather than departmental level. The management develops a list of questions to ask the users; these questions include questions about the tasks to be performed, additional users of the system, functionalities of the system, hidden dependent sub-processes of the tasks, rationale for the users’ business processes and tasks, and network parameters that would impede the automation of these tasks. In order to bypass management pressures, these questionnaires, and any interviews, should be conducted by a member of staff. Once this feedback from the users is obtained, the selected vendor would then be responsible for filtering and categorizing the stakeholders’ feedback. The reason for the selection of the vendor for this task is their expertise with requirements. Another reason is that if administration were given this task, there would be the impression that the administration would simply remove any feedback from faculty/staff and substitute their own requirements instead. Once feedback has been received, the vendor can reexamine the business processes and reengineer them for automation, eliminate duplicate processes, and arrange for the seamless flow of information between departments. If there are any network issues that are observed to impede the automation of a business process, the network team is made aware of the issue and then is given the task to find and return a solution. The vendor also arranges for training of users in the use of the new system. Once this reengineering process is complete, management produces a refined checklist of processes to be carried out thoroughly. These checklists are then handed down to their subordinates for execution. This top-down approach is appropriate in hierarchical organizations, according to our experiences, because subordinates, in such an organization, will not do anything unless ordered to by their manager. This methodology has several advantages. Through the seeking of input from stakeholders, the level of awareness of stakeholders of the system is raised, a higher degree of “buy-in” by stakeholders is given,
hereto unknown functionalities of the system are specified, network issues are identified, the chance of user system rejection is reduced, hidden dependent sub-processes are identified, and managers are made aware of the need for training. This seeking of input helps invoke the changes needed in order for a software system to be effectively used. In certain organizational cultures, management feels that their authority is compromised if stakeholders are consulted. In order to avoid this scenario, an alternate way to gain stakeholder knowledge would be for the vendor to observe the stakeholders performing their business processes and then ask pertinent questions and take notes. From this participatory observation, stakeholder input is obtained indirectly. A neutral third party compiles user feedback, reengineers the processes, and refines the checklist. The use of this third party avoids the problems of a managementemployee split and of one strong interest group prevailing over others in the system implementation. Having management enforce the use of a checklist provides legitimacy to the system while ensuring that users use the system effectively, no dependent processes are ignored, and network management issues are identified and resolved. This methodology, in part, was tried at the Middle Eastern university. When the administrator sought our advice on whether to retain or discard the system, we told them that they should continue using the system and convinced them in order to know the requirements, they should seek input from the stakeholders through questionnaires and interviews. In order for them to know who the users are, they were advised to increase the pool of users by first consulting the known users of the system and asking them about additional users of the system. This advice was implemented. One advantage of following this advice was that the administrators discovered additional features of the system, such as finance, which they were totally unaware of. Another advantage was that the users, when consulted, were first surprised but then happy that their input would be considered; thus increasing their stake in the software system and helping to ensure its effective use. In order to convince middle-level management to implement this solution, it was imperative to
convince them that it was in their best interest to do so. In order to do so, it was necessary to convince them if they implemented this approach, there would be less chance of finger pointing at them. In general, in middle to large institutions, the top administrator become aware of IT systems only when they malfunction in a large way and the systems fail to provide the information needed by the top administrator. At first, middle-level managers would try to hide any problems with the system; only when the problems with the system become overwhelming and the systems do not deliver the information as required do the top administrator become aware of the problems. By preventing problems in the first place by adopting this methodology, these managers avoid the chance of problems in the system first emerging and then growing until the top administrator becomes aware of the problem, and they are blamed.
Business process reengineering followed by effective software use by stakeholders is a difficult task to achieve in any organization. Particular problems arise when this organization is a hierarchical one. As our case study demonstrates, often business process reengineering and effective software use is considered after the software system is deployed. In addition, problems peculiar to this type of organization manifest themselves and serve as barriers to this task. Management is anxious to maintain their status yet they are fearful of the top administrator. Management is unaware of the users’ struggle and unfamiliarity with the new system. Users are unaware that the new system is to replace their old manual processes and they are fearful to adopt any new changes without the approval of management. Our proposed solution supports this hierarchical culture, without trying to change it, and, at the same time, provides a solution for the deployed software system to function effectively even in this culture. Given the experience of these case studies, a proposed solution would be to follow a systematic software methodology tailored for acquiring and using software in a hierarchical institution. This
methodology utilizes stakeholder feedback that is refined by a third neutral party and that is incorporated into the system and into user training. The neutral party then reengineers any business processes as necessary, resolves any network issues, implements the system, and arranges user training. Management then enforces the use of a checklist for users to ensure that business processes are carried out using the system and that no dependent processes are neglected. Our experience in helping convince management to adopt this methodology is that it avoids problems and it is in management’s best interest, even in a hierarchical organization, to do so. One aspect of this methodology is that it contains stakeholder consultation but the system use practices are implemented under management control.
Hammer, M. and Champy J. Reengineering the Corporation: a manifesto for business revolution. London: Brealey, 1993.
 Heracleous, L. “Spinning a Brand New Cultural Web”, People Management, vol 2, November, 1995.  Hicks, P.J. “Re-engineering Higher Education”, Discussion paper, UMIST. Retrieved from http://www.umist.ac.uk/future/re-he.htm, 1997.  House, D., Watson, D. “Managing Change” in Warner, D., Crosthwaite, E. Human Resource Management in Higher and Further Education. Buckingham; SRHE & Open University Press, 1995.  Martinsons, M.G., Revenaugh, D.L. ‘Re-engineering is Dead; Long Live Re-engineering’, International Journal of Information Management, vol 17, no 2, 1997, pp 79-82.  Millham, Richard, and Torsti Rantapuska. "15P. Applying Organisational Learning to User Requirements Elicitation." (2010).  Rantapuska, Torsti, and Outi Ihanainen “Acquiring Information Systems through Organisational Learning”, 2nd ECIME, London, UK, 2008.  Penrod, J.I., Dolence, M.G. ‘Reengineering: A Process for Transforming Higher Education’, CAUSE: The Association for the Management of Information Technology in Higher Education, 1992.  Rich, T., Scott, C. ‘Modularization and Semesterization: ringing the changes’, Perspectives: Policy & Practice in Higher Education, vol 1, no 3, pp 70-76, 1997.  Weerakkody, Vishanth and Wendy Currie Integrating Business Process Reengineering with Information Systems Development: Issues & Implications, Berlin: SpringerVerlag, vol. 2678, 2003.  Wilmot, H, Wray-Bray E. “Process Reengineering, Information Technology, and the Transformation of Accountability: The Remaindering of Human Resources”, in W.J. Orlikowski et al (eds) Information Technology and Changes in Organizational Work, London: Chapman-Hall, 1995.  Yakovlev, Illya V. “An ERP Implementation and Business Process Reengineering Process at a Small University”, EDUCASE, no. 2, 2002.  Yin, Robert Case Study Research, Design and Methods, London: Sage Publications, 1994.
Allen, D.K., N. Fifield “Re-engineering change in higher education”, Information Research, vol. 4, no. 2, Feb, 1999. Davenport, T.H. ‘The Fad that Forgot People’, Fast Company, November, 1995. Retrieved from http://www.fastcompany.com/online/01/reengin.html.  DeLisi, P.S. ‘Lessons from the Steel Axe: Culture, Technology and Organisational Change’, Sloan Management Review, Fall, 1990, pp 83-93. Dobson, S., McNay, I. ‘Organisational Culture’ in Warner, D., Palfeyman, D. (editors). Higher Education Management The Key Elements., Buckingham: SRHE & Open University Press, 1996. Ford, P., Goodyear, P., Heseltine, R., Lewis, R., Darby, J., Graves, J., Sartorius, P., Harwood, D., King, T. Managing Change in Higher Education, Buckingham: SRHE & Open University Press, 1996. Grotevant, S. M. “Business Engineering and Process Redesign in Higher Education: Art or Science?” , EDUCASE, 1998. Geus, A. ‘The Living Company’, Harvard Business Review, March-April 1997, pp 51-59. Hammer, M. “Reengineering Work: Don’t Automate, Obliterate”, Harvard Business Review, July-August 1990, pp. 104-112.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.