Business Solutions with SAP

9 Games ERP Consultants Play

January 14th, 2013 by

ERP Consultant Games

Most in the ERP industry agree that software consultants can play a major role in helping their clients successfully implement a new ERP package. While some consulting firms have more expertise than others do, at least most firms try to operate with their client’s best interest in mind.

However, there are many firms within the ERP industry that are outright thieves. They will not hesitate to take advantage of their clients in order to pad their own wallets. In fact, some firms are so good at this it has become part of their standard operating procedures.

Clients that are educated and aware of the games consulting firms play can save themselves a few headaches and a lot of money. Below are some of their tricks to watch out for.

1)      The “Bait and Switch” Routine

During the sales process, this is when certain consultants are brought in to display the expertise within the firm. They may know best practices and the software, but it might be the last time you ever see them.

2)      Resumes: Lies and Half-Truths  

Outright falsification of consultant resumes is more common than you think. In addition, many resumes presented by the firm are not really resumes, but vague “profiles” that lack detail and read like sales literature.

3)      “Lowballing” the Quote

This is the oldest trick in the book, yet surprisingly many clients continue to fall into this trap. For example, all consultants know that for time and material quotes the actual implementation costs are usually much higher.  Also, most fixed price quotes are only fixed until further notice.  When the client wants to make only minor changes in the project scope, they are hit with expensive change orders. The change order costs are usually 100% greater than the actual time for the consultants to perform the work.

4)      The “Best” Implementation Tools & Methods

Most firms claim to have the very best implementation methods and tools available. However, do not be surprised when their consultants run off and do something entirely different during the project. Maybe the tools are not so great; otherwise, their consultants would use them!

5)      The Less You Know – The More Money They Make

For some firms, a potential client that has ill-conceived project objectives, an undefined scope, or lacks basic knowledge of ERP; is considered a gold mine. The idea is to gloss over these “minor” details until after the client signs the contract.

6)      Marquee Accounts for Reference Checks

When a potential client asks for a list of the firm’s other clients for a reference check, many firms provide only their “marquee accounts”. These accounts are compensated by the firm in some form for being a reference. Therefore, do not expect these clients to mention anything bad about the firm.

7)      Not Enough Time and Talent

Most consulting firms would love to “camp out” on your ERP project. One way to do this is convince the client that the organization lacks the right employees for the project. Also, some firms too easily support the premise that the client’s best employees have other tasks to perform that are more important than an ERP project. That is, “No need to get your hands dirty. Our consultants will do the project for you.”  

8)      “Add-on” Services 

Once consultants get their foot in the door, many try to sell their clients additional services. These include more consultants for readiness assessments, change management programs, best practices, and other services you may not truly need. Also, do not be surprised when your consultants push for software functionality that was originally out-of-scope. 

9)      The Promise of Software Knowledge Transfer

Most firms state that one of their goals is to “work themselves off the project” by transferring software knowledge to the client. However, nine times out of ten, if it is going to happen, the client must force the issue. Considering their hourly rates, what incentives do consultants have to transfer software knowledge?

This guest post is by Steven Phillips, author of the Street Smart ERP blog and the new book Control Your ERP Destiny.

Popular Searches:

  • saxi vedio
  • saxi move
  • Wwwsaxivdeo
  • sap www saxi
  • erp consultants resume
  • saximove com

Related Posts:

Some Reasons SAP Projects are Over Budget and Over Time

July 11th, 2009 by
Storm Clouds pointing to SAP projects over budget and time

SAP Project Blown Budget-Timeline

For years I’ve heard the claims about blown SAP budgets and blown SAP project timelines. Participating in SAP projects since 1994, on over 20 SAP projects, I’ve experienced a few project overruns [FN1] and on a few others, we have come in under budget.  I can’t say any of the projects were ever early. While I believe that coming in under budget is often possible reducing the time frame is much more difficult because of the planning and coordination processes.  Trying to adjust all of the parallel work streams together on a project plan, and getting the coordination and timing correct is much more of a challenge.  In other words there are lots of moving parts that you have to change the timing on.  That is unless you are an SAP “project manager” who has an aversion to using normal WBS, Network, and Activity based project plans.

Aside from 1) scope management, 2) executive buy-in and participation, and 3) using a proven methodology, etc., there are other reasons that cause some SAP or ERP projects to go over budget and over time–, there are basic issues of project coordination and consultant skill.

SAP Project Management Planning and Coordination

After the scope, deliverables list, and a project plan you need good monitoring tools.  A project manager must also consistently communicate the timeline and deliverables ahead of time, throughout the project, to mitigate blown timelines.  They must also provide key templates and the instructions on using them effectively throughout the project, ahead of time.  However there are still other project management planning issues that must be addressed.

A good project plan and methodology will have “tools” and templates that are sophisticated enough to allow time to resolve resource and task leveling constraints.  The deliverables must be designed to support the completion of key milestones and project activities so that they demonstrate not only completion but quality as well.  More than just a “checklist” deliverables should instill some confidence that the project activities they address were done well.

Project plan micromanagement has a way of killing project momentum and destroying project team morale

If deliverables tracking “tools” are not able to support task and resource completion status of the deliverables then a project manager does not have the correct tools to make critical resource leveling decisions.  Your project and its deliverables will be inconsistent and untimely. And by deliverables tracking “tools” I am NOT referring to the project plan.  Project plan micromanagement has a way of killing project momentum and destroying project team morale.  For more information on this, please see the first section in ERP, SAP, or IT Project Management and Prototyping for Success .

One of the biggest problems I have seen from inexperienced project managers is planning at such a detailed level that they spend all of their time micromanaging individual tasks and miss a lot of the “trains” coming at them further up the project track. They overload a project with the “appearance” of managing it through stupid “trackers” and monitoring tools that are overly complex and add little value to the project.

If you have the wrong consultants on the project you will be forever in design mode throughout the entire project which may blow timelines and budgets.  One of the unfortunate side-effects of this type of consultant is that you generally begin to get that sinking feeling around integration testing time.  And by the time you are at integration testing you have moved so far down the track that it is sometimes too late.  For some ideas on how to prevent this, please see the post on  Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results for some techniques and ideas on reducing this type of consulting mismanagement.

Business Process Chains are Only as Strong as their Weakest Project Link

SAP’s integration between all of the functional modules creates interwoven process chains.  These process chains require complete dependence on each other during an implementation so that the integration touch points between the modules are properly designed. For example, SD (Sales and Distribution) and MM (Materials Management) must tie into FI (Financials) for the posting of Revenue (SD-FI), issuing stock from inventory (SD-MM-FI), scrapping stock (MM-PP-FI), and a whole host of other areas where there are tight process dependencies.

As an SAP project (or any ERP project) progresses, each of those process silos (SD, MM, PP, FI, CO, TR, HR, etc.) has to be coordinated so that they are at roughly the same place at roughly the same time. If you are doing configuration of master data in one area, such as the material master setup, purchasing, sales, production and finance can’t be very far ahead. There is a direct dependency on the material master. And for finance, if you are doing the setup for the sales and invoicing processes it is important to slow down enough to ensure that the accounting for revenue recognition and customer receivables is properly configured. If any module gets too far out in front of other modules it can have devastating impacts on the others. There may be a lot of rework or re-design needed, or, if a dependent area gets too far ahead they may be consuming too much of the other module consultants’ time and attention trying support that modules integration points and their work may suffer unnecessarily.

Keys Why SAP Project Timelines and Budgets are Blown

What are some of the other key problems that cause budgets and timelines to be blown?

The first and most obvious is when the timeline and scope are not realistic.

Beyond this it can also be anything that causes any one project area to get “out of synch” with another project area.  Some of the reasons for projects getting out of synch include when scope is too large in one particular module for the number of resources assigned. It may be that one consultant or module is far behind, or far ahead, of another module for any reason at all.

Other times it may be that the business has not dedicated the right core team members and they do not have sufficient knowledge of the business, or know where to get it.  When the wrong business-side core team members are assigned to a project you can be sure there will be lots of missed items and lots of rework no matter how skilled a consultant or system integrator is.  There is little substitute for the business-side resources and their level of experience within your company and industry.

A consultant’s lack of experience, or exposure, or, if they are a fake (which is VERY common in the SAP world) may contribute to problems.

There are two solutions to many of these issues.

1) The first and most important is to make sure your vendor staffs your project with only the right consultants with verifiable and deep SAP experience (see Screening and Interview Methods to Find the Right SAP Consultant and Screening and Interview Methods to Find the Right Consultant – Part 2).

2)  After that, it is a project manager’s responsibility to ensure that client and consulting resources are leveled and adjusted as necessary throughout the project.  When a project manager tries to manage a project at a too detailed task level they can get “lost in the weeds” and not realize that their project is headed for trouble.  The project manager must have the tools and resources to recognize if the teams are on track, off track, or starting to get out of synch. And the tools to support this must be sufficient enough to allow early enough notice to make the necessary staffing and resource adjustments.

In a nutshell a project manager must have a list of deliverables, and with that list of deliverables a set of mechanisms for tracking the progress on those deliverables which roll into the project plan.


