Size Small Medium

Introduction: Proper Planning to Reduce Risks of ERP Failure

In the initial article, we discussed how a well-structured system assessment scorecard may aid Small and Medium-sized Enterprises (SMEs) mitigate enterprise resource planning (ERP)[1] implementation failure risks at the system acquisition stage.

In this article, we outline sure steps SMEs may take to mitigate ERP implementation failure risks in the subsequent phase of implementation: the planning phase.

Briefly defined, the planning phase is the stage for the duration of which the establishment prepares to “ERP-ize” it is business. An ERP project requires much more than the mere installation of an IT software system. It requires organizational restructuring.

Generally, SMEs have to restructure their operations to satisfy the business flow parameters specified by the ERP software. These days, most ERP software packages are pre-customized to spheres according to sure industry best-practices.

The extent of organizational restructuring that is required depends on the structure of existent business processes, and on the technical and functional requisites imposed by the ERP software.

As with any complex restructuring project, ERP implementation is accompanied by sure risks of project failure. For example, failure may result from a runaway implementation that causes the project to become uneconomical. It may also result from organizational rejection of the restructured surroundings where such rejection impedes the accomplishment of the projected efficiencies.

In the following sections, we elaborate on these peculiar risks of implementation failure and how effective implementation planning may mitigate these risks.

Failure Risk 1: Run-Away Implementation

If an SME is planning to apply ERP, it is primary reason for doing so is probably to achieve cost efficiencies. According to 2009 exploration by the Aberdeen Group, the need to reduce operating and administrative costs proceeds to be the main driver of ERP acquisition in the SME segment [2].

Since financial reasons drive the decision to employ ERP, it is critical that the implementation be finished within budget. A failure to deliver an economical implementation will mean project failure.

Since this section deals with ERP-related finance, it is primary to briefly talk about a great deal of of the underlying principles.

The cost side of an ERP budget is based on a total cost of ERP ownership (TCO) calculation. TCO is the sum of the present values of system, maintenance and service costs. System and maintenance costs are fixed and largely determinable in advance.

In contrast, service costs are normally highly variable and difficult to project with accuracy. Further, service costs are proportionately significant. In 2007, service costs accounted for 45% of TCO for SMEs. Put another way, for each $100 an SME expended on ERP software, it expended an further and added $81 on service [3]. As you will have in all likelihood guessed, service costs primarily reflect implementation costs.

Poor scheduling, improper resource allocation, project delays and scope creep (i.e. unplanned increments to the project’s scope) are the general culprits for runaway implementation costs. The basi three are in general well understood. Scope creep deserves a bit more attention.

During implementation, there is a holy-grail temptation to “ERP-ize” sure business processes that were not included in the original project plan. The rationale supporting a scope increase is that incremental efficiencies will be gained by “ERP-izing” the further and added tasks. Implementation seems like the perfective time to widen the scope: the project is underway, consultants are on internetlocation and the teams are dedicated.

These temptations must be resisted. Implementation is seldom the right time to widen the scope (except for dealing with unforeseen items that must be addressed).

The reason the temptation must be resisted is because the argument favouring unplanned scope changes only accounts for the gains side of the financial equation. Incremental costs ought to also be considered. These costs include direct service costs as well as the chance costs of delay. With respect to the latter, each unplanned day that the SME is unable to operate underneath the new system is a day of lost efficiencies.

It is reasonable to assume that an ERP project scope is designed to maximize the net ERP gains (net gains = cost efficiencies – costs). This means that all constituents of the project that yield a positive net gain are accepted. It likewise means that all parts that yield a negative net gain (where the incremental costs exceed the incremental efficiencies) are rejected. Unplanned scope increments are distinctively elements that would yield negative net benefits, i.e. they would be unprofitable. Since they diminish the return on ERP investment, these elements will have to be rejected.

The following graph (omitted) depicts the kinship amidst a project’s gross costs, gross efficiencies and net gains (net gains = gross efficiencies – gross costs). As seen by the Net Benefits line, the idealisti project plan is at Point A. At this point, all profitable constituents are accepted and all unprofitable elements are rejected. Any project plan that lies to the left of Point A would mean that the plan could be fruitfully expanded. Any project plan to the right of Point A would mean that unprofitable constituents are being accepted. Scope increments are in general constituents that lie to the right of Point A.

The above profitability analysis explains why incremental scope changes are both unnecessary and unbeneficial to the project. As time passes, these incremental changes will either be ignored or enforced as portion of a profitable optimization plan.

In summary, a well-structured plan may mitigate the financial risks related with overly wide scope definition and scope creep. Such a plan will help keep the ERP project within budget and on time.

However, even if financial risks are mitigated, other types of failure risk still threaten the project’s success. One such danger is that sure key people will reject the new ERP system and/or the restructured business processes.

Failure Risk 2: Improperly Managed Change

Restructuring is a necessary evil. It causes the SME to undergo substantial and disruptive changes. For example, the SME’s organizational and reporting structures will likely modify as departments are shifted. Its operations will likely modify as business processes are re-engineered. Daily tasks will likely modify as manual tasks are automated. All of these changes mean that employees, management and executives will have to unlearn old habits and learn new ways of doing business.

Some persons will hug the challenges and prospects staged by the change. These humans will support move the project forward. However, there will be those who fear the uncertainties affiliated with change. These persons may protest the project and may peril undermining it is success.

Change resistors are powerful forces. Even comparatively innocuous-seeming resistance may thwart success. Consider, for example, the case of a sales person at a manufacturer who decides not to input an order into the new ERP system. Instead, the employee calls the order into production – the way he had always performed the task underneath the old system. Although the order is now in the procedure queue, it was not registered in the ERP planning system.

This one omission may have severe and far-reaching consequences. Automated production planning, shop floor scheduling and material movements planning become inaccurate and unreliable. These inaccuracies will prevent sales humans from supplying precise lead time quotations. As a result, sales relationships will become strained and clients will be lost. The unplanned production backlog will likewise cause an increase in inventory-related costs. Further, real-time performance reporting will become less precise since the reports fail to include sure transactions. Unreliable reports will negatively affect management’s capacity to make primary and timely decisions.

In summary, a failure to buy-in to the new system and processes may cause the institution to fail to reap the efficacy and informational gains of ERP. The result: an uneconomical ERP investment.

The above is but one example of a alter resistor. Generally, an establishment faces dissimilar groups that protest alter for dissimilar reasons. Common examples of resisting forces include:

· A union that objects because it is members’ occupation functions would modify as a result of procedure re-engineering and automation.

· Employees who object because they have performed the same manual assemblage tasks for 20 years and are affrighted of or don’t want to learn new processes.

· Managers who object to donating their “A-players” to the implementation team. The loss of key performers would closely surely have a negative affect on departmental performance.

· Executives who object to short-term business interruptions caused by the restructuring project, nevertheless the long-term benefits. This moral hazard is caused by an incentive system that rewards the executives for short-term performance. Interruptions may cause the SME to miss compensation targets.

Fortunately, a good deal of of the respective humane capital forces that may sabotage an ERP-driven restructuring may be mitigated at the planning stage.

Good Planning Lessens Failure Risks

A good implementation plan accomplishes two goals:

1. It presents a without doubt or question marked and easy-to-follow roadmap to utilise the procedure changes and ERP system; and

2. It prepares the institution and all potentially affected stakeholders to adjust to the changed environment.

A plan that achieves these twin goals will significantly support the implementation project’s chances for success.

Although each plan must be customized to meet the SME’s peculiar needs, there are sure rudimentary principles that may frame the design of each project plan. These principles relate to project championship, project plan design and team formation.

Project Championship

Top management is in the end responsible for allocating time, resources and cash to the project. Its collective attitude towards the project filters down and impacts organizational dedication to the project. Consequently, top management aid may make the project while it is absence of help may break the project.

Given the importance of executive commitment, the project requires a top-level manager to convert the non-believing managers. This person must be both totally committed to the project and capable of influencing others’ commitment. In his capacity as project champion, this person will be responsible for ensuring that the project remains a top priority and is allocated the resources that are required. In other words, the project champion acts as an advocate who drives change, inspires persistent determination and manages resistance. Ultimately, it is this person who legitimizes the project and the accompanying organizational change.

Project Plan

The project plan is a formal document that is instrumental in preventing runaway implementations and modify resistance.

If done properly, the project plan helps prevent runaway implementations by memorializing the project deliverables on a timeline and allocating a specific budget to each deliverable. Each deliverable will have to be broken down into manageable and measurable tasks. A well conceived roadmap prevents scope creep, cost overruns and project delays.

