Week 5_Customisation in ERP

According to Suresh et.al (2009) Standard ERP systems are also called vanilla ERPs that are designed to function adequately, as well as avoid extensive expense to implement individual components of such a system. Organisations normally want a system that works exactly for them, but it’s not commonly apparent at the cost and size a customisation project is, until it is too late. The decision makers will need to determine if customisation of the ERP systems will be required or will they change their business processes and rule to fit into the ERP system.

Fig 4.1 Level of ERP customization

Risks of customising ERP

Sharma et.al (2012) states that customisation of the system means that individual components are modified to perform in a different manner to what was first intended. In doing so, this may cause some quite serious issues. For instance, some vendors may not support customisation, and stop providing support to an organisation if they choose to customise; without a vendor, maintaining an ERP becomes a more troublesome task. Changing the core system to fit within the business processes can affect the functionality requirements and result in re-coding the changes at each upgrade, or foregoing the upgrade and missing out on the improvements that it may bring. This will not fix or solve the problem and could lead to ERP implementation failure. However, most companies want to keep their business processes with minimal changes and ask the ERP vendor to customize its software. Customisation of an ERP is a very extensive project, and should never be taken on lightly. The expenses, and so forth are usually out of reach of smaller organisations, and mistakes made by larger organisations can bring them to financial ruin. Some of the risks that may arise due to customisation are:

• Higher resourcing and associated costs.
• Ability to upgrade to future releases will be affected.
• Supporting agreements can be affected.
• Functionality problems.
• Time consuming.

Video 4.2 ERP customization kills innovation

Business process re-engineering (BPR)

According to Suresh et.al (2009) business Process Re-engineering is a strategy many companies use in reviewing the way they perform their business activities.  For example in the past one must go to the bank to perform their banking and paying of bills, through BPR clients can now perform this task through phone and internet banking.

References:

Ng, J, Ip, W & Lee, T 1999, ‘A paradigm for ERP and BPR integration’, International Journal of Production Research, vol. 37, no. 9, pp. 199-210.

Sharma, R, Patel, S & Tendon, A 2012, ‘Customization and best practices model for adopting ERP systems: an analysis’ , International Journal of Business Strategy, vol. 12, no. 1, pp. 1-9.

Suresh, S, Mohamed, T & K.V, K 2009, ‘The Role of BPR in the Implementation of ERP systems’ ,Business Process Management, vol. 15, no. 5, pp. 653-668.

Assessment Item 2 (report)

The purpose of this assignment is to provide a report responding to the case study. You should make clear what the problem is and also outline what the options are. The report will consist of the following sections:

Executive Summary

It will summarize any issues or problems faced by the implementation team, any background information to the problems, any methods or strategies used, any issues that arises due to poor planning, schedules not being met or over spending of the allocated budgets. The executive summary will suggest recommendation in moving forwards as a result from the discussion and findings.

Introduction

It will introduce the report through its purpose and the method used in presenting the report. It will also introduce the scope of the report but it will be elaborated further during the report.

Detailed discussion about the report

It is the main body of report that will explains and analyse the findings. All of the requirements are discussed alongside with the processes of the business and their collaboration with the ERP system. It will also discuss about decisions and their impacts to the ERP system by introducing risks and change management to the production line. It can also discuss the current model and procedures and state reasons why it is appropriate to stay with the current system or to implement a new system altogether.

Recommendations

It will be on the best options available by presenting the benefits and risks associated with them.

Conclusion

This part will discuss all of the facts and summarize the report findings.

References

This part will include the detailed references list used in the report.

Week 4_ERP implications

According to Hunton et.al (2002) ERPs are quite complex and large that needs significant maintenance. Although adopting an ERP can provide an organisation with many benefits, in doing so, they also incur a heavy, on-going cost.  Patches are required from time to time in order to preventing any vulnerabilities or future exploitation across the network. Moreover, there can also be a drop of morale amongst staff, as the new technology may scare them; simply because mistakes made with the system will affect the entire organisation; leading to the development of shadow systems, as well as staff resistance to the ERP. The text does not capture the complexity of ERP. In the text it does mention some aspects but mostly elaborates on the ERP Life Cycle with comparisons towards the traditional SDLC. The text does however mention the implications that ERP systems cause for management. Basically, the text implies the tasks to be simple and straightforward. In most cases, however, they can be very complicated and cost quite a lot.

Video 3.2 Importance of change management in ERP

Patches

Markus (2000) alleges that Patches are very important in order to preventing any vulnerabilities or future exploitation across the network, the expected result from applying these patches and service packs will reduce any future resources required in dealing with these vulnerabilities and saving the organisation money. Securing our systems by adding additional supportable functions is a great initiative in addressing any security flaws within our systems. From a basic understanding, that seems like a straightforward process:

1. Get the patch
2. Apply the patch
3. Test the patch.

Fig 3.1 How do you patch your software

Schniederians & Yadav (2013) states that unfortunately, patching for an enterprise-wide system is far from easy. Although centralised, different components will process and pass information individually. Patches will often replace chunks of code, or whatnot, to fix an issue or secure any vulnerability. In order for this to work efficiently, the entire system needs to be patched accordingly, and then tested accordingly. The expected result from applying these patches and service packs will reduce any future resources required in dealing with these vulnerabilities and saving the organisation money. Securing our systems by adding additional supportable functions is a great initiative in addressing any security flaws within our systems. Even when the vendors provides an extensive patching schedule, many organizations still do not apply these patches in a timely manner, this can result in the withdrawal of support by vendor. Some organisations feel resistant in applying these patches due to the following reasons:

• Resources cost
• Changes in production environment
• System availability

Before adopting the new ERP system organisation must consider that the new system has the ability to provide them with the competitive advantages, business requirements and continuous process improvement. These implications can come as a result of:

• Limiting customization
• Standardization and adopting best practices
• Shifting to latest systems
• Reducing fruitful efforts

Small patches to individual components are easy to do; but large chunks often use up significant resources, cause long downtimes, and cost a lot to the organisation. How much support the vendor provides is entirely up to the vendor, and is likely going to be the patch itself along with some basic instructions on the patching process.

References:

Hunton, J, McEwen, R & Wier, B 2002, ‘The reaction of financial analysis to ERP implementation plans’, Journal of Information Systems, vol. 16, no. 1, pp. 31-40.

Markus, M, Tanis, C & Enema, P 2000, ‘Multisite ERP implementations’, Communications Of The ACM, vo. 43, no. 4, pp. 42-46.

Schniederians, D & Yadav, S 2013, ‘Successful ERP implementation: an integrative model’, Business Process Management Journal, vol. 19, no. 2, pp. 364-398.

Week 3_ERP as best practice

According to Lozinsky (1998) ERP provides the best practices to realize business processes rather than defining the business process. If an organization is unwilling to change its business processes, it can still gain value from an ERP. An EPR is an enabling tool but not a driver of business processes.

 

Fig 2.1 Pre-configuration and best practices of ERP

The claim that ERPs are often advertised / touted as providing “best practice” in functionality and business processes is often right in the majority cases for the reason that the domino effect of surveys in current development of business demonstrate that most organizations which implement ERP systems are flourishing in achieving a number of significant objectives like- maximized throughput of information, minimized response time to customers and suppliers, quick and precise decision making, substantial reduction in cost, improved operation and performance etc.

Video 2.1 Best practice process for ERP

According to Vichita (2007) on the other hand, many organizations have their own business processes and are hesitant to change. The reason is that ERP systems require massive investments, necessitate a considerable time and enforce greater threat as a result of business process re-engineering. If an organization is reluctant for entire re-engineering, it can still enhance some value from an ERP by accommodating partial ERP implementation which is accomplished by structure modified and customized modules to prop up foundation operations as an alternative of choosing vanilla system, in-house development system or maintaining of the legacy system. Only the required or critical modules of ERP may be implemented initially in order to diminish the associated risks.

RISKS

According to Abdullah (2007) the possible risks are that the project may involve a considerable time and cost and it may take some time to realize the true benefits of the partial ERP implementation. The risk associated with an in-house ERP system is the significant investment as it is the most time-consuming and expensive option in implementing an ERP. When the core operational processes, such as financial accounting, production planning, and materials management, do not provide a competitive advantage, the high investment in developing and implementing a proprietary ERP system usually cannot be justified.

Furthermore, another risk related with the in-house ERP is the potential of the internal resources to design, maintain and upgrade the system to stay current. Lozinsky (1998) indicated that in order to develop and maintain a system that permits the company to compete in the current market, the in-house professionals will have to thoroughly understand the evolving financial, business and technological aspects that must be measured in the design, maintenance and upgrade of the system functions. Company management must take into account the evolution of all the above-mentioned aspects to adequately maintain systems to stay current. Otherwise, the company can soon move back to its prior situation.

Finally, the in-house ERP development and implementation could divert the internal resources from supporting the core business. Lozinsky (1998) pointed out that the ERP development and implementation is usually not the main business or strength of a company. The company will be better off by directing their available resources into the core business, such as improving their products or services to gain and maintain the competitive advantage.

Organizations which do not want to change business processes can still improve overall productivity from implementing a proprietary in-house ERP system. The substantial cost of developing and implementing an in-house ERP can only be justified if the existing business process can provide a competitive advantage. Other risks involved in the in-house ERP are the inadequate internal capability in designing and upgrading the system and the possibility of diverting the internal resources from supporting the company’s core business.

An ERP ‘allows a company to automate and integrate the majority of its business processes; share common data and practices across the enterprise; and produce and access information in a real-time environment’.  The companies which do not implement ERP may find themselves at a competitive disadvantage, particularly in industries in which ERP implementation is widespread’. Companies using ERP will be able to run their businesses to reduce cycle time, to improve the speed and accuracy of information, and to attain better financial management.

References:

Abdullah S, 2007, The role and impact of business management in enterprise systems implementation, Business Process Management Journal, vol. 13, no. 6, pp. 866-895.

Lozinsky, S 1998, Enterprise-wide software solutions: integration strategies and practices, 1st edn, Addison Wesley, Reading.

Vichita V, 2007, Business process approach towards an inter-organizational enterprise system, Business Process Management Journal, Bradford Vol. 13, no. 3; pp. 433-455.

Week 2_Shadow Systems

According to Behrens (2009) Shadow systems are the systems which replicate data and/or functionality in part or full of the enterprise system in the organisation. Shadow systems are considered undesirable because they could decrease the use of enterprise systems. The organisational performance could go down if shadow systems are not aligned with the organisation’s ERP system.

Video 1.1 Best practices of ERP

Causes that could increase the number of shadow systems in post ERP implementation

• Poor communication between departments.
• System inflexibility.
• Poor planning and management
• Poor data conversion and transformation.
• Change Management or Users resistance to change.
• Users lack of trust of the ERP.
• Users perceive a gap in the functionality of the system.
• Ineffective training.
• Lack of Support from management.
• Conflicts between functions.
• Highly creative users building work-around.

Shadow systems really exist in many companies. Nonprofessional developers usually develop ‘end user’ shadow systems that could create many problems like redundant data entry, provision of inconsistent information and wastage of resources. The development of shadow systems is problematic to stop due to easy access of end user tools. Individual users create shadow systems with Excel, Access or similar tools. However, shadow systems developed by the computing professionals collaborating with the IT division are more likely to use good practice and don’t exhibit negative attributes (Behrens, 2009).

 

Fig 1.1 Different functions covered by ERP

System integration threats of shadow systems

According to (Fang & Wei 2009) these systems have low productivity and inconsistency. There couldn’t easily integrate with the central enterprise systems. A business cannot achieve its goals without a reliable ERP system because ERP systems are designed to provide the accurate information and real time situation. A shadow system is detached from the ERP therefore is not integrated. There are also risk of reduced productivity, collaboration, efficiency and customer satisfaction.

Who could be threatened by Shadow systems?

According to Patricia (1997) Shadow stems could affect the entire organisation especially IT/IS departments. It could also threatened  the suppliers and customers, who would be expecting increased collaboration, integration and information sharing leading to better and improved business relationships and service.

Positive and negative impacts of shadow systems on organisation

According to Sherman (2006) Shadow systems help business process such as budgeting, forecasting and many other reporting tasks. Users may have ES in the company but they really like to generate the real reporting and analysis via using data from shadow systems. Also, data retrieve becomes more faster from shadow systems. On the other hand, each report or analysis interprets the data differently, so even when the numbers start off the same in each silo, the end results will not be consistent. Data which is inconsistent and inaccurate will surely smudge the reflection of shadow system for users. However they’ll also experience the tension of create, maintain and supervision their individual departments.

References

Behrens 2009, ‘Shadow Systems: The good, the bad and the ugly’, Communications of the ACM, vol. 52, no. 2, pp.124-129.

Fang, L & Wei, MN 2009, ‘On the global existence and finite time blow up of shadow systems’ ,Journal of Differential Equations, vol. 247, pp.1762-1776.

Patricia, S 1997, ‘Intervening in the shadow systems of organizations’, Journal Of Organizational Change Management, vol.10, no. 3, pp. 235-245.

Sherman, R 2006, ‘The data shadow system condrum’ ,Journal of Business Change Management, vol. 22, no. 2, pp. 175-189.

Annotated Bibliography

Jones, D, Behrens, S, Jamieson, K & Tansley, E, ‘The rise and fall of a shadow system:lessons for enterprise system implementation, pp. 1-15, viewed 12 July 2012, http://davidtjones.wordpress.com/publications/the-rise-and-fall-of-a-shadow-system-lessons-for-enterprise-system-implementation

Rick Sherman 2006, Business intelligence systems: Data shadow systems pros and cons, viewed 14 July 2012, http://searchbusinessanalytics.techtarget.com/tip/Business-intelligence-systems-Data-shadow-systems-pros-and-cons