Business Solutions with SAP

Agile Project Methods for SAP ERP Projects?

October 29th, 2012 by
Agile or Waterfall on SAP ERP projects?

SAP Project Guidance


Looking at the “Agile Manifesto” and how Agile methods are applied generally involves small, discrete, “digestible” work and task components. 

Trying to juggle the number and complexity of dependencies on a full scale SAP ERP project involves management and coordination efforts which completely go against the idea of Agile methods.   


ERP projects tend to have too many moving parts for Agile–, there are too many dependencies and Agile provides too little control and coordination.  The level of coordination required for a large business package implementation flies in the face of “Agile” methods and techniques.  For example, you have to coordinate:

  • process configuration teams,
  • custom code development teams,
  • data conversion,
  • change management,
  • training,
  • testing,
  • governance,
  • infrastructure, etc. 

On complex projects like this all those “sprints” that are not carefully coordinated and planned (which goes against the “Agile Manifesto” listed below) become completely disjointed disasters.  There are too many work streams with dependencies that can not be going in “their own direction” regardless of the impact to other work streams.

Agile Manifesto Activities

The following chart, from the Agile Manifesto, illustrates serious trouble spots for ERP projects like SAP.



Individuals and interactions Processes and tools
Working software Comprehensive documentation
Customer collaboration Contract negotiation
Responding to change Following a plan

Notice, 3 out of 4 of those items on the RIGHT side are often precursors to ERP implementation failures according to the academic literature.  Numerous case studies prove Agile “De-Valued” areas are the places ERP projects fail.  For example:

  • Failure to follow good processes and have solid tools.
  • Failing to have adequate documentation (training materials, help, etc.)
  • NOT following a well laid out plan (i.e. SAP’s PROVEN ASAP implementation methodology, including sample project plans, templates, etc.).

The only Agile Manifesto item that might have strong need to be followed in the ERP space is the focus on the customer over the system integrator contract.

All of those Competing Stakeholders and Constituents

Not only are the project related dependencies and work streams significant, there are numerous competing constituencies which must also be coordinated:

  • business stakeholders or organization,
  • IT,
  • external business customers,
  • external vendors,
  • system integrators (when you use consulting companies),
  • internal business senior management,
  • business department heads who don’t always agree with each other, etc.

While Agile methods might work well for small, discrete, component areas of an SAP or other ERP project the academic literature proves it is a disaster for ERP implementations. 

Agile is not a waste of time, it must just be understood and used in the PROPER CONTEXT of an overall SAP project.  Even the ASAP Methodology includes an “Agile” overlay.  This is an overlay of the existing ASAP Methodology–, it does not replace more traditional waterfall methods and does NOT adopt the “de-vauled” Agile Manifesto areas.

Does Agile Have a Place in ERP Projects?

It might. 

Agile is not suitable for projects with multiple, overlapping / parallel activities with dependencies between them.  The parallel and overlapping dependencies create a requirement that is more suitable to traditional project management methods with:

  • full project plans,
  • discretely defined tasks and responsibilities (to avoid “border wars” at transition points),
  • clearly defined deliverables,
  • management of parallel work-streams and parallel critical paths, etc.

Applying Agile principles to an overall SAP project creates a high likelihood of blown timelines, blown budgets, and collapsed scope — delivery  suffers while  stress balloons.

Agile in SAP ERP Project Examples

I know about the struggles, stresses and messes of Agile SAP projects.  I’ve been on three of these types of projects and none of them went well.

On one SAP project they tried to manage it with “Agile” and it was a complete mess –, the coordination and responsibility struggles forced  a change to the more traditional waterfall approach.  Using Agile methods the project had an unsustainable burn rate for the budget,  dates were ALWAYS slipping, inter-team coordination and planning were a complete disaster, and before the mid-course correction this project was not  going to go live. 

Worse still because of the “Agile” methods of only planning small, discrete work components just before they are due, each dependent group tried to minimize their own work and risk by dumping many of their traditional responsibilities and tasks onto any other group.  With Agile they were allowed to “self define” much of their own effort and naturally tried to minimize their effort while maximizing their success (at the expense of other project participants and work streams).

I do NOT place this responsibility on the clients who hire outside help, they obviously recognized a capability gap or a need they are willing to pay for.   I hold the outside project managers responsible for this and if you ever encounter one of these snake oil salesmen then you should FIRE THEM!

