This is a multi-topic post dealing with the following three questions:
1) What is an individual SAP-Pheromone?
2) What is a corporate SAP-Pheromone?
3) What is a collective SAP-Pheromone?
Answers:
Question 1: What is an individual SAP-Pheromone
As you all know, pheromones are the little molecules that attract one member of a species to another, or sometimes, even one member of a species to a member of a different species. (No, that's NOT what I'm referring to, so put THAT thought right out of your nasty little minds.)
So, it logically follows that a SAP-Pheromone has to be one of those folks who labor day in and day out, both inside SAP and outside SAP. to make the SAP Ecosystem ATTRACTIVE both to new potential customers and to existing customers who have to make that all important decision whether to renew support or not. (Is Ecosystem still a good buzz-word to use? I've been away for a while and I don't want to seem "passe"...)
Plus, there's an extra-added pun hidden inside the word "SAP-Pheromones" - namely "hero". Any SAP-Pheromone sometimes has to be a "hero" or "heroine" because sometimes there's a critical gap between what SAP thinks the customer should want to do and what the customer wants to do, and even with enhancement spots and access keys, this gap can only be closed by a "hero" or "heroine" willing to go the extra mile i.e. by working the nights and week-ends to get the job done.
Actually, that thought is a natural lead-in to my next topic ... heh heh heh
Question 2: What is a Corporate SAP-Pheromone
For a long time now, I have been wondering whether an SAP consulting firm could possibly succeed financially without adhering to the "fill the seats with butts" and/or "burn the hours" models.
And believe it or not, my current engagement has actually given me the privilege of working for a sub and a prime who believe that the answer to this question may, in fact, be "yes".
Yes, folks, believe it or not, I seem to be currently working for a sub and a prime who both actually believe that the way to be successful is not to "charge more than you're worth", but to "give more than you get".
The idea behind this model is that an SAP consulting firm should look beyond the short-term goal of maximizing profit on a particular engagement, and realize that if you "give more than you get", word will get around enough to ensure that you'll get enough business to make an honorable profit, albeit perhaps not an exorbitant profit. And when you think about it, this is the way any retailer works when it offers a legitimate sale- it's willing to make less on any individual sale in otder to make more sales overall.
Here's a very simple example of the kind of thinking that makes an SAP consulting firm an "SAP-Pheromone". You all know that when SAP functionals (oops, sorry, Marilyn, Business Process Experts) are busy working out their functional specs, they often test things in the "sandboc" client, and in order to be able to do so, they often put relevant test data into the "sandbox" client - at least enough to be useful in the unit testing of any technical solution that's going to arise from their function design.
So, why not "cross" the development and sandbox clients, i.e. make development code available in the sandbox (without allowing changes in the sandbox, of couse)? I can tell you that I personally just saved probably a full week or more of work by not having to build my own test data in the development client because I was able to unit test my code in the sandbox (or not waiting for a functional to rebuild his or her test data in the development client as well as the sandbox client.)
So far as I can see, the only argument against this idea is that if you adopt it, you will burn less hours at the client's expense. And this, of course, goes against all the rules of the "butts and seats/burn the hours" models.
This actually leads me to my third and final topic, which is actually a postscript to an old conversation at SDN which some of you may remember.
Qurstion 3: What is a Collective SAP-Pheromone?
If you're here at SCN reading this blog, you know the answer to this question already.
The biggest and best Collective SAP-Pheromone is SCN itself, because it provides an infinite number of ways to make the SAP experience more attractive to everyone who partakes of it.
Here's an example.
Back in 2006, I was confronted with the problem of displaying photos attached to PM notifications in an HTML Viewer control, even though the client was using the old internal SAP Office DB instead of an external content server, and as a result, the photos had no URL's to pass to the method of the class implementing the control (CL_GUI_HTML_VIEWER_CONTROL.)
This problem actually broke down into two parts: a) getting the damn photo out of the internal SAP DB in the form of a binary; b) finding some way of assigning this binary a URL that could be passed to the control itself.
The first part of this problem was solved with a lot of help from old-timers down in the ABAP forum (although I hope no one will mind me saying that I did do some of the requisite discovery myself by wading thru the apppriate SO function modules.
The second part of the problem was solved by a really bad "kluge" - once we had the binary successfully extracted from the internal DB, we used GUI download to put it out on a disk-drive, and then used the path to this external file as the URL to feed to the control. (Note that this kluge was very IO-intensive and expensive, because we had to write the binary to disk and then read it back from disk into the control.)
Well, guess what?
I'm only a week into my current engagment and I'm talking to another developer on the job about the fact that we can't use the BDS or GOS class-methods to handle documents/attachments because the client is using an external content server that talks to SAP thru the KPRO API.
So one thing led to another and I would up telling this developer about the "kluge" I just mentioned, and he kindly told me that I could have saved a lot of coding and run-time IO by using the LOAD_DATA method of CL_GUI_HTML_VIEWER_CONTROL. In other words, I didn't realize back in 2006 that you can give this method a "dummy" url, like a GUID, and the method will pass back a "memory URL" that you can pass to the viewer control itself when you're ready to pop a photo or whatever.
And the point of this story, of course, is that if this particular developer had been an SCN "habitue" back in 2006, my life would have been a lot easier and the SAP experience would have been a lot easier for the client's Basis and network staff who had to figure out how to give me an external directory that the binaries from any and all users could be written to.
In other words, the more talented and experienced folks become SCN "habitues", the better SCN can fulfill its role as the ultimate "COLLECTIVE SAP-Pheromone" - a tool for disseminating group knowledge that will keep folks attracted to SAP by making the SAP experience as pleasureable as possible.
