Week 5 : Don’t Customise & Ass2 Skeleton

PART A.

Many experienced ERP implementers will say there are two rules you should follow when implementing these systems:

1. Do not customise your ERP.

2. See Rule 1.

Why do you think this is?

What are the risks of customisation?

What does a need to customise say about the willingness or an organisation to effect BPR?

ERP installation involves some factors, such as hardware, human resources and software. Hardware consists of C/S (Client/Server), and Peripheral. Human resources involve all cross-business functionality workers, such as project manager, ERP implementation team, and development team. Lastly, Software contains Operating System; which is a platform for running any software, including an ERP application; Database Management System (DBMS); and Application software, like Oracle, Microsoft Dynamic, SAP, and many more. There is none of the application software made perfectly in their system, including ERP software. It means an ERP system needs to add some missing functionality during implementation from third parties, which is called add-on (as known as addons). Some of the third parties don’t offer it; however, it shares the data into the ERP system. Some of third parties may not be developed by the ERP vendor itself. As a result, it may create some issues of the addons. An ERP vendors need to build co-operation with the third party vendor to overcome the issues.

A successful organisation will implicate a proven methodology in selecting an ERP implementation. The writer will give a best practice in implementing ERP system. He already gave a brief description about selecting implementation in their plan last week. The best solution for an organisation is using Vanilla implementation, because they do not need to spend much money because they will be given from ERP vendors in its functionality to cover simplicity of their business processes. Kimberling (2009, via Panorama-consulting.com) reported that the effectiveness using Vanilla Implementation in the organisation. (See Fig 1).

Fig 1. Customisation average rate using ERP Vendors.

(Kimberling, 2009, http://panorama-consulting.com/erp-software-customization-the-ultimate-sin-of-enterprise-software/)

Many professionals in ERP suggest that they should not customize their ERP system. Before the organisation customizes their ERP software, they need to scrutinize several factors. Motiwalla & Thompson (2009) mention that there are 7 factors in considering it:

1. An organisation runs relatively modest business model which are not unique, they should consider implementing using “Vanilla”.
2. An organisation, which does not have any experience, they should examine implementing “Vanilla”.
3. An organisation, which has many branches run the same system in single system, should have a cost-control factor in implementing “Vanilla”.
4. Leveraging a “Vanilla” implementation will give them a competitive advantage.

What are the risks of customisation?

The writer stands in the same sides with other experienced ERP implementers, which customizing an ERP will be too risky. There is some reasons.

1.    Upgrade

Developer team need to analyse during system modification. They need more time to customize, validate, and upgrade the old system.  The upgrading system needs long-term periods, because it cannot one-time upgrading the system.

Additionally, if the customization is outrageous from the implementation plan, it can be transformed to re-implementation. It is most expensive.

2.    Human resources.

Either too much coding or no-coding testing during customisation will create incompatibility in the new system. It means it will create some bugs or system issues.

3.    Lack of experienced, consultants & experts in the customisation the systems can create difficulties for organisation. On the other hand, if the organisation has experience in customisation, it will have a successful impact.

4.    Reversion.

Vjeko (2009) argues that “The more you customise, the more regression testing you have to do, and what consultant don’t find, the end users will, but after Go-Live (Going LIVE).

What does a need to customise say about the willingness or an organisation to effect BPR?

1. Assess the existing system.
2. Analyse design system in the new system.
3. Define a clear Business Process Reengineering limitation.
4. Track a some particular activities in the re-engineering plan.
5. Use Vanilla Implementation to lessen the customisation.
6. Implement the new system.

REFERENCES

Harris, R 2000, “Customization versus Standardization: Striking a balance in ERP Software”, Machine design, pp. 564–569.

 

Kimberling, E. 2009,  ERP Software Customization: The Ultimate Sin of Enterprise Software?, viewed 15^th Ausgust 2013, http://panorama-consulting.com/erp-software-customization-the-ultimate-sin-of-enterprise-software/.

Motiwalla, L.F. & Thompson, J. 2009, Enterprise Systems for Management, Upper Saddle River, New Jersey.

Vjeko, 2009, Top 7 reasons why to avoid (much) customization, viewed 15 August 2013, http://vjeko.com/blog/top-7-reasons-why-to-avoid-much-customization.

PART B.

Examine assessment item 2. The purpose of this assignment is to provide a report responding to a case study. Provide a rough skeleton (dot point form if you wish) of the content and structure of the main body of your report. You should make clear what the problem is and also outline what the options are.

Assessment item 2 (Term 2 – 2013) examines from the case study about “Difficulties in Enterprise System (ES) implementation: The case of Millicent Home (MH)”. It examines the causes of ERP implementation failure.

The structures of the main report are:

1. Executive Summary

• Describe a brief summary of some major findings of an ES implementation in MH, including argument about continuing using SAP or disregards the SAP implementation.
• Describe recommendation and conclusion.

2. Introduction

a.  Background.

o   A brief ES implementation issue in MH.

o   Describe the timeline of the issues, the important of ES implementation, and factors of people who get involved.

b.  Aim / Objectives.

o   The objectives of report achievement.

c. Scope.

o   The coverage of the ideas in the report.

3. Project Analysis

• Define and explain the either functional reasons or technical reasons why fail in implementing an ERP system.
• Analyse which result in the crucial factors in failure of ERP implementation.
• Analyse some issues befall the existing ERP system.
• Assess any party involved in responding the issues.
• Mention the effect of successful in change management.

4. Conclusion

5. Recommendation

Give some suggestion to perform better using ERP system and work effectively on it.

6. References

Using a standard Harvard Referencing style

7. Appendices

The additional information related to the Project Analysis that may include:

a. Data.

b. Chart.

c. Diagram.

d. Table.

e. Maps.

f.  Some Questionnaires or its answer.

g. Specification.