[FN1] I attribute that success rate to the two consulting companies that I worked at before going independent. They had philosophies about implementation that helped clients realize success. Both of them had very focused policies about getting experienced consultants who had both SAP and business experience. In all the years since I’ve been independent I have seen few projects with that caliber of consultants. It took me a while to realize that these companies I worked for early on frequently staffed projects with what would be considered today as “Platinum” level resources.

Additional Resources for SAP Projects:

Some methods to reduce SAP or ERP project stress

Reduce SAP Project Stress: Part 1 Setting SAP Project Expectation Setting

Reduce SAP Project Stress: Part 2 SAP Project Integration Points

Planning a Smooth SAP Go-Live

Planning For a Smooth SAP Go-Live: Part 1

Planning For a Smooth SAP Go-Live: Part 2

Planning For a Smooth SAP Go-Live: Part 3

Planning For a Smooth SAP Go-Live: Part 4

How to screen for SAP consultants
Avoid fake SAP resumes, fake SAP experience, and get the experience you pay for.

Screening methods to find the right SAP consultant

Screening Methods to Find the Right Consultant – Part 2

Corporate and Personal Liability for Fake Consultants

Related Posts:

Planning For a Smooth Go-Live: Part 3

October 24th, 2008 by

 SAP smooth go-live process issues

3.      ERP or SAP Process issues 

Let me start with a caveat to this section.  No matter how good, thorough, experienced, or conscientious a consultant or a core team member is, there will always end up being a few process gaps, and an occasional completely missing process discovered at go-live.  Now that the caveat is out of the way, there are many reasons for the process problems: inexperienced consultants, company employees who miss some of the process exceptions, inadequate training, insufficient integration testing, lack of user acceptance testing, and other reasons. 

The bulk of the items causing process problems generally fit into three core areas, 1) design or blueprinting, 2) change management, and 3) testing. 

SAP / ERP Design and Blueprinting 

Your business probably developed numerous processes and exceptions over many, many years.  Some of those processes were also developed as the need arose, and in an ad hoc manner and may have many inherent inefficiencies.  SAP projects are generally tasked with replacing all of those years of collective knowledge and processes, as well as any “broken” processes in six months to a year, and on very large projects in maybe a couple years.  That is no small task and to be successful it truly takes an experienced consultant.  As I’ve previously written about, this is one of those areas that all of the fakes end up costing your SAP project and your company big money.  And I mean big money over and above what you pay them.
A good blueprint should translate your scope into all of the key business processes that your company does, and then the key process components needed to support those processes.  I generally prefer a blueprint that has inputs (or some type of process trigger), the process itself, and then the outputs.  It should also contain the key master data requirements, any necessary FRICE (Forms, Reports, Interfaces, Conversions, and Enhancements) development objects, and the key business areas affected.  If there is sufficient time in the Blueprint phase, the Blueprint itself should also begin to capture some of the key change management issues.

Poor blueprints (missing processes, too generic, too high level, etc.) cause serious project delays and flared tensions by constantly dragging your project back into “Design” mode when you should be in full project execution.  It takes up the time and effort of other integrated teams, and generally causes a “drag” on the overall project.  Obviously this burns up budgets too.  Worse still, a poorly designed Blueprint is often blamed on the company, the department, or the key resource on the project who is responsible for that area.  Unfortunately those “smokescreens” are often used by consultants who are not that skilled at extracting the necessary information needed for a good blueprint.  It’s always easy to “blame” the client through the backdoor by putting the responsibility on a core team member, or some other portion of the company / client team.
If there is a genuine issue with a team member, an experienced consultant should raise this issue during the process when it is encountered.  Frankly, if it suddenly comes up AFTER the blueprint is due, it should be seen as nothing but an excuse by the consultant.

ERP Project Testing 

Another area to begin addressing processes is during testing.  Any integrated application like SAP should include at least 4 primary types of testing.  No matter what name is used, they are generally individual transaction tests (sometimes called “unit tests”), transaction strings or processes within the same module like Sales and Distribution (“module tests”) and then full-blown cross module tests that test entire process chains from start to finish (true “integration tests”), and then finally tests that involve the wider user community often called “user acceptance tests” or “day in the life” scripts, etc.
During testing, while it is important to follow the scripts to be sure that all of the proper “boxes” are checked off, it is equally important to test more.  “Integration tests” and “user acceptance tests” serve as the last opportunity to find and address process gaps.  Sadly some consultants (and some consulting firms) see this as an opportunity to absolve themselves of responsibility for potential problems or shortcomings.  As a result, they will often strictly enforce that the script must be followed to the letter and no deviation is allowed and no exception processing is allowed.  There is a legitimate need to control the process to ensure that the work is done and that the known processes work sufficiently as designed, however there should also be some mechanism to address gaps or exceptions.  One simple method to accommodate this is to create a space on the signoff sheet that directly solicits comments about any process gaps and any exception processing that might be needed.  Final signoff of the testing should not be signed off until this commentary is converted into additional testing scripts or some manual process defined to address the processes.

