INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP
Reducing SAP project stress

Reduce SAP Project Stress

A good SAP project with solid performance requirements will often be a stressful experience.  Anyone who has been through an ERP implementation has experienced this stress.  And although this may sound counter-intuitive, if you’ve chosen the right people for the project during the course of the implementation tempers will flare.

Why do tempers flare with the right people?  They are usually the people who care the most about the business and are passionate about their responsibilities.

If the employees assigned to the project are not used to the grueling hours, 10, 12, 15, or more hours a day, they may find themselves in difficult situations.  Some projects have taken significant tolls on project member families, even causing divorces and physical or emotional problems.

There are however a few ways to significantly reduce that SAP project stress and ensure the temper flare-ups are kept to a minimum.

What causes many of the SAP project stress problems?

  • Direct competition from other business areas or processes, often occurring at what SAP refers to as module “integration” touch points.
  • Improperly set expectations (or the lack of setting expectations at all).
  • Few or no objective metrics to ensure that all teams and key project components come up to the same place together (think of an orchestra with the percussion, brass, and string sections all playing different parts of a song–, what a mess!).
  • Little or no recognition for the hard work.
  • Unrealistic scope and time pressures.
  • Consulting resources without the necessary experience to know how to set proper expectations and mitigate risks (see Screening and Interview Methods to Find the Right Consultant – Part 2 and A Cautionary Tale About SAP Knowledge Transfer for more information on the critical need for the right consultants).

Knowing about some of these stresses, and keeping a watchful eye for them during a project can really help to reduce some of the pressures.

How to Address these Project Stress Factors

Direct competition between departments, business areas, or department “touch points” will happen during an SAP project.  Likewise, these same competitive pressures are translated into setting up the SAP application, especially at the integration “touch points.”  This friction usually occurs at a point where clear ownership of responsibility exists or at the point of ambiguity. This area of integration touch points is referred to as “interdepartmental cooperation” in the academic literature on ERP success factors (see The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors).

When you have a process “handoff” to another area or department, the lack of knowing who owns a process area, or decision point, is usually what creates the tension.  One critical factor to reducing these stress points is to communicate expectations early on in the project about capturing these integration touch points.  A good mechanism is whatever issue logging tool you use.  Once it is captured, the key is to work that touch point just as you would any other issue.  Assign a responsible party and be sure to follow-up.  A crucial issue here is that whoever is ultimately assigned as the “owner” is accountable for the completion of the task but may not be the one who ultimately does the work.  In some cases the “owner” of that touch point may not even have any responsibility for the area(s) covered.

Some of the integration “touch points” where I have seen this are in trying to figure out:  

  • Does Finance own the customer and vendor master or does Sales and Distribution (SD) or Materials Management (MM)?
  • Does Production Planning (PP) or Materials Management own the Material Master?
  • How are the Material Master “views” divided up between modules, who owns the various views and how will they be responsible for ensuring they are complete?
  • Who owns master data maintenance after go-live and what process will be used to coordinate the cross-functional maintenance of the data?
  • Who owns cross-company supply (the sales between company codes), is this in Materials Management or in Sales and Distribution, or how are the hand-offs between the modules handled?
  • Who owns month-end close processes and how will they be tested during the project?
  • Who will do the month-end production order settlement, is that in Planning or in Finance?
  • Who will close the current period and open the next period for material movement postings, is that in Finance or Materials Management?
  • During the Integration testing portion of the project, for cross-functional tests, who will “own” what tests, even if there are significant portions of each test which must be conducted by other areas?
  • During realization and implementation, who will own the Revenue Account Determination, will that be in Finance (FI) or in Sales and Distribution (SD)?
  • During realization and implementation, who will own Material Account Determination, will that be in Finance or in Materials Management?
  • Who will own the Product Costing, will this be in Production Planning or will it be done separately with a Controlling (CO) / Product Costing person, or in Finance (FI)?
  • With order related costing, will this be done in Sales and Distribution (SD) or in Finance (FI) or in a separate Controlling (CO) function.

You get the idea.  The list of integration touch points, and of ownership and responsibility creates “flash points” during the project if these issues are not defined and assigned quickly.  This also moves into the live production environment after go-live if the business processes are not sufficiently defined.  If ownership for integration touch points and for process development is lacking during the project it is not likely that it will suddenly work once you go live.