My Conclusion on SAP and Agile Deployments?

Pure application of Agile is a disaster  on any major SAP, ERP, or business software implementation project.  I can absolutely guarantee you that any Agile SAP project delivery “success” claim violated the Agile Manifesto to get there.   There are too many moving parts and too many constituents to use pure Agile on a full blown SAP project.

However, Agile can work within certain task areas, and at different periods and phases in projects.  I have used “agile-light” approaches which have a waterfall overlay.  It is possible to successfully combine agile tasks, to provide a higher quality project result, as long as you continue with the waterfall coordination between work-streams and efforts.

Popular Searches:

  • sap roi powerpoint
  • how to select a project for Agile for sap erp

Related Posts:

ERP vs. ERP II vs. ERP III Future Enterprise Applications

May 31st, 2010 by

ERP vs ERP ii vs ERP iiiERP I, ERP II, & ERP III Abstract

ERP applications integrate enterprise operations within and across enterprise legal entities, or company codes.

ERP ii (or ERP 2) applications extend supply functionality to external enterprises (generally vendor-affiliated companies or enterprises) to reduce cost, improve supply chain efficiency, and to perform collaborative innovation. 

ERP iii (or ERP 3) enterprises go to the next level of integrating the ERP and ERP ii functionality to include customers and the sales side of the marketplace into enterprise operations.  Your customers become active participants in your business.

Moving To the Border-less Enterprise

I’ve heard and read lots of material about the enterprise applications and what the next generation of ERP is.  Some have suggested that ERP systems were just manufacturing tools (see e.g. ERPwire article on major differences between ERP vs. ERP ii).  Some suggest ERP ii systems were little more than an extension of ERP functionality to new industry sectors.  In my opinion this is a completely misplaced assessment.  Changing industry sectors does not change what an ERP application does so a broader definition is more appropriate.

Before we go into the details and background of each of the 3 generations of enterprise applications here are my definitions for ERP, ERP ii, and ERP iii systems:

ERP Definition

An ERP (Enterprise Resource Planning) system integrates virtually all operational business functions and processes and automates entries to finance and reporting within the enterprise (the legal entity or entities that make up an entire company no matter where its operations are).  ERP systems focus almost exclusively on operational excellence value propositions of process efficiency and automation.

ERP II (or, in other words second generation ERP, ERP 2) Definition

Through collaboration, SOA, and other interface, data exchange, or interaction methods the ERP ii systems move beyond Enterprise boundaries (or a basic ERP system) and into the vendor space including the supply, design, and engineering collaboration areas. ERP ii systems continue to enhance operational excellence and start to introduce a measure of the innovation value proposition.

ERP III (or, in other words third generation ERP, ERP 3) Definition

Through collaboration, direct contact, social media, and various data streams within and outside of the enterprise ERP iii integrates marketplace fans and critics into the extended ERP and ERP ii organizations.  From this integration of the customer and vendor a constructive dialog and exchange of information is created to innovate, produce, and then sell / distribute better products or services.  This closes the value proposition loop by going outside of the enterprise boundaries and finding ways to bring customer input, needs, wants, and insight into the enterprise.  ERP iii system create a strong synergy between innovation and customer focus.

ERP System Definition or ERP Defined

The acronym ERP literally stands for “Enterprise Resource Planning.”  And this is exactly where I disagree with the ERPwire definition proposal.  Just a manufacturing system is not an “enterprise” system at all.  It is merely a manufacturing system, or an MES (Manufacturing Execution System).

As the university studies and academic literature note, ERP systems are “a single instance of data, a full process chain of dependencies” (see Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project citing Kallinikos, 2004).

In the ERP industry we (consultants and integrators) frequently refer to any ERP system as a type of “back office” application or system.  By “back office” we are referring to company centered business functions into a single database, or, a single “system of record.”  “Back office” processes are fully within the border and boundary of the enterprise.

In 2000, in an article addressing ERP ii, Gartner noted that they had defined ERP in 1990:

