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?
• Where Does SAP Offshore Development Make Sense?

SAP Offshore Development

There is a time and a place for everything–, even SAP project offshore activities.  Unfortunately in the quest to save money the wrong approach can sound good on paper but cost you far more than the sales pitches would lead you to believe.  The SAP offshore sales pitch uses enticing rates like getting an offshore developer for about 15 to 20% the rate of an onshore resource (about 1 / 5^th to 1 / 7^th the price).  The initial reaction to all of the sales pitches is “wow, that will save us a bundle!”  The truth is sometimes it does and sometimes it does not.  And in many cases it can even cost you far more in hidden costs than local (higher priced) developers.

This is the first in a 3 part series on SAP offshore projects:

• Part 1 – SAP Offshore Project Development Experience (this post)
• Part 2 – Hidden SAP Offshore Development Costs
• Part 3 – Where Does SAP Offshore Development Make Sense?

I’ve worked on 3 projects where off-shore resources were used for the initial project and 2 others where they were used for upgrade.  This is the “inside scoop” from my experience.

The Real Reason Offshore Development Seems So Cheap

Let’s set the record straight on one thing immediately, there is a REASON those rates are that cheap.  In the global SAP world it has less to do with the wages of the host country than you might realize.  In the SAP space there is still strong demand for strong SAP skills globally so market forces plainly dictate that real experience will pay market rate no matter what country it is.  Work Visa requirements for many countries with high SAP skill demand will allow the importing of actual skills –, heck, they let massive numbers of total fakes and frauds in the United States so real experience (rather than faked) makes it easy to move out of these host countries for far higher wages.

When Off-shoring Might Cost You More Than Local Resources

When your SAP project depends on large amounts of custom development work you may be in for reverse “sticker shock” at the actual hidden costs.  And by reverse “sticker shock” I mean it is like getting a car for 25% of what you thought you would have to pay BUT you find out the tires, battery, seats, steering wheel, and all of the key components of the car are “required” add-ons that you have to pay for separately.  But they only show you the nice, finished, new car with all of the “extras.”  The actual cost for a HUGE portion of the offshore development is hidden and that rate you were quoted is a joke! 

Your “offshore” resources have very little if any actual SAP development experience no matter what kind of a sales pitch you are given.  What you are ”hiring out” is some smart college kid who is learning on your dime but *maybe* under the supervision of an experienced developer.  Yes, the rates are lower but in today’s economic climate you could probably find some aggressive local college kids who would do as good or better, for the same wage, and without any language barriers.  Maybe you should consider that and bring in one of those expensive local resources to train, shepherd, supervise, and teach them.  At least then you have the skills in house.

Some of the huge costs that are buried for a new project are in the whole development process itself.  SAP functional consultants, who are typically higher priced than technical or development resources, end up taking 2 -3 times the effort spelling out requirement details.  That extra effort translates into hidden cost that you do not see but it creates a great target for the offshore resources to “blame” for why they are struggling–, “I’m waiting on the functional consultant…” or “the spec had to be re-written…” or “it didn’t have enough detail…”  A truly experienced local resource already knows and understands the table structures, data sources, actual requirements, and has probably done similar SAP development work or reporting.  With a higher level spec in plain English, rather than detailed design with pseudo-code required for offshore work, local SAP resources can churn out a polished first pass development effort which needs only minor tweaks, takes less time to test and adjust, and has better performance.

The actual cost for a HUGE portion of the offshore development is hidden and that rate you were quoted is a joke! 

There really are situations where Offshore development is ideal for your SAP project, just don’t be surprised if the overall project “savings” you expect don’t materialize on a new project or one with complex development requirements.

How Can You Tell If You Are Being Bitten By Huge Hidden Offshore SAP Costs?

The one simple metric that will clearly illustrate if you are a victim of hidden offshore development costs is the total CALENDAR timeline for all development work.  In other words, after you get past the excuses, the finger pointing, the supposedly finished items that are always being reworked, etc., the calendar timeline tells all. 

No matter how many times the offshore development tries to suggest they are having problems getting “complete” functional specs, or how often they say they are done but have defect after defect to resolve, or whatever the excuse is, the simple calendar test will tell you the TRUE project impact.  If it takes 90 calendar days to complete development to the point that it can be used (defects corrected, tested, and ready for production) then it doesn’t matter if they estimate and then claim completion at 3 weeks.  The other 9 weeks to actual completion is project time that is taken from SAP functional resources, reworked development, business resources, etc.  So there is a huge hidden cost no matter what claims sales people may offer.

