INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

FIXING Stupid SAP Vendor – Partner Selection RFI – RFP Processes

February 21st, 2011 by
Why SAP Projects Fail to Deliver ROI and How to Change IT

SAP ROI starts with the RFI - RFP

I’m always amazed at how much time, energy, money, and effort companies spend on the SAP Request for Information (RFI) and Request for Proposal (RFP) processes. It is common to spend months, and in some cases even years, evaluating, analyzing, and preparing for an RFI or RFP.

During the RFI and RFP preparation stage senior management and staff are involved, at times a dozen or more employees may be involved. When you add it all up it can easily cost your company tens of thousands, hundreds of thousands, or with some large companies even millions in evaluation costs. All of this before a single vendor is contacted.

Let the SAP RFI and RFP Race Begin!

After all the analysis you send out your SAP or ERP Requests for Information (RFI) to an initial list of vendors you would consider doing business with. You include details of your initial scope and the key information about the size and complexity of your project in your SAP Request for Proposal (RFP) (see SAP System Vendor Project Success Criteria & Factors 2, Section #10).

After all this time and effort you get the RFI results and narrow the evaluation field to a few finalists. You schedule the proposals and the vendors arrive.

The SAP RFP show is on – Welcome to the Three Ring Circus!

SAP Partners bring in a small army of sales people, senior level management, and maybe one or two key consultants. They start showing lots of slides while their staff “works” the room. Before vendors ever come to the presentation they have strategy meetings and discussions about how to handle various issues and how to set the stage. This is their dog and pony show. A room full of sales people and some senior level employees want to convince you to pick them!

This is their job, this is what they are paid for, this is what they do.

How much of this really matters? At the end of the day are any of them going to actually deliver the business solutions? After all the smoke is cleared and the mirrors are put away how many of the people at the RFP will deliver your SAP or ERP project?

A Simple Fix to the SAP RFI or RFP Processes Increasing SAP Project Success

Based on the number of companies who are dissatisfied with their ERP investments it is clear that the SAP RFI and RFP processes are broken. If they weren’t broken there wouldn’t be nearly as many frustrated customers. After all, it is the RFI and RFP processes that determine the composition of your project team, the consulting project team, the tools and resources that are used for delivery, etc. In other words that early foundational work of picking the right vendor, their consultants, and their project tools is a critical key to your chances for project success.

To be successful your whole focus should be on aggressively addressing the ability of vendors to use SAP functionality for business benefit. Who really cares how great the vendor’s sales staff thinks they are?  That’s what those sales people get paid for.  Ask yourself, during the course of your SAP software project who is going to ensure that your business marketplace competitive pressures are addressed with the solutions they provide? Will any of those grinning sales people or those senior executives work on the delivery of the solution they are trying to sell you?

A focus on the vendor delivery team, rather than the sales team,  should be non-negotiable

Make a real difference in your SAP RFP by focusing on the consultants who will be responsible to deliver project success, for example your SAP RFI might require the SAP partners or vendors to indicate:

  • Average consultant application experience (BOTH in years and numbers of full lifecycle projects)
  • Average consultant business experience before or during SAP projects
  • What is the contact information for the vendor’s last 3 SAP projects (sequentially, not “reference clients”) that were completed?

For the SAP RFP it is critical to ensure you get detailed information on the actual consultants the vendor is proposing. Another key requirement has got to be your ability to interview every single consultant the vendor is proposing. You might even require that the vendor include ONLY customer references from the consultants who are being proposed for your project.  Who cares what the sales guys say — the consultants and project manager will be responsible for delivering the results.  After all, as the research indicates, the level of experience and types of skills needed for excellence can not be underestimated (see  Expert SAP Consulting to Reduce SAP TCO and Improve SAP ROI).

A focus on the vendor delivery team, rather than the sales team,  should be non-negotiable and any vendor who fails to comply must be automatically disqualified. Some of the key requirements of your RFP might include:

  • Consultant special business solutions:
    • What special processing solutions, reports, process changes, automation, or other solutions have they created?
    • What was the difference with the standard SAP solution and their alternative?
    • How or why did they choose any custom solution rather than standard functionality?
    • What business competitive pressures were addressed by these solutions? (Vendor / Supply management, Customer focus, Competitors, New products / services, i.e. operations, innovation, or business growth).
    • What specific business need was addressed and how was this solution innovative?
  • What have the last 3 or 4 clients said about this consultant?
    • Who can you contact STILL AT THOSE CLIENTS (not third parties) who have enough knowledge to speak about that consultant’s skill?
  • What customers or projects are represented by the consultants the vendor will propose (and note that these WILL be checked against the actual consultants proposed).

There are so many “con”sultants with fake, misleading, or insufficient backgrounds or experience it is no wonder customers are often frustrated by the lack of results from their SAP software projects (see Screening and Interview Methods to Find the Right SAP Consultant ).

A Revolutionary SAP RFP Idea

Perform a “game changer” in your SAP RFP processes. Mandate that the consultants who will deliver the project must be the ones who deliver the RFP presentation. ALL OF THE PRESENTATION! What a great way to find out the real skill level of the consultants who will actually deliver your solution. By using this method this is your opportunity to evaluate the SAP vendor’s delivery team skill level. After all consultants with several successful SAP implementations will have developed several key skills that you will be able to directly evaluate during the RFP presentation:

  • clear oral and written communications,
  • solution assessments,
  • problem resolutions,
  • business process design,
  • translation of SAP / ERP speak to business language,
  • knowledge transfer,
  • training,
  • and organizational change.

Their ability to deliver the RFP demonstrates whether or not they possess sufficient experience, how well they handle pressure, and whether or not they can actually solve business problems you might question them about.

If the consultants do not have enough experience to translate techno-speak into plain, understandable business language then how much meaningful experience do they really have? If they can’t deliver the RFP how will they lead requirements gathering sessions and ensure business requirements are captured and addressed? If they can’t answer your business problem questions in ways that you can understand how much experience do they really have?  For more details on critical skills for good SAP consultants please see the post entitled “Screening and Interview Methods to Find the Right Consultant – Part 2“.

If you need help with a business focused SAP RFP, or with the ways to evaluate and screen consultants consider hiring an outside expert for this.  Not just an RFP “expert” who will only help to use the traditional “dog and pony show.”  But an expert who can help to guide you through the important evaluation tasks.

We offer this service at R3Now or you might look for others who specialize in this type of thing like Michael Doane (www.michaeldoane.com), Jon Reed (www.jonerp.com/), or for SAP HR or HCM related functions you might consider Jarret Pazahanick (www.platinumHCM.com).  We are more than happy to partner with some of these and other industry experts to help ensure you get the best possible results.

Contact us today!

Related Posts:

SAP Success Factors for Vender Selection – Responsibility Matrix 2

October 18th, 2010 by

Top ERP Success Factors

Based on a combination of the academic literature [FN1] and my personal experience I have put together the following SAP and ERP Critical Success Factor Responsibility Matrix. The large “A” indicates a primary responsibility, a small “z” indicates a secondary responsibility, and a blank field indicates no direct responsibility.

This is part of the continuing series on managing the SAP vendor relationship to help ensure SAP project success.  This can be achieved by reviewing the SAP critical success factors, how responsibility is divided, and tactics for managing them.

You want success, they want your money, MAKE SURE THEY EARN IT!

The small “z” indicates that the party has a very strong influence over that factor but may not be in the position to ensure that it is successful. These small “z” areas are often the key areas where parties with more of a primary responsibility tend to try to lay blame on the other party when a project runs into trouble.

No. SAP or ERP Critical Success Factor Company Integrator
1 Senior Management Support (and steering committee makeup) A  
2 SAP project champion A  
3 Empowered business project team decision makers A  
4 Company SAP project team (quality and time allocated) A  
5 Experienced SAP consultants   A
6 SAP project success criteria, goals and objectives A  
7 SAP implementation strategy z A
8 SAP project management A z
9 SAP tools, templates, and resources   A
10 SAP scope development z A
11 SAP scope management A z
12 Strong SAP project and business communication (inward and outward) A z
13 SAP change management A z
14 Business process engineering – interdepartmental cooperation A  
15 Sufficient SAP training (user and project team training) A A
16 SAP system vendor and customer trust   A
17 SAP system design decisions  z A
18 Amount of custom ABAP or other SAP coding  z A
19 Appropriate SAP software configuration (system settings)  z A
20 SAP system change control process   A
21 SAP data analysis and conversion A z
22 SAP test planning A z
23 SAP test development z A
24 Company end-user involvement and end-user testing A  

Legend

A = Primary Responsibility for the success factor
z = Shared but secondary responsibility for success

During your SAP or other ERP project it will be critical to pay very careful attention for you as a customer to those areas where the system integrator or consultants have a primary responsibility (the “A” areas) and where you share the responsibilities (the “z” areas). Those are generally the activities that many of the “con”sulting companies and unscrupulous integrators will take advantage of you and lay blame on you for activities they should be more carefully managing. If your project really goes wrong you can bet that in one way or another, you as a customer, will be shown to be somehow responsible for their primary area of responsibility.

SAP Vendor or System Integrator Responsibilities

On the other hand, you as a customer also need to be aware of, and careful about, the areas where you have the primary responsibility. And especially the areas where there is a shared responsibility with the system integrator and they only have a limited ability to influence your activities and success. Those areas should not be blamed on an SAP consulting firm or the consultants if it can be shown they tried to encourage you to do the important tasks to ensure success.  Keep in mind, at the end of the day, as the customer, you are always primarily responsible for your own success.  If risks, problems, or other issues arise and you as the customer do not take corrective action then no system integrator or consultant can change that.

SAP Customer or Client Responsibilities

For those shared responsibilities where the system integrator is tagged as a “z”, if they failed to let you know ahead of time, in a timely manner, a) what to expect, b) how to deal with it, and c) the risks involved, they may not have the experience they sold to you. Keep in mind that does not mean they will be able to spot every issue, every time, ahead of time or have the answer for every situation. But if that foresight is consistently lacking then caveat emptor, or, buyer beware in your engagement with that vendor.

List of ERP or SAP System Vendor Request for Information (RFI) Requirements

One great area to start out your SAP vendor selection process is with an RFI, or Request for Information from the vendors you are considering. I suggest you ask them to respond on how they will handle any and all of the key shared responsibility areas. In the table below you might want to reproduce it and remove the responsibility assignments (see the example below).

At the end of the day, as the customer, you are always primarily responsible for your own success

SAP system vendor RFI’s should include a list of each shared responsibility from the list above, who the vendor believes should “own” that responsibility (the large “A” or primary), and what resources they have to facilitate success.

No. SAP or ERP Critical Success Factor Company Integrator
5 Experienced SAP consultants   A
7 SAP implementation strategy z A
8 SAP project management A z
9 SAP tools, templates, and resources   A
10 SAP scope development z A
11 SAP scope management A z
12 Strong SAP project and business communication (inward and outward) A z
13 SAP change management A z
15 Sufficient SAP training (user and project team training) A A
16 SAP system vendor and customer trust   A
17 SAP system design decisions z A
18 Amount of custom ABAP or other SAP coding z A
19 Appropriate SAP software configuration (system settings) z A
20 SAP system change control process   A
21 SAP data analysis and conversion A z
22 SAP test planning A z
23 SAP test development z A

Legend

A = Primary Responsibility for the success factor
z = Shared but secondary responsibility for success

