You may have noticed that I haven’t been blogging for the first two days of the IRM BPM conference here in London: that’s because I gave a 1/2-day seminar on the BPM technology landscape on Monday, then presented a session on collaboration and BPM yesterday morning, then moderated a roundtable on transforming process models to IT requirements yesterday afternoon. Last night, a small group of us had dinner at the lovely Institute of Directors club, where we had a fascinating conversation about all things related to BPM – off the record, of course. 🙂
This morning, we started the day with Roger Burlton, the conference organizer, interviewing Keith Harrison-Broninski about the future of work. Keith, who I first met at the BPMG conference here in London four years ago, created the theory of Human Interaction Management (HIM), with the idea that you start with the complex human relationships – strategy, goals and deliverables – and work your way out to the transactional stuff. In other words, get a handle on the collaborative human-to-human processes first, with no technology involved, then use the successes in that sort of process improvement to gain support for the greater funding and time commitments required for implementing a BPMS. When Roger said that HIM sounds a lot like project management, Keith replied that project management is a use case of HIM.
Keith comes across as a bit of an old-school technophobe: he pooh-poohs blogging, tweeting and all other social media, and (based on his involvement in my roundtable yesterday afternoon) considers BPMS implementations to take much too long and cost too much although he appears to have little practical experience with any modern-day model-driven BPMS. Ignoring that, he does have some interesting ideas that get back to the definition of BPM that we all give lip service to, but often ignore: the management practice of improving processes, separate from the technology. This is about knowledge work, however, not routine work, where people are given goals and deliverables and work out how to achieve those based on their own knowledge. He refers to these as information-based processes, and everything that could be represented by a process model as task-based processes, where these mundane task-based processes are merely programs (in the software sense) to be implemented with much time and effort by the lowly engineers and developers. The answer to all this, of course, is his software, HumanEdj, and the workshops and services that he provides to help you implement it.
An interesting discussion, showing some of the huge gaps that exist in BPM today, especially between how we deal with knowledge work versus routine work.
Hi Sandy
Not sure why you think I “appear to have little practical experience with any modern-day model-driven BPMS”, since HIMS projects often require a BPMS for the transactional work, and I’ve used BPMS tech extensively. In fact, part of the initial advice I give to organizations interested in HIM is that they may well also need a BPMS in the end.
It’s horses for courses, isn’t it. In IT as in all fields, you need a judicious combination of tools to get a job done effectively and efficiently. For example, I don’t “pooh pooh” social media – and have been blogging for years – but I do observe that used without a HIMS, social tech in the workplace results mainly in people frittering away time on unstructured activity, out of which you are not guaranteed any useful results. Sometimes, yes, value may arise, but it’s a complete lottery, in which I wouldn’t bet on there being any ROI. If I was a social media vendor, I would be anticipating the day when organizations start blocking access to my Web site, and planning for it by building a larger platform that includes a HIMS.
Part of my message is that to realize the potential value of social media, BPM, ACM, ECM and other enterprise tech, you need a HIMS at the top. Otherwise it’s empowerment without a means of negotiating (and continually re-negotiating) shared goals – in other words, anarchy, which may be fun but isn’t going to deliver step changes in productivity, lift the world out of a recession, and put an end to the depressingly poor performance we’ve come to expect from public bodies responsible for healthcare, law enforcement, education, social services, and so on.
All the best
Keith
Keith, I know that you’ve used tech extensively; that’s why it’s so puzzling that you appear to have little understanding of the current crop of model-driven BPM systems. I don’t think that these systems are perfect, but I do think that you can implement in far less than the 12-month timeframe that you claim is required for any standard BPM implementation.
It’s common for vendors to become somewhat fixated on your own solution and ignore all others; as the ever-relevant xkcd comic stated today, “when all you have is a pair of bolt cutters and a bottle of vodka, everything looks like the lock on the door of Wolf Blitzer’s boathouse”. Although I believe that your methodology and tools have merit, I also believe that there are many other capable products out there that can implement a BPM solution in far less time than you believe: HIMS isn’t the only way to get to a solution.
Sandy, the reason it’s puzzling that I “appear to have little understanding of the current crop of model-driven BPM systems” is that it’s not true.
For example, I have never said that “a 12-month timeframe is required for any standard BPM implementation”. What I do say is that BPM projects typically last several months, which is more and more unacceptable compared to the “Internet speed” of making other things happen in business. To young people, BPM must look like their Grandad’s way of getting things done 😉
I’m not blaming this on the tools, by the way, which as you say are getting better all the time. BPM projects take so long because the underlying approach requires careful planning. There are 3 reasons for this.
First, most BPM projects are integration projects, requiring Web services to be orchestrated. This is a non-trivial exercise that requires IT expertise and an engineering approach.
Second, most BPM processes are automated or semi-automated – i.e., you define processes once then run them many times relatively unattended. This means you need to ensure that the processes are correct before releasing them into the wild – run an incorrect transactional process enough times and you’ll be out of business. Further, BPMS deployment typically relies on simulation to quality assure processes, which is more long-winded than the formal testing techniques available to programmers.
Third, BPM tools generally depict processes as flowcharts, in BPMN or some other such notation. These are hard to draw in real-time – typically a process analyst brainstorms with business people, then goes away to turn the results into a diagram, then circulates the diagram for review, then repeats all this until agreement is reached. This in itself is very time-consuming compared to the HIMS approach, in which end-users can define and agree Stages, Roles and deliverables themselves during a meeting.
HIMS isn’t exactly “the only way to get to a solution”. However, a HIMS is part of an optimal solution. There was general agreement on this in the ACM Mentor Camp panel (http://bit.ly/acm-panel), which included key figures from leading BPM/ACM vendors such as Keith Swenson of Fujitsu and Dana Khoyi of Global 360.
Yes, I was puzzled that you appear that way, too, given what I know of your background.