14 August 2013

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:

An organisation runs relatively modest business model which are not unique, they should consider implementing using “Vanilla”.
An organisation, which does not have any experience, they should examine implementing “Vanilla”.
An organisation, which has many branches run the same system in single system, should have a cost-control factor in implementing “Vanilla”.
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?

Assess the existing system.
Analyse design system in the new system.
Define a clear Business Process Reengineering limitation.
Track a some particular activities in the re-engineering plan.
Use Vanilla Implementation to lessen the customisation.
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.

15 July 2013

Week 2 : Shadow Systems

Shadow systems are frequently used as a justification for the implementation of ERPs. Shadow systems are often, but not always, reflective of practice and data storage needs in particular functional silos. Yet oddly, the implementation of an ERP doesn’t always eliminate these systems – sometimes, the number of them increases. Suggest possible causes.

What threat do these systems pose to integration?

Who or what else might be threatened by the existence of these systems?

What is Shadow System?

In the past about 5 decades, every department has their own system, which is called functional silos. The system is not integrated with each other cross-departments. The examples of functional silos :

Human Resource (a.k.a HR Department or HRD) uses HR software,
Finance Department (FD) uses Accounting software and finance software,
Sales Department uses Sales software (e.g POS or Point of Sale).
Administration Department uses administration software.
And many more which depend on the scale of an organisation. 😀

This situation will create system system chaos in the business process in the organisation. Allen Square, Mayor Mitch Landrieu IT Chief (n.d., stated in Rainey, 2013) emphasized that “The current infrastructure is difficult to use, expensive to maintain, makes data access difficult, suffers from data inconsistency, and promotes the use of shadow systems due to a lack of fundamental integration.”

Shadow systems is a main information service to support some business processes. It can be any applications, which is not created by IT Department. Every software vendors; including ERP software vendors; are competing to offer their features for different business purposes in their application software, such as administration software, marketing software, HR (Human Resource) software, manufacturing, financial, and others.

Moreover, Enterprise Resource Planning (ERP) systems will replace all the single application software by integrating business processes (functionality) interdepartmental in an organization (see Fig. 1). The leveraging the ERP systems will give some benefits for business processes.

First, ERP system will make an organization’s business processes more simpler, more effective, more efficiently, more flexible and save their expenses to buy a lot of software for every department. It means the organisation can minimize the deficiencies of formal systems. A successful organisation, who implements it, will create a better B2B (Business to Business) environment (SCM system, as known as Supply Chain Management system). Those kind of organisation can survive in the competitive global market. Ulrich (2006), who is a President, and Founder of Tactical Strategy Group, Inc., and a Senior Consultant of Cutter Consortium; demonstrates through the survey from several respondents that the most off-the-shelf application software used in the organization is the ERP software. The following software that’s used by them are HRM (Human Resource Management), CRM (Customer Relationship Management), SCM, and Commercial off-the-shelf software (COTS).

Second, shadow system can advocate an ERP system in some elements in the academic organisations. Moreover, shadow systems can be any applications, such as :

Excel spreadsheets,
Access databases,
Informix,
Ingres,
Jasmine,
Cognos,
Hyperion,
SAS and others.

The examples of shadow system vendors are :

Oracle,
Sybase,
SAP,
Athena IT Solution,
FinLab Accounting Solution;
IT Works, Inc. (Accounting, Financial, and Personnel Management Solution);
and many more.

There are many shadow data systems come from the data warehouse (DW) and data mart in the organisation. The business person can perform their business using the Extract, Transform, and Load (ETL) in the Business Intelligence (BI) tool. They can analyse from that data for their business performance (Sherman, 2004). According to Neal (2011), there are three roles for ETL processes :

Extract some data from CRM or ERP systems.
Transform those data into the DW, such as Oracle, Teradata, IBM (large-scale company) and SAND technology (small-scale company).
Load / store the data from DW to the users for determining in advanced.

As a result, an organisation will obtain less complicated (Kumar, Mahashwari, & Kumar, 2003, p. 805).

Fig. 1: An ERP System integration.

Behren & Sedera (2004), and Behren (2009) explain that educational organisation; such as Central Queensland University (as known as CQUniversity or CQU), Australia; uses shadow system, which is called Webfuse. It supports the academic functionalities.

What is the cause factors an Organisation Leverage Shadow Systems?

poor in business processes.
lack of manage an organisation, its support systems and training.
lack of good shadow system design.
inter departmental collision, because poor testing and surveillance.
Poor back up cycle business functionalities.
poor business processes documentation, which might be stolen by staffs who resign from the organisation. As a result, an organisation will lose their business secret and also lose their money.

What threat do these systems pose to integration?

There are some benefits of using Shadow Systems, eventhough shadow systems have difficulties at the core business in some cases. Behren (2009) describes that there are some positive and negative aspects using shadow systems.

Positive	Negative
1. Vigorous substances in creativity. For example, Webfuse at CQUniversity system, replies rapidly and tailors in the academic activities which entail the integration in the institution.	1. Control. A shadow system, like CQU Webfuse, is a wild system due to uncontrolled and not belongs to IT Department (ITD). ITD only utilize it to perform the academic institution and avoid the system chaos.
2. Competent resource of Innovation. Innovation is the way to answer the market demand, and can become a market leader.	2. Stigma. Users and IT Support the use of Webfuse systems often wonder about condemnation from ITD and top level management. Their perception that Webfuse is having academic issues, which some data and functionality is reiterated. Nonetheless, they contend that none of another system can do all the processes same as Webfuse system.
3. Potential to bring the stability and order in the systems. Webfuse, which is a CQU shadow System, can be minimized the anxiety their employees to minimize the slack time for uploading the course result data.	3. Organisational politics.

Who or what else might be threatened by the existence of these systems?

1. Stakeholder.

2. Customers.

3. IT Department.

4. And all people who work in the organisation structure.

References

Behren, S & Sedera, W 2004, “Why Do Shadow Systems Exist after an ERP Implementation? Lessons from a Case Study”, PACIS 2004 Proceedings, Paper 136, viewed 23^rd July 2013, http://aisel.aisnet.org/pacis2004/136.

Behren, S 2009, ‘Shadow Systems: The Good, The Bad, and The Ugly’, Communication of the ACM, vol. 52, no. 2, pp. 124 – 129.

Kumar, V. Mahashwari, B. & Kumar, U 2003, ‘An investigation of critical management issues in ERP implementation: emperical evidence from Canadian organizations’, Technovation, vol. 23, pp. 793-807.

Neal, H 2011, Business Intelligence 101 – A Beginner’s Guide to BI Software, viewed 29^th July 2013, http://plotting-success.softwareadvice.com/beginners-guide-to-bi-software-1113011/.

Rainey, R 2013, New Orleans is approaching the Digital Age, but still has a long way to go, viewed 28^th July 2013, http://www.nola.com/.

Sherman, R 2004, shedding Light on Data Shadow Systems, viewed 29^th July 2013, http://www.information-management.com/news/1002617-1.html.

Ulrich, W 2006, Application Package Software: The Promise Vs. Reality, viewed 28^th July 2013, http://www.cutter.com/content-and-analysis/journals-and-reports/cutter-benchmark-review/sample/cbr0609b.html.