Republic Polytechnic Case Study - Assignment Example

Republic Polytechnic Case Study SECTION A Introduction Enterprise Systems (ES) have found much use in a wide range of organizations. Also referred to as Enterprise Resource Planning (ERP) systems, they are defined as integrated computer application packages that support operation processes, data flow and storage within organizations (Davenport 2005, pp. 2). The Enterprise System established at Republic Polytechnic (RP) to drive their problem-based learning pedagogy provides a case example that can be used to study the concept of ERPs in terms the phases involved in its implementation (Sathish and Pan 2008). It can also be used in knowledge sharing strategies adopted to enhance implementation of the ERP, the implications of heavy customization and finally, the strategic recommendations to counter problems arising from such ES customization. 1. The Main Phases of Republic Polytechnic’s ERP Implementation Implementation of an ERP in any organization involves a life cycle from the decision to adopt it to successful roll out, with discernible implementation phases as characterized by the key stakeholders, typical activities, associated challenges and outcomes. Four broad phases can be discerned based on this framework. They are planning, configuration, testing and actual implementation (Kumar, Maheshwari and Kumar 2003, pp. 795). Other authors present the phases as involving planning, implementation, stabilization and improvement (Markus and Tanis 2000, pp.173-207: Shanks et al. 2000, pp. 2). In the case of Republic Polytechnic’s ERP, the latter framework is seen in action thus forming this paper’s line of discussion. The first stage that was undertaken in RP’s implementation of the ERP is planning. RP needed an Enterprise System that was able to support two considerations. These include their problem-based learning pedagogy and their commitment to an IT strategy that would render the campus paperless for faster, efficient and cost-effective processes. RP set out on an outsourcing path for the vendor of an enterprise-wide e-learning management system that would provide a package which could suit RP’s mission and strategic direction. All relevant stakeholders were involved in finding such a vendor, flexible enough to allow for the heavy customization that was necessary for RP’s strategy, finally leading to settling on Wizlearn Pte Limited and their Academic Version 7 package. Post-purchase tailoring was the next step aimed at customizing the vendor’s product to RP’s needs in the system to be rolled out dubbed LEO (Learning Environment Online). This step involved two representatives from RP. These are OAA (Officer of Academic Affairs) and OIS (Officer of Information Systems) and an external IS team from the vendor all of whom liaised together and held discussions that finally resulted in a heavily customized product plan ready to be rolled out. The next phase after the planning part was actual implementation of the settled upon system, done a few weeks before the opening of the school term. The system that was rolled out provided an optimum system for RP and her staff although it was not exactly like they had envisioned as it had not accommodated all their views. Stabilization was the next phase for the system. Although the roll out had determined that there would be no need for training of RP staff, it was still necessary to provide basic training on the core features of the LEO. In a similar fashion, the students were trained on a basic general IT course and then given a few lessons on the core features of the LEO by the facilitators. The last phase of RP’s implementation of their ERP was improvement. This involved addition of the features that had been suggested in the planning stage but had been left out in implementation. More improvements on the ERP were based on suggestions from three sources; the top management, the facilitators and the development team itself, with additional suggestions being drawn from the students. The LEO manager determined which improvements would be undertaken. Such changes had to be accompanied by training end-users on how to use them. RP then developed modalities on working with the external vendors, and ultimately, changes were made to how the entire system was managed. 2. Knowledge-Sharing Strategies During Implementation of the ERP Vandaie (2008, pp. 920-926) explores the importance of knowledge sharing in the successful implementation of an ERP, and argues that the knowledge does not reside within one group of individuals involved in the roll out but is distributed among all the stakeholders including those that will use the system. All the phases of the implementation of an ERP therefore necessitate that the views of all those involved are taken into consideration. Jones and Price (2005, pp. 209-212) also appreciates the importance of knowledge sharing especially when considering that ERP’s require more knowledge in implementation and use as compared to traditional systems. Leknes and Munkvold (2005, pp. 1-2) state that successful implementation of an ERP is dependent on the instituted Knowledge Management (KM) strategy, which is the management of activities and processes that enhance leverage of individual and collective knowledge. Besides a formal KM system, informal communication also plays an important role in any organizational processes (Kraut et al. 2002, pp. 7). In the case of RP, the knowledge sharing strategies utilized will be analyzed in terms of the phases of implementation. To begin with, the planning phase involved a lot of information exchange in deliberating on various activities including the pedagogy, IT strategy, choice of vendor and customization of the learning system. Selection of the vendor involved presentations in which not only the D-OAA attended but also other top management staff, internal IS (Information Systems) staff and facilitators. After the presentations, we can see knowledge sharing taking place as feedback was sought from the parties that attended and used to guide the top management in deciding whether the products on offer were in sync with RP’s strategic direction. After selection of the vendor, the LEO manager liaised with the D-OAA and other staff to understand the institution’s pedagogy and what had transpired before his position was established. The manager also sought the input of various stakeholders so as to ensure that their different requirements and needs were considered in customization, and then relayed this to the external IS from the vendor. A similar pattern was followed during the implementation phase. The stabilization phase is one that involved a lot of knowledge sharing as the system was now being made operational to end-users. The facilitators had to undergo a basic training course to familiarize themselves with the features of LEO. We can see elements of Markus’ knowledge reuse theory here, where a formal approach is used to bridge the knowledge gap between the facilitators and the IS staff (Markus 2001, 57-93). Informal communication played a key role in knowledge sharing among the facilitators as they engaged in peer-learning, confirming the importance that Kummer and Carstens (2003, pp. 20) attach to the role of informal knowledge sharing. The facilitators could approach the development team directly for help on the LEO system or learn from amongst themselves in an expert-seeking approach as put forward by Markus (2001, 57-93). Another strategy adopted for knowledge sharing amongst facilitators was through establishment of supplementary online resources through such as FAQ sections through which the facilitators could access screen shots and movie clips to aid in understanding the every-day steps of using LEO. The first batch of students is another set of individuals that required the knowledge to use the rolled out LEO. Since the system was considered straightforward enough, the students only underwent a basic general IT training course on how IT was to be used in the institution. More knowledge for the students was delivered through the facilitators who were charged with the responsibility of guiding the students through the important features of LEO during the first few classes of the term. The next phase under which the knowledge sharing strategies adopted in implementation of the ERP in RP can be observed was the improvement phase. This was particularly important as it was the main way to get suggestions for improvement and also the main way to make the end-users adjust to any changes implemented. The ideas for improvement given to the development team were from three sources; the top management, the facilitators and the students. The strategy used by the top management to relay their suggestions was at times consultative, seeking feedback before making suggestions for changes in the LEO system. In other occasions, the top management’s suggestions were directives that had to be implemented without consultation with the facilitators. The facilitators were in a strong point to offer suggestions on the functionality of the system since they used it daily. Facilitators could discuss their suggestions with their colleagues and direct superiors before making their suggestions so as to give such suggestions more weight. A formal strategy to collect information from the facilitators was adopted. Contribution of suggestions through the formal online system referred to as the Staff Suggestion Scheme (SSS) was used in the annual appraisal of the staff and furthermore they were required to make a minimum of five suggestions annually. To motivate them to be active in contribution of suggestions, $2 were offered for each contribution made through the SSS. Further knowledge sharing was achieved through web portals to collect feedback from the facilitators and biannual departmental staff sharing sessions. The LEO development team also contributed to the knowledge sharing with the facilitators through organizing ad hoc committees to appraise the features of the LEO. Besides all these formal strategies for knowledge sharing, informal channels were also set up through which suggestions could be shared via tools such as Internet Messenger and email. The students’ contribution to knowledge sharing also followed both formal and informal channels. The formal strategy entailed a suggestion scheme portal in the LEO, and other departmental portals through which feedback was collected from students on the LEO. In other occasions the OIS sought students’ views through direct random face-to-face sessions. The students also had formal options of making suggestions IT help desk. Informal channels included email and web Messenger suggestions on a personal level to the staff. The development team was also a source of suggestions and information especially on technical issues such as feedback on removal of bugs and correction of flaws in the LEO system to optimize it properly for organizational and individual requirements. Such suggestions were the result of the development team gradually understanding the changes that were affecting the organization from the implemented package. The formal flow of communication arising from feedback collected was first through the Deputy Principal who would then route it to the relevant targets. This strategy was important in that it kept the Deputy in the know about the developments in the system, and also gave weight to the suggestions from junior staff that may otherwise have been ignored by the development team. From the deputy, the next stop was at the LEO manager who then decided which suggestions would be implemented. After the suggestions had been implemented, relevant training was undertaken to spread the knowledge formally, besides the important role played by informal peer exchange of knowledge and expert-seeking novice approach observed among both the facilitators and the students. 3. A.) Professional Comments on Customization of RP’s Leo There is undeniable evidence that RP undertook a heavily customized ERP system for their LEO which was justified by their two basic strategies; they based their education on a problem-based learning pedagogy which was non-traditional and would require considerable changes in the ES system implemented. They also set out to go paperless hence increasing the need for customization, and the two factors resulted in heavy customization of the LEO. During the planning phase (selection of the vendor), RP found that most of the presentations were unsatisfactory since they were not close to what the institution’s mission was, and after implementation of the LEO it was observed that the system did not meet the visions of the staff and top management. More changes based on contributed suggestions were added to the already much customized LEO during the improvements phase of the implementation. To begin with, the decision to customize an ERP is understandable since each organization implementing it is unique in its operations, culture and other considerations. Davis (2005, pp. 250) argues that customization is necessary due to a number of reasons; first, non-customized ERPs may be accompanied by strategic misalignments, where it has been shown that about 20% of an organization’s processes cannot run optimally on an non-customized ERP. Generic ERPs miss the dynamic simplifications and complexities of an organization’s activities. Besides, certain gaps are bound to be realized when an ERP is implemented without customization, and customization is also a sure way to enhance uptake of the ERP system by the staff since it is made familiar to them. However, all these considerations and advantages are in terms of minimal and necessary customization. Heavy customization is accompanied by risks, including but not limited to heavy costs, complications and continuous bugs and flaws which may even lead to a total systems crash. Besides these, there is also the problem of inability to adjust to newer versions of products by the vendor. Basing on this insight, Republic Polytechnic has not made the right decision in the heavy customization of their package. B.) Potential Risk Perhaps the biggest risk that the top management at RP should be aware of is one that arises from the heavy customization of the LEO system. The problem here is the fact that vendors do not traditionally support customizations during production of later versions of the software (Davis 2005, pp. 250; Garg 2010, 41). The reason behind this is the huge numbers of clients that such vendors serve which makes it difficult for them to align future upgrades to customizations from one client. The implication of this is that the painstakingly long and involving steps of customization may need to be repeated each time there is a software upgrade by the vendor, a scenario which is further hammered home by the rate at which technology evolves. Elements of this consequence are already appearing in the case of RP where the management is now faced by the dilemma of whether to upgrade to the new version being offered by the vendor- which would be made difficult by the heavy customization already undertaken that make LEO very different from what was offered originally by the vendor. Sticking to their old version leaves RP using a patchwork of a system that needs streamlining and effectively prevents the institution from moving forward with new technology. It is therefore obvious that this is one of the greatest risks currently facing RP’s LEO. C.) Strategic Recommendation The good news is that there is a way out to effectively preempt such a scenario. The strategy involved in doing this is attractive since it does not essentially involve a radical shift from RP’s strategic direction and instead dwells on an alternative approach to pursuing the same strategy. The recommended strategy is based on three approaches that first necessitate a critical evaluation of the processes involved in pursuing the organization’s mission; in this case the problem-based learning and paperless IT strategy. The first approach is informed by the fact that while an organization’s processes may appear to be very unique, they may not necessarily warrant heavy customization of the ERP system. This calls for shift of efforts from adjusting the ERP system to suit the organization’s processes to instead aligning the processes to the existing features of the ERP. This means that RP should quit transforming the LEO to meet organizational and individual needs and instead focus their efforts to how their processes can be managed and modified so that they are optimally functional with the existing features of the LEO. The problem-based pedagogy will now be pursued without having to make heavy changes on the ES adopted. The second approach also requires that an intensive and extensive evaluation of RP’s processes be accomplished. After this, the changes that need to be made will be based on simple configuration shifts rather than complete code rewrites which are responsible for the great difference between the original vendor’s product and RP’s current LEO. The result will be customization that is only far-reaching in terms of usability but not in terms of basic structure, hence software upgrades can be implemented since the ERP remains recognizable to the vendor. Lastly, RP needs to analyze the changes they have made in terms of their purpose. Davis (2005, pp. 250) identifies two classifications of the customizations that an organization makes; strategic and consistency. Strategic customizations are those that are undertaken to essentially help achieve a particular strategic goal of the organization. However, consistency customizations accompany an organization’s efforts towards strategic customization albeit sometimes obliviously. An organization may or may not notice that they have undertaken some of the customizations on the ERP so as to replicate the feel of their business or their “organizational status quo” (251). An example of this is making codes to include an organization’s way of reporting or communication in terms of specific headers and footers instead of using the product’s system. Such customizations are not strategic, but contribute to the heavy customization that an institution such as RP may have undertaken especially considering the emphasis placed on contributions from all stakeholders about improvements to the LEO. Consistency customization should therefore be limited. Conclusion The phases of planning, actual implementation, stabilization and improvement are directly discernible from RP’s implementation of an ERP system. A formal strategy of knowledge sharing backed by informal approaches enhanced implementation of the ERP throughout all its phases. The heavy customization undertaken by RP is ill-advised, and poses potential risks including inability to take advantage of software upgrades from the original vendor. A solution to this is to adjust their processes to suit the ERP, undertake customizations that do not involve coding changes, and finally, limit consistency customizations. References Davenport, TH 2000, Mission critical: Realizing the promise of enterprise systems, Harvard, USA. Davis, A 2005, ‘ERP customization impacts on strategic alignment and system agility’, Southern Association of Information Systems, pp. 249-255. Garg, P 2010, ‘Critical failure factors for enterprise resource planning implementations in Indian retail organizations: An exploratory study’, Journal of Information Technology Impact, vol. 10, no. 1, pp. 35-44. Jones, MC & Price, RL 2005, Organizational knowledge sharing in ERP implementation: Lessons from industry, IDEA Group Publishing, USA. Kumar, V, Maheshwari, B & Kumar, U 2003, ‘An investigation of critical management issues in ERP implementation: Empirical evidence from Canadian organizations’, Technovation, vol. 23, pp. 793–807. Kummer, N & Carstens, C 2003, Formal and informal channels of communication, viewed 22 October 2011, . Kraut, RE, Fish, RS, Root, RW & Chalfonte, BL 2002, Informal communication in organizations: Form, function, and technology, SAGE, Beverly Hills. Leknes, J & Munkvold, BJ 2005, The role of knowledge management in ERP implementation: A case study in Aker Kvaerner, Agder University College, viewed 22 October 2011, . Markus, ML & Tanis, C 2000, ‘The Enterprise systems experience- From adoption to success’, Pinnaflex Educational Resources, 173-207. Markus, ML 2001, ‘Towards a theory of knowledge reuse: Types of knowledge reuse situations and factors in reuse success’, Journal of Management Information Systems, vol. 18, no. 1, pp. 57-93. Sathish, S & Pan, S 2008, ‘Republic Polytechnic: Facilitating feature-function-stakeholder fit in enterprise system implementation’, Asian IT Case Series, no. ES – 001. Shanks, G, Parr, A, Corbitt, B, Thenasankit, P & Seddon, P 2000, Differences in critical success factors in ERP systems implementation in Australia and china: A cultural analysis, University of Melbourne, Australia. Vandaie, R 2008, ‘The role of organizational knowledge management in successful ERP implementation projects’, Journal of Knowledge-Based Systems vol. 21, pp. 920-926. Read More