You have selected SAP as your software application– now you move on to look for competitive bids from several software vendors to implement the system. You have a good understanding of the scope you want to address, but what do you look for and where do you begin? [FN1]
Your Primary SAP Implementation Focus
You can install SAP in your company through two primary ways: making your company fit the software, or making the software fit your existing processes. In other words, either you do a software re-engineering project, or you do a business process re-engineering project. These two methods provide the end-point markers or goal posts, and all implementations fall somewhere between them.
SAP has such a massive depth and breadth of functionality, combined with a significant number of industry vertical solutions, that you cannot underestimate this decision. No matter what some SAP system integrator or competing vendor might try to sell you, SAP’s business software applications cover at a minimum 80% and in most cases more than 90% of any business requirement with standard functionality. After over 100,000 implementations, in nearly every country on earth, in nearly every industry vertical, the applications simply have few gaps.
SAP Software Engineering or Business Process Engineering
As a business, what is your core competency? If you bring the right business people to the project, does your business competency, software engineering, or process design meet customer/marketplace requirements?
If your core competencies were software engineering and software design, you probably wouldn’t need many consultants. When it comes time to do your SAP implementation, the best approach is to lean heavily on vendors who can provide the right consultant for your needs.
If you want to stay closer to the business process engineering goal post (change the business to fit the software), then consultants with heavy project experience will help you through the critical change management activities. In any event, your focus will be more on training, communication, and change coordination (see Screening Methods to Find the Right Consultant – Part 2).
If your goal is to re-engineer the software application, then you should focus more on the technical competence of the army of coders you are paying for. You should spend a significant amount of time on business process analysis and fit gap analysis (the old “as is” and “to be” analysis). Your testing needs to be far more extensive and thorough; the number of “break-fix” support resources for your go-live will be significantly higher; you need extended support resources for a much longer period of time. You will still need some of the change management activities, just not quite as much. But you will be gaining SAP system integrator “lock in” for a long time as they support their custom-coded design work.
If your goal is business process re-engineering, you need solid consultants who know the application. They need enough skill to ensure that the thousands (and in some cases tens of thousands) of system settings are made to meet 90-95% of your business needs without any custom coding.
Should You Do SAP Software Engineering or Business Process Engineering?
No matter which route you choose, you should have clear business justifications for it. In other words, do you have specific processes that are part of your core value proposition or create significant competitive advantage in the marketplace? If your processes are that unique to your business model, are there other ways to accomplish the same process advantages? These types of key questions clarify whether or not you have a business justification.
If those unique process areas directly impact your industry or market position, then they might make sense for customized modifications. However, in less unique areas, such as purchasing, or accounting, or inventory management, you should try to stay close to the standard functionality. Sticking close to the standard system functionality may require change management, but it will be far more cost effective and less troublesome throughout the entire application lifecycle.
With very few exceptions, be suspicious of the consultants who frequently request for a something to be custom coded. I have found that the most common area for custom-coded requirements is in Sales and Distribution (SD). The only reason the team requires them there is because these are customer-facing processes most companies just will not change, no matter how compelling your case may be (this is why as a consultant we jokingly refer to SD as the “land of user exits”).
No matter which goal post your implementation is closest to (“out of the box” or “make it fit our business”), you should always have a direct business-related justification for custom-coded modifications. Usually, this is not the case. On the contrary, the most common reason I hear for modifying things in projects is “this is the way we’ve always done it.”
The closer you stay to the “out of the box” goalpost, the less expensive the entire application lifecycle will be. For example:
- The initial implementation will be less expensive,
- Ongoing support and maintenance will be less expensive,
- Upgrades will be less expensive,
- And you will have fewer issues and bugs to resolve.
Of course, many system integrators love custom-coded solutions. The more you customize, the more revenue they make– both in the initial implementation and in ongoing support and maintenance (which is not covered by your SAP support contract). The more customized the solution, the more dependent you are on them to maintain and support it. If you build many custom solutions, then you might as well get used to those expensive consultants (who have billing rates at two to four times your salary) as long-term pseudo-employees of your company. You will likely be paying them for several years after you go live.
Differences in SAP Consulting Models Depending on Your Goalpost
If you are content with modifying, coding, customizing, and otherwise re-engineering SAP, your consulting needs to lean more heavily toward software engineers. You likely need an army of ABAP and Java programmers, together with lots of consultants who have deep experience evaluating processes and writing technical design specifications for custom-coded work. A number of large consulting firms specialize in this kind of talent by bringing numerous generalists to the table. These are supposed process experts who have little or no specialization in SAP but are tasked with designing your SAP solution.
Maximize Your SAP Investment
If you wish to use the application to its fullest extent, with minimal modifications or customizing [FN2], then only consultants with deep application experience will do. As my friend Steve Phillips writes, modifications are sometimes needed and justified (see ERP Software: Are Modifications Always a Bad Idea?). However, knowing when that is and when there might be other alternatives takes a significant measure of experience and a deep understanding of SAP. For the most productive solutions, consultants also need some measure of other work experience before they started doing consulting work. The most experienced consultants can more accurately identify when to change the business processes rather than changing the application. They can evaluate the personalities and culture of the area they are responsible for, understanding how much change they can absorb and whether or not certain functionality is appropriate.
Because of the depth and breadth of SAP’s business software solutions, there is no substitute for real, verifiable, and deep experience. If you desire to stay close to the standard functionality, then the generalists from many large consulting companies, and the low-cost providers, cannot do the job. The generalists do not have the application exposure or application experience to know when you should or should not pursue custom alternatives. The low-cost providers usually (though not always) provide questionable resources with sketchy and hard to verify experience, or they take a project approach that is so narrowly limited in scope that the end result has less functionality and less automation than the systems it replaced.
Consequences of Custom-Coded SAP Solutions
The custom solution requires significant testing and may require additional iterations. Frequently when a custom-coded solution goes into a live productive system, new bugs or other unintended consequences occur. SAP’s software maintenance and online solution database does not support these bugs and fixes. That means every fix requires additional levels of coding, rigorous testing, and verifying that some new dependency from the fix does not affect or break something else. That custom coding requires long-term hand holding from the vendor who developed it.
The custom-coded approach requires much more skilled and disciplined project management around testing and coding quality checks. While testing is critical for every project, and for every part of the system that is going to be used, the custom-coded testing requirements are very different. Where testing standard application solutions is more for fit and function, the custom-coded solution has new dimensions of dependencies. Some of the things you need to consider are the following:
- Does the custom-coded solution even work as planned?
- Does it create new data dependencies and new data maintenance requirements?
- Does it interfere with the operation of other system functionality?
- Does it create new dependencies that require coding of additional processes to bypass incompatible standard system functionality?
- Does it create performance problems?
- Is it coded correctly so that data inconsistencies do not occur?
- Can it scale up?
- Are there regulatory implications (such as in healthcare and FDA validation)?
- Etc., etc., etc.
The list really could go on and on, but this provides some idea about the differences in testing requirements. The standard options can have these same issues– they are just less intensive and less dependent on correction.
Frequent Custom-Coded Messes and Ongoing Maintenance Costs from Bad Design
The standard application functions need to be tested more for fit and function, not whether or not they even work. If you do discover an actual problem with the standard options, your SAP maintenance agreement covers providing a fix for their own application.
These issues may be present with a standard solution as well; however, you have the benefit of many other customers discovering these items, referring them to SAP for a correction, and then SAP providing a solution as part of the standard maintenance. For example if you notice a performance issue with standard functionality, you may need to take up to an hour to research SAP OSS (Online Support System) Notes, and then apply the fix in that note at some convenient time. Depending on the system setup and design, you can perform testing relatively quickly. And here again, the level of testing even for applying note fixes depends on the amount of custom coding. If there has been a lot of custom coding, the testing will be extensive to ensure that the custom coding was not broken by a standard system fix.
For the custom-coded solution, this relatively easy fix might require an experienced system guru (an SAP Basis expert) to run performance traces and logs. After they isolate the source of the performance problem, they need to debug, fix programs, test, and then move it to production and hope something else doesn’t break.
The level of project management skill is more significant with the level of testing rigor for large projects with significant amounts of custom-coded solutions. The number and types of variations of testing and potential problems is also more significant. Rather than just testing for fit and function (as with standard functionality), you also need to complete a high level of integration testing between and among all other areas. Whereas the standard SAP solutions have had the benefit of hundreds, or even thousands of customers and system integrators beating on it and testing it, you are the only company testing or resolving your custom solution. No matter how thorough you are and no matter how skilled the consultants are, something will be missed.
On top of this, inconsistent or poor coding methods can cause huge problems and create major risks. I have seen many problems that are not readily apparent during the controlled testing, which cause huge problems in a production environment:
- Whole tables (all records) being locked from processing rather than individual table records, thereby preventing all users in all locations from being able to process similar functions. Single-record controlled testing did not reveal this until live in production.
- User exits (custom coding points in the source code provided by SAP) coded improperly so that they create other records or other processes before the record that triggers the requirement is completed. If anything happens and the initiating record does not post, then an inconsistency is created. Again, another anomaly that is a rare occurrence and probably would not be discovered in testing.
- Massive performance problems from poor coding and repeated select statements that are unnecessary (rather than using proper join statements in selects to minimize the number of database hits).
- Badly coded forms that cause entire transaction processes to crash without any indication there was a problem.
- Poor use of fields for selection options, or missing selection options that process massive data tables without any restrictions. This is not seen in the controlled testing and may only be discovered after larger amounts of data are available.
- Direct table updates that bypass normal system checks and create huge data messes and data “orphans” when they do not process correctly.
- Over-engineered and overly complex custom solutions when much simpler and more elegant options are available. Sometimes you should change the business process rather than trying to custom code a more painful fix.
- Hard-coded program values rather than using parameter tables. As a result, every time a key value changes in a company or organization, the program has to be modified, retested, and transported,. Not to mention, hopefully nothing that is dependent on it gets broken.
- Etc., etc., etc.
I am always amazed at the amount of hidden costs from custom solutions that too many system integrators are happy to accommodate. Sure, some customization is required, but some of it is also a complete waste when there are other alternatives.
In the end, it is your system and your solution. There are always some good reasons to move some areas of the application toward the goalpost of modifying the software to fit your business processes. However, you often only need standard functionality, or only slight variations on the delivered standard functionality. The more you minimize the custom-coded solutions and make the changes to standard application options, the less expensive your application lifecycle will be. In the end, some things will need custom coding, but minimizing that will minimize your costs and headaches as well.
Always keep in mind that there are tradeoffs, just like pushing on one side of a balloon. As you push in one area, out comes another. If you choose to keep the application closer to standard functionality, you will likely need to budget accordingly for change management because processes and jobs will be changing. If you make the application fit your business processes, change management issues may not be as significant, but you will pay more throughout the entire application lifecycle.
What can you do to minimize this? Insist that every custom-coded request be supported by a specific business justification, and then insist that a whitepaper be written that shows what other alternatives were considered and why they would not work.
======================
[FN1] One thing to keep in mind is that SAP’s ERP application primarily addresses value propositions related to operations. It is not because the functionality and the capabilities do not exist to do something different; it is because system integrators don’t generally know how to do it. While they have both functionality and the ability to build integrated custom solutions within the application for increasing revenue and profitability, this is rarely done because the marketplace hasn’t demanded it (see Using SAP to Improve Revenue and Profitability).
[FN2] In SAP, a technical type of customizing appears more like core application modifications or adding additional and specialized custom coding to existing places in the software where this is allowed. However, another type of customizing is frequently referred to as configuration. This type of customizing is very different. It involves setting up new standard system data types, such as new document types for POs, Sales Orders, Accounting Documents, Production Orders, etc., and then making standard system settings to support specialized business process requirements. Because the configuration type of customizing in SAP has literally hundreds, and in many cases thousands, of potential settings and options for any single process chain (such as order to cash, requisition to pay, plan to produce, etc.), there is no substitute for experience. These requirements and more do not allow room for fakes, or “freshers” as they are often referred to by the consulting fraud factories (see Screening Methods to Find the Right SAP Consultant and Screening Methods to Find the Right Consultant – Part 2).
