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.