In 1990, Gartner defined ERP, establishing a new vision for the resource planning domain. That vision centered on resource planning and inventory accuracy, as well as visibility beyond the plant and throughout the manufacturing enterprise, regardless of whether the enterprise was a process manufacturer, discrete manufacturer or both. ERP has since appeared in different “flavors.” Extended ERP reflected the fact that many nonmanufacturing industries turned to ERP systems for “backbone” financial transaction processing capabilities (Bond, et. al., 2000 pg. 2, note 2).

That article went on to note that the accepted definition (in 2000 and beyond) had become:

Despite [the] original definition, ERP has become the accepted term for back-office transaction processing systems, regardless of the industry or region (Bond, et. al., 2000 pg. 3).

The definition I have provided is as comprehensive as the original Gartner proposal and includes the later understanding of the application to more industries and business functions.

ERP Focuses on the Operational Excellence Value Proposition

To understand the operational excellence perspective see the more detailed explanation of the functions and operations of an ERP system like SAP under the section “What is SAP?” ( ).

I generally try to categorize all system efforts and business functions into one of three “value proposition” buckets:

  • operational excellence (ERP),
  • innovation (ERP ii),
  • and customer focus (ERP iii).

The ERP context is almost exclusively focused on the “operational excellence” portion of business “back office” transactional processing.

ERP vs. ERP ii — What is ERP ii?

The next generations of Enterprise applications, or ERP ii systems, extend the “back office” ERP system processing to the extended supply chain.  They extend the enterprise into the supply chain outside of their legal entity borders as an active participant. This would include VMI (Vendor Managed Inventory) processing and KANBAN type demand and supply signals to vendors for JIT (Just In Time) stock management.  But it goes far beyond that, it is the “innovation” portion of the value proposition that is addressed here.

SAP includes ERP ii type extended supply chain applications like SRM (Supplier Relationship Management), APO (Advanced Planning and Optimization), and PLM (Product Lifecycle Management) to help move the supply chain beyond the enterprise borders.

ERP II Creates Collaboration Hubs Beyond Planning and Distribution Functions

Together with the extended supply chain applications there are a number of various exchanges such as common catalogs that are published to the web and integrate with their customer ordering.   Some examples of external exchanges can be seen in initiatives such as “Covisint” for the automotive industry, or Grainger’s online catalog system (although it is not a competitive based platform like Covisint), and many others.

One of the key functions or features of ERP ii systems is supply chain or vendor collaboration, which extends to engineering design and development.  Most enterprises using SRM systems use this to focus on cost reductions, vendor competition, and supply chain efficiencies.  They are generally geared to the operational excellence system domain but there is a LOT of untapped possibility.

The highest and best use of ERP ii functionality includes active collaboration with vendors to reduce cost, improve quality, reduce extended supply chain cycle times, and even co-engineer (or co-develop) better products and services.

Many ERP ii solutions now include some type of built-in “reverse auctions” where companies can place requirements out for competitive bids in various formats.  These exchanges might include data interchange methods such as EDI (Electronic Data Interchange) or other standards compliant communication protocols, but they are much more, they are active collaboration hubs.  Together with these collaboration hubs, SOA extensions are being used to extend collaboration and engineering design work to the extended supply chain.

How Has SAP Implemented ERP ii System?

SAP has created an entire collaboration network called the SAP Community Network or SCN ( where customers, vendors, consultants, and any interested party can exchange information, ideas, or dialog.  SAP has implemented ERP ii systems internally through the development of specialized vendor partnerships it calls an “Ecohub” (  This is a place where vendors, partners, or other firms with specialized SAP solutions can integrate and promote their offerings to enhance SAP’s various software offerings.  Along with that there are code exchanges, “how-to” articles, discussion forums, and many other types of collaborative information exchanges.  This is similar to what I proposed a few years ago when I wrote “SAP, ERP III, SOA — Learning Organizations through Social Media Collaboration.”

Operational Excellence and Innovation Value Propositions

ERP ii systems integrate the external vendors and suppliers into enterprise processes so that they can directly impact productivity, cost, and efficiency.  Some elements of ERP ii include engineering staff augmentation, free or at a very reasonable rate to the “customer company,” and as a value added service from vendors.  For vendors the ability to augment engineering functions can mean customer retention; for the customer companies this may mean higher quality and lower cost products or services.

SAP’s ERP offerings include PLM (Product Lifecycle Management) with CAD integration for several off the shelf CAD programs.  Although the PLM functionality is primarily used for internal engineering processes it can be pushed out into the extended supply chain for collaborative engineering and design.  That collaboration can be used for innovation if it is properly structured and implemented.  This is in conjunction with other integrated application offerings such as SRM and APO.

By extending engineering or collaboration functions outside of the enterprise, but still within the supply chain, innovation can be introduced into the ERP ii enterprise (see the entire series on Process Execution of Business and IT Innovation).   However, the primary feature of ERP ii systems is the additional operational excellence that is brought about by extended supply chain processing.  Very few companies have succeeded at collaborating with the extended supply chain by introducing extended engineering capabilities, or vendor insight to produce significant innovation.  Most ERP ii systems only work to extend the supply chain beyond the boundaries of the enterprise for cost savings and efficiencies (operational excellence).

Using SOA (Service Oriented Architecture) for Creating ERP ii and ERP iii Enterprises

The promise of ERP ii system success that moves toward ERP iii (discussed in a moment) is SOA or Service Oriented Architecture.

In layman’s terms, SOA is the ability to create a set of “talking points” from any internal system to external systems. 

They are the data structures and data schemas that are published for other systems to interact with and begin to create the framework for the “borderless enterprise.”

ERP iii Defined, What is ERP iii and How Does it Go Beyond ERP ii?

ERP iii addresses the final domain of enterprise class applications by addressing the customer focus value proposition.  It is the extension of technology capabilities which brings collaboration with customers and the broader marketplace into the enterprise system.  This goes way beyond what we currently refer to as CRM (Customer Relationship Management) systems of today.  Today’s CRM applications still operate within the walls of the enterprise and are generally used for managing the sales force rather than moving the enterprise out into the wider marketplace and to direct interaction with customers.

ERP iii from a high level is fairly easy to define, however what it looks like in a few years is difficult to predict.  The areas that ERP iii touches are in a rapid state of change because of the dynamic nature of social media and the global marketplace.

ERP iii Defined

  • ERP applications integrate enterprise operations within and across enterprise legal entities, or company codes.
  • ERP ii applications extend supply functionality to external enterprises (generally vendor-affiliated companies or enterprises) to reduce cost, improve supply chain efficiency, and to perform collaborative innovation.
  • ERP iii enterprises go to the next level of integrating the ERP and ERP ii functionality to include customers and the sales side of the marketplace in general.

The end state of the ERP iii enterprise would include a dialog between customers (and potential customers), the ERP organization, and the extended supply chain so that even suppliers would participate in the sales side of the marketplace.  Because there is little or no information in the marketplace about ERP iii direction and design I am offering a more detailed definition here:

Through collaboration, direct contact, social media, and various data streams within and outside of the enterprise ERP iii integrates marketplace fans and critics into the extended ERP and ERP ii organizations.  From the integration of customers and vendors beyond the enterprise boundaries a constructive dialog or information exchange is created to innovate, produce, and then sell (or distribute) better products or services.

ERP iii will create the “borderless enterprise” by bringing together a host of technology sources such as:

  • Collaboration tools (within the enterprise and across the supply chain and marketplace)
  • Social media
  • Internet technologies
  • SOA
  • Smart information integration and synthesis (specialized search with analytics or within specific information domains).  An early example of this type of search is a web service called “Lijit.”  Lijit allows you to manually assign searchable information sources for a customized, high value “search engine.”
  • Extended marketing analytics that are “like” tracking cookies but less invasive and use additional sources of information and research beyond the web (a good example is like grocery store checkout programs that automatically print coupons on the back of your store receipts based on what you just purchased).
  • Direct customer collaboration (we see early examples of this in the Dell “designed by me” and “I made Windows 7” television commercial marketing campaigns).

The Future of ERP iii Systems

Within the extended SAP enterprise (which is my area of expertise) I see many of the seeds of ERP iii germinating and beginning to grow.  Even though the initial “green shoots” are there for an ERP iii revolution I don’t anticipate that occurring for several years within SAP.

Today SAP has:

  • Very active, country specific SAP User Groups (xSUG, in America is it ASUG) with “influence councils”
  • Community forums (previously mentioned)
  • “Mentor Groups” within the community network.

While these all contain the seeds of ERP iii outlets I do not see a lot of the raw material being converted into application enhancements to directly address business marketplace demands.  There are still way too many technical solutions and not enough for genuine business needs.

ERP iii integrates marketplace fans and critics into the extended ERP and ERP ii organizations to innovate, produce, and then sell (or distribute) “customer-centric” products or services.

I doubt that the integration of more social media will move the ERP iii needle much further.  SAP like any other company that embarks on this type of transformational exercise must begin to use their well established outlets to drive innovation and to meet marketplace requirements (see the entire series on Process Execution of Business and IT Innovation).

Social Media and ERP iii

Social media outlets like Facebook, Twitter, and other resources will need to become more sophisticated to produce meaningful differences in business-centered innovation or customer focus.  That sophistication for business will mean finding a means to use those outlets for genuine business competitive advantage.

It will take business some time to find new ways to tap into the collective marketplace consciousness through social media in spite of the massive number of what I refer to as “snake oil” salespeople.  Social media in the enterprise will not be useful until the snake oil sales finally align actual business needs to areas of the enterprise (sales, marketing, HR recruiting, etc.) that align with business goals and directions (see Social Media Fads and the Risk to the Enterprise).

Before ERP iii systems are ready for the extended marketplace and for customer interaction it will require “back office” integration with social media (see ERP III – Is the Integration of Collaboration the Future of Enterprise Applications).

As social media and collaboration tools mature over the next 10 or more years then corporations will finally build the ERP iii systems for integration into the wider marketplace.  By then the ERP ii systems will have finally matured to the point that some of them can provide meaningful integration between the enterprise, the entire supply chain and the sales side of the marketplace in general.

ERP, ERP ii, and ERP iii Conclusion

Considering this specialized class of business systems through the lens of the high level value propositions of

1) operations,

2) innovation, and

