INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

Why SAP Vendor – Partner Selection RFI Processes are Stupid

February 7th, 2011 by
Vendor RFI processes and information

SAP vendor RFI

 

It’s time to kill useless SAP Partner RFI (Request for Information) practices.  They need to be updated and replaced with results-oriented criteria.

———————————-

The SAP implementation or integration vendor selection RFI today is nothing more than a beauty pageant measuring the wrong things and providing little useful information for making the right SAP consulting service vendor selection.

SAP Quantity or SAP Quality, Which One Do You Think Makes a Difference Today?

Just because a baker has baked 100 cakes doesn’t mean they were good.  Lots of professional race car drivers have driven a hundred races or more and rarely (if ever) placed in the top 3.  Thousands of home-builders built hundreds, or thousands of cookie-cutter promotional tract homes but few  ever moved on to build award-winning custom homes.

Once the stupid parts of traditional RFI processes are killed we can focus on the useful parts of what an RFI should include.

The number and variety of comparisons to long term and financially sound business endeavors is never ending –, none of them indicates meaningful performance for your SAP project.  Typical SAP RFI measures are easily gamed by firms with deep sales and marketing staffs so that they hide whether an SAP partner is able to deliver value.

Background for Current SAP Enterprise Software Integration Vendor RFI Processes

Modern RFI practices were originally created to support manufacturing and distribution functions.  As technology service industries were maturing during the Technology Revolution the industrial (or manufacturing) Request for Information processes were well suited to support custom technology system and software development functions.

Because of the nature of the supply chain, and of custom developed software or hardware infrastructures, RFI processes which were developed for them are not properly aligned to modern Commercial Off-The-Shelf (COTS) enterprise business software.  Today’s frequent RFI and RFP factors came about before COTS enterprise applications.  At that time vendor financial performance, length of time in business, and office locations were critical components.  Businesses needed assurance that the vendor was going to be there for the long term so the supply chain and software or hardware business systems were not disrupted.  Today’s mobile economy and the nature of COTS software consulting changed that paradigm but the old RFI and RFP business models haven’t kept pace.

An SAP vendor RFI must shift away from factors that favor vendor lock-in to factors that indicate SAP project success with business improvement.  Does your SAP RFI-RFP process provide information on how a vendor can help your business succeed or is it just a “beauty pageant” for your vendors?

The rise in technology and services industries focusing on packaged business software applications are not well-suited to these old-fashioned SAP Request For Information (RFI) approaches.  When implementing SAP business software you are buying and implementing Commercial Off The Shelf (COTS) software.  Ask yourself how financial strength, time in business, and other typical RFI factors might help, but also how they might hurt you as well.

Vendor financial strength, time in business, and physical locations should not be ignored, but they distract from the important results-focused factors which are related to SAP project and business success.  Relevant RFI or RFP factors will ensure you focus attention on success with Commercial Off-The-Shelf business software applications like SAP.

SAP  Commercial Off The Shelf Business Software Requires Business Process Engineering Instead of Software Engineering

Normally SAP or other ERP application purchases are made with the idea of buying an off-the-shelf solution that you do not have to build–, not custom coded, custom developed, custom designed application suites.  In other words the whole idea behind implementing SAP or other package business software applications is to get away from the software engineering and focus more on business process engineering (see SAP Implementation Focus, Software Engineering or Business Process Engineering?). Otherwise, why did your company even consider SAP?

Even if it is not spoken or articulated, part of the reason you choose a COTS package such as SAP is to avoid system integration vendor lock-in.

Do you need SAP vendors to act as squatters –, to nurse, fix, adjust, and maintain their custom software engineering long-term?  Did you budget for this?

The focus of an SAP RFI must shift away from factors that favor vendor lock-in to factors that indicate SAP project success.  Typical RFI factors which focus on vendor financial stability and time in business may work against your goal of achieving a successful package implementation.  On the other hand, the typical SAP RFI checklist may support that vendor’s ability to “squat” at your company for years to support some custom-coded solution promoting their “financial health” and “long term stability.”

Big SAP Shops With Strong Financials and Time in Business

For a COTS system integrator, such as with SAP, longevity and financial stability means what to your business?  Does it mean that you will get a good, standard functional implementation of SAP and a vendor who moves off the project at go-live because they focused on business process engineering rather than software engineering?

Low Cost SAP Providers and How You Get Gamed to Cost As Much or More

