Business Solutions with SAP

Where Does Agile Fit in SAP Projects?

November 12th, 2012 by
Agile on SAP projects

Agile SAP Success

After offering insight based on my personal experiences around “Agile Project Methods for SAP ERP Projects?” I thought it would be helpful to highlight a couple of areas where Agile does work.

  • Design sessions
  • Development efforts (i.e. coding)
  • Data conversions

Once you begin to move very far beyond these areas you quickly encounter dependent work streams that need much more coordination.  Those additional dependencies make it difficult to apply Agile methods.

While Agile tends to emphasize the 1 week to 1 month “sprint,” I would define a “sprint” in more of a completed requirements and planning package rather than a pure time-box approach.


Applying Agile Methods to ABAP Software Development and SAP Data Conversions

Development (ABAP, Java, or other coding)

Since Agile methods have been used for some time with small, discrete components of software development I won’t spend a lot of time there.  On a typical SAP project you will end up with a functional spec which defines the program requirements and a technical spec which informs the development details.  Even though the more typical “Agile Manifesto” method would not require the documentation it is well-placed on an SAP project.  In fact, it is foolish not to have it for long term support and maintenance. 

Development can work well for the Agile stages of build / prototype, demonstrate, gather feedback, adjust, and repeat.  The key here is to limit the number of these “Agile” cycles to no more than 3 for software development.  By 3 cycles I mean 3 completed cycles too.  This is not a demonstration with feedback that is only partially built.  If the feedback cycle is not completely implemented then it is not a complete cycle.  Even though Agile would consider these “sprints,” I would consider them a FAILED sprint if the requirements of the current plan, or the subsequent plans, are not fully realized in the prototype or demonstration.

SAP Data Conversions using Agile Sprints

With data conversions I suggest at least 3 complete cycles or “sprints” (not including a minimum of 1 mock go-live conversion, probably 2 or more if you can). 

  1. Build the initial conversion program to all of the requirements (again, partial requirements do not count as a full cycle).
  2. Pilot a test conversion with all data, no matter how much fails, and capture all necessary changes.  This will include data dependencies and sequencing.  At this point you will be lucky to achieve a 70% success rate when considering all of the data dependencies.  This step is not about getting things perfect but about identifying data and programming issues to resolve.
  3. Implement all SAP data conversion changes the conversion pilot exposes, script every conversion step and rough timings, and aim for a successful test target of at least 90%.
  4. Make additional changes and attempt to follow the scripted conversion, making adjustments to the conversion script where necessary, and achieve a goal of at least 98% conversion completeness and accuracy.

Once you achieve this level of conversion consistency it is ready for a mock-conversion.  These Agile “sprints,” or as they are starting to call them now “Scrum-ban” (as a spinoff of Kanban) will help to ensure a successful data conversion.

Agile Design

Agile processes or sprints, are effective for design sessions.  Done correctly, this allows a customer to be exposed to the system earlier, provide better insights and results, and generally improve overall solution fit.  

One of the major differences with Agile Design vs. the traditional SAP Blueprint is the timeline.  An Agile Design approach requires more time because there is an element of system setup and solution discovery.  In the traditional Blueprint approach, everything is done on paper and many details are often missed.

When you combine an Agile Design approach with Lean principles, you can see overall project benefits in quality, cost, and overall solution stability at go live.  What this means is that during the design you are actually doing small “sprint” type activities to build out key areas of the solution.  Design sessions become playback and adjustment.  One key consideration with this approach is that you will not have 100% of the integration areas, or solution areas completely set up and defined.  This is important to understand.  If a customer expects to see perfection during Agile Design then a more structured waterfall approach, with a formal paper Blueprint would be required before any system solution activities are performed.

Conclusion on Agile in SAP or other ERP Projects

Even with newly packaged Scrum, Agile, or other methods, on an SAP project there are so many moving parts and work streams to coordinate that there is no substitute for a good waterfall project approach.  Using “Agile-like” methods for the ABAP development or data conversions is not a substitute for good project management either.  Done properly this approach can work well as long as it is carefully managed along with the rest of the work streams.

The Agile approach that works for an SAP deployment is one with a mix of both Agile for discrete task areas combined with a waterfall overlay.

Popular Searches:

  • erp prototype

Related Posts:

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:

The Agile SAP Enterprise and Regulatory Compliance

February 21st, 2008 by

Speed, Agility, Technology, Advanced SolutionsHow can you be more nimble? Are you in an agile enterprise?

The very nature of regulatory schemes makes agility difficult. Most businesses restricted by regulatory environments often find these areas of the enterprise “off-limits” to the type of process improvements, streamlining, cost reductions, and simplifying that are required to stay competitive in a global environment.

Regulatory compliance and their difficult to navigate requirement structures make the creation of an agile enterprise very difficult. After doing several projects for U.S. companies subject to Sarbanes-Oxley (SOX) compliance and pharmaceutical companies heavily regulated through 21 CFR Part 11 (Validated environments) I’ve found highly regulated environments need to be nimble in our modern global environment.

SAP Compliance with Sarbanes-Oxley (SOX), FDA Part 21, and Others

Getting business benefit

Regulated companies do have significant potential for improvement in the area of streamlining and improving the compliance processes and procedures.

I would challenge some of the highly regulated companies to do cost studies on their compliance requirements to see how much overhead they add or how much of an impediment they are to making needed changes. We’ll call these impediments to change “regulatory overhead.” This regulatory overhead applies almost equally to even the very smallest and least significant of changes.

The failure to take advantage of even small incremental changes can have serious negative consequences over time. Because of the regulatory overhead many small or incremental changes will never be implemented because of the painful, expensive and time consuming validation requirements.

Standing alone these small changes are generally not that significant. However, stacked together across dozens or even hundreds of these changes, multiplied across an entire enterprise, the cost and automation can represent orders of magnitude improvements . These changes have direct impacts on efficiencies and cycle-time improvement for both supply chain and financial processing.

Think about it, all those changes, multiplied across the number of times that small task is carried out, multiplied by the hundreds, and in some cases even thousands of people impacted by the processes they affect. It doesn’t take long for small improvements to add up to major differences and efficiencies across large organizations. As for larger changes, reducing compliance cycle time saves costs related to this regulatory overhead.

How Aggressive “Regulatory Overhead” Infects the Whole SAP Enterprise

Regulatory overhead routinely translates into learned behavior that causes a productivity slowdown and lack of enthusiasm even in the processes not subject to compliance. People become so frustrated dealing with unnecessary regulatory overhead, or “red tape,” that it poisons all facets of productivity.

I’ve seen little consistency in compliance schemes on several heavily regulated SAP projects.  The only constant is the painfully inefficient, frustrating, and obstructive design of compliance systems. These compliance systems never follow the famous “7 habits” for success. I have yet to see a compliance system designed from the beginning with the end in mind.

How do you Improve Approval Processes in an SAP Regulated Environment?

SAP, like other ERP applications, can help the enterprise through the integration it provides. To leverage your SAP investment it is important to be able to add new functionality or enhancements improving or automating existing functionality. However, in highly regulated environments after your ERP or SAP go-live the regulatory restrictions can be painful, time consuming, and frustrating. For regulated industries the validation and approval processes can be killers to productivity–, they stifle your ability to respond to changing market conditions.

Your internal compliance requirements may be slowly choking your business with overly rigorous controls that aren’t supported by a genuine regulatory requirement. Or worse still, the exponential growth of “controls” often means that important processes and functions are not enhanced to improve the business and operations.  There has got to be some measure of balance between the required controls and the ability to make changes.

Compliance “Gates” that Affect Your SAP Project Time and Budget

Too often compliance processes rely on many “serial” processes or “gates.” These serial processes have built-in “stops” to ensure that certain critical steps are accomplished before being able to continue. Anyone who has been there knows the problems with being forced to stop, and then wait for days, or in some cases even weeks, before the “gated” procedure is completed. Worse still, while the intent is to place these “gates” or checkpoints into the processes at critical points, they often end up throughout approval processes choking any possible efficiency.

