On Spreadsheets, Clean Handoffs, and a Dinner Bet
July 11th, 2006
A frenzy of recent blogger activity around the question of whether the business people who do “modeling” can really build executable processes, by analogy with the spreadsheet. Keith Swenson says absolutely, David Ogren and Jesper Joergensen of BEA echo right on, and Phil Ayres is a lonely voice of dissent. I come down squarely on the Keith/David/Jesper side. A key point — that with the right tool, business folks can do things we used to consign to programmers — is accepted at some level by everyone. But taking the spreadsheet analogy too far — as Phil does – gets us off the track.
In the BPMS world, the debate is really between the clean-handoff vision and the collaborative tool vision. The clean handoff says business does modeling, IT does design, and anything that blurs that separation is inherently dangerous. (In fact, even directly creating skeleton design from the model is somewhat distasteful, but don’t worry, IT can change it later…) The collaborative vision says the line between modeling and design is a fine one and blurring rapidly. They’re really the same thing, and share a common tool, with users layering on different levels of specification. This is essentially the old Third Wave idea, the new BPM 2.0 idea put forth by myself and Ismael, and in my view the ultimate winner of the dispute. Ogren sums it up in one line: “The process model is the implementation.”
Are we there yet? Maybe, maybe not. That’s what the famous dinner bet was all about. Stay tuned.
Entry Filed under: BPM
11 Comments Add your own
1. phil_ayres | July 11th, 2006 at 5:54 pm
Bruce,
Fair enough comment on your part. Business users who do modeling should absolutely be able to produce executable processes (with appropriate control around the review, versioning and deployment enforced by the tool). The modeling tools should encourage and enable that goal. Therefore my voice of dissent will be refined a little…
It is my understanding that ‘modeling’ is a skill that not every business user will have, but once acquired should be fairly transferable to any particular BPM modeling tool. A customer services supervisor (for example) who has learnt to model the processes she owns can probably pick up many modeling tools. But she does not have to have the modeling skills to do her day to day job.
On the other hand, this customer services supervisor probably did not have to learn a completely new set of skills to start (or need) to use a spreadsheet. She picked it up one day to help her find the mean call length for each of her staff.
Business modeling is a skill that not every business owner needs, or can in fact perform, despite the evident need to improve their processes. Only those with the mental aptitude to model processes and improve them will be able to pick up the tools, model and produce executable processes. The barrier to entry is higher than that of a spreadsheet, however good the vendors make the tools.
So if you pick the right business owners that can model processes I absolutely agree that they can build executable processes. Those who can’t model processes may still have the skills to run their teams very effectively, so perhaps should be supported by dedicated process analysts.
Does that sound better?
Phil
2. bruce | July 11th, 2006 at 6:10 pm
Phil,
I think we’re getting to the heart of the matter. When I talk about “the business” doing modeling, design, or anything else in BPM, I don’t mean any Joe Blow hanging around the water cooler. I mean business people whose job it is to do these things, with some amount of training in the tool and methodology, and certainly knowledge of the business process and its objectives… but not trained as a programmer or technical specialist. But I wouldn’t rely on Joe’s spreadsheet either…
Nobody’s trying to say anyone who can load up an ipod should be designing executable processes.
–Bruce
3. IT|Redux » Why we N&hellip | July 11th, 2006 at 7:02 pm
[...] Last but not least, I will report progress on the BPMS Challenge. Bruce Silver is running with it as official referee, and I got his assurance that he will thoroughly investigate the claims made by a couple of vendors who believe they won the challenge. Knowing the products in competition, I must express very serious doubts about it, but I would love to be proven wrong, as long as the game remains fair, and I trust Bruce that it will. In the meantime, Intalio is actively working on its product in order to participate to the challenge later this year. [...]
4. phil_ayres | July 12th, 2006 at 6:17 am
Bruce,
Thanks for letting me clarify where I stand on the users that can and can not build executable processes. I agree with the concept that the “process model is the implementation”, with a little control to prevent a three step: “model, save, go-live”
As I also wanted to extend my discussion of how spreadsheets really are used for modeling business processes, and are ripe for improvement by the business users as you suggest, here is a link to my post for the day. Its a little out of scope of your original discussion, but relevant for anyone that was confused my post yesterday!
Cheers
Phil
5. Stefan Farestam | July 12th, 2006 at 5:49 pm
I think the discussion of whether or not a business person can design a process model that can be executed is misdirected. The really important point is that when the abstraction level used during a business level discussion of a process matches the abstraction level used in the actual implementation, then the feedback loop (between business process owners and engineering) becomes very rapid and much less room is left for implementation mistakes. It also means that any process metrics that is captured is likely to make sense and be reliable.
6. bruce | July 12th, 2006 at 6:10 pm
Stefan,
I think your “really important point” is a good one, whether the issue of business-driven implementation is misdirected or not. Since I see from your email you are a Tibco person, is there anything in your tools or methodology that encourages this abstraction alignment?
–Bruce
7. Stefan Farestam | July 13th, 2006 at 7:00 pm
Bruce,
It’s a good question. Does TIBCO’s tools support the proper level of abstraction and is the abstraction aligned with business users? I would say they do, but needless to say I’m partial. For BPM to be effective though, you need to provide properly abstracted models on multiple levels so that business process owners need not be concerned with low level implementation details. I think that’s where the “rubber hits the road” in terms of being successful with SOA and BPM.
8. Derek Miers | July 17th, 2006 at 2:22 am
When you thuink about it, most spreadsheets used by people have some sort of “business process” model about them. Even the cash flow I have been working on assumes an implicit process model.
Have to say that I think that the essential ingredient is for buisiness people to understand their processes (which is somewhat different from model them at an appropriate level for process execution). The problem is that most people involved in this industry (wrongly) assume that a single procedural view of activity icons strung toogether is sufficient to allow people to step outside of the “way things get done around here”, allowing them to see the process for what it is. As I have said many times, the business person needs contrasting views of how work happens - not just a single simplistic view (a la BPMN), but also the interactions that occur between roles (how the roles change state and how these affect the way the process unfolds), how the thing moving through the process changes state (as a result of the actions and interactions that occur).
Having understood the process, it is then possible to identify the 20% of the process that should be initially implemented (tgiving 80% of the value), leaving the rest to iterative development. It is also a relatively simple exercise to implement this 20% on the chosen BPMS by someone who is trained to do it (whether that be a biz person, a biz analyst or an IT Developer).
The development of those high-level contrasting views of the process should be time-boxed (to a matter of a few weeks) to ensure that people dont get lost in the weeds. It is my firm belief that this understanding phase should be entirely separate from the implementation phase … i.e. dont think about translating those models onto the BPMS, by definition 80% of it is wrong anyway or at least irrelevant going forward
9. BPMS Watch » One No&hellip | July 18th, 2006 at 2:31 pm
[...] Paul Harmon of BPTrends weighs in on a worthy topic, how many perspectives do we need to describe a business process? He acknowledges that while “alternative approaches” like Role Activity Diagrams or the Flores-Winograd interaction model used by Action Technologies are useful in special cases, most of the time it would be better to standardize on a more conventional workflow perspective such as BPMN or UML Activity Diagrams. Sandy Kemsley expresses her agreement, while Derek Miers (in comments on BPMS Watch) has expressed the opposite view. [...]
10. ECM-BPM Corner » Ar&hellip | July 20th, 2006 at 4:40 am
[...] Le sujet a été en fait initié par Keith Swenson, et repris depuis par Phil Ayres, Jesper Joergensen, et même Bruce Silver, sur leurs blogs respectifs. Sandy elle n’a pas encore réagi, mais elle me semble bien occupée ces jours-ci . [...]
11. tombaeyens | July 26th, 2006 at 3:52 am
I’m not sure the two visions are that far apart. I see the clean handoff as an extension to the collaborative vision: http://jboss.org/jbossBlog/blog/tbaeyens/2006/07/26/Clean_handoff_Collaboration_and_Pluggable_Process_Constructs.txt
Leave a Comment
You must be logged in to post a comment.
Trackback this post | Subscribe to the comments via RSS Feed