For final integration testing you may wish to pick random documents from your current business operations to run those through the system with the converted data.  This will give you the best test to ensure things are working correctly.  For example, you may wish to choose 10 or more each of the sales orders, purchase orders, production orders, reports, etc.  The key is to use something that is meaningful and can be verified back against your current system.  

ERP Project Change Management 

Unless you completely re-design and re-write SAP to do all of your processes exactly the way they were done before, there will be change management issues to deal with.  And unless you also re-write the user interface, there will still be training and user acceptance to accommodate.  If you’re going to re-write everything, why bother with a packaged system application at all?  On the other hand, if you are putting in a package application such as SAP, Oracle Apps, or others, there are change management issues to deal with.
Change management generally encompasses a few key areas:  Training, communication, organizational change, process / job changes, and post production support.  Some change management is necessary on every project and if your company handles change reasonably well it may not be a struggle.  However, if your company has many employees who have done the same job for a long time, without much change taking place within the organization it will take a tremendous amount of “hand holding” to get them through even small adjustments. 
You will need to assess your own organization and its ability to absorb change for whether change management resources should be budgeted.  From a project perspective however, one of the key things to be wary of are consultants who want to add new functionality without understanding the impact on the organization. 
Business Change Management analysis case in point:  I was at a client where SAP’s Handling Unit Management functionality was the best fit I had ever seen.  They had high dollar custom made steel transportation racks that needed to be inventoried and returned, the packing was consistent and uniform, their production volume was not intense as a sheer number, and they already had wireless bar codes with some warehouse automation.  From a functionality standpoint it was almost a “no brainer” and a great ROI on the automated tracking, inventory, and return of the units.  However, a more careful look at the organization showed a very different picture.  The staff responsible for maintaining the data and processing the transactions had not been reliable with data maintenance or with processing in the past.  Also, because of the organization there was virtually no chance that would change in the future.  

A less experienced consultant with limited project or change management experience would have seen this as a great opportunity to throw some “gee whiz wow” new functionality at a company.  They keep billing for the new work (a scope change), they would be needed almost indefinitely for production support, and they’ve got a great candidate to blame for why you have to keep paying them.  Sadly I’ve seen this scenario played out over and over again.  On a recent project I saw this with the implementation of SAP’s Customer Service and Solution Database functionality.  The company had an “ugly” but mature and working solution, they were downsizing the customer service area, the SD scope for the project was already pretty significant, sales were beginning to slow, portions of the business were being spun off, and employee morale was already low.  The consultant convinced them to “replace” their solution database and customer service functions from a CRM application that they did not even retire.  So there weren’t even any software license savings.  The consultant got to stay on, support an unnecessary process (the legacy app was not going away and worked fine), and was needed for post production support.  

 The process related issues will quickly separate experience from inexperience.  There are lots of good consultants out there, and then there are lots of less than satisfactory fakes in the market as well.  Unfortunately it is it the “good” consultants who are often penalized for smooth and successful go-lives by early roll offs.  Meanwhile fakes and less skilled consultants are rewarded by extensions to support poorly designed processes and inadequately prepared user communities at go-live.  The old adage rings true here that “you get what you pay for” as long as you have a way to separate the genuine articles from the fakes.  In the end, there are many hidden ways you end up paying as much or more for inexperienced consultants, not the least of which are the many hidden ways their SAP implementation approach impacts your business.  A truly seasoned consultant may cost a little more up front, but at go-live with the quality of delivery and the overall satisfaction of the solution it can pay dividends for many years.  

 In essence, the need for careful process understanding can not be underestimated.  The amount of change your company can absorb, the impact of processes being brought into a package application like SAP, and the cost to your implementation budget should all be considerations. 

Four Part Series on SAP Project Planning for a Smooth Go-Live:

Planning For a Smooth SAP Go-Live: Part 1
(introduction, security and authorizations)

Planning For a Smooth SAP Go-Live: Part 2
(master data, data transformation methods)

Planning For a Smooth SAP Go-Live: Part 3
(process issues, blueprinting, testing, and change management)

Planning For a Smooth SAP Go-Live: Part 4
(custom development, costs and consequences of inexperienced developers)

Related Posts: