SAP & ERP Consulting from the Customer Point of View

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

Manage SAP Consultants

Over the years the most successful SAP projects I have participated in had strong client side leaders. They had some knowledge and understanding of how to deliver large, complex, or difficult projects. Not just SAP projects but large complex undertakings. Their ability to deliver projects came from their ability to manage, direct, and engage with project participants. They took the initiative to directly manage their own projects.

Many of these leaders had something else in common, they understood you can become overly reliant on consultants to deliver a project –, it creates an artificial sense of security.

One project and leader in particular stands out from my past because of the attitude about SAP project delivery. That project’s senior leader used a phrase about consultants I found a little insulting but have since learned to appreciate. He had a “rented skills” attitude about consultants and frequently referred to us in that way. Along with that attitude he and the senior leadership of the company chose very strong leaders from within the company ranks to manage each module or key area of the project. And by strong leaders I mean REALLY strong leaders. During the course of the project a number of consultants were replaced when they did not perform up to the company’s expectations. That project was probably one of the best delivered projects I have ever seen:

• It had one of the largest SAP scope and functionality footprints.
• That project’s first phase replaced nearly 60 homegrown legacy systems.
• It was delivered ON TIME and WITHIN BUDGET.
• It met every business requirement.
• It was delivered across international company codes and business units (including foreign trade).
• And for similar sized companies, with similar scope, similar time frames, etc., it was delivered for probably 10 – 20% of similar projects.

That project was very different because the level of automation and how smooth the go-live went, and even the post-production support issues were far fewer than any other implementation I had participated in.

I participated in this implementation’s post production support as the SD lead and to help with reporting for about 6 months after we went live. They had slightly more support issues than many companies have with “stable” SAP implementations. This senior leader went on to become CTO and nearly all of the company’s leaders involved in that SAP project went on to senior level leadership positions.

How Clients Can Effectively Manage SAP Consultants to Deliver Results

The background I just provided illustrates one of the most important factors necessary for successful SAP project delivery. The Ivey Journal published by Harvard Press about “Leading Consultants to Exceed Expectations” (PDF file) went into detail on this issue. The key is in aggressive client management of SAP projects for companies that want meaningful results and value.

For me this involves a few critical components:

1. Develop a project or team set of values and expectations for project delivery. The expectations should be focused on action and execution.
2. Provide a training course to client participants on the latest SAP ASAP methodology. It can be made available through Solution Manager or as a stand-alone HTML download from the SAP Service Marketplace.
3. Define clear boundaries, tasks, and roles for all project participants. No one should have to try to figure out what they are supposed to be doing.
4. Every client project participant should be trained in how to manage and work with consultants. Use RACI charts to help manage consultants.
5. Every client project participant should be spelling out the specific tasks, assignments, and expected completion of deliverable for each project participant.
6. Each person on the project, whether contractor or employee, should have clearly defined deliverables, tasks, and criteria for success.
7. The client project participants should capture and regularly discuss lessons learned on dealing with consultants, including challenges and soliciting ideas on managing them.

Client and consulting leaders should accept responsibility for the delivery and execution of those they are responsible for. Be on guard for excuses, deflection, and blame-shifting. At times these are common consulting tactics to hide a skill, talent, or capability gap.

One key thing to consider is that any decent SAP consultant who has managed to deliver SAP project results can be difficult to manage at times. Because of their type “A” personality tendencies they need input and awareness of anything within their domain of influence. To manage high performing consultants the use of a RACI chart cannot be underestimated. Because of these tendencies project managers must activity work to solicit their input and feedback, and well as keeping them in the loop on what is happening in the project. If you fail to do this you are setting yourself up for trouble and unnecessary conflict. This is why a RACI chart is a useful tool on an SAP project.

For an overview of the key SAP project success factors, including allocating responsibility, please see this table which provides an overview of success factors:

Critical Vendor Management Success Factors for SAP Project Success

For a detailed explanation of each of these success criteria you may wish to review the series which analyzed them from the consulting selection point of view:

• SAP System Vendor Project Success Criteria 1
• SAP System Vendor Project Success Criteria & Factors 2
• SAP System Vendor Project Success Criteria & Factors 3
• SAP System Vendor Project Success Criteria & Factors 4
• SAP System Vendor Project Success Criteria & Factors 5

Related Posts:

• SAP System Vendor Project Success Criteria 1
• Why Use the SAP ASAP Methodology?
• SAP Offshore Development Project Experience
• How the SAP Consulting Peter Principle Works
• SAP Consultants for High Speed SAP Projects

Managing SAP Project Conflict

