Reduce SAP, ERP, or Technology Project Stress: Part 2

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

How to Address These Project Stress Factors

Direct competition among departments, business areas, and department “touch points” will happen during an SAP project. Likewise, these same competitive pressures are vital to set 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. Academic literature on ERP success factors refers to this area of integration touch points as “interdepartmental cooperation” (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, tension often results from not knowing who owns a process area or decision point. To reduce these stress points, you need 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 you capture the integration touch points, 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 the following:

• 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? 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, going live will certainly not resolve the issue.

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

As an SAP consultant, I find the system setup relatively “easy” — even 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. However, struggling with integration is another indicator of upcoming problems when you go live.

Unfortunately, the start of integration testing is when you will likely begin to discover the consultants with fake resumes or dramatically exaggerated experience. Testing will reveal high levels of defects and gaps in processes– or they just won’t be ready for testing when other teams are. This is another area where tensions will rise from the experienced consultants, because their fake or inexperienced counterparts’ poor decisions are negatively affecting other areas. This is also where you, as a client, will begin to worry that the project timeline and budget are going to fail. 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.

To avoid getting ripped off by so many of these fake consultants, write 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 unscrupulous integrator well into six figures for each of their fakes?

Real Life Example of the Damage Done by Fake Consultants

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 complete consumption of the underlying 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 threw anyone under the bus who 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 because maintenance was an absolute headache. Although it worked, I would never do that to a client again.

Unfortunately, to keep the project moving, some of your experienced consultants may end up giving less than optimal solutions because inexperienced consultants with promising resumes are creating a mess.

Although enticing, the costs of all of those “cheap” but inexperienced consultants are far higher than you might think. Because these consultants slow down the project and hinder other team members, their hidden costs may be much 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 who 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. Instead, 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. Generally, an integration touch point or junior resource that someone has to cover for is to blame. Sometimes, however, the issue is simply personality differences. Either way, mitigate these project stresses when the symptoms begin to show up. This way, the team will offer a better final result for the project.