As you may have already read here, I believe the creation and maintenance of BPPs could be a critically valuable and instructive step towards effective, human-centric BPM and business knowledge management (BKM). Several of you have e-mailed your general agreement. However, more than a few of you have expressed curiosity, if not confusion, over what information belongs in a BPP, and how best to capture, create, and organize that information.
I'm about to utter words that industry analysts, consultants, and pundits have avoided, and users and vendors have suspected and frequently longed to hear, for decades. Those words are "I don't know."
Or, to be more precise, "I'm not sure. It depends." (Ahhh – comfortable territory once more.)
To elaborate a bit, below is a list of basic elements that belong in any BPP that's going to provide any significant business value. These are not necessarily listed in any particular order of importance.
• Name of Process
• Owner(s)
• Key Contributors and Affected/Supported Constituencies (including specific people, groups, and lines of business, in order of importance or criticality where possible)
• Supported and Supporting Business and IT Activities, Processes, and Services
• Required and Affected Intellectual Property (IP) Resources (including access information and restrictions)
• Relevant Compliance, Governance, and Risk Considerations (in order of importance or criticality where possible)
• Relevant Effectiveness Metrics (as determined by relevant IT and business decision-makers)
• Recommended/Required Assessment Method(s) and Frequency/Frequencies
• Historical Performance Assessment Efforts and Results
I stand by the above list of BPP element recommendations. However, I also assert that it is beyond my knowledge, and my ability to deliver value to those who ask, for me to go much beyond those recommendations.
That's because while many businesses have processes in common, they often express those processes using different taxonomies and vocabularies. For any BPM-related initiative to deliver maximum value, it has got to be integrated and harmonized with how the business does business now. And this goes as far as the words used to define and document processes and their interconnections with other elements of the business and IT infrastructures.
One company's "customer" is another's "client." One company's "sale" is another's "order." One company's "shipment" is another's "fulfillment." Multiply these differences too many times, and they make clear communication and consensus impossible. And that makes success with BPM and/or BKM impossible.
At many enterprises, the first successful steps toward creating useful BPPs will be in achieving consensus regarding the very terms and rules used to define and describe the processes to be managed. And the processes used to accomplish these tasks must themselves be submitted to the same scrutiny as other processes, to maximize consistency, repeatability, and scalability.
And of course, there needs to be agreement about how all of this is to be captured and stored, and how access to it is managed, to maximize that value of that information. And the processes used to make those determinations should themselves be captured and documented, just in case anyone might want to use them again, or refine them.
[This is now officially one of those times where you who work at larger enterprises can freely envy your counterparts at small and mid-sized businesses. Those smaller companies may have fewer resources to throw at such problems, but I bet their people have to endure far fewer meetings to make decisions.]
If you have or can find recent examples of tools used to profile or describe other business or IT infrastructure elements at your company, by all means, try to adapt these to your BPP-building purposes. However, I'd be skeptical of any purported template or format that promised much more than greater detail focused on areas such as those I have outlined here previously. Remember, your enterprise's goals and processes are unique – just like every other enterprise's.
Reactions, suggestions, or other tangentially related thoughts? Please share them, by posting comments here or e-mailing me. Let's see where this goes...
Michael Dortch has been an analyst, 'information entrepreneur,' speaker, and writer about IT and 'the real world" for the past 30 years. After almost 10 years at the Robert Frances Group (RFG), Michael begins a new position with Aberdeen Group in September.
Dennis Byron is an analyst with ebizQ, focusing on Open Source Software as well as Business Process Management technologies.
