Connie Moore's Blog

Today I’ve had the opportunity to speak at and attend a conference about Business Process Management for financial services.

Here’s what I’ve learned so far:

Process practitioners and BPM practitioners are still discovering each other. Although these two types of people are passionate about improving and transforming processes, they invariably come from different backgrounds and practices. Process practitioners typically have Six Sigma black belts and/or practice Lean, and they usually report into business operations or some C-suite business executive. Often, process practitioners do not have any experience in, knowledge about, and interest in BPM software. Conversely, many BPM practitioners work in IT, may report to a director of BPM or the CIO, and have found BPM software to be a powerful way to “modernize” IT and automate improved processes. These two kinds of people desperately need to meet each other, join forces and learn from one another, and ultimately end up in a BPM Center of Excellence together. Usually process practitioners get nervous whenever software creeps into the discussion, but this conference is different. It’s great to see both types of practitioners sharing experiences and figuring out how to work together in the future.

Interest in dynamic case management is high, but questions abound. Dynamic case management (DCM) is a powerful use case for BPM software and is raising the bar significantly for all BPM suite vendors. Dynamic case management allows an automated process to change in flight depending upon the situation and business rules. Many attendees have come to me and expressed both keen interest and some concerns. One attendee said that business managers at his firm are deeply concerned about the need to control the process and manage what their people do — and they are fearful of DCM. My response to him was that he should describe the controls that are built into DCM — including controls over who can change what. We believe DCM needs four things: 1) dynamic binding of process fragments, with a parent process instance defined; 2) a repository for storing documents; 3) a way to handle individual variation (task reassignment); and, 4) a way to selectively restrict changes (balancing control with worker flexibility). Another attendee told me that she sells DCM to the business by talking about all the exceptions they are able to handle in an un-automated process and then tells them all that flexibility will be added to the BPMS-powered process. In other words, the BPM software will not be a straightjacket.

Business process practitioners must drop the jargon. During a panel discussion, several attendees raised how to talk about BPM with business people. Most of the people asking this question were in the IT organization. The answer is: Drop the process talk; don’t show your process maps, but instead talk in business terms. My advice is 1) talk about financial results to the C-suite and the board — they do not care about the software, only the outcomes; 2) discuss business outcomes, business capabilities, and business services when talking with business managers and execs — the target operating model is your friend; and 3) describe and validate procedures and checklists when talking with business workers about how the process works — drop the process jargon and use their terms.

Next week I'm attending Process Excellence Europe in London, so I’m looking forward to more insights from the event. Here are some details about what’s planned:

Comments

Next week's Process Excellence conference is the premier BPM event in Europe. There will be live blogging throughout, and Forrester will lead a Tween Jam on April 24th at 10:10 eastern. Please join us for this social event.