On the other hand the ugly truth is that low cost vendors may not deliver one penny ($.01) of ROI or of business return from their implementation.  You might get SAP in cheaper but that low cost provider may also cause havoc with your business by insisting SAP’s robust application suite can’t do what you request.  And then there you go down the custom coding path again.  Or, their lack of knowledge may cause you to design very poor business processes to support the application because of a lack of depth of skill and experience.

After over 100,000 SAP installations, upgrades, etc., in virtually every industry vertical you can dream up, SAP application depth and breadth has been pretty well developed.  

Low cost providers generally cut thier costs to keep their margins up by providing green consultants.

As I’ve offered in a previous post, if you pay half the implementation cost of a competitor but get a negative ROI and your competitor pays twice the price but gets significant ROI then you have a serious marketplace competitive issue to deal with.  You did NOT get what you really paid for!  For example, in writing about SAP Implementation is an Investment NOT an Event the point was made pretty clearly:

[Two executives] wanted to know how their expenditure compared with other competitors, what they were really asking but were not articulating very well is whether or not they got what they paid for.

A simple illustration drove the point home quickly–, it doesn’t matter if you spent twice your competitors, or if you spent half, what matters is the return on technology dollars.  The numerical illustration I gave them is if they are looking at the amount they spent, say if they spent $50 million and their next closest competitor spent $20 million, they are looking at the wrong thing.  What really matters is the return.  If they achieved a 10% financial return from process improvements, automation, task time reduction, etc., and their competitor was achieving a -3% return then even at 2 ½ times the cost of their competitor they got the better deal.

By the time we finished the conversation it was clear they were simply asking how to measure any return or business results they received from the implementation.  However, from the conversation it didn’t sound like they were very happy with any perceived return.

The project team you put together, both with the implementation vendor and with your own internal resources are the ones that will deliver business solutions, or deliver junk.  At the end of the day that is the bottom line.  So ALL of your RFI – RFP and project processes must focus on getting the right resources to design the right business solutions for you.

Your SAP RFI must focus on the things that indicate the SAP Partner helped companies achieve operational excellence, innovation improvements, or customer focus

There are several posts here, including academic studies, anecdotal evidence, personal experience, and plain old common sense that demonstrate the current RFI and RFP supported consulting models are completely broken:

If you have the time to review those posts you will quickly see why so many enterprise “COTS” projects, like SAP, Oracle, etc., are disappointing, or worse still, complete failures!  But there is a better way.  There is a game changing way to resolve this issue and help ensure you get the right people for your SAP project.

It’s time to kill useless SAP Partner RFI practices so they can be useful again

Let’s look at a couple of examples where system vendors had decent (not great, but decent) financial statements, long-term business roots, and lots of office locations but they went out of business–,  Arthur Andersen Consulting and Bearing Point.  Arthur Andersen’s greed, compromise, and unethical activities brought the organization down.  But those activities had been going on for many years (and are unfortunately very common in some consulting firms today)>

The lesson is to resist the lure of big money to pull you away from your values. Enron’s pile of cash was irresistible to Andersen’s leaders. And their lack of moral fiber cost a storied and proud firm its existence. [FN1]

With Bearing Point, after they spun off from KPMG and tried to go solo they got into financial trouble and eventually sold or disbanded their U.S. consulting operations [FN2].  Before that spinoff, with all of those customers they were engaged with, they were able to provide great financial stories, deep geographical reach, and from their KPMG roots they had long-term “stability.” 

Bearing Point initially had $200 million dollars in liquidity but could not get additional financing or secure additional credit guarantees.  Until that came out publicly the indications were their financials and time in business were strong.  From an SAP RFI standpoint would have qualified right up until they got into trouble.  And they did qualify for many SAP projects that were started or underway when they didn’t survive.  They simply ceased to exist as a company much like Arthur Andersen.

Traditional RFI processes would have shown both of these vendors were highly qualified.  They had size, scope (locations), financial backing (even Bearing Point had it publicly), and were well respected.  Traditional RFI processes might have caused you to select the wrong vendor.  So, again I ask, what is important in evaluating SAP partners?

SAP Partner or ERP Integration Vendor RFI Conclusion

Hopefully by the time an SAP Partner has performed several SAP implementations they have figured out how to do them correctly.  Unfortunately for many customers my experience has shown me this is rarely the case.  To resolve this problem customers everywhere must insist on SAP Partner RFI criteria that indicates business success.  Focus on the things that indicate the SAP Partner helped the companies implementing SAP software to achieve operational excellence, innovation improvements, or customer focus.  By taking this approach you may be disappointed at how quickly you have a shortlist of SAP Partners or enterprise integration vendors even before getting to the proposal stage.

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

