EMC: Role of Process Improvement Methodology in BPM

Scott Francis
Next Post
Previous Post
I was surprised to run across this article from EMC/Documentum. It is a pretty thoughtful post about Process Improvement methodology and BPM.  It starts with a pretty good background proposition to set the tone:
BPM and PI share a common definition of the concept of process—“activities or tasks that produce a specific service or product for customers”—but from this common ground, their interests can go off in separate directions. In the ideal situation, they are synergistic, with an analytic, data-driven PI methodology identifying and building a sound business case for a BPM application while enabling a continuous improvement cycle driven by BPM transaction data. But it’s also possible for the methodologies to ignore each other’s roles or, worse, disparage each other’s value. This article examines the interaction for both synergies and contradictions.
Followed by a quick summary of origins, pinning process improvement’s history as far back as Henry Ford, with modern manifestations in TQM, Six Sigma, Lean, and Operational Excellence.  Whereas BPM’s origins are in IT, with a background in workflow, SOA, enterprise resource planning, and BI. Its a pretty good read, overall, especially if you aren’t already familiar with BPM.  The conclusion I find especially interesting:
So, why are we not more aware of the successes of a combined PI–BPM approach? Reviewing articles and blogs on the BPM side, there seems to be a developing interest (or at least an awareness) of sharing the process space with PI and an interest in learning how the methodology can add to BPM’s value. This is especially true among BAs who are responsible for understanding process and process design. Discussion of the value of PI training and certification is common. This interest may be a leading indicator of change, but for the present, much of this thinking is lost in the push for software delivery—“It’s out of scope,” or “We have to get this done now; we’ll fix it later.” In contrast, PI practitioners are more or less ignorant of BPM’s capabilities; at best, BPM is thought of as workflow. PI’s origins on the factory floor and its tradition of small, simple, incremental improvements sometimes do not translate easily to a complex back-office or case-management environment. Although basic principles of flow, pull, and stability remain the same, a literal U-shaped work cell may not be the answer; an understanding of its BPM equivalent may be. Disdain for or ignorance of software solutions—even a handoff of requirements—will not produce optimum future-state designs. Knowledge of BPM capabilities should be in the PI practitioner’s toolkit right along side Minitab and kanban cards.
At BP3, we’ve noticed the same opportunity, and the same disconnect – PI practitioners are often ignorant of BPM, or dismissive of any technology-enabled process improvement (despite the fact that they do use their own software tools to help do PI work…). At BP3 we look for opportunities to apply PI to our BPM projects, its almost a free boost to ROI (it requires minimal extra investment and yields better returns).

Tags: