Successful ERP: The Third-Party Service Provider -- How to Lower Costs and Receive Greater Value

With the demand for enterprise resource planning(ERP)returning after the Y2K jitters, more large-scale enterprise projects and the need for implementation services are necessary. Learn how to successfully negotiate third-party ERP to receive maximum benefits at minimum cost.

• 11/01/2000

Despite early reports of the demise of enterprise resource planning (ERP) software, the industry has apparently overcome the Y2K jitters and production (and consumption) has, again, surged as a new wave of Internet-enabled applications has hit the streets. With the demand returning and the new supply now in place, more large-scale enterprise projects, and the inevitable increase in the need for implementation services are necessary.

As a current employee of a high-growth consulting firm, there have been many times where I find myself in positions to simply answer any client request with, "Sure, we can do that." However, I have recognized that being a consultant is not simply about successfully fulfilling client requests. In fact, it is quite the opposite.

In some subconscious manner, saving clients from themselves is what the vast majority of individuals who hire service providers are looking for. Thinking back, that is what I had always looked for when bringing in consultants – I typically knew the subject matter, but was just not comfortable with committing to an idea until I had somebody there to implement it. Subconsciously, I was always looking for the implementer to subtly shoot holes in the idea. By not saying anything, they would just indirectly validate the idea.

Therefore, the first thing I present at any client introduction is a simple model with an implementation project – and I vehemently stick to it. I start by explaining, "There are, generally, three major roles a consultant can provide in an enterprise system project: technical expertise, functional expertise and leadership." We can do them all, but what makes the most sense is starting that decision-making process by defining what you, the client, is most concerned with avoiding: An ERP project that is over-budget and late, results in inadequate function or performance or some combination of these.

As technology becomes more complicated, systems implementations and integration becomes increasingly difficult. As a result, the technical expertise with a particular technology or packaged solution may not be available in-house, or your staff may have enough on their plate maintaining current development and support activities. Furthermore, the pace of technology in today’s business means you likely can’t afford to go through a formal hiring or special training process just to get your project off the ground. Using these technical experts to receive a quicker return on your technology investment just makes sense.

Functional expertise can be just as critical. Typically, the biggest disconnect for a packaged software solution is between the new processes and functionality of the software and the current end-user knowledge base. Good functional experts, or subject matter experts (SMEs), or "super-users" – there are a variety of names and descriptions – simply help reduce that disconnect. This is done through fit/gap sessions, system configuration and data conversion, process redesign and/or reengineering, best practice solutions, conference room pilots, train-the-trainer and change management. All of these tasks help make the transition to a new system much easier. Remember that you can have the most technically impressive system in the world, but if your users refuse to support it, the project will be unsuccessful.

Now for my "pet peeve" for technical and functional consulting: knowledge transfer. Why not start with the biggest transition failure point for most large-scale implementation projects? Most IT leaders would agree that technical and functional experts are necessary for the majority of a project’s lifecycle. Unfortunately, what typically happens at the end of the lifecycle is one of two scenarios, or a combination of both: 1) The service provider picks up and moves on to the next project leaving your company in chaos with both limited technical and functional knowledge of the new system, or 2) Your company recognizes this void and chooses to retain (or bring back in) the service providers to support your system – sometimes staying forever.

Now, I am probably not telling you anything you didn’t know about the world of consulting. What I want to confirm for you, is that this is not a healthy scenario for anyone involved, and that both parties (client and service provider) are equally to blame. Fortunately, the solution is relatively simple: Part of the knowledge transfer should be in the form of comprehensive documentation that details the care and feeding of the new system. Encourage your consultants to work with your staff to create this throughout the project lifecycle (not the week before they leave). The other part of the process includes having your own staff walking (not running) through the whole implementation process. Ideally, this should take place as your staff works side by side with the service providers.