What experience has shown me:  If you have trouble with ownership or resolution for a process or business area during the project, expect trouble with that same process or business area once you go live.

Fake SAP Consultants or those with Exaggerated Experience Cause Significant SAP Project Stress

For me, as an SAP consultant, doing the system setup is relatively “easy.”  It is not even that bad for some of the more difficult and complex areas.  What creates headaches for me, and what causes project stress is when integration testing begins and the business is still struggling with these responsibilities.  Any decent consultant can “push through” the testing process and ensure that things work the way they should but this is another indicator of upcoming problems when you go live.

Unfortunately, by the time integration testing starts is when you will likely begin to discover the consultants with fake resumes or dramatically exaggerated experience.  Testing will reveal high levels of defects, gaps in processes, or they just won’t be ready for testing when other teams are.  This is another of those areas where tensions will also rise from the experienced consultants because of how their fake or inexperienced counterparts made poor decisions which negatively affect other areas.  This is also where you, as a client, will begin to get that sinking feeling that the project timeline and budget are going to get blown. This can also be a direct result of a fake or incompetent SAP “project manager” who might have good people skills but no clue how to run an SAP project.

Avoid getting ripped off by so many of these fake consultants by protecting yourself with an engagement contract that defines some specific level of skill, experience, and consultant requirements.  And be sure to at least screen some of the vendor’s consultants (see Screening Methods to Find the Right SAP Consultant).  You would NEVER hire a senior level manager or executive without due diligence, why are you going to pay an integrator WELL into 6 figures for each of their fakes?

Real Life Example of the Damage Done by Fake Consultants

For example a chemical company had a requirement to sell the exact same products under different names and at different prices with different product labeling.  The product construction and the manufacture was identical in every way.  The right solution was for the Materials Management Consultant and the Production Planning Consultant to work together to create a new Material BOM and Routings for Production Planning.  This would allow for 100% consumption of the underlying “common” finished product.  However, the MM and PP consultant were not as experienced as they led everyone to believe and it became a near war over the issue.  At that point I had a difficult decision to make as the SD consultant.  The worst part is that the MM consultant was a “climber” up the  consulting ladder who actively worked to throw anyone under the bus that might even minimally disrupt her plans.

Unfortunately, rather than throwing it back at them and pressing them to address the issue I accepted the “responsibility” to allow for pricing to be done based on product DESCRIPTION.  This was not the best solution and although it worked I would never do that to a client again. The maintenance was an absolute headache and this was not the best solution.

Unfortunately, to keep the project moving, some of your experienced consultants end up giving less than optimal solutions because of the mess that is created by having inexperienced consultants who have “great” resumes.

The costs of all of those “cheap” inexperienced consultants and all of the H1Bs are far higher than you might think.  But they are enticing because someone “works” the numbers to make them fit.  But there are many more hidden costs you never see.  And some of those costs may be many multiples, or orders of magnitude higher than you anticipate over the application life-cycle.

Conclusion on Reducing SAP, ERP, or Technology Project Stress

One of the biggest problems I see repeated on projects is improperly set expectations.  Combine that with junior level consultants that are “sold” by consulting companies as senior resources and you have a recipe for a less than optimal implementation.  Don’t just accept every consultant that a consulting company places on your project, and definitely take the time to define responsibilities for these integration touch points as quickly as possible.

When you begin to experience project stresses and tempers start to flare look for the culprits, it will usually be related to some of these integration touch points or junior resources that someone has to cover for.  Sometimes it is just plain personality differences.  Either way, watching for and mitigating these project stresses when the symptoms begin to show up will help to give a better final result for the project.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175
Bill Wood contact

=========================


Print pagePDF pageEmail page

Related Posts:

One Response to “Reduce SAP, ERP, or Technology Project Stress: Part 2”

  1. Bill,
    I am grateful for the insights contained in the various articles.
    I have worked in the SAP space for 13 years,and judged myself to be knowlegable and experienced. Your postings show that I still have a lot to learn.
    many thanks for making this available freely.

Leave a Reply