Analysis of the Company ASIS - Case Study Example

Name: Number: EXAMINATION ISYS 2396: ENTERPISE SYSTEMS Section B SEMESTER 1, 2013 Date: Section B: ASIS is an energy utility company that provides household customers with a “one-stop” convenient service based on its integrated customer service as well as a consolidated billing approach that combines water, electricity, gas, wastewater and refuse collection under a single bill and account management. It upgraded its billing and customer management system successfully using SAP to consolidate utilities billing for businesses and households. However, upgrading of the system experienced various business and technical challenges which led to adoption of various strategies to ensure successful implementation at different stages. 1.0 Business and technical challenges 1.1 Blueprint In this stage, one of the challenges encountered during the business process definitions (BPDs) is the intense relationship between the consultants and the users (Gibson, Holland, & Light, 1999). This has also been referred to as “getting a meeting of minds”. The users were disappointed because they felt that the consultants lacked a good understanding of their detailed business process. This is because some consultants had challenges in explaining the logic and concepts of the system to the users. For instance, as explained by a staff in top management, the staff wondered why consultants can’t get it right while consultants wondered why the users cannot understand. This was based on lack of knowledge and experience by consultants in supporting the project team. This further resulted to negative feedback to the working committee from the users. In addition, each party was given a task of drafting their perspective requirements leading to lack of coordination between parties. Another challenge in this stage was during the evaluation of the scope of BPDs which entailed the project team. In carrying out this task, there was much reliance on exchange of documents as well as email conversations by the consultants and users instead of face-to-face discussions. This led to creation of a bottleneck in blueprint finalisation. For instance, during discussions, the consultants took notes and then prepared documentation. However, after this sending the documents to users was done by mail; the users reviewed the documents and sent the back through mail; and finally, the consultant made revisions and sent back the documents through mail. After BPDs completion, the team also realised that BPD items far exceeded the contractual obligations of the consultants. For instance, the projected number of interfaces, forms, conversions, enhancements and reports was about 200 but the final tally gave about 700. 1.2 System Development After the approval of functional designs (FDs), the consultants developed Enterprise Business System (EBS) while on the other hand; the internal staff customised the re-use items in order to retrofit into EBS. As a result, this led to a creation of situation where there was little time for internal IT staff to monitor what was developed by the consultants (Gibson, Holland, & Light, 1999). This is because there was no plans for incorporation of re-use items at the beginning of the project. This led to pulling back of the internal staff from their proposed involvement and responsibilities in the project team in order to put more focus on implementation of re-use items. As a result, it created inefficiencies because the internal staffs were too busy and could only point out mistakes that required rectification during later stages of development when they had time for assessing EBS. For instance, they were not fully involved in new developments and if there was a chance, the problems would have been spotted at the right time. During the implementation of the system, they experienced challenges where some parts of the screens and interfaces were not ready physically during the training sessions. There was a challenge of a string of miscommunication during development between the project team and the system integrator developers (Gibson, Holland, & Light, 1999). The system integrator sent FDs to developers who returned to the team, the finished programs. But the issues of miscommunication between the two sides resulted to a protracted process of development although different parties usually possess different views in regard to the root of the problem (Martin, 1998). For instance, a consulted a miscommunication problem working with a team where there are communications problems about specifications in regard to “A” instead of “A- prime”. The accuracy of data was also a key problem where it was noted that there was a lot of migration of data and based on research from the previous projects. In addition, accuracy and reconciliation of data that is transported over represent a key factor to success. Thus, the accuracy of the data was mostly brought about by lack of fully involvement. Finally, there was also evidence in regard to communication errors. This was identified during data conversion exercises. This led to delays in the project. 1.3 System validation There was a presentation of an interesting challenge due to heavy users’ involvement during UAT. The heavy involvement led to declining of the confidence of the user, in particular, when they initially encountered errors in the system during the first cycle of UAT. Based on their previous experiences, the users used to test a system that was fully developed before being rolled-out (Martin, 1998). However, in this phase, there was a common encounter of bugs that were yet to be resolved from the first test cycle. To the users, this was a different thing and they were not prepared and their initial misgivings in regard to the system upgrading surfaced. However, in order to address this issue, there was an inadvertently creation of another challenge in regard to the scope of testing of the users. At first, the users tested the system in line the agreed test scope. However, the users later added other test scenarios that were beyond the UAT scope. This even involved scenarios that had remote occurrence possibilities. This was related to the attempts of the user of being all-inclusive while defining their business process definitions (Martin, 1998). While the consultants were quick to commend the thoroughness that the testers employed, there were also worries in regard to the tests whether they could even lead to further delays in the project. Thus, the issue of the scope of testing was brought forward to the committee for reviewing. To ensure that there was checking of data interdependencies and smooth data reconciliation was also a challenge. As the System Integration Head Stated, data reconciliation was the most important point and various tables are interdependent. However, there was a common mistake that was experienced in such projects where personnel never checked for these interdependencies. As a result, people must were not able to trace the connection between the tables, to ensure that all tables are present as well as using programs to do this and report the results (Gibson, Holland, & Light, 1999). This even goes further to failure in checking of discrepancies. Another challenge in the implementation of the system was the means of ensuring absolute certainty that the developed system would cutover as well as operate smoothly. This is because the system would only be rolled out if only they were absolutely sure about its smooth cutover and operation. Another challenge was to get the people to understand the schedule as well as the plan (Gibson, Holland, & Light, 1999). This is because the system was dynamically changing meaning that it could have been faster that what was expected. As a result, the subsequent activity also required to be speeded up. For instance, a user may be informed to come at 5am and then the part suddenly takes only may be forty five minutes rather that the anticipated three hours. As a result, the user has to be told to come about three hours earlier. 1.4 Go-Live and Aftermath The key challenge in this stage is cut over disruptions. Although the company deemed the cutover a success, there were a few problems that were encountered after going live. These cutover disruptions took about six for the company to address or resolve them. However, based on their previous experiences, the company can be said to be operating on much lower tolerance in regard to failure. In addition, there was a spotted mistake in eyeballing exercise. This was as a result of an obscure condition to affect only a few customers and it was referred as a minor mistake. 2.0 Strategies that ASIS adopted to ensure that the implementation of the system was successful 2.1 Blueprint The key strategy to ensure that the company got the “meeting of the minds” between parties is using risk mitigation strategies of ASIS. These strategies were based on the lessons that they learnt from MSS project. In reaction to this, they decided that the project would not be content if they retained consultants that were not prepared in contributing to the project. Thus, the committee requested for making changes on system integration (SI) personnel. Afterwards, the SI proactively replaced personnel with difficulties in working with the team in an effective way. The managers of Integration and User Project also ensured that their respective requirements were integrated into one whole. In order to support their efforts in ‘meeting of the minds’, various users also identified potential gaps in regard to integration in a proactive way between the requirements of various departments. They also initiated appropriate actions in order to ensure an integrated flow of the process. The strategy employed for involving users in this stage created emotional-buy-in opportunity as well as educating. This made the users to show appreciation of the initiative to upgrade the system with development of a greater sense of responsibility and ownership in making sure that the system was successful (Martin, 1998). In order to ensure face-to-face discussions, the committee introduced a new strategy that enforced face to face meetings. This was achieved ensuring that the consultants walked through the documents and as well the users had a clear understanding and arrive at consent in regard to their contents. More importantly, the strategy ensured that ASIS held regular meetings with the personnel to discuss and resolve concerns (Martin, 1998). Effective stakeholders management was also enhanced through promotion of the head of IS and his deputy as the MD and the chair of working committee. Based on their experience, they consolidated the governance structure through clarification of responsibilities, roles and the actions to be followed through and the way to do it (Gibson, Holland, & Light, 1999). To address the issue of BPD items exceeding the contractual obligations of the consultants, the committee realised the need for a firm scoping of the project with limits that are manageable in order to avert project delays. The committee conducted various meetings to review each BPD critically with process owners and shortlist the most important BPDs (Martin, 1998). Eventually, the committee concluded on a list on what was absolutely necessary. This balanced between jeopardising the project and keeping requirement, and dropping requirements that will lead to suffering of the operations of the company. Then, an alternative strategy was adopted in order to split and prioritise the final list of BPDs into two. The implementation of the first set would be addressed during the first phase while the second set in phase two after cutover. Since this strategy solved a part of the problem, the committee also realised the some BPDs could also be addressed by existing programs as well as reports from MSS. To address this, internal IT staff was given the responsibility of porting existing program to the new EBS (Gibson, Holland, & Light, 1999). The consultants welcomed this move due to high user confidence. 2.2 System development The strategy on involvement of the parties is very crucial at this stage. Involvement of the users is critical to the success and the top committee settled on pushing to boost involvement as part of plan for mitigation of risk, most importantly, to mitigate risks in regard to lack of the support of the user (Martin, 1998). This called for support of the proposal for consultants for the users in the project to write up documents with the help of consultants and internal IT staff. Since the users did not practice this in the previous project, the committee alleviated the concerns of the users as well as convincing them of the importance of being fully involved. The committee also focused on key decision of using actual data instead of simulated data. This was very critical in ensuring grater realism and accuracy. The committee ensured that various users from every department were picked as trained in order to be trainers and the consultants familiarised them through the designs and processes of the system (Gibson, Holland, & Light, 1999). In order to address the challenge where some parts of the screens and interfaces were not ready physically during the training sessions, the risk mitigation plan motivated the early training decision. This is because it was crucial to ensure that the user trainers were prepared sufficiently and had ample time to train the diverse and numerous users of ASIS. For instance, the trainers had to address the customer service staff’s training needs that had to ensure a continual manning of service counters. As a result, this they could be trained only in small groups as well as for a short time before or after working. Thus, the committee had to ensure that there were adequate plans for trainers to develop own materials for training which were required for the training remaining users. After the development of the system, there were initiatives by the project teams for conducting system integration testing (SIT). This ensures effective integration of modules. In order to facilitate SIT, it was essential to use a common investigation report database for tracking all identified issues. The database was open to everyone and proved easy to use and effective especially in supporting risk mitigation plan (Gibson, Holland, & Light, 1999). This ensured addressing issues in time in order to prevent disruptions and delays in the system cutover. In regard to the issue of miscommunication as well as the resulting delays, the committee pushed for a resolution. The system integration developers were given the responsibility of getting the locally based developers to do some development work and in some cases; they flew some developers from India to work on the project locally. In order to address the errors in communication, effective governance was employed (Martin, 1998). The committee requested for issues on granular reporting in order to ensure that the exercises on conversion of data could be monitored more closely. 2.3 System validation This stage calls for more involvement of the users that led to declining of the confidence of the users. The strategy in this phase involves giving assurance to the users and encouraging them to ‘test the system to death’. Based on past experiences, encouraging the users to test the system is a section of plan for mitigating risk. This will result in avoidance of rolling out a system that is less than perfect. The committee also introduced a strategy on review of scope of testing. The focus on this review is to ensure as smooth reconciliation of data as well as check the interdependencies of data. This is a strategy that escalates the plan on mitigation of risk in order to ensure that there is accuracy of data during system cutover (Martin, 1998). In order to be absolute certain for smooth cutover and operation of the system, there the committee applied a two pronged strategy for attainment of this objective before cutover. The first prong is about verification on whether the system was ready operationally. The focus on the first prong was to ensure a smooth running of the system after going live. The second prong is about testing whether the ASIS and the project team were ready carry out the cutover. It focused in familiarising ASIS staff and project team with each one’s responsibility during the cutover in order to ensure a smooth proceeding of the actual cutover (Martin, 1998). In order to ensure that the people know the schedule and plan, the committee set up a command centre manned on rotation basis by various consultants and the company staff. This is to ensure that the contingency plans and the cutover could be activated efficiently (Gibson, Holland, & Light, 1999). The committee also ensured an employment of an Excel-based master plan to facilitate these activities. The master plan was stored in ASIS intranet for everyone to track the progress easily. The centre also ensured that there is involvement of all parties and that they carry out their duties promptly according to cutover plan. 2.4 Go-Live and Aftermath One key lesson in this phase is reinforcement of the need for contingency plans. The committee ensured that there is a formulation of an ultimate contingency plan. This is important in a situation where in case of a major difficulty, before a point of no return during the cutover, the project team will be able to roll back to the previous or old system (Gibson, Holland, & Light, 1999). Another initiative adopted by the committee in order to reduce disruptions before cutover, in particular after last mock conversion was to temporarily halt some ASIS transactions in order to allow the project team to prepare for as well as conduct the cutover. The main aim is to minimise the different in environment and data in order to ensure that there is reduction of unforeseen circumstances that could lead to disruption of the cutover (Martin, 1998). All business operations of ASIS were stopped by the project team during the cutover period to ensure that the new data came in. In anticipation of stopping of such operations, the public was informed in advance in regard to impending disruptions to the services of the company. Another initiative that the committee ensured is to arrange their vendor in order to allow the technical staff to be stand-by onsite. This was to ensure that any potential problem the hardware during the cutover was resolved (Gibson, Holland, & Light, 1999). Though the cutover took one week, the committee ensure that daily reviews were held in the command centre. This was very important in monitoring of such as crucial phase of the project in alignment with the plan for cutover that covered all reconciliation points and critical checkpoints. The final initiative in the risk mitigation plan is the management to ask the staff conducting eyeball checks to check bills that were printed in the first three days after the system rolled out. In conclusion, throughout the ERP upgrade implementation, the project team focused on a single objective that was over-ridding, that is, to go live if the project team was convinced that the system was ready operationally. All the strategies, risk and governance risk that were put into place during the implementation of this project were initiated with an aim of assisting in achieving this objective. With a very ambitious schedule, assurance and promise of quality over target date, every party involved in implementation of ERP upgrade agree that it have been more that adequately fulfilled. References Gibson, N, Holland, C, & Light, B 1999, Enterprise Resource Planning: A Business Approach to Systems Development, Proceedings of 32nd Hawaii International Conference on System Sciences, Hawaii. Martin, M 1998, “An ERP Strategy”, Fortune, 2 February 1998, pp. 95-97 Read More