Most of my customers are large financial institutions, and I help them to select and implement BPM within their organizations. The technology is only one part of that, however: I’m almost always helping them with their business processes as well. Since policies and procedures drive processes, I often end up in the thick of their policies and procedures, and that’s where the confusion starts.
First of all, there’s the definition of terms. What’s the difference between a policy and a procedure, when many people lump them together as if PoliciesAndProcedures were one word? I like this definition:
Policy is a mandate and directive from the top of the organization. Its purpose is to influence behaviour. From it, management provide the overarching principles under which the business operates. It should not vary in its message or enforcement model.
Procedures are process specific and detail the steps taken to achieve an objective. Procedures include operations manual, user manual, and all manner of process documentation.
I see policies as the rules, or laws, of an organization, whereas the procedures are the processes used to enact the policies. The problem is, however, that many companies see policies and procedures as belonging to the Legal/Compliance department, and create another set of processes — usually referred to as an "operational guide" — that are created and maintained by the operational area that executes the actual processes. If you throw in a BPMS, then some (but rarely all) of these operational procedures may be further documented in the process descriptions within the BPMS or a BPA tool.
What’s the distinction between a policy and a procedure? Is there a difference between a procedure and the operational description of a business process? What about between the business process and the process model in a BPMS?
Secondly, there’s the responsibility issue that I referred to above: who’s responsible for each of these essential bits of corporate documentation? Legal/Compliance is almost always handed policies and procedures, but what about the case when the procedures are actually descriptions the operational business processes? Should policies be left with Legal, and procedures given to the operational areas, with Compliance there to make sure that everything matches up? Or are the operational process descriptions a separate, more fine-grained version of the procedures, leaving the procedures with Legal and the operational processes with Operations?
If process maps are created within a BPMS, do they become part of the business process documentation, replace part of it, or stay as a separate "implementation view" of the processes? I’ve definitely seen cases where the process maps in a BPMS bear little resemblance to what the business perceives as its processes, either due to limitations in the BPMS environment or to the business having an incomplete view of the process.
And if there’s four separate types of documentation — policies, procedures, business processes and BPMS process definitions — who’s responsible for keeping them all in synch?
Third is the whole technology issue: how is all of this information captured, published and synchronized? There are a tools such as RulesArts and RuleBurst (both of which I saw last week at the Business Rules Forum) that help to capture policies as high-level non-executable rules — an approach that makes more sense than just trying to document them free-form in a word processor while praying for consistency. Check out the Flash demo on the RuleBurst site to see what this can look like. Some of this systems are also business rules engines, that is, they execute the rules and can be called from other applications; some are just platforms for non-technical users to document policies, detect gaps and exceptions, and help to ensure compliance.
As we move into procedures, operational guides and process definitions, it’s all about processes. Processes based on rules (and what process isn’t?), but processes nonetheless. Those organizations documenting their policies in a word processor are likely also documenting their procedures in the same way — in fact, possibly in the same document — using descriptive text and a few diagrams. At some level of detail, someone starts drawing process maps, although these are usually as illustrations to the descriptive text rather than a replacement for it.
The two biggest issues in all of this technology are synchronization (usually manual, and therefore almost certainly out of date) and publishing (ditto). From the synchronization standpoint, there needs to be something that links the policies (rules) with the various granularities of process descriptions (both text and graphical) and either keeps them in synch or alerts someone when related pieces are modified. For publication, none of this information is of any use unless it’s in the hands of the people who need it; that means that there needs to be an easy (or automated) way for all of this information to be published within an enterprise and accessed with nothing more than a browser and network authentication.
What starts to become shockingly apparent as you dig into the technology is that policies are about rules, and procedures are about processes. Yeah, I know, I said that at the start of this post, but it’s not just some abstract concept, it’s about how you need to document and implement policies and procedures. The crux of the issue is in the crossover from rules to process, since a rule (policy) usually doesn’t dictate the operational procedure required to enact it, hence there’s not a clear technology path to map from policies to procedures. If policies are maintained in a high-level rule repository and procedures are maintained in some combination of descriptive text and process maps, what’s the missing link between them?
Policy and procedure documentation is just one place where business rules and business processes intersect (they touch again at the point of process execution), and I’m interested in exploring the ideas around this. I’ve put forward more questions than answers — feel free to join the conversation by commenting on this post, tracking back from your own post, or dropping me an email.