3) customers;

here is my summary:

ERP (Enterprise Resource Planning)

Primarily focused on the “back office” with a heavy emphasis on operations, automation, cost control, financial activity, and lagging business indicators of performance.

ERP ii (the second generation of Enterprise Resource Planning)

Extends “back office” processing functions and operations into the extended supply chain with a heavy emphasis on supply chain automation, additional efficiency, more cost control, and some vendor collaboration for limited innovation.  This area of the application moves into the “last mile” of improvements that can be more expensive to implement and yield lower returns.  However, carried out properly with significant supply chain collaboration and joint engineering or development efforts this can provide new / innovative products or services addressing both lagging indicators of cost control and efficiency while exploring leading indicators of new products or services.

ERP iii (the next generation of Enterprise Resource Planning)

This will encompass the integration of social media with new marketplace intelligence and analytics into the ERP ii enterprise.  With a very simply “hub and spoke” idea, the enterprise will constitute the “hub” and the extended supply chain vendors, engineers, and designers, together with customers and market analysis as some of the “spokes.”  This will be enabled by the ERP application that is extended with collaboration and social media tools.  The ERP, ERP ii, and ERP iii functions will all be integrated with new analytics and “smart source” search methods to integrate and synthesize trend, market, and product or service information.  This will close the loop on the ERP ii innovation and will bring a new customer focused business paradigm into the enterprise that goes far beyond today’s CRM applications.

ERP iii state companies will be marketplace disrupters who are agile, nimble, and global.  They will be able to spot emerging trends and unmet customer demands (needs or wants) far more quickly and with greater ability than their peers.  From those trends and customer needs these companies will be able to quickly execute innovation programs to develop new products and services to quickly fill those customer demands.  The most advanced of these new “disruptive innovators” will be the companies who can intelligently synthesize all of the various data points to understand customer demands that are not even articulated.


Bond, B., Genovese, Y., Miklovic, D., Wood, N., Zrimsek, B., and Rayner, N. (2000). ERP Is Dead — Long Live ERP II; Gartner Publications.

Kallinikos, J. (2004), “Deconstructing Information Packages. Organizational and Behavioral Implications of ERP Systems.” Information Technology and People, Vol. 17, No. 1, pp. 8-30.

Popular Searches:

  • erp 2
  • erp II
  • erp2
  • erp 3
  • erp 1
  • www whatssapapp

Related Posts:

SAP Implementation Focus: Engineer Software or Business Processes?

April 29th, 2010 by

SAP Software Engineering or Business Process EngineeringYou’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).

Related Posts: