Answer the questions below in an academically rigorous manner, using a business report style, with claims supported by referring to relevant literature, using in-text referencing (Cambridge referencing is preferred to Harvard). The assignment will need to be a mix of your own intellectual property (interpretation and analysis) and evidence drawn from published material to support your arguments, or the case you are building. You may make appropriate assumptions about the case as required, but please note them in your report.

The Tasks

Prepare a business report for Leadtek's senior management team.

The aim of the report is to:

1. Identify the likely causes of the problems experienced by the ERP project.

2. Show how these problems could have been avoided or mitigated (with particular reference to the concepts and frameworks covered in this course).

3. Provide clear recommendations as to what steps Leadtek Corporation should take to ensure the success of the next phases of their ERP implementation and maintenance. Consider the options that would be available today.

Business report format (required for Assignment 2)

Readers of business reports expect certain information to be in certain places. They do not expect to search for what they want and the harder you make it for them the more likely they are to toss your report to one side and ignore it. So what should you do?

1. Follow the generally accepted format for a business report: Title/Table of Contents, Executive Summary, Introduction, Main Body, Recommendations and Reference List.

2. Organise your information within each section in a logical fashion with the reader in mind, usually putting things in order of priority - most important first.

Report Title/Table of Contents. This is simply the front cover page identifying the report and a Table of Contents page showing each key section of the report and the page number where it can be found in the report.

Executive Summary. Give a clear and very concise account of the main points, main conclusions and main recommendations. Keep it very short, a few percent of the total length. Some people, especially senior managers, may not read anything else so write as if it were a stand-alone document. It isn't but for some people it might as well be. Keep it brief and free from jargon so that anyone can understand it and get the main points. Write it last, but do not copy and paste from the report itself; that rarely works well.

Introduction. This is the first part of the report proper. Use it to paint the background to 'the problem' and to show the reader why the report is important to them. Then explain how the details that follow are arranged. Write it in plain English.

Main Body. This is the heart of your report, the facts. It will probably have several sections or sub-sections each with its own subtitle. It is unique to your report and will describe what you discovered about 'the problem'. These sections are most likely to be read by experts so you can use some appropriate jargon but explain it as you introduce it. Arrange the information logically, normally putting things in order of priority -- most important first. In fact, follow that advice in every section of your report.

[Tasks 1 and 2 should be included in this section.]

Recommendations. What do you suggest should be done? Don't be shy; you did the work so state your recommendations in order of priority, and in plain English. Time has marched on, there are newer versions of Oracle ERP and the availability of cloud delivered solutions.

[Task 3 goes in this section.]

References. As your business report must be academically sound as well as making good business sense, it is essential that your report is supported by accurate in-text referencing and the inclusion of a reference list

Case: ERP Implementation at Leadtek Corporation

This case study relates to Leadtek Corporation, a technology driven computer components company based in Taiwan with over 2,000 employees, over a 100 industrial customers, and a supplier base spread all over the country as well as overseas. Computerized accounting systems were introduced at Leadtek Corporation in the early part of the 1980s.

In the early 1990s, a FOXPRO-based accounting system was developed by an in- company IT team. Data were captured in a batch mode, from the various departments of the company and updated daily into the standalone accounting system. Modules for stores/inventory, sales, purchase and payroll were added - each stand-alone, feeding into the accounting system through batch updating. To overcome the problem of disparate databases, the FOXPRO system was replaced with a relational data base management system (RDBMS) using INGRES. The various modules were linked, creating the first semblance of a future enterprise wide system.

In the years 1993-1995, the legacy system grew in functionality and was used for all transaction processing. The internal DP department maintained the system, often going out of the way to accommodate requests from the users for newer and newer reports and functionality. The demands from the users often exceeded the capacity of the internal DP department to meet them.

With the rapid development of the Taiwanese economy in the start of the new decade, Leadtek Corporation had the vision of becoming a world class player in its business domain. The company appointed an international consultant to carry out a gap analysis to study if the existing IT system was ready to meet the information needs of the future. They wanted the consultant to answer the following questions:

• What were the weaknesses of the current IT system of the company?
• What changes should be made to align the information system to the business vision of Leadtek Corporation to become a world-class company?

The consultant team after a detailed study recommended that the company go for an ERP system. A detailed exercise was carried out to select the ERP. The choices were between SAP, JD Edwards, Oracle Applications and Ramco Marshal. Oracle Applications Version 11i was chosen as it had a local support office, met the required functionality, had another reference site and was competitively priced. The implementation was planned at the largest division of the company. It was felt that that after successfully implementing ERP at one location, rollout to the other locations would be much easier.

Roll out of Oracle applications 11i at Leadtek Corporation

The same international consultant was engaged for the implementation. A project team headed by the IT head was constituted for the ERP project. The in house team consisted of three full time IT resources, five user members (part time - as the departments could not spare resources full time). The consultant team consisted of a project manager and five full time resources (two technical consultants and three functional consultants). A senior manager was appointed as the project champion.

The project was initiated with a formal "kick off" with the CEO and top management team emphasising the importance of the project. The project then followed the standard ERP implementation methodology involving:

• Definition (requirement analysis, scoping, creating work plan); operational analysis (Gap analysis, "As is" and "To be" process design);
• Solutioning (detailed design, work-around plans);
• Building (parameterizing, coding, data migration, testing);
• Transitioning;
• And go live.

A steering committee consisting of the IT head as chair and departmental heads as members was constituted. This committee was mandated to meet once a month to review the project. Being themselves new to ERP and perhaps as a means of securing the contract the consultant had raised the expectations of management on what the ERP would do for the business. The scope of the project, therefore, was ambitious.

From the start the ERP project had problems. Top management showed great interest at the start of the project but soon this interest started to wane with competing pressures on everybody's time. After the "kick off" meeting there was no formal review of the project. The steering committee met for the first two months - from the third meeting onwards the attendance for the meetings started dwindling and stopped altogether after the fourth meeting.

User team members, not being full time, got busy with their day-to-day work and saw the ERP project as an "additional burden". In key areas, the participation of user members was poor-the most dispensable junior was often the choice for serving on the ERP team. This person neither had the knowledge nor the authority to make process change decisions that were required in configuring the ERP. There was a lot of resistance from users who constantly compared the ERP with the existing system. A comment often heard was:

Why are we spending so much for this (say an accounts payable report) - our old system already gives it at the click of a button- in the ERP we need to go through three screens to get the report - and that too without all the details [...]

Problems also started with "localization" - this refers to the ability of the ERP to handle the country/region specific requirements of taxes/ levies, etc. The legacy system handled all of this perfectly but ERP always seemed a step behind in addressing these. This necessitated work rounds which were cumbersome.

Another source of resistance to the ERP came from:

1. Maverick behaviour. In many operational areas, there were informal (not officially authorised) practices. For example: in purchasing, very often suppliers were asked to send material without formal purchase orders. These were then "regularised" post-facto at the time of bill passing; similarly the sales department had a practice of extending despatches beyond the close of a period (say quarter or month) - with predated invoices - to meet month end targets. These practices were tacitly allowed by the departmental managers but were frowned upon by top management. As the ERP would not allow such practices, users who had been doing this for years resisted the change terming the ERP as not being "user-friendly". Training

was given well ahead of use. When a particular module was ready (about four to six months down the line) to be used most users had forgotten all that they had learnt).

• Perceived loss of power. ERP best practices brought about some work flow changes that resulted in power shift between departments. For example, in the legacy system bill passing was done by the accounts department. As a best practice it was decided that the complete accounts payable process from "Indent to Payment" would have the procurement department as the "process owner". As the ERP provided a robust "three way match" (between invoice, goods receipt and purchase order) and also provided good audit trails, it was felt that the bill-passing function could completely move to the procurement department by passing the accounts department. This change was resisted by the accounts department team. They felt that they had lost the power they had earlier exercised over vendors and the procurement team by controlling the payment process. The procurement department happily accepted the changed workflow as they saw the power (to control payment to vendors) shift to them. This caused conflict between departments that manifested in other areas also.

At the end-nine months the ERP project was nowhere near completion. Costs had already exceeded the original budget as hardware had to be upgraded, additional licenses had to be procured to take care of the revised workflows, users had asked for several additional non-standard reports/customisations (to match legacy system functionalities) that required additional 12 man months of work. New estimates of cost were twice the original estimate which top management had no choice but to approve.

The "go live" happened after 14 months from the start of the project. During the first two weeks there was total chaos. The legacy system had been switched off and the ERP processes still had glitches. Dispatches of products were getting delayed as inventory data were inaccurate. Manufacturing systems were completely unusable. Improperly trained users could not handle the screens on their own. IT department and consultants' staff were running from one user to the other to trouble shoot/train/help. Customers started complaining of wrong /delayed deliveries.

With no other alternative it was decided to switch back the legacy at least for key "show stopper" processes and continue working on the ERP. The consultant was asked to extend his contract by another six months.

After 24 months the conclusion was that the ERP project was a failure. The consultant had left the project. ERP was running but in many of the business processes the legacy system was still continuing in parallel.

There was total dissatisfaction at all levels in the company. Commenting on the state of affairs, a senior manager from accounts put it best. To quote him:

We had a reasonably good legacy system [...] we were told that the ERP would solve all problems and take us take to the next level [...] now after more than a year and a half we find the ERP is way below our legacy system, and we are putting efforts to bring it up to our legacy level. If only we had spent half the amount of time and money and upgraded the legacy system we would have been much better [...]

The conclusion: Leadtek should consider abandoning the ERP project and focus on improving the legacy system to bridge gaps. This feeling was shared by quite a few other

managers. The company continued with this hybrid solution for another year or so before deciding to take a complete relook at the whole ERP implementation. By now Oracle had come out with an upgraded version 12c and this was seen as a good opportunity to review the whole situation.

You have been employed as a consultant by Leadtek Corporation to review their past ERP problems, so that they may learn from them and prevent their re-occurrence. They have also asked for your overall recommendation as to how they should manage the implementation of Oracle ERP version 12c, which they are strongly considering.