Ray Mannion

Although nothing makes me happier than having my headphones on with some hypnotic trance music playing as I become one with the ABAP editor, I can only enjoy that time if I’ve done the upfront work to support 4 important groups of people.

Sadly, many ABAP developers can’t see beyond the cubicle next to them where their spec-writer sits. “That guy will tell me what I need to do and he’ll tell me what’s wrong. No need for me to do any thinking. I just code.”

1) Users

Of course, you have to put yourself in the user’s shoes. Most ABAPers do this quite adequately. Frequently used values are pre-filled on the screen using PARAMETER IDs. Search helps are where you need them. A link from one report over to a document via drilldown – whoa! Talk about consideration!  The best way to make sure your users are happy is to learn the BEFORE and AFTER.  What happens, what do they do, BEFORE they get to your code in the process flow?  Maybe you can head off some problems.  Next, what are their follow on actions?  How do they research issues?  How do they resolve discrepancies?  Maybe a link to the Stock Overview is more meaningful than just a link to the material master.

By far, one of the best ways to serve your users is to actually watch them use SAP.  Some people are menu-users.  Some love the mouse and others prefer the keyboard.  Some people need to print everything whereas others wish to email everything.  How would they like to sort the information?  What information are they looking for in a report?  Can it be highlighted to make it easier to see?   Watch your users in action and ask them what they are thinking.  Then, put yourself in their shoes as you begin designing and testing your application.

2) Management

Here’s a thought: Programmers are cost centers. Users of your applications are also cost centers. Put yourself in the shoes of the person who signs your invoices and ask yourself “What value am I getting from these applications? Who is using them? How often? How many problems have we encountered? Avoided? Resolved? Was it worth it to hire that geek that’s always spouting off about ALV this and GUI that?”

The other day, I received a change request to an application that went live almost a year ago. It was the first time anyone ever contacted me about that application.

In a year.

Fortunately, my application is designed to provide some simple statistics and table counts. I built them during integration testing so I could feel 100% confident going live. So, I did a quick check and fired off a note to the guy who pays the bill…

Dear Dave,
I just wanted to congratulate you on your decision to replace that old invoice distribution application in favor of our homegrown solution. It seems that we’ve managed to send over 712,000 emails in the past year without fail. In fact, I just got my first request to make a small enhancement to the application. I’m sure you don’t always get a pat on the back when things are working, just complaints when they fail. Coming up on the 1 year mark, I thought I would congratulate you on your decision to trust our ability to build a great product. I think the mission is well accomplished.

If you understand what’s important to the managers, you are better able to deliver value to your client.  The next time you say “the whole thing should be re-written”, give some thought to the actual cost/value to the customer.  Don’t waste your manager’s time proposing solutions that are clearly not of a cost benefit.

3) Auditors

Before I owned my own business, I thought auditors were some evil, anal-retentives who spent so much time getting picked on as kids they felt they just had to grow up to be in a position of power where they could ruin your life with the swipe of a pen!
As a business owner, I’ve come to appreciate having someone come in and show me where my weaknesses are, places where things don’t add up and reconcile. They are the people who prevent problems before I have them.

Before you open the ABAP editor, ask yourself about this program you’re developing: “How would someone reconcile this on a high level to make sure it is accurate to the penny?”

By using table locks, the standard ENQUEUE / DEQUEUE functionality in SAP, ABAP developers prevent issues where numbers don’t add up. Sure, it may be one in a thousand chance that two people make changes at the same time, but so what? WRONG! Try having the CFO glare at you across a table asking why total 1 doesn’t match total 2 and your only response is, “well, I guess the database hiccuped”.

Isn’t there some authority-checking that should be done here? Sure, it’s a pain sometimes to create custom authority objects. It’s a Pandora’s box to ask your security team to create a custom profile for your function. But, it’s the right thing to do so that your auditor’s don’t have to report it as an issue later, or worse – a SARBOX violation!

4) IT Support

Sure, you wrote a sweet function. It runs fast, crunches the numbers accurately and makes a pot of coffee, but who knows about it? Did you ever think that maybe your Portal developer might like to know about your function? Did you design it to be remotely callable?

Dare I mention the word “documentation”? Egad! The dreaded insult to a programmer – having to write something in plain English! Well, having “inherited” code for over a decade, I’ve learned that a few sentences here and there can prevent hours of frustration.

You know that problem you spent an hour troubleshooting and finally solved? Don’t keep it to yourself! Give a little somethin’ to the next guy to walk in your shoes.  Explain the issue and why/how you chose to address it.

Remember how that user told you “For now, we only have one Sales org, but we’ve been trying to buy that other company for awhile now and we think it might happen next year”? Did you just ignore that and hardcode a single sales org?? Of course you didn’t. You care about your team. IT Support needs you to make good decisions so that their lives are easier when they have to make changes to that pile of spaghetti.

Summary

So, those are the 4 groups I try to consider whenever I build an SAP application. Let’s face it, we’re just glorified plumbers, piping the inflows and outflows. Someday, someone is going to be looking closely at our work. Try to consider what they might be looking for when they get there and how they’ll find it.