[FN1] Companies that vanished: Arthur Andersen succumbs to the lure of big money, http://www.bloggingstocks.com/2008/06/08/companies-that-vanished-arthur-andersen-succumbs-to-the-lure-of/ (published 6/8/2008 and retrieved 10/18/2010)

[FN2] Consultancy Seeks Release From Debt Trap, The Washington Post.  http://www.washingtonpost.com/wp-dyn/content/article/2009/01/11/AR2009011101733.html (published on 1/12/2009 and retrieved on 10/18/2010).

Related Posts:

More on Vendor Selection Criteria and Methods for ERP Project Success

June 29th, 2010 by

Make the Right IT DecisionUsing the RFI and RFP Process for your ERP or SAP Education

One of the key vendor selection processes is to use the RFI (Request for Information) and RFP (Request for Proposal) processes to solicit comments, methods, tools, and resource examples of how knowledge transfer will be handled.  In other words, be sure to actively engage in the RFI and RFP processes rather than simply using them as some kind of a checklist or scorecard for the correct vendor.  This is your first and best chance to gain badly needed knowledge for your implementation project. Be sure to leverage a Request for Information process and the RFP process as an educational experience (see Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts).

The RFI and RFP process should also be leveraged to insist that every vendor provide actual sample templates, resources, project plans, tools, and any other item they claim will help ensure implementation success.  If necessary, proactively volunteer to sign an NDA (Non-Disclosure Agreement) and put in writing that you will not provide copies of any of the material to any of their competitors.  Note in the RFI or RFP that non-response to this item WILL disqualify them [**].

Successful Vendor Selection Process Best Practices

This is a followup to the previous post on SAP Implementation Partner or Company Selection Criteria.  That post reviewed a 2009 academic study from the country of Romania on successful ERP vendor selection criteria and processes.

The Romanian study (which I believe has fairly broad application) lined up several factors for a successful vendor selection process (Hurbean 2009, pg. 4-5).  Those include:

  • Develop an implementation plan prior to SAP implementation company selection
  • Have a clear understanding of the business with the reasons for the SAP implementation
  • Act as a change agent and avoid custom coding unless there is a clear business driver or business need

On developing an implementation plan and acting as a change agent you can use the RFI (Request for Information) process and the RFP (Request for Proposal) processes to have the vendors educate you.  For example, you may wish to ask each proposed vendor for example implementation plans from companies of similar size and similar type operations.  You may wish to ask for sample change management and training plans, or the number of consultants that were needed for each of those activities. 

During this process be sure to start out with a “checklist” for your vendor selection critieria, but routinely update that checklist as you go through the RFI and RFP learning process.

Vendor Selection Matrix of Resources, Budget Requirements, and Best Practices

If you use the RFI / RFP process well enough you can get a fair number of vendors to compare implementation processes with.  If there are plans and estimates (dollars, man hours, etc.) that are extremely high or extremely low in comparison to all of the others I would either ask for clarification on how that few resources can handle the responsibility, or why so many resources are needed – or you may just eliminate those vendors from consideration [***].  There may be some genuine validity to the points made on the number and quality of resources needed, but if vendors make certain claims be sure to spell them out in writing and include those claims by the vendor in your final contract agreement. 

To get a reasonable idea of the real resource and planning needs I would tend to stay near any clustering of effort, timeline, resources, that several vendors provide.  It is highly unlikely that any two of them will be exact, but they may be close enough to begin to make reasonable comparisons and use their information. 

For the business, that will take some effort to ensure you have defined the number of legal entities (company codes) number of physical locations (plants, warehouses, distribution centers), the number and types of customers or vendors, the number and types of materials, etc.  This will help to ensure proper scope and ensure a more even “apples to apples” vendor comparison.

Before you Make that Final SAP Implementation Company or Partner Selection

The one thing that can not be overlooked is the actual SAP consultants that an implementation company provides.  Do NOT accept generic resumes in the final round.  Once you have arrived at your short list of vendors, insist on actual resumes from the consultants that will be on the project.  Ensure that any RFP you offer spells out that this is a requirement, and ensure that any agreement penalizes or even disqualifies any vendor for any changes or substitutions of more than x% or y number of resources at the project start (there is a high turnover to the truly talented SAP consultants so many consulting firms experience a normal annual turnover of 15 – 25%). 

