BPX and the Drift toward "High-Margin/Low-Risk" (Non-)Deliverables

[former_member181923]

Andre (Truong), Chris (Solomon), and some others here will admit tjat they know what I mean by "high-margin/low-risk" (non-)deliverables.

Many others will know what I mean but won't admit it.

But for those that really don't know what I mean at all, "high-margin/low-risk" (non-)deliverables are the work-products of analysts who don't have to stay around though system testing before their companies are paid.

Will BPX further the drift toward these kinds of (non-)deliverables?

Or help to halt it?

In my opinion, the jury is still out on that one.

djh

[Former Member]

There're a lot of things a BPX could do to participate to the software enablement of a business requirements besides documentation and eventually configuration whenever it's possible. Things like process flow, data flow, UI configuration, role determination for each process steps...

But unless they learn more technologies especially the new composition ones, the wannabe BPX will get stuck in the paradigm you outlined, I'm afraid. They can always learn old technologies like Abap but that's not new. They could always do that for the past decade.

Even if the individuals wanted to use new technologies, I'm not sure corporations are so keen on innovation overall especially business software innovation. R3 4.6c still huge presence is a proof of that right?

I think the idea is great. Technologists or business analysts are willing to cross the chasm but the market (SAP, its development and service partners, its customers, its developer and functional consultant base...) is so not ready yet. The risk you outlined might constitute another round of consulting bonanza at the BPR sauce.

At this point you got to be really lucky to work for a forward thinking and innovative customer or partner who wants to spend that kind of money developing solutions using SAP new concepts and technologies. Those are rare instances and hopefully we'll be able to find them. Actually I might this year

[former_member181923]

Hi Andre -

And thanks to you also for a second sanity check, which means as much to me as the one that Chris S provided - believe me when I say I am very grateful.

But since we agree to a certain extent, let's take the problem a little closer to home here at SDN.

If you look at the main blog space here at SDN (what's now called the "Expert Blogger" space), you will see all these really great blogs on Enterprise SOA theiry and practive that are totally divorced from the kinds of "in the trenches" realities that you and Chris and Gareth and I are discussing here at the Coffee Corner.

In other words, if you just read the "Expert Blogger" space, you would have absolutely no idea that the "socio-politico-economics" of IT are as nasty as we know thet are. You would think that all IT is developed and used in a huge monastery (Buddhist, Catholic, whatever - take you pick) where everyone has the best of intentions and no one ever does anything purely to up his or her bonus or the bottom-line of his or her company.

In my own opinion, SAP is a big enough "elephant in the room" that it could afford to start throwing some weight around with its premium platinum partners to reduce the amount of feeding at what I've called the "high margin/low risk" trough.

Like they used to say in the 60s - "If you ain't part of the solution, you're part of the problem", and this goes for corporations as well as people.

As usual, best regards

djh

[Former Member]

Nice and laudable intend David. But I'm not sure how practical it would be or even in SAP interest to act on. The SAP consulting business is something even SAP benefits from hugely. There was even a time in the mid-90s were SAP didn't even have any consulting practice and were watching their partners making ten times what they were making. It's a greedy business (lots of money) and as rule of thumb I'd like to say: every time money reaches such importance, you can say bye bye to common sense.

The good thing is in this insane environment is if you're part of a small organization that knows how to deliver value, you'll get business. But as for the key to big customers and their big wallet, I think at this point it's pretty well guarded by SAP account execs and consulting managers as well as US and India big Four.

I have to admit I'm somewhat amazed by your energy and passion and I wish I'd do a better job at getting there myself. Keep it up. That's refreshing. (look at me I'm talking like an old guy

[Former Member]

Hi Andre,

One of the big problems during the nineties was the clients pushing a conservative, tight-scope approach which (understandably) minimised their risk but also slowed acceptance of better technologies and practices for the customers. This meant that the benefits of using SAP were lost a bit unless the partners were prepared to push the envelope - which in many cases they weren't.

It was quite frustrating to talk about something new to customers and see this vetoed bu the partners during implementation. Fortunately this model appears to be on the outer (which is good because it focussed on benefitting the partner rather than the customer).

But what worries me is that unless care is taken, BPX could be a way of returning to a "by-rote, this is the only way etc methodology" unless the BPX takes their role very seriously. But if they do, the complexity of both modern business and SAP systems themselves, mean the BPX may have to be in the genius mould in order to have enough data to do their job.

In actuality, I find the best approach to business process work is for the customer to engage with the consultants and drive their process themselves.

And while I'm on the soapbox, I hope we don't end up with (as we had in the nineties) graduate BPXs who are well trained but have never <i>actually</i> worked in business running around. When this market had a downturn after 2000 they all disappeared and haven't returned yet.........

Well, I've had my rant and now I think I'll go and have a quiet lie down. And maybe a Bex. (Classic Australian Antacid tablet - my Gran used them to cure everything)

Regards

Gareth

[marilyn_pratt]

I'm glad DJH starts this thread with "the jury is still out", although it doesn't fully resonate that way as this conversation progresses and the humor grows ever more dark (from your cumulative war stories and experience-based cynicism, it would seem). Still, many good and valid points are found here and its an important conversation for us to engage in if the BPX is still on trial and not yet swinging from the hangman's rope. Having lived through BPR failed initiatives that almost brought productivity of my kibbutz's thriving plastic injection mold business to a grinding halt back in the '90's and having worked on enormous projects in some very large and now derailed telcos in the late '90's, I actually can appreciate the candor, frustration and concerns expressed in the coffee space around what could be perceived as the next hyped fad and non-deliverable multiplier (heaven forbid).

And it seems that the "X" letter, as in eXpert, generates eXpectations that can easily be disappointed or inversely and worse perhaps, become a barrier to the very productivity gains that are the desired outcome, as Gareth points out: Fear them: Graduate BPXers running around waving certifications but clueless about the running of the business .... easily an organization's worst nightmare.

But what seems to me to be missing not only from the hype but even this conversation is the customer's endgame. What is the successful customer outcome sought in all this business "transformation"?

Consider a different view of what nurturing business process professionals could mean:

1) That rather than generating need for yet another expensive external hired resource, these "new breed" process-focused professionals can be internally evolved. I dare say that most "techies" exiting universities and entering the job force today will have had a good deal more business training and exposure than the computer scientists of the past. Of course, these newbies still lack experience and need time, mentoring and exposure to the business to become productive and make informed decisions and often that mentoring can come from external sources, but shouldn't the goal be autonomy? Aren't there folks suddenly realizing that they have the experience, the technological know-how and the business savvy to be filling the roles of business to IT liaisons?

2) In addition, think of this BPX community as a way of empowering former "code monkeys" (forgive the term) by helping them understand they need to ask and learn and know their business context as well as ensuring that technologists understand that they not only need to question the need for 2500 interfaces, they need to understand the context in which those interfaces exist. Take a look at what is happening in a number of forward thinking organizations that succeed in business transformations because they are able to nurture optimal cooperation between and amongst the geek/suit professionals that are their internal resources. What if the idea of creating a community of experts was a democratization of expertise. Simply put, empowering resources to be knowledge experts and to have access to tools, experiences, informed resources, that enable them to be more autonomous, better equipped, less "dependent" on external consultants. Shouldn't that be considered a desirable customer outcome and goal?

3) What if we evolved the means to "tell our own time", calculate our own ROIs within our own initiated BPI endeavors and be the owners of simplifying our own 2500 interfaces sans highly paid outsiders. Would not this be an outcome /"consummation devoutly to be wish'd "(also Bard), from the customer's perspective?

4) Perhaps, we are in the cusp of another evolutionary age that moves us from "agrarian" (nod to the sheep farmer and sheep), through industrial and on through information age to customer age. We are witnessing customer "impatience" and a feeling of service entitlement that is unmatched in history and probably irreversible. Doesn't that merit faster acceptance of better technologies and practices for customers?

