SAP & ERP Consulting from the Customer Point of View

Manage SAP Consultants

Over the years the most successful SAP projects I have participated in had strong client side leaders. They had some knowledge and understanding of how to deliver large, complex, or difficult projects. Not just SAP projects but large complex undertakings. Their ability to deliver projects came from their ability to manage, direct, and engage with project participants. They took the initiative to directly manage their own projects.

Many of these leaders had something else in common, they understood you can become overly reliant on consultants to deliver a project –, it creates an artificial sense of security.

One project and leader in particular stands out from my past because of the attitude about SAP project delivery. That project’s senior leader used a phrase about consultants I found a little insulting but have since learned to appreciate. He had a “rented skills” attitude about consultants and frequently referred to us in that way. Along with that attitude he and the senior leadership of the company chose very strong leaders from within the company ranks to manage each module or key area of the project. And by strong leaders I mean REALLY strong leaders. During the course of the project a number of consultants were replaced when they did not perform up to the company’s expectations. That project was probably one of the best delivered projects I have ever seen:

• It had one of the largest SAP scope and functionality footprints.
• That project’s first phase replaced nearly 60 homegrown legacy systems.
• It was delivered ON TIME and WITHIN BUDGET.
• It met every business requirement.
• It was delivered across international company codes and business units (including foreign trade).
• And for similar sized companies, with similar scope, similar time frames, etc., it was delivered for probably 10 – 20% of similar projects.

That project was very different because the level of automation and how smooth the go-live went, and even the post-production support issues were far fewer than any other implementation I had participated in.

I participated in this implementation’s post production support as the SD lead and to help with reporting for about 6 months after we went live. They had slightly more support issues than many companies have with “stable” SAP implementations. This senior leader went on to become CTO and nearly all of the company’s leaders involved in that SAP project went on to senior level leadership positions.

How Clients Can Effectively Manage SAP Consultants to Deliver Results

The background I just provided illustrates one of the most important factors necessary for successful SAP project delivery. The Ivey Journal published by Harvard Press about “Leading Consultants to Exceed Expectations” (PDF file) went into detail on this issue. The key is in aggressive client management of SAP projects for companies that want meaningful results and value.

For me this involves a few critical components:

1. Develop a project or team set of values and expectations for project delivery. The expectations should be focused on action and execution.
2. Provide a training course to client participants on the latest SAP ASAP methodology. It can be made available through Solution Manager or as a stand-alone HTML download from the SAP Service Marketplace.
3. Define clear boundaries, tasks, and roles for all project participants. No one should have to try to figure out what they are supposed to be doing.
4. Every client project participant should be trained in how to manage and work with consultants. Use RACI charts to help manage consultants.
5. Every client project participant should be spelling out the specific tasks, assignments, and expected completion of deliverable for each project participant.
6. Each person on the project, whether contractor or employee, should have clearly defined deliverables, tasks, and criteria for success.
7. The client project participants should capture and regularly discuss lessons learned on dealing with consultants, including challenges and soliciting ideas on managing them.

Client and consulting leaders should accept responsibility for the delivery and execution of those they are responsible for. Be on guard for excuses, deflection, and blame-shifting. At times these are common consulting tactics to hide a skill, talent, or capability gap.

One key thing to consider is that any decent SAP consultant who has managed to deliver SAP project results can be difficult to manage at times. Because of their type “A” personality tendencies they need input and awareness of anything within their domain of influence. To manage high performing consultants the use of a RACI chart cannot be underestimated. Because of these tendencies project managers must activity work to solicit their input and feedback, and well as keeping them in the loop on what is happening in the project. If you fail to do this you are setting yourself up for trouble and unnecessary conflict. This is why a RACI chart is a useful tool on an SAP project.

For an overview of the key SAP project success factors, including allocating responsibility, please see this table which provides an overview of success factors:

Critical Vendor Management Success Factors for SAP Project Success

For a detailed explanation of each of these success criteria you may wish to review the series which analyzed them from the consulting selection point of view:

• SAP System Vendor Project Success Criteria 1
• SAP System Vendor Project Success Criteria & Factors 2
• SAP System Vendor Project Success Criteria & Factors 3
• SAP System Vendor Project Success Criteria & Factors 4
• SAP System Vendor Project Success Criteria & Factors 5

Related Posts:

• SAP System Vendor Project Success Criteria 1
• Why Use the SAP ASAP Methodology?
• SAP Offshore Development Project Experience
• How the SAP Consulting Peter Principle Works
• SAP Consultants for High Speed SAP Projects

Business - IT Convergence

Proper SAP project governance is a function of the business in partnership with IT.  With the exception of a few of SAP’s technical applications (like parts of Solution Manager, HANA, etc.) the entire application suite is about business; business transaction processing and business processes. If key business resources are not directly engaged in SAP project governance you may never realize the SAP benefits you expect.

This brings me to the point of what benefits you expect from an SAP implementation?

From what I have seen there are generally 2 broad “buckets” of benefits on SAP projects.  The first “bucket” is focused on consolidating and eliminating systems while the second is all about transactional business execution.  Or, IT benefits and business benefits.

SAP Project Drivers in IT

The first benefit “bucket” is related to pure IT cost reduction with a focus on consolidating and eliminating legacy systems for many of the following reasons:

• reducing numerous applications’ license costs
• narrowing technical infrastructure needs
• simplifying technical architecture
• reducing system maintenance costs
• reducing legacy staffing needs
• standardizing on a single development platform

If your SAP project is more of a pure landscape play, around replacing legacy systems, then SAP project governance would fall more clearly under IT.  However these types of projects usually end up having the business user community demand that all legacy system functionality be meticulously reproduced in SAP.  In the end you will likely achieve some measure of savings but far less than you originally anticipated.  Any expected savings will generally be consumed through mountains of custom coded solutions which will need continual care, maintenance, and feeding after go-live.  These custom coded “solutions” are not supported by your SAP maintenance agreement and can eat you alive in post-production support costs.

SAP Project Drivers in the Business

The second benefit “bucket” is related to business processes and business transaction execution producing results such as:

• improved cycle times
• greater process automation
• inter and intra departmental integration
• unified reporting data
• improved inventory management
• better planning capabilities
• greater supply chain efficiencies
• faster, more accurate financial closes and statements
• better operational decision making tools

As you can guess, the list goes on.  The difference here is the focus is on direct engagement and active participation with the business.  This is the real challenge.  A business partnership in your SAP project requires more change management, greater flexibility, and a clear understanding that some business needs will override IT drivers and IT goals.  The goal of well executed SAP project governance is to achieve measurable benefit –, it is more about delivering business objectives and strategic direction. 

IT Governance of the SAP Enabled Organization

When the SAP enabled IT organization is able to deliver on business objectives and focus on strategic direction their role in the enterprise changes.  This SAP change moves the IT organization from being a mere “service provider” (a very expensive cost center) to a critical “value added” business partner. When the SAP IT department is seen as a “service provider” you quickly encounter budget and cost cutting pressure.  As I have previously noted:

In today’s competitive global economy, filled with international economic instability, no part of the enterprise can afford to move very far from what pays the bills.  If your SAP or IT organization is focused completely on technology solutions you lose sight of what is important to the business.  And what is that?  Customers! Customer retention, acquisition, loyalty, satisfaction, and experience.  Without customers there is no growth or revenue.  Without growth or revenue there is no need for that expensive SAP or IT investment…

Without a clearer focus on customers as well as innovation in the enterprise, or “how business gets done,” the SAP and overall IT organization becomes a very expensive operational support layer.  Without the genuine business focus the organization becomes a commodity to be outsourced (see SAP IT Convergence Beyond Business to IT Alignment).

SAP Governance Includes Business to IT Convergence

The whole area of governance and convergence is very closely related.  For effective governance the business direction and integration must be a key component of all SAP or IT initiatives.  When you have that involvement, over time, and with some effort, convergence happens.  It isn’t automatic but the environment for it to occur begins with direct business engagement. 

If the business isn’t in the SAP co-pilots seat you may be headed for a IT crash landing.

If you’re thinking to yourself this “doesn’t apply to me” then you might want to think again.  A recent IBM study found that many corporate lines of business are beginning to make their own independent technology purchase decisions.  And they are doing this outside of the SAP or IT organization.  Add to that Ray Wang’s recent Harvard Business Review Blog Post about the consumerization of [business] IT (see Integrating Business Stakeholders as Part of SAP IT Convergence) and you have a serious issue to contend with.  As his research noted, “corporate tech spending is up by 17 to 20%… [but] spending by IT departments is flat.. business leaders, not their IT colleagues… are driving purchasing decisions.”

Business decision makers are starting to use their own budgets to make their own IT decisions rather than making the contribution to what they see as a very expensive “service provider.” That integration or “convergence” with the business is more important than ever because in the end they have more influence over your budget than you may realize.

For more information on this topic please see these additional posts:

• Steps to Achieve SAP IT Convergence
• SAP IT Convergence is About Business Focused Integration
• Steering Committee Governance for an SAP Center of Excellence
• Using Your SAP Steering Committee for Business Transformation
• SAP & Business Convergence

Related Posts:

• Steering Committee Governance for an SAP Center of Excellence
• SAP Program Management Requires a Type of CMMI
• Steps to Achieve SAP IT Convergence
• Toward an SAP Center of Excellence or SAP Competency Center – PART 2
• Series on SAP Competency Center or SAP Center of Excellence

SAP Offshore Development Cost

If you are capable of providing detailed design specs where there is almost no deviation or thought required then this is a great option.  The instant your SAP design requires a measure of experience and insight to make judgment calls, or to look for data or processing that is not explicitly spelled out in detail, you are headed for huge hidden costs. 

The level of detailed spec design work by SAP functional consultants merely shifts the development time and costs to the higher priced resources where it is “hidden” from TCO and sales quotes.  If you are capable or writing “functional” specs that are really more like technical specs with specific table and fields spelled out in detail, program pseudo-logic defined, every possible alternative anticipated, and no detail left out then SAP offshore development works well.  If you are not prepared for that level of detail and “perfect specs” then you are likely headed for a much larger invoice in change order costs and hidden functional time than you ever anticipated.

Offshore resources are often smart, industrious, and hardworking but the ugly reality no one talks about are the real rates because these resources do NOT have any significant amount of SAP experience.

This is the final post in this series.

• Part 1 – SAP Offshore Development Project Experience
• Part 2 – Hidden SAP Offshore Development Costs
• Part 3 – Where Does SAP Offshore Development Make Sense?

A quick “test” for the SAP outsourcing or SAP offshore fit is the nature of the work.  “Commodity” services are a perfect fit for SAP outsourcing or SAP offshore work. 

If the effort involves any type of innovation, business transformation or needs any level of change management then SAP outsourcing or SAP offshore development may be dangerous and it WILL cost you far more than you are led to believe.

SAP Upgrades Might Support SAP Offshore Development

One area I have seen where SAP offshore development work makes sense is with upgrade projects.  Much of the development work there is re-working existing objects where the requirements from previous projects have been well tested and adjusted.  Or, if there are enhancements the gaps are well-known and understood so that the detailed SAP development requirements can be easily defined.  From this standpoint SAP offshore review and adjustment of existing code makes sense.  There is little in the way of experience needed to use the syntax checker and to do the occasional program adjustment.  And other than poor coding which causes performance problems the risk is lower.

SAP Production Support Might Work With SAP Offshore Development

In a fairly stable production environment, where there are not a lot of enhancement or new functionality requests SAP offshore support might work well.  The “fix” requirements are very specific and limited so that these types of small adjustments or corrections work well in an offshore environment.  Even for some of the smaller and less complicated enhancements or improvements SAP offshore support might work well.  However, for more extensive troubleshooting, or very complex requirements, you are likely better with some sort of local or onsite support. 

For a more details see Outsourcing Your SAP Application Support.  This provides some insight and a little framework for understanding the SAP outsourcing or SAP offshore fit.

Conclusion on SAP Offshore Development

Regardless of the hype and sales pitches SAP Off Shore development has far more Total Cost of Ownership than anyone has been led to believe.  There is a place for it but that is rarely in a new project or an extensive rework of complex processing requirements.  While you may not see the costs, the offshore project model will cost you unless you are fully aware of the requirements and hidden costs that are never defined in any of the sales pitches or materials.  Of course they will never tell you SAP offshore development might cost you far more than higher priced local resources in many situations.  If they had that level of integrity you would never engage with them for those services. 

For more information and insight on this topic see IT Outsourcing, Off Shore Support, Cost Cutting and IT Department Changes.  That post provides some additional insight on helping to understand where SAP internal resources should focus as well as where offshore support might make sense.

Related Posts:

• Hidden SAP Offshore Development Costs
• SAP Offshore Development Project Experience
• More on Stupid SAP Vendor – Partner Selection RFI-RFP Processes
• How the SAP Consulting Peter Principle Works
• Steering Committee Governance for an SAP Center of Excellence