You can use this table as a first pass method to disqualify ANY system integrators that are non-responsive and those vendors that attempt to avoid any accountability for what they deliver. If any SAP system integrator is going to try to make you solely responsible for the success of every facet and phase of the project what do you need them for? In other words, if they are not willing to “own” any of the responsibility for your project’s success maybe you should be looking for different vendors.

How to use the SAP Vendor RFI Shared Responsibility Matrix

Use this table for gaining insight into a vendor’s operations and project approach. For example you might wish to use it in the following way:

    1. Send the proposed system integrator a list, similar to the one below, with BLANKS under the responsible party column and ask them to fill out who should be responsible for each success factor.
    2. SAP ERP Critical Success Criteria Table for Vendor RFI processing.

     

    Resource
    Y / N
    SAP or ERP Critical Success Factor Company Integrator
      Experienced SAP consultants    
      SAP implementation strategy    
      SAP project management    
      SAP tools, templates, and resources    
      SAP scope development    
      SAP scope management    
      Strong SAP project and business communication (inward and outward)    
      SAP change management    
      Sufficient SAP training (user and project team training)    
      SAP system vendor and customer trust    
      SAP system design decisions    
      Amount of custom ABAP or other SAP coding    
      Appropriate SAP software configuration (system settings)    
      SAP system change control process    
      SAP data analysis and conversion    
      SAP test planning    
      SAP test development    
            Additional Vendor SAP Success Criteria 1    
            Additional Vendor SAP Success Criteria 2    
            Additional Vendor SAP Success Criteria n…    

     

    1. Pay special attention to those vendors that might offer ADDITIONAL success criteria from what you send them. These vendors may understand and appreciate your focus on project success. If nothing else it will at least indicate they are giving it serious thought.
    2. Indicate in your RFI that failure to adequately address the critical success criteria section of the RFI will automatically disqualify that vendor. Why deal with ANY integrator, no matter how cheap or how supposedly “experienced” they may be if they are not willing to focus on your project success?
    3. Under the “Resources” column ask the vendors to indicate if they have specific approaches, tools, methods, or other resources to help ensure success.
    4. In your RFI ask them to include in a separate sheet any of the “Y” answers, and to be ready to demonstrate those approaches, tools, methods, etc. during any future sales presentation.
    5. For any Resource answer with an “N” (no resources) ask the vendor in their RFI to propose some method to manage the risk associated with not achieving that success factor.

    In other words, this exercise does a number of things that are helpful to you as an ERP services buyer from an SAP system integrator or SAP implementation vendor:

    • It focuses every vendor on project success criteria even before they engage in their sales pitches.
    • It helps to separate some of the less reputable vendors from the process by exposing the vendors who do not believe they have any stake in your project’s success.
    • This approach ensures that the prospective SAP system vendor or SAP consulting company provides tools, resources, methods, and approaches to mitigate risks associated with not addressing each of the success criteria.

    As we continue through this evaluation of SAP software critical success factors in future posts we will look at methods, tactics, and strategies for managing each of them to promote success. After all, you want project success, ROI, and business benefit, they want your money so they should earn it. Take some time and review the following posts for more background on vendor selection and vendor evaluations.

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

    [FN1] This table was developed from a combination of factors found in a graduate student’s submission, from peer-reviewed academic literature I’ve previously written about, and from my own experience with SAP since 1994 and business systems since the mid 1980’s.

    Bhagwani, A. (2009). Critical Success Factors In Implementing SAP ERP Software, University of Kansas Graduate School. http://www.r3now.com/literature/2009-Bhagwani-SAP-Project-Success.pdf .Somers, T., and Nelson, K., (2001) The Impact of Critical Success Factors (CSF) across the Stages of Enterprise Resource Planning Implementations. Proceedings of the 34th Hawaii International Conference on System Sciences. Somers, et. al., has been reviewed in detail on this site at:

    The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors
    http://www.r3now.com/the-top-5-erp-success-factors-by-project-stage-from-22-critical-success-factors

    Related Posts:

    ERP Software Selection: Do you want to be a Guinea Pig?

    August 9th, 2010 by

    Hit the target

     

    “If the software functionality does not do what we need it to do, nothing else really matters.”

    Back in the 1980’s, IT department preferences or mandates to use specific proprietary mainframe technologies drove many ERP software decisions. This was about the technologies the IT department could (or would) support not the mainframe software that best satisfied business needs.

    Later in the 1990’s the mainframe vs. “open system” (client/server) wars caused many to take a blind leap of faith into open systems only to find out later the ERP software functionality in this arena was not as mature as their mainframe counterparts. Though open systems eventually won, many jumped head first into this brave new world simply at the wrong time.

    Today “open source ERP”, upstart internet based application services (SaaS), “cloud computing” and other paradigms represent the same fork in the road. It is guaranteed tomorrow there will be a new one. The point is not to generalize regarding any particular direction; but the lessons of the past must not be ignored…. If the software functionality does not do what we need it to do, nothing else really matters.

    When this occurs everyone will forget all the seemingly valid reasons a package was selected in the first place (cheaper, newer technology or everyone else is starting to do it). They will focus on the lousy functionality and lack of project benefits.

    In the real world budgets are not unlimited, technology can be a strategic enabler, and there are other important trade-offs. However, nine times out of ten if the software functionality is a bad fit, eventually the project is deemed a failure. This means software decisions that do not weigh functionality the most can defeat the purpose of a new ERP system.

    The Future of ERP?

    The message above seems simple enough (and almost elementary), but many smart people allow themselves to get caught up in the industry hype.  Let the academics and consultants who really care debate the future of ERP because in the meantime you have a business to run. Unless you are interested in becoming a guinea pig. Believe me, a lot of software vendors are looking for them.

    The Right Side of ERP History

    Selecting software is not just a quantitative process. It ultimately boils down to a business decision and you want to be on the right side of history. As long as the cost of ownership is affordable, the technology stable, the package is supported, and many other companies are using it; go with the software that best meets business needs. 

    If the organization cannot find a package that satisfies at least 85% of the overall software requirements (and almost all of the important ones), it is time to either look at higher-end packages or redesign your business processes.

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

    Editor’s commentary – Steve Phillips runs a great blog which is linked here:

    http://it.toolbox.com/blogs/street-smart-erp

    Be sure to visit his site and support his efforts!

    Related Posts: