Two Methodologies for Structured Organizational Change: Lessons from the University of British Columbia

The University of British Columbia (UBC) has experienced tremendous growth since its establishment in 1917, but it has become clear that some of its business practices have needed modification to meet with new demands of expansion and technological change. In addition to ongoing renewal efforts, UBC has successfully employed structured organizational change methodologies, including Business Process Redesign and Process Streamlining. This article gives an overview of our experience with structured change methodologies. Process Streamlining and Business Process Redesign Hammer and Stanton (1995) define Business Process Redesign (BPR) as the fundamental rethinking and radical redesign of business processes to bring about dramatic improvements in The key to BPR methodology lies in three defining words: fundamental, radical, and dramatic. Redesign, or reengineering, by definition, is not glorified downsizing, job restructuring, reorganization, automation, or even a traditional business project. Rather, it deals with fundamental questions about why we do what we do, and focuses not on what is, but what should be. It is about reinventing, not improving, enhancing, or modifying. The optimum outcome of reengineering is found in quantum leaps in It is essential to discard old ways and introduce a totally new approach (Hammer and Champy 1993). Though prospect of dramatic and radical change is often daunting, BPR methodology is designed not just to change, but to dramatically improve processes by reorganizing and restructuring how tasks are combined and completed. Redesign of processes naturally leads to further improvement within rest of organization. Process Streamlining (PS) may also result in dramatic changes and improvements in performance. Assessing which methodology is best to apply in a given situation is not always easy, so it helps to understand differences between a BPR and a PS project. The degree of radical change expected and timeline for implementation are two distinguishing features, as exemplified in Table 1. Both methodologies rely on a Case for document that is developed by a planning body before team begins its work. A key feature of case for Action is careful articulation of desired end result, i.e., in very specific terms, what it is that team is set out to accomplish. The case for Action also specifies scope of project and identifies any particular constraints, such as legislation that is not easily changed or a deadline that absolutely cannot be avoided. The importance of case for Action should not be underestimated, as a team will refer to this document repeatedly as they undertake their work. One other critical element for success is a commitment from senior management to accept team's solutions as long as they fall within any specified constraints and work towards a satisfactory end result. This commitment empowers team members to explore most creative solutions and set aside preconceptions of what would likely be acceptable to senior management. UBC's Student Information Management Plan BPR Project Summary In 2000, Enrollment Services sought to improve its general operations, and focused its attention on interactions with new and prospective students. Providing excellent service to students is a key goal for UBC-mentioned both in V-P Students Strategic Plan and in Trek 2010, University's Strategic Plan. Despite a very strong commitment to excellent service, staff members often experienced frustration at being unable to serve increasing numbers of students-some of whom needed help to navigate complex processes and systems-because of inadequate resources. To improve our processes and service, we applied BPR principles in order to make radical changes in way we recruited and admitted undergraduate students. The project, known as Student Information Management Plan (SIMPL), is described below. …

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.