SAP & ERP Consulting from the Customer Point of View

SAP IT Convergence

The problems with Enterprise SAP IT organizations are they are focused on SAP and IT.  They lose sight of their purpose which is to support and promote the broader objectives of the enterprise.  In an SAP centered IT organization this means your whole existence is about ensuring business benefit, focusing on enterprise goals, strategies, and objectives.

Somewhere between the SAP sales cycle and the SAP go-live the concept of business benefit gets lost and is never found again.  By the time you go live with the SAP application the entire IT organization becomes narrowly focused on the care and feeding of the new system.  Everything is all about the “new” ERP application and the business is left holding an empty bag –, the money is gone but the business now has to struggle through getting their operations stabilized just to continue doing business.

The entire IT organization’s existence must focus on enabling business.

Today’s enterprises will no longer pay the premium prices for SAP or IT organizations which exist in a silo.  To continue with this old way of doing SAP or IT support will turn those internal services into very expensive commodities to be outsourced to the lowest cost provider(s).  If you want to do more than survive, but rather to thrive, you must build a converged SAP or IT organization.  Without IT convergence you can expect budget cuts and more outsourcing pressures.

Research Shows a Business Focus Produces SAP Results Needed for IT Convergence

Successful SAP projects require the management and measurement of expected benefits and the purpose for the project throughout the entire SAP life-cycle (Holland and Light, pg. 1630-1636, 1999).  To gain business benefits from an ERP package like SAP you will need serious discussion of goals, direction, objectives, and what the business software can do in those areas.  After that, coordination of key resources from both business and IT is also required to create business to IT alignment (Willcocks and Sykes, pg. 33-38, 2000).  This business to IT alignment produces some great results but is just the beginning.

[F]irms that invested more heavily in business process redesign and devoted more of their IT resources to increasing customer value (e.g. quality, timeliness, convenience) had greater productivity and business performance (Hitt, Wu, and Zhou, pg. 3, 2004 citing Brynolfsson and Hitt)…   [A 1999 study on] the impact of ERP systems on self-reported company performance based on a survey of 101 US implementers of SAP R/3 packages [showed]… companies reported substantial performance improvement in several areas as a result of their ERP implementation, including their ability to provide information to customers, cycle times, and on-time completion rates (Hitt, Wu, and Zhou, pg. 5-6, 2004).

In the 2004 study just cited they also referenced compiled research by Gattiker and Goodhue (2000) which identified four broad categories of ERP benefits including (1) better information flows, standardization, integration, communication and coordination; (2) centralization of administration activities like, AP, payroll, etc. (i.e. “shared services”); (3) reduced IS maintenance costs and improved ability to deploy new IS functionality; (4) a move to “best business practices” around business processes.

Some of the additional and very interesting findings (Hitt, Wu, and Zhou, pg. 18, 2004) include:

• Greater sales employee performance
• Higher profit margins
• Better return on assets including greater asset utilization
• Higher inventory turns
• Greater receivables management (including better “cash to cash” cycles)
• More revenue generated per unit of input

This is impressive but notice these benefits are nearly all operational business performance results.  They certainly appeal to the CFO and improve market valuation making them meaningful. However, as operational benefits they are nearly all focused on lagging indicators of business success.  Shareholders like them with the valuations of companies who implement ERP systems like SAP being “worth approximately 13% more than their non-adopting counterparts, controlling for assets, time and industry” (Hitt, Wu, and Zhou, pg. 20, 2004).  So implementing SAP has a positive impact on stock values.

Today’s SAP Enterprise Can Realize Even More Through SAP IT Convergence

All of these benefits and gains from roughly a decade ago are not enough today.  While the study from Hitt, Wu, and Zhou (as well as the others reviewed here) showed tremendous benefits for SAP they were based on studies at least 10 years old.

In the last decade the entire global landscape has dramatically changed –, the Internet and the pace of technology change has disrupted every value proposition model relied upon by business.  No area of the enterprise is off limits–, business is in the midst of a global and dynamic transformation of operations, innovation, and customer focus.  To thrive in our modern business era we will all have to move past the IT to business alignment model and push into IT convergence.