If you are determined to gain and then maintain SAP project momentum you will see stress.  Part of the requirement for momentum includes asking people to reach for stretch goals which can challenge (and deepen) their capabilities but also causes tension and even conflict.

One author says conflict is “a situation of competition in which the parties are aware of the incompatibility of potential future positions and in which each party wishes to occupy a position which is incompatible with the wishes of the other.” [FN1] 

In plain English, conflict happens when there are competing expectations and priorities.  Put another way, I want what I want and you want what you want and the level of our conflict depends on just how much each of us wants “it”.

Without hands on, active SAP project management it is likely that stress and conflict will destroy your SAP project momentum.  Active SAP project management is not about micromanaging people or their activities but rather finding the right balance around task execution and delivery while working through the stress that will arise.  As a project manager part of your key responsibility is to work through conflict to maintain momentum.  At its most basic project SAP project management is like babysitting adults who at times act like squabbling children (and I’ve been guilty of childish squabbling as well at times!).

Key Phases of SAP Project Stress Which Can Create Conflict

In relation to physical and life stress Canadian Physician Hans Selye (1907 – 1982) proposed 3 stages of stress in his 1956 book “The Stress of Life”: 

• Alarm
• Resistance
• Exhaustion

On an SAP project the alarm or panic stage occurs when you attempt to create a rapid project delivery pace.  The resistance stage occurs when the alarm does not slow down or stop the momentum that is gaining. Exhaustion or “checking out” can occur when the stresses and pressures of an overly aggressive timeline continue beyond what the project participants are able or willing to deliver.  A good SAP project manager must carefully evaluate and then manage the source(s) of alarm and resistance.

The key to good SAP project management is to maintain a sense of urgency that is strong enough to keep momentum high but no so urgent or so stressful that it causes people to burn out or check out.

There is a healthy level of tension which is needed to keep momentum going but knowing where that line is requires a project manager to be directly engaged with the project participants.  Even though it is critical to gain and then maintain momentum at times you also have to know when to ease up to allow the stress level to moderate. 

It is equally important for a project manager to know whether the alarm and resistance are from unskilled project participants who are trying to hide their lack of experience, or from unrealistic demands, or from the project as a whole. 

At First Most People Try to Deal With SAP Project Stress in a Productive Manner

Regardless of the reason for the stress, and ultimately what the conflict is, most people do attempt to mitigate the initial source of the stress.  The research shows they may:

1. apply extra effort to compensate for the greater demands,
2. they may attempt to overcome the stress by fixating on the task(s) which create the stress, or,
3. they may become anxious, worry, and then avoid the tasks.

If a project manager is skilled and recognizes these signs they can quickly intervene and help to alleviate the source of the stress.  Although it is critical for momentum to keep a forward looking perspective throughout the project there are times it is more productive to pause, reflect, and allow stress levels to lower.  When you see tension and stress building to an unhealthy level it may be time for a special recognition of how much progress has been gained to help people regain a sense of perspective and give them a chance to “take a breath.”

A good SAP project manager must carefully evaluate and then manage the source(s) of alarm and resistance.

Knowing when to back off the gas and recognize accomplishments and when to press the gas and push ahead is the most difficult skill for any project manager to develop.  It is like a professional race car driver who must know when to step on the gas, when to let off, when to apply the brakes, and when to step back on the throttle.  A project manager who is able to perform that balancing act demonstrates their experience and their people skills.  This requires direct engagement with the project participants on a day to day basis. 

This type of engagement by the SAP project manager needs to be in the project participants’ work environments, not just in planned meetings where people may not be as candid or forthright.  That direct engagement requires the project manager to serve as an active umpire, counselor, decision-maker, expediter, and all around gopher to help coordinate many of the integration activities. 

A Good SAP project manager GENUINELY UNDERSTANDS that their success depends on every other project participant’s success and will directly engage in activities which help promote the success of project participants.  Sometimes this means giving some project participants the opportunity to be successful on a different project  :)

As a final thought, an SAP project manager who needs a separate “integration manager” should be more carefully considered.  It may be necessary but do you really need a Microsoft Project administrator or a meeting monitor or do you need a manager for your project?  Needing an ”integraton manager” may be a way to avoid the day to day involvement that is critical for SAP project success.

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

[FN1]  Capozzoli TK. Conflict resolution-a key ingredient in successful teams. Supervision (60:11), 1999, pp 14-16

Related Posts:

• 5 Leadership Tips for Successful SAP Project Management
• SAP Project Manager – SAP Program Manager, Lessons from the Trenches
• 5 More Leadership Tips for Successful SAP Project Management
• SAP System Vendor Project Success Criteria 1
• Some Reasons SAP Projects are Over Budget and Over Time