SAP Implementation Focus: Engineer Software or Business Processes?
You’ve 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 of the business processes you want to address but what do you look for and where do you begin? [FN1]
Your Primary SAP Implementation Focus
There are two primary ways in which SAP can be installed in your company; you make your company fit the software or you make the software fit your existing processes. These two methods provide the end-point markers or goal posts and all implementations fall somewhere between them. They present the classic options you have available, either you do a software re-engineering project or you do a business process re-engineering project.
Let me assure you, SAP as an application has such a massive depth and breadth of functionality, combined with a significant number of industry vertical solutions that this decision can not be underestimated. No matter what some SAP system integrator or some competing vendor might try to sell you on 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, there just aren’t a lot of gaps in the applications.
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, is your business competency software engineering or process design to meet customer / marketplace requirements? If you think of it in those terms the answer for any successful business is clear, you do what it takes to meet customer / marketplace requirements (unless you are a software company).
If your core competence 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 the one that leans 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 likely be able to 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).
Either you do a software re-engineering project or you do a business process re-engineering project
If your goal is to re-engineer the software application then you will focus more on the technical competence of the army of coders you will pay for. A significant amount of time will be spent on business process analysis and fit gap analysis (the old “as is” and “to be” analysis). Your testing will need to be far more extensive and thorough; the number of “break-fix” support resources for your go-live will be significantly higher; you will need extended support resources (read, expensive consultants and developers) for a much longer period of time. Mind you some of the change management activities will still be needed; they just won’t be needed 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 will 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. SAP is that broad and that deep in terms of functionality and in terms of industry specific options.
Should You Do SAP Software Engineering or Business Process Engineering?
No matter which route you choose, there should be clear business justifications for the approach you take. In other words, do you have specific processes that are part of your core value proposition or processes which 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 help to clarify whether or not there is a business justification for one approach or another.
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, it makes more sense to 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 very suspicious of the consultants who frequently seem to need something custom coded. It may be required, but you should still be suspicious. Over the years I’ve done SAP the most common area for custom coded requirements is in Sales and Distribution (SD). The only reason it is required there is because these are customer facing processes most companies just will not change how they do things 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” standard or “make it fit our business”), there should always be a direct business-related justification for custom-coded modifications. Usually this is not the case. The most common reason I hear on projects for modifying things is “this is the way we’ve always done it.”
The closer you stay to the “out of the box” goal-post the less expensive the entire application lifecycle will be:
- The initial implementation will be less expensive.
- Ongoing support and maintenance will be less expensive.
- Upgrades will be less expensive.
- And there will be 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 for maintaining and supporting it. And if you go all out with changing the application to match your business processes, and if you build lots of custom solutions, then you might as well get used to those expensive consultants (who have billing rates at 2 – 4 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 Goal Post
If you are content with modifying, coding, customizing, and otherwise re-engineering SAP your consulting needs lean more heavily toward software engineers. You will likely require an “army” of ABAP and Java programmers together with lots of consultants who have deep experience evaluating processes and writing technical design specifications for all of the custom coded work. A number of very large consulting firms specialize in this kind of talent by bringing numerous “generalists” to the table. These are supposed “process experts” with 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, there are times when modifications are needed and they are 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 very deep understanding of SAP (to know what the application’s limitations are). For the biggest benefit and the most productive solutions it also takes consultants with some measure of work experience before they started doing consulting work. The most experienced consultants will be able to more accurately identify when it would be best to change the business processes rather than changing the application. They will be able to evaluate the personalities and culture of the area they are responsible for and understand 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 have any desire at all for staying close to the standard functionality then the “generalists” from many large consulting companies, and the “low cost” providers can not do the job. The reason is simple. The generalists just don’t 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 is frequently less functionality and less automation than the systems SAP’s applications replace.
Whether your vendor considerations are a low cost provider or one of the big consulting companies there is no substitute for experience if you want to stay close to the standard system functionality. I still learn new things all the time because of SAP’s massive depth and breadth (even after doing SAP projects since 1994 and being an entrepreneur and tech “geek” since the mid 1980’s).
Consequences of Custom Coded SAP Solutions
The custom solution will require significant testing and may require additional iterations. It is a very frequent occurrence that a custom-coded solution goes into a live productive system and new bugs or other unintended consequences occur. These bugs and fixes are not supported by SAP’s software maintenance and online solution database. 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–, unintended consequences of the change. That custom coding requires lots of long-term hand holding from the vendor who developed it–, you get SAP system vendor lock in.
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 (does it do what it needs to and is the data correct) the custom coded solution has new dimensions of dependencies. Some of the things you have to consider are:
- 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 requiring additional processes to be coded to “bypass” other standard system functionality that it is not compatible with?
- 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. And it isn’t that the standard options don’t 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. And if you do discover an actual problem with the standard options your SAP maintenance agreement covers SAP 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 it may require an hour of researching SAP OSS (Online Support System) Notes, and then applying the fix in that note at some convenient time. Depending on the system setup and design, testing may be performed 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 take the time of an experienced system guru (an SAP Basis expert) to run performance traces and logs, then after the source of the performance problem is isolated program debugging, program fixes, testing, possibly additional iterations of fixes and testing, and then moving it to production and hoping 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) the level of integration testing between and among all other areas is increased. And where 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 creates major risks. I have seen many problems that are not readily apparent during the “controlled” testing that most projects do which causes 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 then 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 were available. Sometimes the option is change the business process rather than trying to custom code a more painful “fix”.
- Hard coded program values rather than using parameter tables so that every time a key value changes in a company or organization the program has to be modified, re-tested, transported, and then hopefully nothing that is dependent on it gets broken (because other dependent programs may have hard coded values) .
- Etc., etc., etc.
I’m always amazed at the amount of “hidden costs” of all of the “gee whiz” we really need that custom solution which too many system integrators are happy to accommodate. Sure, some of it 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 goal post of modifying the software to fit your business processes. However many times standard functionality, or only slight variations on the delivered standard functionality is all that is needed. The more you are able to 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 it comes out in another. If you choose to keep the application closer to standard functionality then 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 they will still be there), 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 there is 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 there is a technical type of “customizing” that is more like core application modifications or adding additional and specialized custom coding to existing places in the software where this is allowed. However, there is another type of “customizing” that 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 also mean there is no 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).
I’m always amazed at how many projects miss one of the most important (and relatively simple) scoping requirements. The worst part is that projects don’t just miss it but they get it completely backward!