Interesting !!Dan Woods is trying to compose a BPX Book with the help of SAP Community and then having another thought here. See Mark's comment on Intelligent Design Vs. Evolution approach. I wrote about it sometime back Perfection by Design and not Evolution. Is it Practical?
It seems Blogger's bug is catching me which forces you to reference your own old posts, even if it is as much related as Yahoo & Microsoft :)
But why is it 'Interesting'? Have you ever read any book which tries to answer 'Who is an ABAP Developer?' or 'About Java Programmer's Role' or even 'Who is a SAP Consultant' ? I doubt.
[ I hope I won't get a few amazon-links in the comments, telling these books do exist and I should buy one]
The BPX Book is to answer the question - 'Who is a BPX [ Business Process Expert ]?' and not about what is BPM [ Business Process Management ]? One reason for writing a Book about BPX is probably because clarification of the role seems to be equally/more important than the BPM technology available at the moment.
So who exactly is BPX apart from being the coolest super(wo)man of IT's new era. Is S/he real?
I am not trying to answer it, you better read and write ( if you want to ) the BPX Book.
I guess analysts at Gartner are better placed to draw the hype cycle of these SAP Community Buzzwords. However, I think 'Peak of Inflated Expectations' is still not reached for 'BPX'. So 'Trough of Disillusionment' is far away.
I can only write about some of my thoughts on BPX & Geek Gap [ That too might well have been contaminated by me reading a few related blogs / the Book ]:
eSOA & BPX?
May be IT is getting serious about shifting the power to the Business users. And eSOA is another step in the direction of shifting the software power to the Business side. The idea is that developers / consultants/ software makers will only provide the building blocks, in the form of services [ eSOA components ] along with the modelling/mashup tools. Optimists believe that someday these tools will be so
powerful and simple enough that business users will be able to model their complex business scenarios, all by themselves, and the (da-vinci-)code will be generated automatically. Till that time BPX is a stop gap arrangement.
Only issue – that gap could be rather huge.Also check SAP's announcement at SAPPHIRE® 2008 SAP Ushers In New Era for Business Process Management . Luckily, you don't need a telescope to see this Galaxy.
Geek Gap & BPX
Suddenly you may find that all the problems & failures of IT projects are being attributed to this ‘Geek gap’. To an extent that you might wonder if it is actually a black hole. Till now, bad project management was responsible for most of the failed projects but now it’s Geek gap. For example, see SAP Network Blog: Geek Gap Kills the Handheld Census by the authors of a book called The Geek Gap.In my opinion, failures due to incompetent requirement determination by Business users or a poor solution provided by unskilled developer/consultant, should not be considered as Geek Gap. It covers only the problems encountered due to difference in the mindset of business users and technology consultants.
For example: A Business user asks for 'Time Display' along side the customer data display of the Interaction Software. The intention being - it will help in greeting their customers [ Good Morning , evening etc. ]. Developer thought it's easy and provided the system time alongside the customer data. Next day, customers in different time zones are amused, if not angry.
That's Geek Gap. BPX is a promise to bridge that Geek Gap.
If the developer would have even slight inclination to understand the business needs, S/he would understand that the time should be displayed as per customer's time zone. At the same time, if users understand that developers may not have the background knowledge then they will take extra care in communicating the requirement.
However, if the business user never really thought about the need of displaying time alongside customer-data and still expects that the specified software will be able to serve the 'Greeting' need then it's a failure to determine the requirement and can't be termed as Geek Gap.
I thought of a few more points but only the headings at the moment:
Difference between (Techno)Functional Consultant & BPX
[ BPX's ability to understand the Business process of an organization (Industry Vertical) while Functional Consultants is more into Horizontals ( across industry ) like Finance , Purchasing etc. ]
Web2.0 ( collaboration ) and BPX
[ I don't see this skill as specific to the BPX role. In the long run everyone will need this. However, BPX can be the initiator for the change ]
BPX - All-rounder or Split Personality [ Sometimes Netweaver is accused of the split personality disorder due to Java & ABAP stacks. But that's technology. People can't assume the personality disorder so easily. They have to be an all-rounder unless they had the disorder even before]
I will probably write a Part II , if required.
Posts
Perhaps it's a matter of definition. To us, faulty requirements are very definitely a Geek Gap issue.
ReplyDeleteThe Geek Gap is defined as a communications breakdown and culture clash between business and IT that exists in most organizations. The failure to properly think through requirements is a very common effect of that culture clash.
Writing good requirements means thinking logically, planning for all possible contingencies, and understanding that creating technology means figuring out how to solve a problem--in other words, thinking like a geek.
Most suits don't naturally think in those terms. They think things like "Hey, it would be neat if the greeting screen showed the time." Then they want someone to make it happen for them. They don't want to spend the time or mental energy figuring out details like time zones.
Bringing these two points of view into some kind of sync, so they can work together effectively is what bridging the gap is about--and it requires adjustments on both sides.
Minda Zetlin
co-author
The Geek Gap
Hi Minda,
ReplyDeleteThanks for your comment and sorry for my late response.
- X sends an email to Y but Y didn't get it [ Gap ]
- X didn't send an email to Y but Y got it :) [ Still some kind of a Gap ]
- X sends an email to Y and he gets it. [no gap ]
- X does not send email to Y so Y didn't get it. [Still no gap ]
So if the suits could not determine the business requirement itself and didn't even try to communicate it to the Geeks and that resulted in Geeks not getting it - well then there is no geek gap here. It’s incompetency.
As you said
"To us, faulty requirements are very definitely a Geek Gap issue."
Well I disagree - all faulty requirements are not due to geek gap. Most of the cases are due to incompetent people ( geeks or/and suits ) + ineffective requirement determination process + bad management, planning & execution + so many other factors.
The way I see Geek Gap
- It's a gap between a competent Geek and a competent Business user/analyst due to the difference in their mentality, thought process and background.
- It's not a gap between an incompetent geek and / or an incompetent suit. That gap is due to incompetency and cannot be termed as geek gap. BPX's role is not to bridge the gap due to incompetency.
- Communication gap between geeks and suits is not a cause of geek gap. Actually communication gap occurs because of the geek gap [ it's a result of the difference in mentality ].
- Geek gap is the case when both of them seems to be right [ as assessed by their respective communities ] but still the requirements could not be fulfilled.
[In my example of ‘Greeting requirement’, Suits will wonder why the geeks could not understand, despite being given a clear requirement. And Geeks will consider this as un-clear requirement. And that’s why this scenario represents the real Geek Gap]
- Learn from each other. Easier said than done.
- At the best it can be minimized by cross-skilling or cross-environment exposure however it cannot be eradicated completely. Further, skilling Geeks to act like suits or vice versa may not be the most effective or economical solution. Hence other options like Agile methodology or BPX/techno-functional as a bridge is needed to minimise the gap. Still we will keep on discovering Geek gaps during user acceptance testing but hopefully the new strategy will be able to minimise the damage.
Thanks again,
Ram
The important thing is we both agree that in the case you describe, where a greeting was added but forgot to account for time zones, the Geek Gap was indeed at fault.
ReplyDeleteThere certainly is a big difference between the Geek Gap and general incompetence! But, depending on the nature of the organization and the job, being unable to write (or help write) good requirements may not be an indication of incompetence, because it may not be the core function of someone's job.
Imagine a sales manager whose main responsibility is to oversee a sales team and make sure they meet quotas. That sales manager may be called on to help write requirements and she may not do a good job, but that does not make her incompetent in general. Same for someone on the geek side whose primary responsibility is to write code.
There are so many complaints about this issue on both sides. Geeks complain that suits don't give them detailed enough information about what's needed. Suits complain that geeks expect them to know too many details.
In an ideal world, there would be a BPX person--what we call a go-between--working with both who *is* expert at crafting requirements and can make sure they say what they need to.
Best,
Minda