And in worst case scenarios, the most demanding controls are placed early in the process stream making even the thought of initiating improvements distressing.

Rather than having fully documented code and configuration reviews and formal approvals with signoffs before something can be moved to the QA environment, more of an ad hoc approach could be used. For compliance purposes there might be a first review and only a project manager’s approval needed to move it to QA. From there, informal testing performed and any incremental coding or configuration changes are made, and then before the final testing, the final, formalized, fully approved review and approvals are performed. What this does is remove the numerous review cycle times from the earlier development process and ensures the necessary quality, documentation, and compliance exists before the changes are moved into production.

Recent SAP Project with FDA 21 CFR 11 Validation Requirements

Recently I had a project on a company subject to U.S. FDA regulatory requirements. Their regulatory model was very thorough, well-planned, and well thought out. It was a work of art and was internally called a “V” model to cover their validation requirements. This model had a few small areas that if they were to be adjusted would still be compliant and would offer tremendous improvements in processing cycle times.  Several of their validation approval gates were on their Development system rather than later in the process.

A few adjustments to gates and gate timing of some of their process model would dramatically improve change cycle times and reduce the overall amount of effort. For example there was too much validation control in the Development environment that might have been better if some of the review gates were moved to the quality assurance system. This would have required fewer review cycles and fewer “early” gates in the process. It would accelerate the process and allow for several more parallel activities to take place making the process more efficient. This approach of moving some of the gates to the QA environment would allow for more incremental adjustment and change, as well as unofficial testing without as much of the administrative overhead.

Where Some SAP FDA Regulatory Validation Problems Occur

Too often in any regulated environment there are several types of issues:

1) Problem: A lack of understanding of the compliance requirements, and SAP provided tools which support compliance, within the organization responsible for compliance.

Solution: On any new project, or before any major undertaking ensure that the entire project team reads and reviews the relevant regulations and compliance requirements. In other words, get the actual language of the regulations and ensure that every team member reads them before the project begins. Do a little online research and get a better understanding of the requirements.

2) Problem: Compliance triggers defined at unnecessary control points such as having controls on a Development sandbox.

Solution: Move any “serial gates” (those processes that stop all other activities until they are completed) to as late in the process as possible.

3) Problem: Compliance processes with too many serial process streams or “gates” where everything must stop completely until the gate is successfully navigated (in an FDA validated environment there will always be a need for some  of these serial “gates”).

Solution: To the extent possible, combine the number and frequency of serial gates to reduce the overall number of “hard” compliance points. However, use some thought here and be sure that where it makes sense, at logical breakpoints, where an item may not have to go all the way back to the beginning of the process that you also break up any of the gates. One huge gate with numerous controls and reviews may not be productive either.  Think of it like this, if the gate can be used to efficiently find and resolve an issue earlier in the process, where it is easier to correct then that might be a good use.

4) Problem: Auditors or systems administrators who do not have sufficient understanding of SAP security capabilities and are too quick to declare risks at a transactional level without understanding how those transactions can be controlled. Arbitrarily finding “segregation of duties” (SOD) problems and conflicts.

Solution: Be sure your system administrator and system security personnel have enough exposure and experience with SAP to help any compliance officials understand the ability to control security at a more detailed level than the transaction level. For example, SAP allows you to use security to control document types. So in an invoice process you may wish break up overlapping responsibilities by document type. Another thing I have seen is the silliness of defining “conflicts” where the entire dollar amount involved was not sufficient enough to be materially significant. Insist that “material misstatement” thresholds are defined and published. A deviation from SOD requirements can easily be justified if the compliance cost is prohibitively high (e.g. hiring a new employee) and the activity is subject to thresholds so low that it does not make any business sense to separate the duties.

5) Problem: Auditors and consulting companies often have little or no background with SAP and its published control points for various types of compliance. Often, vendor published GxP (Good “x” Practices) or SOD (Segregation of Duties) documentation, such as SAP’s, provides a critical basis for understanding and challenging improper or unnecessary compliance requirements.

Solution: The vendor documentation frequently serves as reasonable due diligence for most regulatory agency compliance requirements. At a minimum vendor documentation serves to also distribute the risk so that a vendor such as SAP who provides paid support will address any compliance deficiency in the software that arises.

6) Problem: Validation empire builders who are internal political players (which is beyond the scope of this article).

Solution: This one is for senior management to tackle. Dealing with corporate politics is beyond the scope of this post.

SAP and Sarbanes-Oxley or “SOX” Compliance Stupidity with Segregation of Duties

One of my pet peeves are some of the supposed “SOX prohibited” system transactions. Sometimes there is no way to describe it except stupid. How an auditor might demand that some simple display transaction is a “conflict” often baffles me. With the exception of HR data and some limited financial information there is little risk for display access to other information. I still have not found an auditor who can answer how some of these ridiculous requirements can lead to or cause “material misstatements.”

A story from the trenches

Recently I was at a small subsidiary of a very large company. When I say small, I mean the parent company gross revenue was 30 times the size of the small subsidiary. Like most small companies, they were lean on staffing and different individuals often performed more than one task or function. They failed to meet the parent company “segregation of duties” requirements but during the SAP implementation the parent Sarbanes-Oxley requirements were imposed on the small company. The attendant increased staffing requirements coupled with the ridiculous bureaucratic overhead bordered on insane. At the very least it was a comedy of errors.

This company has several U.S. and European Plants, each with their own bank accounts, and between them there were 3 or 4 separate banking institutions involved. In a worst case scenario, if someone could figure out how to pilfer an entire month’s gross receipts from one of the plants, the overall financial impact to the parent company, and to their quarterly report would have been little more than a rounding error.

When I dared to ask the parent company’s compliance staff what the threshold for a “material misstatement” was for the small subsidiary I got blank stares of shock from the auditors. It was as if I were speaking a foreign language under water. To this day I wonder if they even knew the regulations or actual compliance requirements they were supposed to be auditing. After all, when the subsidiary contributes a whole 3% to the gross revenue of the parent, forcing a 20% increase in staffing just to comply with “separation of duties” requirements is patently absurd. The measure of regulatory requirements imposed on them by the audit requirements were the height of plain stupidity.

If the regulatory overhead equals or exceeds the cost of the risk, this should be carefully evaluated. Sadly this is common in many companies subject to various regulatory compliance schemes.

Where to Begin With Regulatory and Compliance Programs

As you may have guessed, my all-time-favorite Sarbanes-Oxley compliance item is the never defined “material misstatement.” This is the catchall excuse for choking a company in needless audits. It’s great for auditors to point at anything you do, no matter how trivial, menial, or inconsequential and scream that it is an audit problem–, even when there is no real financial or regulatory significance. And even those things that have some direct financial significance may be so small as to be a worthless waste of time. Fix the audit process and stop the compliance processes from choking you to death.

Start with the end in mind. Define what compliance really means in your company and then determine how that compliance will be measured. We’ll call those activities or efforts that directly support measuring compliance (or the deliverables that are needed) as those items that support “compliance value.” If something you do in your compliance efforts do not have a specific purpose that supports a clearly defined compliance requirement then it is not only a waste of time, it is an artificially imposed impediment to efficiency and competition.

In other words, define the actual compliance requirements up front and then determine the criteria it takes to ensure compliance. From there work backward to determine the appropriate processes. Without that up front determination of how you will define what compliance is, and how compliance will be measured, you have nothing to measure value added steps against. In an environment without clear understanding of how you define and measure compliance, it becomes an expanding balloon that grows while choking everything in its path.

1) Work with the auditors to map compliance requirements to the specific statutory provisions or regulatory requirements that are affected. If an auditor will not map specific requirements to statutory or other written regulatory requirements (such as CFR’s or “Codes of Federal Regulation”) then it may be time to find a new auditor.

2) Define clear, specific, and objectively measurable criteria for each of those compliance requirements, and if the regulatory provision is not clear enough to define such criteria, find some generally accepted governing body or publication that provides guidance. Don’t just make something up because an auditor says you have to.

3) Define what “material misstatement” means in terms of financial liability amounts. If necessary, to avoid shareholder liability and in the interests of proper disclosure publish the new compliance schema in a quarterly statement explaining the new compliance paradigm, the potential risks, and how the streamlined process will improve business operations.

After you assess, or re-assess your processes to eliminate steps that do not directly add “compliance value,” take a look at the remaining process to see how it can be improved or streamlined.

Regulatory and Compliance Process Improvement Options to Consider

In all highly regulated companies one of the biggest compliance time killers is regression testing. Determine the actual testing requirements and then find ways to streamline and automate those processes. A full regression test process should not take weeks, even in very large, far-flung enterprises. If test processes are sufficiently automated by using SAP CATT, eCATT, Mercury, or other automated test tools there is no legitimate reason a full regression test cycle should not be able to be resolved in a few days, even in validated environments.

In the area of defining automated regression testing it is important to understand that in highly regulated environments this can be a “mini-project” taking significant one time efforts to implement.

Take a hard look at serial processes, especially those “gate” processes that must be completed before any further activity can be done and see if they are adding any “compliance value.” If they are not directly related to achieving compliance deliverables then why are they in the process chain?

Serial, Parallel, and Gate processing in IT Project Compliance

As much as practicable avoid gate processes. When developing compliance processes the only genuine “gate” process should be a high risk validation process or high risk direct financial impact segregation of duties process–, and then only when going into a production system. Regulatory requirements rarely extend to most segments of a development system yet it is shocking to me how many companies implement stringent controls even in a sandbox.

If you must extend validation requirements to a development environment, it is likely less expensive and more productive to invest in the hardware and application(s) to set up a separated stand-alone SAP system that you can copy your production system to. All advance development efforts and work should be done there and only after there is some comfort level that it will work and is correct, duplicate the effort in the “compliance” development environment.

If there are needs for “gate” processes before going into your production system, attempt to define some parallel processing that will allow some or all processing to continue. To the extent possible don’t allow “gate” processes to stop progress.

Develop “staged” or graduated levels of compliance requirements based on the process of moving from a development stage, to a testing stage, and then preparation for moving into a productive system. The less restrictive these processes are until they get to the stage of preparation for moving into a productive system the more efficient they will be. For example, if testing shows that things work but additional efficiency or automation improvements might be made, the ability to go back and add additional enhancements should not be so prohibitive as to create significant obstacles to improvement. The amount of compliance “pain” or regulatory overhead imposed at earlier stages in the processes will have a direct relationship to the ability to make useful changes as the process is worked through.

Early process stages should be the least restrictive and the least intensive to encourage the type of early testing, checking of assumptions, setup, verification of processes, prototyping, and checking of concepts that are critical for well developed processes. The less restrictive the early stages are the more investigation and development can be performed. The development environment should meet this requirement.

For a quality or testing environment provide a separate, completely non-validated test environment that is a periodic copy of the validated test client. Then move system changes into there, test run through test scripts or test scenarios in an informal manner, evaluate for improvements or enhancements, then make adjustments and move them to the testing environment for re-testing. Once satisfied that the results are what you expect, then begin the testing in the formal validated QA environment. This non-validated test environment is refreshed with copies of the validated test environment from time to time.

Conclusion on Regulatory and Compliance in SAP or Other IT Projects

This article only scratches the surface but as you can see there are many possibilities for reasonable improvement that will help you to become agile and more competitive. Compliance processes should not become a stranglehold for your enterprise. A little work, and a careful review and evaluation of what the actual compliance requirements are can go a long way toward understanding whether your compliance processes make sense.

Compliance is important but in today’s globally competitive environment and fast paced world, activities designed to build empires or which do not directly support clearly defined compliance requirements are an impediment to the agile and competitive enterprise.

Related Posts: