On and off I’ve run across Business Process Management - the descendent of Business Process Re-Engineering. Earlier this year I did a little work with a SAP team who wanted to be Agile, and a few weeks I was at the BPM conference in London.
What was noticeable at the BPM conference was both how dependent on IT it is, and how many of the techniques used by BPM practitioners look like IT techniques, specifically, the practices in software development.
Whenever I encounter BPM - or when I looked at BPR years ago - I get this feeling that it is an attempt to apply software development methodologies to the corporation. The BPM folks seem to regard the corporation as a machine to be programmed.
Processes are the sub-routines. These are programmed and linked together. Processes are re-usable - at least in theory. Under taking BPM seems to involve analysis, design and implementation (but no testing, strangely.) It sounds like Waterfall software development.
BPM folks want to create “the agile business.” They are talking the language of Agile and borrowing a few techniques. I even met a company at the BPM conference who have their own proprietary BPM process which looks, sounds and smells like Scrum.
Which leads me to ask: Is BPM just programming at the corporate level?
I think BPM folk would reject this suggestion simply because they view “programming” as dirty, cheap, low-end work for unwashed young people. What they do is expensive, strategic and practiced by ex-programmers (who would prefer not to talk about the past).
The other reason I think BPM people would rush to reject the idea of programming is because - as they are always keen to tell you - the software systems they use are not programmed. They may be configured or they may be customized. In the extreme you might write a customer module (or rather pay someone else to).
But, as all programmers know: programming is not just about code and its not just procedural. The configuration and customization are a form of programming. Some of the configuration tables in SAP look like table driven programming to me - not unlike a Turning machine, actually.
Now the BIG irony....
BPM folk are keen to talk about end-to-end activities and processes. Yet getting BPM tools - I’m thinking of SAP specifically - to do something means working with functional specialists who know their module and little else. An SAP Finance person would never think of working on SAP HR, an SAP HR person would never work on SAP Logistics.
A standard techniques in Agile teams is to have people work on difference parts of the system to do end-to-end. But this seems to be one thing SAP people can’t do. Ironic isn’t it, the people who advocate end-to-end processes can’t do it themselves.
Allan
ReplyDeleteThere is indeed the idea to regard the organization as a programmable. While the customization <> programming argument is idiotic as you rightly point out, there is a crucial difference between a program and a process. BPM people often, though not always, take "end-to-end" further than some programmers in that they regard human involvement as conceptually the same as machine activity, merely a different means to an end.
A person knowledgeable in HR may not tread on FI/CO turf just as well as a Java person may not tread on the DB2 admin's turf. It is a matter of project context and configuration management in how far you diverge from it. SAP is a 3rd party application with APIs, release schedule and upgrade policies just as well as Eclipse is to developers delivering extensions to the platform. You don't see too many developers using RCP that have much of a clue of the inner workings of OSGI or the compiler or syntax coloring frameworks. The reason to stick to this model and the somewhat implied though never *required* separation of duties is economical, not organizational or personal. There is no implied restriction on SAP people that they can't work on different modules - it's just too darn risky to have them do that, just as well as you would normally not have all your team tamper with the complete details of Eclipse.
This is the one place where I have found a *real* difference between the, classical you may say, agile/XP/... understanding of the word "agile" and the BPM/SAP folks is the picture of human beings and testing. Agility in the BPM context, as I see it, is most often understood as "agile in execution on top of" but not "agile in changing." A corporation is considered agile if it can rapidly execute the routine parts of its operations, hence react quickly in higher-level activities. However, it does not mean rapidly changing these routine parts, and that is something where the classical interpretation perhaps adds a richer view.
But again, I don't regard this as a product-specific property. SAP is, for example, just as open as Eclipse or any custom-made Java product. You can re-code all the ABAP there is, but don't expect too much the next time a release upgrade comes along.
Hence, I think you are interpreting "end-to-end" and "agile" in a way that was never intended by these folks, but that also does not really matter. The perhaps implied view that the grunting, bearded SAP trolls are not able to be agile is more a function of semantics and perception than one of ability. As we all know, once the scale of the problem (and indeed I'd argue that FI/CO is well beyond the scale of Eclipse) goes out of hand, it is hard to stay agile. But that is not something that one should take against them.
Hans