Gareth writes: "I find the best approach to business process work is for the customer to engage with the consultants and drive their process themselves". Perhaps they will be better equipped to do so if they have access to others' experiences, challenges, successes, methods in the context of a community. I think that is a major goal for facilitating communication and interaction here.

One other aspect of the community which as yet has been untapped in BPX is access to the very forward thinking customers that Andre mentions when he writes: "At this point you got to be really lucky to work for a forward thinking and innovative customer or partner who wants to spend that kind of money developing solutions using SAP new concepts and technologies. Those are rare instances and hopefully we'll be able to find them. Actually I might this year ".

What if, participating in dialogue around illustrated stories of a BPX in action, such as a number of folks are attempting to do in the .<a href="https://wiki.sdn.sap.com/wiki/display/BPX/Community+Project">BPX Community Project]BPX Community Project</a> actually gave access to emerging customer thought leaders in organizations that <i>are</i> innovative? If one was looking for interesting and long term work, those might be the only kind of companies to consider.

Maybe we should start thinking of what things to share beyond documentation, as Andre suggests: "data flow, UI configuration, role determination our models and process flows". My impression in speaking to many customers at Sapphire and ASUG is that there are many folks who are not looking for an instant formula methodology with a certificate slapped on, but rather for access to others' leading practices and mentoring. Should we not broker or at least observe such idea exchange here?

Lastly, we see what happens when community-spirited innovators commit themselves to the sharing...they get invitations to imagineer with our emerging technology developers...that's not just a pretty wish, but an actual outcome.

So maybe there is hope that we can move beyond the hype to something tangible and worthwhile. I imagine there are many out there who aspire to be sitting where Ed and Dan sit and it was community interaction that brought them there

[former_member181923]

Hi Marilyn -

Good on you for taking the time to compose such a thoughtful contribution to this thread.

I'm going to respond in what I hope will be an equally thoughtful way, but as you may be aware, there's something that may see the light in the next few months, and I'd prefer to be able to reference it in my response.

Very best regards

djh

PS - Talila asked me what prompted me to join SDN to begin with, and I told her the truth, cause I'm always honest. So for better or worse - Tag! You're it!!!

[ChrisSolomon]

Sorry it took me a bit to respond David....been busy on project work and working from home (nice).

To your post....yep, I know what you mean. Over my years as a consultant, I have seen this more so in larger companies. I will be very clear not to generalize....it does not happen ALL the time, but does happen quite often.

A company will bring in some "dream team" to do all this "front end" work which supposedly will "ease and streamline" the actual implementation and is packaged with fanciful and vague names such as "strategy" or "process" or "consolidation" ("business process" just seems to be the latest trendy one...started seeing this about 3 years ago on an early BPM project for an oil company)

These teams will spend great amounts of time (billable time, that is, and as much as they can possibly get) and produce vast quanities of supposed "work product".

Then like the wind, the "dream team" declares their work done (against what measure?) and are off and out the door out to rescue another company from themselves. 😃

AND THEN....the folks left behind to actual DO the work have to figure out what, if anything, was done to help them. Sure the "dream team" produced what they agreed to, but what can be done with it? What is it held against? As David said "low-risk".

Again....not all consulting companies that offer these services are "getting over on their clients" (sadly, there are some out there that do), but I think often times those services are only necessary because a company is not in a position to do that "inner analysis" themselves either due to politics, culture, process, or whatever other obstacle. It is easier for them to fork out big money to have someone else come in and do that reflection for them.

Most of your bigger consulting firms will have entire practices around this work. Further still, there are consulting firms that do nothing BUT this kind of work.

*additional funny personal story:

I was on a project for a large company (@120,000 employees worldwide). The folks I worked with commented one day that they really liked my documentation and that it was thorough yet easy to understand. They said they especially liked that I used a lot of screenshots and pictures to show exactly what I meant. I was a bit taken aback and asked what they meant....I mean, using pictures/screenshots was groundbreaking?!?! Come on....they explained that they had a BIG consulting company in to lead the previous project. That consulting company also set the standards for project documentation and made a strict rule that NO picture/images could be used in documentation. ..."WHAT?!" I thought to myself...but then I figured it out...the saying goes a picture is worth a thousand words....if you have a bunch of billable consultants pounding out those thousands of words to describe what to do instead of showing it visually with a quick picture, that adds up to much more billable time. Pretty sneaky eh? My client and I had a good laugh over that.

[former_member181923]

Hi Chris -

You have no idea how much I appreciate the sanity check your post provides - really.

Yeah - what bothers me about "BPX" and all other bling coinages is that they are put out there by people with a perfectly straight-face, as if all of the rest of us have contracted Alzheimer's and don't remember the last three bling-coinages.

For example, I'm sure you remember "Business Process Re-Engineering" and the "BPR Diamond". The "diamond" was put out there as if it was some magical mystical symbol that held the answers to all mysteries - like the eye on top of the pyramind on the US dollar bill.

The first time I encountered the "diamond", I was writing the Data Migration section for what turned out to be a winning proposal for a very large systems integrator on a very large SAP ERP imp.

So I decided to be a little devilish and put a subsection in my prose on the "Data Migration Hyperbola".

On the one hand, I meant the "hyperbola" as a serious construct, because it helped illustrate how some as-is and to-be data points are quite close, while others are quite far apart.

On the other hand, of course, I meant the "hyperbola" as a sly tongue-in-cheek dig at the "hyperbolae" of the "diamond" - "hyperbolae" in the sense of "puffed-up" speech "full of sound and fury signifying nothing" (to borrow a phrase from the Bard).

A couple of people got the joke, including the Senior VP in charge of the proposal effort, and his deputy.

Below them, people were too scared to get it, for reasons we're all too familiar with.

Best regards, as usual

djh

[former_member181923]

Hi Stephen -

It's certainly related to the ploy used in the time-honored "by the lb" methodologies that you mention, and it's also related to the equally time-honored "butts and seats" methodlogies.

But sometimes, the "lb" and "butts and seats" methodologies aren't appropriate and something else has to happen.

This is the case when there is actually TOO MUCH work to be done, so it doesn't make sense to pad "up".

For example, suppose the systems integrator gets paid to deliver a working system in 18 mos. In those 18 mos, 2500 separate interfaces have to be developed which send various transactions to 250 logical receivers.

So to make the client believe that this is doable, several really high-paid "high-margin/low-risk" sharpshooters are brought in to convince management on both sides that there aren't 2500 separate interfaces but only 250.

And then, of course, when the sharpshooters leave, there are still 2500 interfaces to be done, not 250.

Regards

djh

[Former Member]

Hi Dave

I agree the danger is there that BPX will lead to the old adage of a consultant using your watch to tell you the time. Often we see the customer bring in a process expert who produces long and impressive documents which do nothing to assist in the development of a particular system but are referred to by management consistently in anwswer to just about any developer query.

There is a musician joke that drummers are unmusical people who like to hang out with musicians. I hope that BPX is not a way that untechnical people can hang out in IT.

Apologies to all drummers out there

Gareth.

[former_member181923]

Ya know Gareth - if I hadn't invested my inheritance in 40+ acres of mountaintop outside of Nashville 2 yrs ago, I'd love to come down there and work for you.

Because I can tell you do know "where it's at", and that kind of cynical knowledge born of bitter experience is unfortunately sadly lacking on most development projects.

Maybe I could telecommute - remember - I do know that stuff they still use down there pretty well.

Best regards

djh

[Former Member]

Hi Dave,

I think you'd like it. I live on 150 acres 50 miles outside of Canberra. Full satellite broadband but cannot get the customers to accept remote consulting......

The sheep give me insight into IT - one goes for a walk, the rest follow to see what's happening.

Cheers

Gareth

[stephenjohannes]

David,

Is this along the lines of "being paid by the pound(weight)" methodologies that have been used?

Take care,

Stephen