INNOVATE. INTEGRATE. TRANSFORM.

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.

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

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

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.

Conclusion on Agile ABAP Development and Data Conversions

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.

Related Posts:

An SAP ABAP Innovation Revolution Beyond HANA

December 12th, 2011 by
ABAP Development Revolution

ABAP Development Revolution

Some time back I wrote about Opportunities for INNOVATION SAP, HELLO? At the time I wasn’t really expecting a lot and I’m guessing I didn’t have a lot of influence but I do find it coincidental that many of the suggestions I offered have been adopted. Some of them, like the switched framework to improve order management processing is included in ECC 6.0 EP4.

So, one thing that I have been chewing on for a long time is how to dramatically improve ABAP development and overall application enhancements.  My own requirements were to find a way to make ABAP coding simpler, improve code quality, provide better overall system performance, and make it easier to troubleshoot. Tall order I know. Impossible? No!

Welcome to the “Big Data Revolution”

This post is more about a technical issue which SAP can “easily” address that would completely revolutionize its own internal development as well as external customer development.

The New SAP Development Revolution

I’m not an SAP ABAP coder but over the years I’ve had enough exposure to it to see some great tools, resources and improvements. This development effort has been mostly on the usage side of the existing syntax.

  • What if there was a way to revolutionize the way ABAP is coded that is 100% compatible with current syntax ?
  • What if it dramatically improved coding quality and solution development?
  • What if it improved the performance and consistency of customized ABAP solutions?
  • What if it simplified the entire coding process AND made troubleshooting easier?
  • What if it opened up a whole new world for coders to develop dramatically improved solutions?

You say that sounds crazy? Not only is it possible it would propel SAP’s place in the entire business application space to new levels.

Where Did This Crazy Idea Come From? And WHAT IS IT?

After many years working in SD (along with other modules) I had a client who needed help creating a new “smart” trade promotion execution solution. The solution had to do a LOT of things no standard SAP process handles. It needed to dynamically determine complex offers, with discounts, free goods, limits, caps, quotas, perform dynamic best price processing, provide loyalty points, etc. –, all while dynamically evaluating the customer segment and strata for offer eligibility.   The solution had to be done across a large population of order items, with multiple promotions based on the mix of products and the number of discounts or promotions that had already been given to a customer over time. The mix of products or offers could bundle multiple free goods, multiple offer discounts, or other special items, in a many to many relationship, based on the customer purchase and purchase history.  And performance HAD to be good because of the huge order volume.

The client had been asking for someone to deliver this for some time. A previous system integrator who did their upgrade couldn’t do it. I ended up spending 6 months working on a new custom coded ABAP “mini-module” in SAP that allowed them to achieve their goals by using mostly master data.

That process taught me more about ABAP programming and SAP coding than I ever anticipated. As I went through this process I was amazed at one simple thing that was completely lacking from all of this coding effort –, the amount of “VIRTUAL” SQL syntax for internal data processing in the form of loop, sort, read table (with key), append, move, move corresponding, index, etc.

Why not develop the syntax to handle all of this in the background through “virtual” select statements?  Create a new “iSelect” syntax which performs all of these functions that can be exploded.

SAP already uses internal tables in memory for processing data during the transaction stream.  By creating a new “iSelect” syntax much of this coding, looping, moving, etc., could be masked by fairly common SQL type commands. Since this would be compiled syntax the performance would likely be better and the quality would be FAR better while needing fewer lines of code to accomplish the same thing. For simplicity I will call it “internal SQL” or, iSQL.

This would be the perfect complement to SAP’s HANA in memory processing, and would help with reporting extractor and programming development of all kinds.

This type of iSQL could be developed to allow inner or outer joins on internal tables, external tables, or any combination of them. The normal SQL statements like Select Sum, Select Distinct, etc., etc., etc., could be employed throughout the entire ABAP processing stream. With internal tables in memory as well as the tables read from the database.  Still more interesting would be the ability to “explode the code” underneath this new iSQL syntax. When finer detailed control, processing, or calculations are needed, within or across joins, the underlying loop, sort, append, etc., could be exploded out and adjusted to fit the specific need. This would speed up development efforts by being able to quickly rough-out a data processing framework and then explode the code to make more detailed adjustments.

By focusing on syntax that is like SQL for the internal loops, sorts, reads, sums, append to table, move, etc., the coding complexity is reduced WHILE also providing more flexibility and options. SAP would have greater control over the development of the internal / external table processing standards and programming knowledge around actual data processing would improve.  This would be the perfect complement to SAP’s HANA in memory processing.

It would allow for faster, more reliable coding efforts with a higher performance result. Small performance tweaks or changes to the underlying compiled iSQL statements, along with that ability to explode the underlying code would create a revolution in the ability to more quickly and consistently deliver SAP solutions.

What is most important of all is this could be rolled out piecemeal and stay 100% backward compatible with no negative downstream effects. As new iSQL syntax is developed the original coding standards could remain in place without change. It would just add an additional set of power processing options. Think about all of the areas this would radically affect, custom coding, data conversion, SOA development, report development, function module creation, you name it. This could create HUGE customer benefits for outstanding development.

I’m tired of crappy, poor performance, system choking code from poor development, aren’t you? Come on SAP, YOU CAN DO THIS!!!!




Popular Searches:


  • sap innovative ideas abap

Related Posts:

Where Does SAP Offshore Development Make Sense?

October 10th, 2011 by
SAP Return on Investment or ROI

SAP Offshore Development Cost

If you are capable of providing detailed design specs where there is almost no deviation or thought required this is a great option.  The instant your SAP design requires a measure of experience and insight to make judgment calls, or to look for data or processing that is not explicitly spelled out in detail, you are headed for huge hidden costs. 

The level of detailed spec design work by SAP functional consultants merely shifts the development time and costs to the higher priced resources where it is “hidden” from TCO and sales quotes.  If you are capable or writing “functional” specs that are really more like technical specs with specific table and fields spelled out in detail, program pseudo-logic defined, every possible alternative anticipated, and no detail left out then SAP offshore development works well.  If you are not prepared for that level of detail and “perfect specs” then you are likely headed for a much larger invoice in change order costs and hidden functional time than you ever anticipated.

Offshore resources are often smart, industrious, and hardworking but the ugly reality no one talks about are the real rates because these resources do NOT have any significant amount of SAP experience.

This is the final post in this series.

A quick “test” for the SAP outsourcing or SAP offshore fit is the nature of the work.  “Commodity” services are a perfect fit for SAP outsourcing or SAP offshore work. 

If the effort involves any type of innovation, business transformation or needs any level of change management then SAP outsourcing or SAP offshore development may be dangerous and it WILL cost you far more than you are led to believe.

SAP Upgrades Might Support SAP Offshore Development

One area I have seen where SAP offshore development work makes sense is with upgrade projects.  Much of the development work there is re-working existing objects where the requirements from previous projects have been well tested and adjusted.  Or, if there are enhancements the gaps are well-known and understood so that the detailed SAP development requirements can be easily defined.  From this standpoint SAP offshore review and adjustment of existing code makes sense.  There is little in the way of experience needed to use the syntax checker and to do the occasional program adjustment.  And other than poor coding which causes performance problems the risk is lower.

SAP Production Support Might Work With SAP Offshore Development

In a fairly stable production environment, where there are not a lot of enhancement or new functionality requests SAP offshore support might work well.  The “fix” requirements are very specific and limited so that these types of small adjustments or corrections work well in an offshore environment.  Even for some of the smaller and less complicated enhancements or improvements SAP offshore support might work well.  However, for more extensive troubleshooting, or very complex requirements, you are likely better with some sort of local or onsite support. 

For a more details see Outsourcing Your SAP Application Support.  This provides some insight and a little framework for understanding the SAP outsourcing or SAP offshore fit.

Conclusion on SAP Offshore Development

Regardless of the hype and sales pitches SAP Off Shore development has far more Total Cost of Ownership than anyone has been led to believe.  There is a place for it but that is rarely in a new project or an extensive rework of complex processing requirements.  While you may not see the costs, the offshore project model will cost you unless you are fully aware of the requirements and hidden costs that are never defined in any of the sales pitches or materials.  Of course they will never tell you SAP offshore development might cost you far more than higher priced local resources in many situations.  If they had that level of integrity you would never engage with them for those services. 

For more information and insight on this topic see IT Outsourcing, Off Shore Support, Cost Cutting and IT Department Changes.  That post provides some additional insight on helping to understand where SAP internal resources should focus as well as where offshore support might make sense.




Popular Searches:


  • sap softwareentwicklung offshoring

Related Posts: