SAP & ERP Consulting from the Customer Point of View

ASAP Methodology Background

In the mid 1990’s SAP had gained a significant amount of bad press and publicity around several high profile project disasters that the company knew were completely avoidable. At that time Oracle, Baan, JD Edwards, and PeopleSoft all had sales people making the case that SAP was too expensive, too complicated, and took too long to implement. In response SAP released the ASAP Methodology in the mid-late 90’s (around 1996 or 1997) because of the number of SAP projects that were going over time, over budget, and were at risk. It has been refined, polished, enhanced, and adjusted with SAP’s supported R&D resources and efforts for about 15 years now.

The ASAP implementation methodology has leveraged the PMI (Project Management Institute) best practices around project delivery and the Carnegie Mellon CMMI (Competency Maturity Management Integration) approach for maturing the delivery process. The ASAP methodology also includes a number of ITIL (Information Technology Infrastructure Library) components in the Phase 6 Run and the ValueSAP portions of the methodology. Agile techniques are an option which can be “turned on” if you like.

The toolset includes an implementation “Roadmap” which is a WBS based project template. It has full explanations, templates, tools, resources, checklists, etc. Together with that the original version also included an MS Access, and then an MS SQL Database application for selecting your solution options which would then generate a list of processes, transactions codes, template BPPs, and a full SAP centered Blueprint document, etc.

Today all of that functionality is still available but it is housed in Solution Manager. The ASAP Roadmap is just ONE component of the entire ASAP Methodology. The Roadmap is focused on effective Program or Project Management for accelerated project delivery with high quality results.

My Experiences with the SAP ASAP Methodology

I was originally certified in the ASAP Methodology in 1998 while at Grant Thornton. In that time I have had the privilege of using ASAP on several projects and as the project manager on a few. One consistent result of using the methodology is that projects are delivered and they are usually delivered on time and on budget (although not always).

Every major SAP system integrator claims some methodology and nearly all of them are similar to, or variations of the SAP ASAP Methodology.

I have only ever seen significant problems with ASAP when a system integrator started to use the methodology and then abandoned it part way through the project. At one recent client I used it as the framework to support a LEAN implementation methodology. That LEAN methodology has served as an ongoing framework to significantly accelerate numerous rollouts at probably 25% of the normal implementation cost of other SAP projects.  This was driven by the client project manager and facilitated by using the ASAP tools. 

Starting with the ASAP Methodology

Even before the first consultant comes on board the ASAP methodology provides templates and resources to cover key project and program management areas such as

• communication planning
• decision making
• risk management
• project management master planning
• resource planning
• steering committee tools
• external links to best practice resources for reference (PMI, ITIL, Internal SAP, etc., etc., etc.).

Why ASAP Instead of a System Integrator Methodology?

First, I have nothing against the system integrator methodologies and some are very good with great resources. Unfortunately my experience has been while they have them, and may start with them, they rarely stick to them throughout the project. Since it is their methodology you have little or no insight to cross-check or validate their methodology use.  With ASAP it is yours to use as an SAP customer and you have full insight into it and control over its use.

One of the primary reasons for using the SAP ASAP Methodology is like all things SAP there has been a mountain of R&D spend, development, adjustment, and support. Every SAP client (large or small) who uses the ASAP methodology can avoid the “proprietary methodology lock-in” which the system integrators will walk out the door with. Another important reason is you own it as part of the standard Solution Manager offering. 

As you probably know Solution Manager is already a required part of your SAP landscape.  The SAP Solution Manager portion of the ASAP Methodology can house key items related to scope, configuration, documentation, the implementation roadmap, and all of the key deliverables. As the system integrator rolls off the project you have a centralized repository which is SAP specific for any future employees, support, upgrades, etc. You do NOT get that with a “custom” system integrator methodology which is probably based significantly on SAP’s ASAP Roadmap to begin with. Using an SI methodology you will NOT get the full configuration and development scope monitoring tools which Solution Manager contains either.

The entire ASAP Methodology is part of your application licensing and support you pay for. Why not at least take it for a test drive and see what it can do.

For more information on the SAP ASAP Methodology for SAP customers use your SAP OSS ID and log onto http://service.sap.com/asap .

Related Posts:

• SAP System Vendor Project Success Criteria 1
• SAP IT Governance, SAP Program Management, SAP PMO Metrics
• 7 Tips for Effective Client Management of SAP Consultants
• SAP Program Management Requires a Type of CMMI
• Steering Committee Governance for an SAP Center of Excellence

The most frequent response around accountability for program or project managers was a call for ”independence.” So when I raised the issue of project manager or program manager accountability, metrics, performance, and how to ensure project messes are avoided there were no takers.  Is it any wonder so many business application projects and programs get into trouble, go over budget and time?

SAP Program and Project Management Office Success

A good Program or Project Management Office provides the resources needed for delivery project participants to be successful.  Without this focus the value of an SAP Program or SAP Project Management Office is not realized.  The U.S. Department of Energy did a good review of performance and benchmarking for project management.  And while this was applied to a government program there is a lot of valuable insight for any SAP project or business application project [FN1].  

The U.S. Department of Energy had a committee evaluate success criteria and offered four sets or categories of performance measures to cover the 30 possible discrete measurements of project or program success.  Those four sets or categories were [FN1, pg. 1]:

• Project-level input / process measures. Assess the resources provided to deliver an individual project and the management of the project against standard procedures.
• Project-level output / outcome measures. Assess the cost and schedule variables of an individual project and the degree to which the project achieves the stated objectives.
• Program- and department-level input / process measures. Assess the total resources provided for all projects within a program or department and the degree to which program- and department-wide goals for projects and their management are met.
• Program- and department-level output / outcome measures. Assess overall project performance and the effectiveness of completed projects in supporting program and department missions.

Without this type of analysis and evaluation your project may be headed for trouble before it even begins.  When you start your large business application project what type of deliverables, output, or results do you expect from those who are leading the projects?  How will you measure and evaluate their performance?  If your evaluation of their performance is focused on how well they support the success of delivery teams, along with how well the projects are delivered (budget, scope, schedule, and quality) then you will be measuring the key project delivery values for success.

That same U.S. Department of Energy study provided guidance on the key components for a successful performance measurement system of program or project managers which can be applied to business software projects like SAP.  They noted key components of an effective performance measurement system include [FN1, pg. 7]:

• Clearly defined, actionable, and measurable goals that cascade from organizational mission to management and program levels;
• Cascading performance measures that can be used to measure how well mission, management, and program goals are being met;
• Established baselines from which progress toward the attainment of goals can be measured;
• Accurate, repeatable, and verifiable data; and
• Feedback systems to support continuous improvement of an organization’s processes, practices, and results.

The Answer for SAP Program and SAP Project Management Results

Over the years I have found the SAP ASAP Methodology helps to ensure SAP Project delivery.  The entire methodology is focused on project participant success; budget, time, and scope control; and quality control for project delivery. 

My non-cynical assessment for why it is not more widely used is because many SAP Program Managers and SAP Project Managers have not be trained to use these tools (or Solution Manager which contains them).  On the other hand there are some SAP Project and Program Managers who have a financial motive that can not be ignored.  They do not use the ASAP Methodology because it makes a client less dependent on them.  After all, why do you need an expensive program manager to deliver tools, templates, resources, guidance, quality control, and measurement utilities if you have a methodology that already contains all of this with step by step instructions to use it?

==============

[FN1]  Measuring Performance and Benchmarking Project Management at the Department of Energy. http://management.energy.gov/documents/performance_measures_final.pdf

Related Posts:

• Why Use the SAP ASAP Methodology?
• SAP Program Management Requires a Type of CMMI
• Steering Committee Governance for an SAP Center of Excellence
• SAP System Vendor Project Success Criteria 1
• The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors

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!!!!

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• SAP Offshore Development Project Experience
• The Real Reason Executive Participation Creates IT Project Success
• CRM, ERP, BI, and IT Investment — Where Do You Find the Business Benefit?
• Key Design Considerations for SAP Reimplementation