Stalled ERP Implementations: Get Back to Business
Remediating a failed ERP implementation may be the answer to salvaging a broken, stalled or underperforming enterprise system. Each type of implementation failure and subsequent remediation project is approached with a different strategy. The goal is to economically get business operations and technology back in sync, quickly and effectively.
A stalled implementation represents an ERP system that never quite reached a state of production readiness. Various modules may be in production, but other critical components remain to be implemented or were never quite finished. In the latter case, the business processes defined for modules in production are relying on information from the unfinished modules.
The result is a variety of manual workarounds required to provide the missing information. Companies suffering from stalled ERP implementations fail to reap the benefits that initially justified implementing the system. They’re potentially saddled with processes that take longer than before.
This type of ERP implementation failure creates not only process problems but can increase tension between various departments. Those departments saddled with additional workarounds are forced to make up for the missing and/or non-implemented components.
Stalled implementations can result from:
- Staffing changes
- Lack of management commitment
- Obstinacy on the part of the non-production user departments
Challenges
Stalled implementations are often the most difficult to detect, in that the underlying issue is political in-fighting between various departments. ERP systems often redistribute work amongst departments requiring one department to capture information to be used later by another. This addition of work to benefit another department raises the question of “why us?”
This is particularly true if workloads are high and pressures to maintain previously established performance metrics are unrelenting. If company and management are not attuned and aggressive in addressing this question, the resistance of one group can create problems for all.
Requirements & Commitments
Remediation of a stalled implementation requires a skilled consulting partner or contract team and a serious commitment by company management.
The company and its consulting partner must:
- Analyze the source of reasons for the delayed production status
- Make realistic determinations concerning the validity of those reasons
- Establish and agree upon a plan to address the reasons for the delay
- Complete the implementation of stalled modules
It’s the potential political nature underlying the stalled implementation that makes it amongst the most difficult to remediate. The challenge is rooted in addressing issues during remediation that the company and management weren’t able to resolve during initial implementation.
Of the reasons you propose for failed ERP implementations you don’t mention two I have found more impactful:
- A poor effort on behalf of the IT organization or the project team to gain the necessary ‘emotional energy’ from functional leadership early on to see the program through.
- A poor fit of technology and process in the first place.
As I see it, either of the two are often the result of the technology organization believing they know best on behalf of the overall business, creating a suspicion of arrogance and a resulting loss of trust.
Am I missing something?
I would add two other reasons also that are just as impacting.
- the lack of control and leadership of the consulting partner to allow aggressive departments to “push” out of scope agenda or additional extensions or customizations causing budget or schedule constraints on the project that cuts into other areas.
- a short fall of a proper gap analysis to address proper solution design in the areas being sacrificed that lead to delivering an incomplete or inappropriate solution.
We at ERTechnologies have had a many requests that are flatly bailout remediations from clients recently gone live and experience various levels of inadequacy from thier implementations.
Rick – thanks for your comments. In many respects I agree with you. While there may be many reasons contributing to the result, it is often the result of IT having been given a mandate to address a problem in one area and electing to address broader issues without adequate buy-in or agreement from other key functional managers that there is a problem that needs to be addressed.
I worked with one client; a project oriented manufacturing/services firm that installed an ERP system to address accounting and billing needs while the company ran on spreadsheets. When I got involved they had defined the problem (courtesy of another consulting group) as a workflow issue requiring control over massive (7 MB) spreadsheets that they were e-mailing throughout the organization as a project passed from sales, to engineering, to manufacturing, to the field for installation.
This implementation was the direct result of the operational managers initially believing that they could operate the company without a real system. I wound up taking a team of these operational managers through the process of identifying internal procedures/process steps, demonstrating several workflow approaches to addressing the stated requirements, and then showed them what their ERP system could do with their currently purchase/installed modules, and then how it would fit if we added a workflow component.
The end result was that EVERYONE agreed their problems were more than just the workflow and the team took the conversation to the executives to implement their ERP as a production system with the addition of the workflow components.
I believe, as you’ve pointed out, that initially the operational managers were too involved with their own needs to devote the attention and emotional energy to implement the ERP system properly on the first go-round. Unfortunately, it was a situation of things needing to get worse (business increased four-fold in two years) before people understood the roots of the problem.
Regards
Jason
Haynel – Yes AND …
I’ve noticed that with US companies there is a tendency to address a problem by writing a check. In many cases there seems to be an expectation that writing the check is all that is required of the client company and all the remainder of the work is the responsibility of the consulting partner … along with the thought that the check is carte blanc to solve the problem however the company subsequently defines it. Having worked for a European consulting firm just after it entered the US I quickly realized the difference in their expectations of the client and what US clients were expecting.
The problem of scope creep is possibly the result of or aggravated by the absence of a good fit/gap analysis between existing processes and the system being implemented.
Regardless of how or why, it does seem that those of us who provide the consulting are expected to work “magic” on more than one front and more than once in order to create a satisfied client.
All I can say is persevere … there are enough poor implementations that those of us who understand are needed.
-Jason