The other day, I made a post to SAP’s Community Network on how to ensure customers get the best SAP business software integrator for their money. One of the comments to that post suggested that I was advocating for customers using only SAP as their system integrator. In my response, I stated that my goal is to encourage SAP customers to get educated so they actually achieve value and ROI from their SAP business software projects. My response sums up why I started this site and what the posts here are all about.
Don’t waste money on consultants who cannot help you implement business software in ways that improve your business!
To that end, we will look at the implementation of SAP or other large business software applications. Continuing this series of posts on shared success criteria, please see the table below for more information:
| 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
16. SAP System Vendor and Customer Trust
I place this SAP critical success factor (SAP CSF) clearly in the SAP system integrator column. You are writing the checks for an SAP system integrator who needs to deliver value. Otherwise, what are you paying for anyway?
Trust, but verify: Why would you pay an integrator who does not deliver business value?
SAP System Vendor “Trust but Verify“
There is a Russian proverb which states “trust, but verify” or, its English equivalent, “better safe than sorry.” The phrase gained popularity in the United States during the presidency of Ronald Reagan. He often used the phrase when dealing with the Russians about nuclear weapons. When the U.S.-Russian INF (Intermediate Nuclear Forces Treaty) was signed, Mikhail Gorbachev commented to Reagan that he used the phrase at every meeting, to which Ronald Reagan replied, “I like it!”
How does this relate to you and your SAP project? The whole idea behind the proverb as used during the Nuclear Treaty discussions was the ability to monitor compliance with the treaty details. Just as this nuclear weapons discussion was critical to the relations and operations of the two nations, so is an SAP implementation to your company. A business software system project is critical to competitive advantage, efficiencies, operations, innovation, and even customer acquisition and retention. A properly implemented SAP business software system is critical to navigating a hostile competitive global business landscape.
Progress monitoring, deliverables verification, and QA assessments must take place throughout the project lifecycle.
See the list of SAP ASAP Methodology deliverables by project phase. Your SAP sales rep or SAP system integration vendor will have access to the most recent ASAP methodology and can provide you with the SAP standard version of the requirements. Unfortunately, because of the way the SAP copyright is written on the material, I am unable to directly distribute it legally.
How do you “trust but verify?” Here are some tips for ensuring this:
- Ensure that you consistently communicate your expectations to the system integrator
- Make sure your integrator provides a clear project plan with key project milestones (from the ASAP methodology).
- Ensure that there are deliverables that have a connection back to the project activity being completed (again, from the ASAP methodology).
- Verify that the vendor has a complete set of deliverable templates they can show you and explain ahead of time how they will work and how they are used to track SAP project progress.
- Perform a mini-audit at each project milestone with business stakeholders to determine whether the deliverable(s) were sufficiently addressed and whether the upcoming deliverables templates appear sufficient for the next milestones.
- At the end of each project phase, ensure that you perform a QA check of that phase before continuing with the next. This is a standard SAP methodology process but is rarely followed by many consulting firms.
17. SAP system design decisions and
18. Amount of SAP ABAP custom coding
Both of these topics are directly related. With SAP in particular, they are pretty much interchangeable. The academic literature breaks these two critical success criteria items out because SAP is not the only business software package that is evaluated. With SAP in particular, the depth and breadth of business software functionality is so significant that custom coding should only be used if there is no close fit from standard functionality.
Before you begin your SAP project, you need to decide whether you want to do software engineering or business process engineering. This post explains the differences, what the consequences are, and when it might be appropriate:
SAP Implementation Focus, Software Engineering or Business Process Engineering?
https://www.iitrun.com/sap-implementation-focus-software-engineering-or-business-process-engineering
The amount of custom-coding and software engineering you engage in will have a dramatic affect on your overall SAP TCO (Total Cost of Ownership). This will also have a significant impact on the amount of budget you allocate to critical change management activities and to ongoing software support and maintenance.
- Set a project expectation with the system vendor that everything you had in your scope must be delivered with standard functionality.
- Create a change review board to address any scope change requests and any custom coding requirements.
- Create a contract provision with terms stating you will get ( x ) amount of a credit when a custom-coded solution is proposed that had standard package functionality addressing ( x ) % of the business requirement.
- Ensure that every custom coding decision includes a written justification with:
- The standard functionality that was evaluated
- Why the standard functionality would not work (what were the gaps)
- What the business justification for the custom coding is (is it mission critical?)
- Alternatives considered (remove from scope, third-party software, manual process, etc.)
- Business impact if removed from scope or manually performed
- If you decide to pursue the custom development, then you must complete a standard functional specification. A good template to start with can be found in the SAP ASAP methodology. It should contain the following:
- Detailed requirements.
- Expected effort and cost.
- All SAP module or other areas affected (in other words, is this custom development going to be a huge project distraction by consuming too many of the consultants’ time and effort?).
19. Appropriate SAP Software Configuration (system settings)
The system integrator is hired to set up the SAP software. Through the sales process, they have convinced you their consultants have the experience you need for success and you hire them for your SAP project. They are the experts, and you have to rely on them because you don’t have the internal experience.
This is where good SAP consultants come into play. The SAP ERP application contains so much functionality that nearly any business process can be addressed.
Appropriate software configuration is one of those things that is usually discovered at integration testing. By that time in the project, it may be too late to make significant corrections or adjustments without jeopardizing the entire project timeline and budget.
As a customer, you can do several things to ensure that the correct SAP software configuration and settings are made, even though you as a customer may not know what they should be. Here are the major ways to ensure good software configuration:
SAP Project Team Training
First and foremost, to ensure appropriate SAP software configuration and quality SAP consultants, invest in your own project team’s training. This critical training should be budgeted for right from the beginning. Do not let any SAP system vendor talk you out of it.
Some system vendors will try to convince you that they can teach your project team rather than having you send your people to independent SAP training. That is a great way for them to “control the message” you receive about SAP’s functionality and the consultant’s level of skill. Oftentimes, they try to sell you on the idea that they should be training your people instead of you sending them to training. Won’t it be cheaper?
However, if you do the math for the consulting hourly rates and then factor in the consultants’ time away from value-added implementation efforts, it doesn’t add up. Often, it is less expensive to send your project team to formal training. Even if it isn’t, you still need that independent oversight. Only independent training ensures your people really know what they need to know.
SAP Prototyping and Proof of Concepts for SAP Project success
I personally favor the prototyping approach. If you are a customer who wants to make sure you have the resources you are paying for, this is the easiest way to find out. By requiring a baseline proof of concept no later than the end of your Blueprint phase, you will quickly see which consultants have real experience that the SAP system vendor has provided. By contrast, you will also see those who lack experience.
In the SAP ASAP methodology, one suggestion is that the initial baseline prototype (the first one done right at the end of blueprint) might cover 50–80% of the business requirements.
For more information on prototyping and the steps for ensuring project success, please see the post ERP, SAP, or IT Project Management and Prototyping for Success at https://www.iitrun.com/erp-sap-or-it-project-management-and-prototyping-for-success
Be sure your system integrator’s consultants do full, end-to-end process prototypes. For example, just doing a single transaction is not enough to demonstrate the system will meet the business needs. By the end of Blueprint, a seasoned and experienced consultant should be able to demonstrate these simple, straightforward, and standard processes.
- In the SD area (Sales and Distribution) an order, and then delivery with picking and goods issues, and then an invoice must be created. You may wish to have them post cash and then review the material and accounting documents as well.
- In the PP area (Production Planning), maybe you want to see independent requirements run through MRP and then convert the results into the purchasing and production documents. From there, you may wish to have them do the receipts and the confirmations of the production on a material.
- In the MM (Materials Management) area, you may wish to integrate this with PP (or not) and have the consultant show you the requisition to PO to Goods Receipt to Invoice receipt and then application of cash payments to the vendor.
In other words, a skilled SAP consultant can do the setup work for at least a first pass at all of these processes by the end of Blueprinting.
Significant benefits of SAP Prototyping and Proofs of Concept
I strongly favor SAP prototypes and functionality demonstrations throughout any SAP project. Prototypes can quickly expose process gaps, potential integration problems, and business process issues– ensuring that testing is smoother. One of the significant advantages of prototyping is that it places an emphasis on overall business processes.
By relying heavily on prototypes and functionality demonstrations throughout an SAP project, you ensure that the project team works more closely together. Additionally, only the best consultants are provided by the integrator, your internal client project team acquires more knowledge sooner in the process, and you have a better go-live.