Do not hesitate to review, question, and even randomly spot check consultant references that are provided.  You will spend a LOT of money on them over the course of the project, far more than many of your company’s senior level management, so the up front due diligence can not be underestimated. They must be able to bridge the technology to business gap by possessing the following skills for success.  As I have previously outlined in Screening Methods to Find the Right Consultant – Part 2, a good consultant must possess the following skills:

  • Facilitation skills
  • Meeting skills
  • Process mapping
  • Business case (or whitepaper) development
  • Problem solving
  • Organizational dynamics

If the consultants they propose lack these skills you probably do not want them on your project anyway if you expect good results.  When it comes time to screen or interview them you might want to think twice if there are any type of language barriers to the employees you will be assigning to work with them.  After all, as I have said before, why does any company ever hire a consultant who has barriers to consulting?

Any consultant proposed by the SAP implementation company or partner will need all of these skills to perform the following project activities:

  • requirements gathering sessions,
  • design sessions,
  • blueprint writing,
  • solution assessments,
  • problem resolutions,
  • fit / gap analysis,
  • business process design,
  • translation of SAP / ERP speak to business language,
  • knowledge transfer,
  • training,
  • and organizational change.

The ability to communicate clearly, in an understandable manner, and to be able to translate application processes and requirements into intelligent business language is a key to these activities. How else are you going to get any kind of a decent blueprint, specification documents, or potential whitepapers explaining your options? If they are in SAPanese or other technical jargon they are virtually meaningless to a business driven project. If there are language barriers or the individual is too technical and unable to speak in plain, non-techie type language how will knowledge transfer and critical change management activities be carried out?

That list of the required consulting activities can also be used as part of your vendor selection checklist for templates, tools, resources, experience, projects plans, or other items needed for a successful project.

Vendor Selection Conclusion

In the end if the SAP implementation company or partner uses a good methodology, decent tools / templates, can help you understand key change management requirements, and ensures you have the best resources you are likely to be successful.  Any one of these areas can create a handicap right from the beginning and the maturity level of SAP is strong enough there is just no reason for it.

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

Hurbean, L. (2009). Factors influencing ERP projects success in the vendor selection process.  West University from Timisoara (Romania), MPRA Paper No. 14430, Faculty of Economics and Business Administration.

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

[**]  One of the routine scams that some SAP implementation companies use is to claim some special methodology or some special tools for implementing SAP.  This is almost always just some reformatted version of SAP’s ASAP (Accelerated SAP) Implementation Methodology and it is a scam.  The other routine scam by some SAP implementation partners is to claim that they use the SAP ASAP Methodology the way SAP provides it.  They may give you a couple of generic templates from that tool, but they have no actual client examples where they have actually used those templates and successfully adjusted them for the client.  You are looking for some type of redacted templates from actual client projects.

[***] Be VERY careful here.  A low number of resources, and a seemingly low budget may be a common shell-game.  Some vendors will come in far lower than others just to change order you to death and end up costing as much or more than the premium vendors in the end.  They may also be using “second string” or only slightly experienced consultants to keep their margins decent but costs low.  In the end this may work for an SAP INSTALLATION but not for an SAP IMPLEMENTATION.  If you are looking for a return on investment from the SAP implementation then this will likely not work.  On the other hand, the provider with significantly higher resource and budget requirements may be a large integrator with huge overhead that they have to support.  So you may be paying a premium in the number of required resources and budget.  In the end you control your own project fate and the more educated you are the more sophisticated of a service buyer you will become.




Popular Searches:


  • Discuss the criteria one would use for selecting ERP vendors
  • innovation in vendor selection process
  • sample proposal for change of ERP
  • sap vendor evaluation best practices
  • Vendor Selection Criteria Matrix
  • vendor selection matrix template
  • vendors evaluation matrix for erp project

Related Posts:

Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4

January 18th, 2010 by

Series Introduction Note:  The next 3 parts of this series contain step by step instructions and pointers on managing the RFP process (Part 2), conducting the vendor selection (Part 3), and then how to use the blueprint process to correct any discrepancies and lay a solid foundation for succes (Part 4). 

 R3Now.com - Breakthrough ERP, SAP, or IT Project Success

If you are an IT decision maker and you’re tired of pressure to achieve results that your system vendors or integrators can’t seem to deliver, use these steps to get the most for your money and achieve breakthrough results. Much of this article can be applied to any major project effort your company undertakes.  While some of the suggestions offered here can seem harsh or difficult from a people management perspective they can make a huge difference in your career prospects, credibility, and any future budget requests. 

Neutralizing the vendor proposal scams, clearing the smoke and looking past the mirrors for your ERP, SAP, or technology project requires a little clarity up front before you start your vendor selection.  It is possible to achieve breakthrough business results using technology and business software systems like SAP if you approach your project with the right perspective. 

That Brown Smelly Stuff they are Selling is NOT Chocolate

Promises, promises, sales scams, smoke, mirrors, and vendor proposals, you’ve heard it all before–, the sales pitches promise you a chocolate pie but all you get is some very expensive, and very smelly, dark brown fertilizer.

What these sales pitches never tell you and never deliver on is the “how” to make all of those chocolate pies.  As former General Electric front man Jack Welch calls it “the secret sauce.”  Sure, they describe some super-special secret sauce, they tell you all about their wonderful “Willy Wonka Chocolate Factory” but they only describe a fictitious place, an imaginary state of being. 

Fairy Tales and Vendor Selection Promises

I’ve been on lots of projects where someone dreams up what I call “mutually exclusive requirements.”  These are things that are completely contradictory, they are the old “either / or” logic gates.  You can have one, or the other, but you can’t have both.  Lots of presentations have the sales person delivering tons of promises that no one can deliver on.

Then reality sets in after you’ve signed the contract and the sales person leaves.  A strange odor begins to permeate the whole project.  But this usually happens very slowly over time so that you go through the “boiling frog” syndrome.  You smell a little here and a little there, but like most people you get used to it and think this is just the way it is.  You dismiss early signs that there may be something wrong, or you chalk it up to isolated incidents.  After you transition to a live environment and it is too late you suddenly realize it was not a chocolate pie you were getting but something else that is brown and smelly. 

When someone on the project has to deliver on the sales person’s promises some members of the vendor selection team are no longer involved in the day to day project delivery of those sales promises–, even if they are they often forget everything that was promised.  They only remember a few of their pet peeves they saw or heard during the presentation.  When the sales person describes lots of what sounds like chocolate you end up with lots of brown smelly stuff that is NOT the chocolate you were promised!

After the sales pitches and the promises what you end up with are blown technology project budgets, blown technology project timelines, and buggy custom-coded solutions for “off the shelf” packaged applications.  Fear not, there ARE things that can be done to reduce these results that are so very common with technology projects.

And even if you are misled by a vendor there are still things that can be done after you start with that vendor to ensure you don’t get taken.

SAP, ERP, and Technology RFP – Getting the Most Out of Your Technology Investment

There are several opportunities in early stages of your SAP, ERP, or other technology project to lay the ground work for genuine breakthrough results.  Along with the breakthrough results these early steps can help to set the tone and foundation for a very successful on time and on budget project.  There is just no reason for companies to continue to get taken by some of the unscrupulous or questionable practices in the technology and IT marketplace.

Even after you have selected your system integrator or implementation vendor you still have several chances to make sure they deliver their very best–, the very best tools, resources, and quality of workmanship.  If you change out questionable consultants early in your project then you will set a clear expectation of the caliber and quality of resources you will accept from your vendor.  Doing this early is the best time before they can do any serious damage.

General Patton once said that “War is Hell!” and business in today’s global economy is WAR!  The question you need to ask yourself is if you are in a war in the marketplace do you want raw recruits who are going to go through boot camp at your company, on your dime?  Or do you want veteran Navy Seals, Marine Snipers, and Airborne Rangers?  Raw recruits are usually cheaper, and that experience from those veterans comes at a cost, but who do you think will give you the best chance of winning the war for marketplace position?

Let me tell you, that Marine Sniper will hit his targets at 1,000 yards, but the raw recruits will not only miss, but in doing so will also give away your position and open you up to attack.  So in the end you decide which is more important.  You decide if it is better to take your chances or to take steps to make sure you’re not paying Navy Seal prices for raw recruits.

There are three key events or timeframes early in the project when you can create the best environment for breakthrough project success.  Two of these areas have no risk and at all and one of them contains a moderate amount of risk.  These three key events are:

  1. During business case development, RFP creation, and first pass rough project scoping.
  2. The actual vendor selection process, vendor proposal reviews, and system integrator contract.
  3. During and at the end of the blueprint process.

These key events contain several ways you can take control of your own business destiny and help to ensure the technology investment you make will move your business forward.

Four Part Series:

Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4
Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts
Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results

Related Posts: