What Techniques Should a Process Methodology Support?

A few days ago, I posted a blog entry on Case Management.  That article stimulated a friend to make a comment, and in passing, remark that they didn't include Decision Management (or Business Rules) in process, but left it to IT, and would probably do the same with Case Management.

I disagreed, and wrote him, as follows:  The question, it seems to me, relates directly to the role of the Business Process analyst or manager.  I believe that BPM should be the basis for a broad understanding of an organization.   I imagine, in an ideal world, a room with a large overview of the process architecture of the organization.  The major value chains and level 1 processes would all be shown with links between those processes and key stakeholders, and perhaps with key measures of success.  Close by would be more detailed maps that showed the subprocesses within the major processes, and which used annotations to show which processes depended primarily on people and which depended on automated systems.  In addition, the maps would show processes that were essentially procedural in nature and those that involved decisions.  To my mind these are basic things that the senior management team ought to know.  Major changes require that the management team consider these things and make decisions accordingly.  To not show where major bodies of knowledge were required and used to make important decisions would be to seriously undermine one's understanding of the organization.

In other words, I believe process people — the people who create and maintain the high level process maps for the organization — the business architecture if you prefer — should be familiar with where knowledge needs to me maintained and where that knowledge is applied to make decisions.  That doesn't mean I think that process people ought to structure knowledge bases or formalize business rules.  I'm quite happy to let IT specialists do that, if that's how your organization prefers.   In a similar way, I think the high level business map of the organization ought to show where major software applications are used, and where major databases are maintained.  That doesn't mean I think process people ought to create software applications or maintain databases.  But they ought to be aware of them.  Without being aware, how can they truly understand the business processes, or identify where problems are likely to occur, or where work will need to be focused if the organization decides to change its processes.

I know that lots of organizations believe in a much more limited role for business process people, but I think they cheat themselves when they do that.  Process people ought to maintain the broadest and best integrated map of the working of the organization.  Failing that, your process people aren't prepared to provide the kind of support which they provide in well-run, process-focused organizations.