Related Posts:

• Where Does SAP Offshore Development Make Sense?
• Hidden SAP Offshore Development Costs
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Industry Specific SAP Consulting vs Deep SAP Application Experience
• Using SAP to Improve Revenue and Profitability

IT Convergence

The other day I was having a conversation with an IT executive from one of America’s largest companies.  I was really interested in his perspective as a hard working senior level IT insider.  We started talking about the role of IT and business as well as the future of business and technology while I relayed my passion for how IT needs to integrate with the business and how the future was going to change significantly (see e.g. What is the Proper Relationship for the CIO, CEO, and CFO?).

I gained a new appreciation for how difficult an IT executive’s job can be when the economy is in turmoil.  I’m sure my comments and perspective were challenging but here is part of what I gained from that conversation (my assumptions and my “read” may be wrong)…

The wider global technology discussion (inside and outside of the company) is putting real pressure on IT return on investment, IT Convergence, and full integration with the business (see Steps to Achieve SAP IT Convergence).  Even while all of this takes place there is still a critical need to stay on top of technology trends and be sure the organization does not stagnate.  To stay competitive what does he do with “cloud” processing, do they need different applications for some of their processes (CRM, APO,SRM, etc.), what about social media (does it even fit), virtualization, shared services, service excellence, outsourcing, in-sourcing, etc., etc., etc.

This executive’s IT organization is being challenged to do more with less.  As a result of cost-cutting pressures his organization is having to look at outsourcing while he also has to maintain a positive and upbeat appearance in the face of working through difficult cuts.  He has to continue encouraging and rallying the troops while some of them will not be there.

A Simple Response to the Nagging Problem of Business IT Convergence

With all of this background in mind one of his responses to me set me back a moment for its simplicity, candor, and most of all the underlying frustration.  It is certainly one of those very difficult struggles that many corporate technology leaders today face:

“What is the business responsibility for this?”

The business not only has responsibility but they have to help drive solutions and delivery. The various business stakeholders must see, understand, and then accept their role in developing the technology roadmap. And once it is developed they must help ensure its execution.

The Business to IT Convergence Solution That Was There All Along

The IT Convergence approach in the SAP enterprise is partially based on best practices around IT Governance.  By creating a governance structure that involves and integrates both the business and IT stakeholders you gain business buy-in and involvement.  I have written a solution brief on this approach and provide a free, no-obligation MS Access application to build technology roadmaps (see the Solution Brief, governance process, and application overview here:  Beyond Technology Alignment )

The basic takeaway here is that business involvement is critical.  They are already making technology investments, with, or without your involvement. So it is critical to gain that convergence so that technology investments are performed as a partnership and not in isolation.  As a recent Harvard Business Review post by Ray Wang notes:

“[O]verall corporate tech spending is up by 17 to 20% in our latest data, spending by IT departments is flat at best. It’s business leaders, not their IT colleagues, who are driving purchasing decisions.”

Coming to Terms with the Consumerization of IT, http://blogs.hbr.org/cs/2011/07/coming_to_terms_with_the_consu.html and a followup with more details on his site at:  http://blog.softwareinsider.org/2011/08/22/mondays-musings-balancing-the-six-ss-in-consumerization-of-it/ (both retrieved 8/23/2011)

So the key here is to integrate the business into the IT and application infrastructure.  One way to do that is through leveraging SAP steering committee skills and business connections to ensure meaningful involvement by IT.

Additional Steps to SAP IT Convergence – Creating the Center of Excellence

Last week’s post provided a few high level steps to achieve SAP IT Convergence, and this week I am adding to that list the following items.

• Pursue business executive sponsorship but don’t wait for it to get started.
• Start a communication program
• Engage at all levels of the organization
• Conduct one or more pilot programs and capture lessons learned
• Hold IT staff accountable for participation
• Don’t let available tools stifle participation or innovation

Related Posts:

• Steps to Achieve SAP IT Convergence
• SAP IT Convergence is About Business Focused Integration
• SAP Program Management Requires a Type of CMMI
• SAP IT Convergence Beyond Business to IT Alignment
• SAP Project Manager – SAP Program Manager, Lessons from the Trenches