The Reason The ERP Journey May Never End

The ERP or enterprise resource planning system can be considered as the packaged application system of a business that allows integrate and automate most of its processes associated with business, sharing practices and data across the whole organisation and generate and access data within a real-time environment. The average time for implementation of an enterprise resource planning system takes up to four years. According to Schwalbe (2015), various organisations believe that deploying the system into business environment is just a beginning of the ERP journey. Going-live is the beginning of making the most use of the ERP system. The ERP after deployment needs to be corrected many times to make it best suited to the organisation’s goal (Nwankpa and Roumani 2015).

Within the report, the description of the journey of ERP after going live has been described in detail. In addition to that, various case studies has been used in the study for making the statement more strong. The study incorporates the information of stages of ERP development, benefits of the stages, barriers to move from one to another and many more.

It is to be remembered by the organizations that going live is not the end of the ERP implementation journey. There are mainly two reasons behind the extension of the ERP journey after going-live. The first reason is the ever-changing patterns of business. In this case, the client organisation integrates a system into its business environment, but the need of changing the ERP functionalities occurs due to change in business processes. Taken as an example, Cadbury implemented the ERP into its environment for reducing the operational cost of the organisation (Elbardan, Ali and Ghoneim 2016). The organisation is an England-based multinational organisation that produces confectionery. The organisation implemented the SAP ERP 6.0. Kraft was in charge of deploying the system into its business. According to Rahman and Saha (2016), this implementation was a successful one but the same organisation integrated master data management solution and Net Weaver into the ERP system of Cadbury. Now the reason behind the journey of ERP beyond going live was to make the system more compatible with the business objectives and become more effective. In order to reduce cost, the system needed a solution that can allow to process and govern critical data through creating standards and policies (Elbardan, Ali and Ghoneim 2016). As the organisation will expand its business or detect more areas within its current environment needed to be modified, more upgrades will be carried out within the system.

The second reason behind the never ending journey of ERP is the failure of the system. This cause is as common as the first one. However, there is a need for stakeholders to support the further changes in the ERP after the heavy loss from failure. Taken as an example, the recovery of Nike from its supply chain disaster is most suited with this reason. In 2000, the executive management of the organisation took the decision of implementing a special SAP ERP system in the supply chain division to forecast demand (Qrunfleh and Tarafdar 2014). The system after going live did not provide the estimated profit instead it was a hundred million US dollar loss for Nike. In this case of ERP journey, the Nike needed to change the system functionalities and many more aspects of the system after deployment (Hwang and Min 2015).

Stages of ERP System Journey

So from the above two case studies, it is clear that the ERP journey is never-ending. Going-live is only the beginning of the journey. The change in business, system non-effectiveness and much more reasons forces the clients to change the ERP systems continuously.

There are five stages of ERP system journey. The ERP system journey can be considered as the distinct phases that hold the operations essential for carrying out the project in a successful manner even after the deployment of the system in the organisational environment. The five stages are projected chartering, the project, shakedown and onward and downward (Hustad, Haddara and Kalvenes 2016).

Project Chartering: This stage or phase of the journey is concerned with the activities that lead to project approval and funding. According to Rahman and Ripon (2014), the process of collecting the IT requirements across the organisation is one of the vital and foremost activates of the chartering phase. The same person or group appointed for the job of gathering requirements will present a rough idea of the ideal system for the organisation (Khan et al. 2016). The main reason that most of the organisations after this activity goes for ERP is its ability if integrating the various departments and functionalities. Not the IT requirements but also legislative requirements for implementing the system is also acquired in the phase (Oseni et al. 2014). Taken as an example, Macedonian organisations are surely taking after the pattern of actualizing ERP frameworks for the most part for lower scale ones, basically due to asset requirements. Large portions of them execute ERP so as to enhance their business forms, yet some of them to agree to administrative prerequisites (Tasevska, Damij and Damij 2014).

