IMPLEMENTING THE NEW SYSTEM

The AFF proposal was to complete the implementation in just over two ears. and this would be achieved in three cases. Arrstrework under phase I on February 1. 2010 with their team being led by Irtan raruqui, the partner in charge of the project. Phase 1 included core accounting functions (Oracle Financials), procurement, inventory, order management, and planning modules for which AFF had deputed seven functional consultants and five technical consultants.

The functional specialists did a situation analysis for business processes in each functional area to develop a functional design document (FDD) based on PEL procedures, which were converted to a functional design manual (FDM). The PEL ERP team (Exhibit 7) worked closely with the Art consultants to provide information on the company procedures and to develop revised procedures (the FDD) under Oracle EBS. The technical consultants configured Oracle software technical stack, uploaded initial data, and developed the customized reports as required by the functional design manual al DM. They were also helping PEL IT staff to understand the Oracle installation of database and application software. As all the financial modules required for the Hyperion planning and 1 financial data quality management were not implemented, tell implementation was also deferred. Phase II was to include the manufacturing modules to cover the Fuman Resource modules.

User Training

The training provided by AFP included formal instructor-led sessions as well as hands-on work for each functional area and included the following components for each member of the department staff:

1. General presentation about the functional area and how Oracle EBS was designed.

Functional design manuals (FDMs) were handed out as well as training manuals

3 Hands-on work was done in a test environment under the supervision of AFF consultants.

Parallel data started on a supervised basis, and results were matched with the legacy

August 2010. the FDMs were mostly completed, and the AFF staff used them to prepare training changing their standard manuals to suit PEL needs. The hands-on training implementation was started in parallel to the existing legacy systems for the five modules Accounts Payable. General Ledger. Fixed Assets, Purchasing, and Cash Management). In November, two more modules (Order Management and Accounts Receivable) were started in parallel. In December LOTTO A matched the results in the SBT GL, and legacy fixed assets with those of the corresponding Oracle modules, the legacy systems were closed (see Exhibit IT).

The training was targeted at the user in the respective functional departments involved in the activities of the specific module or process. After the training sessions, the users gained more familiarity through hands-on use of the systems running on a parallel basis. Rehmatallah commented ERr usage is very different from how legacy applications operate. This change of mindset and the way we operate took some staff over one year to understand the way transactions have to be processed in Oracle

as compared to the legacy

systems. Even today, despite repeated training, some of the users lack an understanding of basic concepts like drilling down from General Ledger.

Ne timing to start partner processing was convenient as

June 30 was the date on which the systems were closed for a month and hall-year-end reporting. Thus, the July I. 2010 balances were used as opening balances for Oracle

ERST

Phase 1 of the implementation involved several modules and numerous procedural changes that needed time to be understood by the users. Data processing had become integrated so that entries in one module affected other modules, a drastic change from the legacy systems. In addition. there were the following to be considered:

Phase 1 included the use of eight new Oracle BS transaction processing modules covering the financials and order management, which would replace about 30 legacy systems, which resulted in a large number of processes being redesigned.

There were differences between the calculation mechanics of some Oracle EBS modules and the corresponding legacy systems, e.g., inventory valuation calculations in EBS are based on the material overhead application concepts whereas, in the legacy systems, the actual overheads were charged on the respective inventory transactions.

There were constraints imposed by the liquidity crisis facing the company as additional financing would be required to move to Phase II of the implementation.

The changed procedures as well as understanding the Oracle EBS operational and intelligence modules had to be fully understood and adopted by PEL staff.

In March 2011, AFF suggested to Rehmatullah that they would like to start Phase Il, but the above factors led PEL management to rethink their plans. A meeting with AFF's Faruqui and the key user's management of PEL was held in May 2011 to review the ERP status. As no major issues were reported by the business team, it was decided to release AFF and that any new implementation and support of the existing modules would be done by PEL. Phases II and III were to be deferred for the time being and AFF would rejoin PEL once they were kicked off. Later on, in subsequent internal meetings at PEL, it was decided to defer Phase II and III for a year or so.

Pace of Implementation

The parallel runs, which were initially planned for a short period, were extended substantially due to the change in the overall implementation timeline. This required users to manage two parallel systems. All the data entered in Oracle EBS was not on a real-time basis. For example, in the case of inventory, the material issuance was done at the end of the month in a monthly batch, which meant that the Oracle EBS could not provide real-time information. The new system is very tightly integrated into the form of processes that was entirely different from how things were done in the legacy systems. This, coupled with the financial and operational issues, also slowed down the pace. Management, realizing these implications, initiated the development of an interim solution in the form of MMS to close the loop of the inventory and costing cycle. Software development work by nature and the complexity of the varied manufacturing processes and practices, as well as the change of core master data structures, required time to conclude.

These solutions were in the implementation phase and were expected to be concluded by the first quarter of 2012, which would make Oracle BS the primary source facilitating real-time information.

While the ERP implementation was in progress, unexpected changes in the business operations caused the management to make major structural changes such as:

Arrangement with LG for distribution or co-manufacturing was discontinued.

2. The dealership of Carrier air-conditioning expired.

The appliance business operating structure was changed.

All these changes also had an impact on the configuration of the Oracle EBS, and this added more complexity that slowed down the progress.

With the resignation of Amen in February

2011, ownership and leadership to provide ERP

the understanding was missing in the financial area. This gap was filled in September 2011 with the hiring of Iftikhar Ahmed, who had an accounting and systems background and who in addition to financial reporting was made responsible for solving the bottleneck in the Oracle EBS implementation.

Ahmed was aware that nothing could be achieved unless the recording process was streamlined on a daily basis. His first task was to inculcate a culture of recording, reviewing, and reconciling the effects of the transactions immediately after entering the data. He had to carefully remind all the users that if the data was entered correctly he was confident that Oracle EBS would give the correct results. On enforcing this discipline, he soon identified the reasons for duplicate entries: transactions had not been reviewed while recording.

After Ahmed's hiring, the EBS implementation started to gain some momentum. He had already reviewed the various accounting data of Oracle Financials and found that many accounting transactions had not been posted in the respective ledgers and that most of the financial reporting was focused on the periodic review rather than detailed daily data entry and reconciliations of the accounts. There were 250 customized reports and more than 120 financial statement generator reports; the focus was also required on standardizing the reporting requirements as well as the quality of data.

ERP Benefits

By October 2011, it had been more than one and a half years since the start of implementation work by AFF but the objectives for the main end users of Phase I, such as Gilani in the finance department, were not being met. While the external consultants (AFF) had concluded their work and had handed the full operational responsibility to PEL, the problem of using Excel to generate final reports was a major issue that had the potential to erase any benefit of the system. AFF had adopted the normal software project implementation strategy, starting with the modules that were relatively easy to implement (Oracle Financials). However, the environment of numerous legacy systems at PEL had slowed down the implementation so that when AFF left only a handful of legacy systems were closed (see Exhibit 11).

The initial plan was that by the end of December 2010, after six months of parallel operations, the legacy systems related to Phase I were to be stopped. By virtue of multiple legacy systems still being utilized and some of the core functionalities not being covered in the implemented Oracle EBS modules, the organizational tendency was to rely more on Excel reporting. The differences in the reports from the new and the old systems had to be removed before a complete changeover could be made. These differences were due to missing functionality in the new system or differences in the accounting basis and controls between the two systems. The differences notwithstanding, Rehmatallah had also discussed with the CFO that the staff would not attempt to adopt the new system unless the legacy modules were discontinued.

CONCLUSION

Oracle E-Business Suite was designed to work as an integrated system in which information is passed from one application to another without any incremental integration costs. While Oracle's applications were integrated, they were also modular, but due to PEL business constraints, the implementation of further modules was delayed. The Oracle business intelligence systems and the transactional systems used the same data and information; there was no need for changing data or any manual delay possible, whereas, in the legacy systems, Excel-based reporting was not reliable. But for the intelligence modules to work, the transaction processing modules had to be implemented. No ERP could generate meaningful results unless the information was captured on a real-time basis and the respective departments took ownership of the data.

Ahmed had set his objective clearly: to streamline the Oracle Financials modules by resolving the daily list of problems reported to the IT department by the users and ensuring a discipline that financial information was captured and reconciled on a daily basis. However, he also needed management support as it was a major challenge for him to convince his team to convert to treating the data on their personal machines as being "live" and up-to-date. Handling the conversion from the legacy single-dimension data generated in silos to an integrated relational data structure based on globally accepted business processes was the major challenge for PEL.

SUMMARY AND FIRM ANALYSIS

Firm analysis (competitive advantage, value creation, resource-based analysis, competitive analysis, strategic positioning etc),

Discussion/Recommendation, Conclusion,