The details of the project plan ought to be (to the extent necessary) transparent all around the entire organization. Communicating the project plan will diffuse a part of the organizational anxiety by eliminating ambiguity in regards to the project and the future state of the organization.

In terms of it is components, the main project plan should, at a minimum, include the following:

Project Charter:

This is an articulation of the project’s mission and vision. It distinctly and unambiguously states the business rationale for the project.

Scope Statement

This defines the parameters of the project. The scope is broken down into measurable success constituents and strategic business attainments that drive the intended results.

Target Dates and Costs

This sets out person milestones. Identifiable, manageable and measurable goals are established. Target completion dates are set. Each person milestone is valued. This step articulates the breakdown of the project into discrete sub-projects.

Project Structure and Staff Requirements

This sets out the project’s reporting structure, and how that reporting structure fits into the more prominent organizational structure.

The main project plan will have to be supported by whatsoever subsidiary plans are necessary. Common examples of subsidiary plans include: IT infrastructure and procurement plan, peril plan, cost and schedule plan, scope management plan, resource management plan, and communications plan. For present purposes, these last three subsidiary plans is worthy of a bit more attention.

Scope Management Plan

This is a contingency plan that defines the routine for identifying, classifying and integrating scope changes into the project.

Resource Management Plan

This sets out person assignments, project roles, responsibilities and reporting relationships. It likewise sets out the criteria for back-filling positions and modifying project teams. Further, this plan details humane capital development and training plans. Finally, where necessary, it sets out the reward scheme employed to incentivise project performance.

Communications Plan

A communications scheme is critical to manage alter resistance. This plan codifies the procedures and responsibilities relating to the periodic dissemination of project-related selective information to the project teams and allround the organization. Examples of mutual channels include email newsletters, press releases and team meetings.

A good project plan is only effective if the project teams are competent of executing the recommendations. For this reason, team formation and training are critical parts of the planning phase.

Team Formation

Successful execution requires an enabling structure. Like some well-structured organizations, an ERP project structure must integrate a steering committee that has executive-level strategic responsibilities; a core team that has managerial-level delegation authority; and functional teams that are responsible for implementing the changes.

To facilitate communicating and decision-making, each hierarchy level must have a fellow member who is represented on the level below. For example, the ERP project manager must sit on both the steering committee and the core team, and sure key users ought to sit on both the core team and a given functional team.

The Steering Committee

The project steering committee ought to be comprised of the chief executive officer, the CIO, executive level business managers, and the ERP project manager. The committee has strategic-level obligation for reviewing and approving the project plan, making changes to the plan and assessing project progress.

The Core Team

The core team is responsible for managing the implementation project. It will have to be comprised of the ERP project manager, functional leads, the outside advisors and sure key end-users.

Functional leads will have to be top-performers who are reassigned to the implementation project on a full-time basis. They ought to be experts in their respective departments, must understand other departments’ business processes and will have to be welleducated with regards to industry best practices. In a heap of cases, functional leads will have to be backfilled in their day-to-day jobs.

During the planning phase, the core team is trained on the basi principles of ERP theory and on the particulars of the ERP software. The intention of the training is to assure that the core team is competent of managing the development of the new business processes.

Functional Teams

These teams are responsible for implementing the business routine changes in their respective functional departments. Each functional team is comprised of a core team key end-user, select end-users that cover all of the functional unit’s business processes, and a functional advisor with an understanding of the ERP software.

Organizing consecrated and capable teams is critical to the project’s success. The project teams will be responsible for managing the implementation and helping the establishment adjust to the new business environment.

Conclusion

ERP implementation is a complex project that involves substantial operational restructuring. The restructuring is accompanied by sure risks of project failure, including runaway implementation and resistance to change.

Fortunately, an SME may mitigate a good deal of of the ERP failure risks by decently planning for the project. At a minimum, proper planning requires a project champion to secure executive buy-in, the preparation and communicating of a project plan that breaks the project down into manageable sub-projects, and the assemblage of strong teams competent of executing the project.

[1] Briefly, an ERP scheme is intended to electronically incorporate an organization’s functional areas, administrative areas, processes and systems.

[2] Jutras, C. (2009). ERP in the Midmarket 2009: Managing the Complexities of a Distributed Environment. Boston: Aberdeen Group.

[3] Jutras, C. (2007). The Total Cost of ERP Ownership in Mid-Sized Companies. Boston: Aberdeen Group.

Size Small Medium Image

Size Small Medium Picture

Size Small Medium Pic