The Project: This phase is the most vital among all the phases. It is because the project team carries out the entire system by analysing the recognised functional and non-fictional requirements (Khan et al. 2016). The project phase is first commenced with creating a detailed plan of the project with complete functions as per each department as well as the entire organisation. The project groups generate various processes and procedures for completing the system. Taken as an example, The company Personal Computing and Consulting (PC&C), later renamed Navision A/S made sure that all the processes of the system development are perfect (Antero 2015). These processes and procedures are presented to the stakeholders in the monthly meeting. After approval of the processes, in those meetings, the progress of the project is discussed. The project team starts creating codes, implement system functions, add different units of the system and carries out may more other system development related tasks. As per Kim, Jung and Young (2015), the case of implementing ERP in the agriculture states that in the second phase of ERP appropriation in agribusiness, the bound together form of ERP was received by horticultural firms. Nonetheless, the selection of the second era ERP was negligible because the ERP framework did not mirror the necessities of individual farming firms and ceaseless updates of the ERP framework were not made.

Potential Benefit of Each ERP Journey Stage

Shakedown: This phase initiates with going-live and remains active until the routine use of the system is achieved. Opined by Nwankpa and Roumani (2014), the initial three months after going live can be considered as chaotic. It is because a lot of users of the system do not accustom with the functions and use of the system. One possible solution for this issue is hiring new internal consultants who will carry out the tasks like data conversion, problem solving, training users and system performance tuning (Gelogo and Kim 2014). It is to consider that the poor communication between the stakeholders in this phase can result into a poor journey of ERP.

Onward and Upward: This phase can be considered as the period of which the organisation that implemented the system will recognise the business advantages in the aspect of the system. The client organisation must appoint an ERP manager who has a good knowledge of the organisational objectives and involved in ERP implantation (Kim, Jung and Young 2015). This will allow the organisation to recognise the gaps that exist in the system after going-live. After the recognition of the gaps, a new IT team or existing one is appointed to change the system aspects as per the business goals (Oseni et al. 2014).

Project Chartering: In order to gather the project approval from the stakeholders, various in dept analysis of the potential system and business process is done. The IT requirements for the business divisions are gathered in this part, and this allows the organisation to understand its own business more effectively (Rahman and Ripon 2014). Various issues in the business process that were unknown or related to low productivity can be recognised easily. Various works of one department are related to other departments. Through the findings of the requirements, by interviewing employees, the organisation can understand that how slow productivity of one department is affecting the other departments. One of the other benefits is that the organisation can understand the gaps in its processes, guidelines and procedures that are associated with the project approval process. An organisation changed their project approval process after they realised that there were severe issues in their approval process (Tasevska, Damij and Damij 2014).

The Project: The planning of the project is an essential and inevitable aspect of a project. These are the potential benefits that an organisation can have from planning activity of a project management. The organisation will be able to establish a clear view of the objective of the project that will be used to guide the project through its journey (Khan et al. 2016). In IT projects risks are the most severe issue and planning will allow the project team gather the knowledge of possible risks of the project. Through the creation of the milestones, the project team can utilise its resources as per the scheduled deadline and work. In an ERP project, the resources are limited, and project manager must utilise the resources in the most efficient way possible (Antero 2015). The planning phase will allow the project manager to allocate resource for each activity.

The project phase is also consisting of other processes like development and testing. The development phases assist the organisation is getting a prototype that will be placed in the business environment. The testing process makes sure that the implemented system is ready.

Shakedown: It is not possible for all the employees of an organisation to change the way of work with the integration of new ERP system. Many staff faces the issue of little understanding of the system, which leads to less productivity (Gelogo and Kim 2014). It is essential to make the staff able to adopt the changes. This phase does the same act by appointing new employees or employee who worked on the ERP project. The responsible person trains the user to use the system and increase their productivity. This will motivate the staff to recognise the issues they are having in doing their work due to the system incompatibility. This information is stored in a spreadsheet or some other document and serves a crucial data in the onward and upward stage (Nwankpa and Roumani 2014). The staff will be to operate their work day today with the newly gathered knowledge regarding the system functions. Another big advantage of this phase it that it makes the employees believe that they are special to the organisation.

This phase also consists of the activities of discussing future IT strategies. With the ERP system in the business core and effective IT team, an organisation can easily manage to change its business environment and make almost all the activities automatic (Gelogo and Kim 2014). These kind of IT strategies are important for an organisation to stay completive.

Onward and Upward: In this stage, an ERP manager is appointed. The managers are responsible for managing all the activities of the ERP from the ground level to the utmost level (Oseni et al. 2014). Often it has been seen that the management does not analyse all the aspects of the employee dissatisfaction toward or low productivity because of the system. It creates a huge gap between the employees and management. The ERP Manager acts as a medium and sorts out all the issues that are associated with the ERP (Kim, Jung and Young 2015).

Project Idea to Project Chartering: There is a silent stage called project idea within which the stakeholders of an organisation feels the need for a change in the organisation to get more benefit from it or to be competitive (Ram, Wu and Tagg 2014). The reasons in forwarding the project toward the chattering stage are the willingness to adopt change, proper utilisation of the resources, support of the stakeholders, getting a hold on the future market and much more. Te factors that drive these causes are the cost, scalability and flexibility. Though the stakeholders do not acquire any knowledge of the project type in this stage, the support to become more scalable and flexible from the stakeholders are a crucial entity (Verdouw, Robbemond and Wolfert 2015).

The barriers are the limited knowledge, financial crisis, absence of IT team and much more. Suppose an organisation needs to take a crucial step of implementing ERP that will change its business processes almost entirely then having a small amount of knowledge is not enough for the stakeholders (Talib and Hamid 2014). The ERP projects are very costly and often extend way more than its predefined figure. Therefore, various organisations do not move forward to the process of actually implementing an ERP.

Project Chartering to the Project: The project chartering provides all the fundamental information required to the selected project team. However, the issue always remains in transforming the requirements into functions (Norton et al. 2013). The person who collects the information regarding the IT requirements in the business does not directly take part in project development. It often appears that the responsible employee does not record some requirements that later appears as a huge entity in carrying the project successfully. As the resources are limited, the project team does not get the permission for crosschecking the gathered requirements and starts creating the system by the findings (Seth, Kiran and Goyal 2015). These kinds of the situation lead to missing requirements, additional requirements in the middle of a project, failed project and much more.

On the other hands, the drivers of moving from project chartering to the project are support of the stakeholders, allocated resources, pre-gathered requirements and much more. In the project chartering stage, the organisation approves the project with the approval of all the stakeholders which is the biggest driver in this move.

The Project to Shakedown: The project is the process, and the shakedown is the effect. In the shakedown phase, the implemented ERP is deployed in the business environment, and its activities are tracked. The biggest driver is that the gaining-live is the easiest task among all the activities. However, afterwards, activities are not that simple. The barriers to this movement are a lack of skill and knowledge, unsupportive nature of the employees and much more (Nedbal et al. 2014). The ERP projects sometimes consist of employees that are not skilled enough for completing the project. If a single issue remains in the system, then the total development phase is considered as a failure, and the project manager put a hold to deploying the system.

Shakedown to onward and upward: Lack of understanding regarding the system is one of the main barriers to moving from shakedown to next stage. In the shakedown phase, the deployed system is analysed to see any gap in the system remains or not. However, if the user does not have the knowledge of using the system then gathering the accurate and complete knowledge is impossible. The driver is the skill of the test and development team (Ahmer et al. 2016).

Conclusion:

From the above study, it can be concluded that the ERP development project may end with deployment, but the journey of the system remains endless. The ERP journey can be among the most complex IT-related changes that an association can attempt. Given the solid and all-inescapable nature of the product, its spread crosswise over the greater part of the major working offices, and its connection to numerous legacy frameworks, its impact upon associations can be effective, now and then calamitous. It has been something of an ordinary in the venture administration writing to watch that specialised individuals are not the ideal individuals to oversee specialised activities. The wide extent of a normal ERP extend proposes that it ought to never be described as an IT execution. It will dependably be better considered as an IT framework driven authoritative change program. We think that it’s difficult to envision that all the important administrative abilities for such a program could all the time lie with one individual yet by one means or another a blend of individuals, with the correct mix of skills at the perfect time, must be found to deal with the excursion. We speculate that the general populations who can do it truly effectively are few and that they procure their pay rates.

Reference List:

Ab Talib, M.S. and Abdul Hamid, A.B., 2014. Application of critical success factors in supply chain management. International Journal of Supply Chain Management, 3(1).