Let’s assume, for a moment, that you have been successful in establishing a healthy technical and functional team, composed of consultants and your internal staff, and ground rules have been laid for transferring knowledge. At this point, you are on your way, but there is still one large piece missing from your project’s success: Leadership – perhaps the most difficult "role" to define. It really brings up an age-old client/consultant confrontation: "Who is leading this project, anyway?"

For years I have read about and listened to why you should not let consultants drive your project. The consultant typically has entered into a traditional "time and materials" arrangement usually accompanied by "estimates" of their man-hours projected for the engagement. And, very often, the project goes over your budget because you based it on the consultant’s estimates and the project actually took longer and consumed more resources and overall hours than anticipated. Why? The service provider has no incentive to finish early, on time or within budget. Sure, you do, but they do not share the same pain when the project goes "over."

You can then work the next time (assuming there is a "next time"), to lock your service providers into a "fixed fee" arrangement. That way, you know your budget and you are able to hold them to a ceiling fee. Interestingly, this second scenario seems to produce a lesser quality product than you originally envisioned and your consultants typically skip town a little quicker than you anticipate, leaving you with a major gap in your knowledge-share strategy. If your end product actually turns out to be quite functional, you probably will have gone through enough change orders to fill a garage. When you look at the final cost, including the work associated with those documents, you will likely be, once again, over-budget.

So, now you are thinking about that hot topic you read recently on "gainsharing." Gainsharing, risk/reward, creative partnerships – all the vogue names for establishing relationships with your product vendors and service providers where they have some "skin in the game." Yes, this seems to be the preferred path to take. However, this is also where consulting "leadership" comes into play.

The reasons for having a consultant play a managerial role in your implementation project are numerous: experience ("been there, done that"), proven efficiency and cost-effectiveness (look at their resume and talk to their past clients to verify, of course), ability to transcend internal political agendas, etc. You simply cannot underestimate the value of a trained professional with project management skills on large-scale technology projects. However, maybe most important to the success of your project is their role as it relates to their firm having "skin in the game."

The model is simple. Make the consultants put their money where thier mouths are. If we say we can effectively implement your system in six months with x-number of resources, then make us share the risk of not achieving that goal. There are several methods to this approach: You can use defined metrics for returns on the final product, or set a floor and cap on the implementation time where anything in between results in splitting the gains between yourself and the service provider, or you could even keep it as simple as setting up a rating scale that allows you to reward (or penalize) the consulting team based on your objective assessment of the outcome of pre-defined phases of the project.

Note, the key to my agreement with these terms is a clearly documented set of assumptions and my ability to have a lead role on the effort. In other words, give the service provider a level of responsibility that matches their accountability.

There are other ways you can supplement this model that clearly help in its ability to translate into a successful project. These include using local or regional firms that have even more "skin in the game." If they have not formally aligned with other vendors, your chances of a true, unbiased perspective are increased. A service provider’s intimate knowledge of your business can be a real asset.

The further you stray from these basic elements, the more difficult it will be to turn over your project to a consultant, or to even share that responsibility. And that brings up a final point on the "roles" I have found to be successful: No one should be the final arbiter of their own work – neither the client, nor the service provider. If your consulting firm of choice has leadership you find capable of leading your project, you as the client obviously still need to play a quality assurance (QA) role. If you can’t, in good faith, give that level of responsibility to your preferred implementation partner, than they should be allowed to QA your management of the project.

An alternative plan for the QA role can be developed using your software vendor. The "Second Party" in your project can potentially do much more than simply sell their product. It is very likely that they possess a competent, albeit pricey, service "arm" that you can use to supplement your implementation team. In my experiences, the QA role is likely the most cost-effective and efficient use of their services, and the same rules we have discussed for all consultants should apply to contracting their services, as well. And that is the crux of the model: Treat these relationships as partnerships. However, be aware, that requires all parties to share in the successes and share in the failures. The good news is, this former client-turned-third-party service provider, has proven it can work.