Your SAP Enterprise Can No Longer Avoid Full Business to IT Integration (i.e. “Convergence”)

The business benefit focus has been difficult for SAP or IT leaders trying to quantify returns from their investments.  Even though SAP has been at the forefront of addressing this message it is slow to catch on.  Over a year ago I highlighted SAP’s “value delivery” and value focus to implementing their software:

Studies have shown that there is a critical disconnect between projected benefits in business cases for IT investments and actual value achieved, because so many firms focus on going live with a project rather than its value delivery. An SAP / ASUG best-practice survey on the ability to capture the projected benefits of an IT project found that 73% of companies do not quantitatively measure value post-implementation (SAP Executive Insight Series, pg. 7, 2009)…  Critical business benefits for an SAP project require taking a hard look at the enterprise and its goals or direction…  (see A New SAP Implementation Methodology and Implementation Steps).

And while all of this is critical for realizing SAP ROI from your investment there is still more to do.  With this groundwork focusing on the need for business benefit, or measurable ROI, we can take the next step and start to explore full IT convergence around your SAP endeavors.

Next week we will look at some methods to create SAP IT convergence.

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

Gattiker, T., and Goodhue, D. Understanding the plant level costs and benefits of ERP: Will the ugly ducking always turn into a swan? In: R. Sprague, Jr. (Ed.), Proceedings of the 33rd Annual Hawaii International Conference on System Sciences ( CD-ROM), Los Alamitos, CA: IEEE Computer Society Press, 2000.

Hitt, L., Wu, D.J., and Zhou, X. ERP Investment: Business Impact and Productivity Measures.  Wharton School at U of P (2004).

Holland, C. and Light, B. Critical Success Factors Model for ERP Implementation.  IEEE Software. May / June (1999).

Willcocks, L. P. and Sykes, R. The Role of the CIO and IT Function in ERP.  Communications of the ACM, Vol. 43, Iss. 4 (2000).

Related Posts:

• Integrating Business Stakeholders as Part of SAP IT Convergence
• Steps to Achieve SAP IT Convergence
• What are SAP Best Business Practices Anyway
• Why Indexed KPIs are Critical for Business Performance and Success
• Using SAP to Improve Revenue and Profitability

SAP consulting services best practices

Last week’s post took a hard look at the types of consulting services you need for a high speed SAP project (see SAP Consultants for High Speed SAP Projects).  Consultants who work on SAP projects in the small and mid-sized business space develop great breadth of SAP experience across an entire area.  This week we will look at the other side of that coin, consultant skills from large, long-term type SAP projects and what their experience provides.

Consultants on the larger, longer-term SAP projects may not develop the breadth of experience gained through smaller company experience but they develop depth of experience.   Small and mid-sized SAP implementation projects create breadth of experience while large projects create depth of experience.

How is Consulting Service Delivery Impacted by Large SAP Project Skill Development

On larger SAP projects the projects are usually broken out into sub-teams within a module or area.  These SAP consultants may cover a small subset of a module, or of the overall solution within a small subset.  As a result they spend much more time digging into the details of the functionality around that small subset of SAP setup.  That type of focus creates a high degree of narrowly focused specialization.

For example, a consultant who focuses on just the SAP GL Account setup will easily become an expert at every setting and every option related to its setup.  They will learn about the different posting possibilities, account settings, document types, how to deal with taxes, reporting issues, data elements that can be stored in the GL, etc.  An SAP SD consultant who focuses on order setup might become an expert at all of the copy rules around moving the data from an order to a delivery or to billing.  Depending on how the responsibilities are broken out they might focus on the different types of item categories and all of the functionality they drive.

Small and mid-sized SAP implementation projects create breadth of experience while large projects create depth of experience

Big SAP project consultants gain great depth of experience with very narrow areas of the application.  Those with many years of experience are great for projects that require specialized focus for complex processing around a very specialized area.  So if you are having a particular problem, in a very narrow area of the application, these SAP consulting skills may provide value.

SAP Consulting Services to Produce Business Value and Achieve ROI

Depending on what you are trying to achieve different types of consulting skills are required.  When you need SAP architecture, complex process design, involved SAP custom development, or other unique requirements you will want an SAP consultant with many years of all around experience.  That type of consultant needs both depth and breadth of experience with a well-rounded background in small, mid-sized, and large company SAP implementations.

The obvious but often overlooked fact is SAP consulting service delivery is directly related to the type of consulting experience you are provided

This type of experience will generally take around 10 or more years of experience.  I’ve written about this previously in Expert SAP Consulting to Reduce SAP TCO and Improve SAP ROI where the academic studies lay out the path to “expert performance.”  Unfortunately for most SAP customers they will rarely find this level of skill with any of the consulting firms or system integrators unless those integrators use contractors.  Few consulting companies provide these types of consulting services because as I’ve pointed out, if you haven’t moved up “through the ranks” after 10 years in a consulting firm, your future is pretty dim.

Where Can Customers Find These Skills or High Quality SAP Consulting Services?

One of the most important areas where you can make a difference in your solution results is to hire solution experts (see Industry Specific SAP Consulting vs Deep SAP Application Experience).  They are not easy to find, but they are out there.

If your SAP project is large enough to have more than one consultant per module then demand that at least one of those consultants has both depth and breadth of experience.  If they are the only consultant for an entire module you may wish to insist that they have a significant amount of small and mid-sized project experience.  If you need specialized skills then you will certainly want to consider large project experience in that particular sub-area of expertise.

As an SAP customer you have to insist on the level of skill and experience that a consulting company provides in their initial proposal.  In other words, your SAP RFP must call out what level of skill and experience you expect.  You must insist in writing on this and build it into your SAP consulting service contract with the vendor you choose.  Until SAP customers begin demanding this from the marketplace nothing will ever change, results will continue to be sub-par, and ROI from your SAP investment will continue to be lacking.

One last consideration is to be very, very careful of the consultants you or your SAP consulting firm hires.  There are so many frauds, fakes, and con artists out there it is frightening.  And I don’t mean just exaggerated either, but outright fabrication and fraud.  Unfortunately many of the staffing firms knowingly allow the fraud to continue (see Screening and Interview Methods to Find the Right SAP Consultant and Screening and Interview Methods to Find the Right Consultant – Part 2).

Related Posts:

• SAP System Vendor Project Success Criteria & Factors 4
• SAP System Vendor Project Success Criteria 1
• Reduce SAP, ERP, or Technology Project Stress: Part 2
• Series on SAP ERP Project Success Factors
• How the SAP Consulting Peter Principle Works

SAP consultant results

No matter what size company or organization you have the type of consulting experience you choose will have a huge impact on the results of your SAP solution.  For high speed projects consultants with several small or mid-sized SAP project experiences tend to be more well rounded.  They have skill at delivering the more difficult SAP solutions with standard functionality and at a faster pace than their counterparts with significant amounts of large project experience.

Why are SAP Consultants with Many Small and Midsized Projects Uniquely Qualified?

The small and midsize business segment of SAP implementations use smaller teams, smaller budgets, and tighter timelines.  Contrary to popular belief a small or mid-sized company’s SAP implementation often has the same process requirements, similar industry needs, common competitive pressures, and all of the other issues that go with doing business.  In other words, their business software application requirements are exactly the same as their larger counterparts.  However, they must deliver similar or better results than their larger counterparts with fewer resources.  Consultants who deliver solutions in this space must know their area of responsibility well because they are often one deep, without others to fall back on.  They have to cover the integration touch points and other project activities together with their own module.  This type of effort is usually performed by other groups and numerous other consultants on larger projects.

Consultants who have worked in the small and mid-sized space don’t have the luxury of the big consulting firms, on their mega projects, where they can specialize in one little component of a module at a time. They don’t have the luxury of massive numbers of people coordinating small, discrete components of an overall effort.  Small and midsized SAP implementations often don’t have the resources or budget for large change management and training staffing, separate data conversion groups, separate testing staff, or other key areas of the project.

The consultants with many years of small and mid-sized business exposure are able to do in a few hours, or possibly a few days, what takes consultants with less exposure weeks to figure out. Even if it is a bit of a stretch, they have enough background, enough exposure, and enough experience to be able to start immediately with 80% or more of the solution. From there it is just detailed testing of different settings to be sure you have just the right combination and the process or transaction behaves exactly like you planned.

Small and midsized business consultants are less likely to need lots of custom coded solutions because they can figure how to do it with standard functionality, or how to “re-purpose” other functionality for your company’s particular need.

An SAP Project Examples of Complex Standard Functionality that Helped Avoid Blown Budgets and Timelines

I’ll provide one example here of many SAP experiences I’ve had where this experience made a huge difference in the SAP project result.  The SAP experience helped save the timeline, stopped the continual circular meetings, and finally moved the process along.

SAP Cross-Company Supply

I was on a very large project that had cross-company supply issues that no one had been able to resolve for about two months when I joined. There were weekly meetings, and weekly arguments, and no one could agree on the solution.  There was third party cross-company supply where one company would take the order, transfer the requirements to a separate company who would actually carry out the delivery and bill the other company who then billed the end customer and collected the payment.  This was also being done in different countries, with different currencies, cross-company pricing markup, and foreign trade.  After a few weeks of this dragging on after I arrived on the project as the SD team lead  I knew something had to be done.  All of the “Big x” consultants claimed this could not be done without mountains of custom code and that standard SAP would not work.  These consultants did not have a lack of years in SAP, or large projects doing SAP, it was a lack of experience having to deliver results on a compressed timeline with standard functionality.

The SAP Blueprint was over and we were still in design on a key set of processes.  After several discussions where it was mentioned this was standard functionality and strong disagreements together with claims that only custom coding would work I had enough.  I took a couple days to set up and prototype the entire solution.  The standard SAP functionality did over 90% of everything that was needed for every process and transaction they needed. After the prototype was set up, and without telling the other consultants who insisted it wouldn’t work (and claimed they wouldn’t support it if it did), I set up a meeting with all of the key stakeholders and the client project manager to demo the new functionality.  It was a huge success and the ridiculous arguments and endless discussions to flow out processes for unneeded custom ABAP solutions finally stopped. The solution was nearly complete with almost all standard functionality. [FN1]

Big SAP Project Experience Effects on Compressed Timeline and Budgets

When you want to do a compressed timeline project with resources (consultants, managers, coordinators, etc.) who come from big SAP projects you end up with unnecessary struggles.  Their “experience” has conditioned them to believe these types of projects cannot be done, they rely on too many middle layers of coordination / management, they struggle with the intense need for integration coordination, and undermine attempts to gain momentum because they are not used to the pace.  These large projects often provide the “luxury” of deferring discrete components of an area to others.  They provide big budgets, lots of time, each delivery area broken down into little tiny “chunks” and then handed off to others.  Some (though certainly not all) of these consultants and managers from larger projects are so uncomfortable with the pace and demands that they spend more time making excuses for lack of results and look for others to blame. The idea of delivery “ownership” over an entire area is a foreign concept to them.  Some of these consultants from larger implementations, with slower paces and many layers of coordination are lost without someone managing each tiny aspect of what they do.

~~~~~~~~~~~~~~~

[FN1] In fairness to the other consultants who thought this could only be done through ABAP custom coding, it does require a major amount of setup in SD, MM, FI, and EDI to work correctly. While it is all standard functionality, consultants with experience on very large projects have limited exposure to even their own module of expertise. As a result it is unlikely that the full breadth of this and other functionality has been seen outside of the small and midsized business space. In the small and midsized business space the consulting teams are smaller, and out of necessity are more knowledgeable within their module area, and because of the integration requirements with other modules they tend to gain greater application exposure to standard functionality options.

Related Posts:

• Industry Specific SAP Consulting vs Deep SAP Application Experience
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Using SAP to Improve Revenue and Profitability
• More on Stupid SAP Vendor – Partner Selection RFI-RFP Processes
• How “As-Is” Process Mapping Can Damage Your SAP Project