Ahmer, Z., Demir, E., Tofallis, C. and Asad, H., 2016. Usage of enterprise resource planning systems in higher education institutions in Pakistan.

Antero, M., 2015. A Multi-case Analysis of the Development of Enterprise Resource Planning Systems (ERP) Business Practices. Copenhagen Business SchoolCopenhagen Business School, Institut for IT-LedelseDepartment of IT Management.

Elbardan, H., Ali, M. and Ghoneim, A., 2016. Enterprise Resource Planning Systems Introduction and Internal Auditing Legitimacy: An Institutional Analysis. Information Systems Management, 33(3), pp.231-247.

Gelogo, Y.E. and Kim, H.K., 2014. Optimized ERP System Deployment on Mobile Cloud Computing with AOM.

Hustad, E., Haddara, M. and Kalvenes, B., 2016. ERP and Organizational Misfits: An ERP Customization Journey. Procedia Computer Science, 100, pp.429-439.

Hwang, D. and Min, H., 2015. Identifying the drivers of enterprise resource planning and assessing its impacts on supply chain performances. Industrial Management & Data Systems, 115(3), pp.541-569.

Khan, S., Babar, M., Khan, F., Arif, F. and Tahir, M., 2016. Collaboration Methodology for Integrating Non-Functional Requirements in Architecture. the Journal of Applied Environmental and Biological Sciences (JAEBS), 6, pp.63-67.

Kim, J.H., Jung, R.D. and Young, C.C., 2015. A study of success and failure in ERP implementation: the case of the agricultural products processing center. Int J ue-Serv Sci Technol, 8, pp.183-194.

Lawrence Norton, A., May Coulson-Thomas, Y., Coulson-Thomas, C.J. and Ashurst, C., 2013. Ensuring benefits realisation from ERP II: the CSF phasing model. Journal of Enterprise Information Management, 26(3), pp.218-234.

Nedbal, D., Stieninger, M., Erskine, M. and Wagner, G., 2014. The Adoption of Cloud Services in the Context of Organizations: An Examination of Drivers and Barriers.

Nwankpa, J. and Roumani, Y., 2014. Understanding the link between organizational learning capability and ERP system usage: An empirical examination. Computers in Human Behavior, 33, pp.224-234.

Nwankpa, J.K. and Roumani, Y., 2015. Real Options and Subsequent Technology Adoption: An ERP System Perspective. In System Sciences (HICSS), 2015 48th Hawaii International Conference on (pp. 5020-5027). IEEE.

Oseni, T., Rahim, M.M., Smith, S.P. and Foster, S., 2014. An initial empirical evaluation of the influence of erp post-implementation modifications on business process optimisation.

Qrunfleh, S. and Tarafdar, M., 2014. Supply chain information systems strategy: Impacts on supply chain performance and firm performance. International Journal of Production Economics, 147, pp.340-350.

Rahman, M. and Ripon, S., 2014. Elicitation and modeling non-functional requirements-a pos case study. arXiv preprint arXiv:1403.1936.

Rahman, M.A. and Saha, B., 2016. An Assessment to Identify Causes of ERP Implementation Failure and to Predict Its Success: A Case Study on Beximco Pharmaceuticals Limited.

Ram, J., Wu, M.L. and Tagg, R., 2014. Competitive advantage from ERP projects: Examining the role of key implementation drivers. International Journal of Project Management, 32(4), pp.663-675.

Schwalbe, K., 2015. Information technology project management. Cengage Learning.

Seth, M., Kiran, R. and Goyal, D.P., 2015. Waning the Challenges in the Implementation of Supply Chain Management Information System: A Study of the Indian Automobile Industry. In Managing in Recovering Markets (pp. 473-484). Springer India.

Tasevska, F., Damij, T. and Damij, N., 2014. Project planning practices based on enterprise resource planning systems in small and medium enterprises—A case study from the Republic of Macedonia. International journal of project management, 32(3), pp.529-539.

Verdouw, C.N., Robbemond, R.M. and Wolfert, J., 2015. ERP in agriculture: Lessons learned from the Dutch horticulture. Computers and Electronics in Agriculture, 114, pp.125-133.