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.
Hi Sandy,
You have chosen my favorite topic: process documentation.
Regarding who should own procedures and policies, I believe procedures should belong to the operational areas and Legal should review them to make sure everything matches well. Detailed procedures that describe how tasks are to be executed should be owned by someone with experience on field work and higher level procedures describing end to end cross-department processes should be owned by someone with a complete understanding of the whole process and all the functions involved (as well as authority if possible).
I believe that BPMS process descriptions in any format (maps, BPEL files, etc…) are aimed primarily at machines (IE, a process engine), while procedures are aimed at humans. A BPMS process description requires a formal structured style while a procedure requires a less formal one (the ultimate objective is that people consulting it understand how the process should be carried out).
You are 100% right with your comments about synchronization and publishing. From my experience this is always an issue when organizations work with procedures and policies in MS Word format, where no traceability exists and making sure that changes are notified to all interested parties is almost impossible.
I am working on the concept of “structured process description” which streamlines synchronization and publishing. At my company, we have created a procedure documentation software called metoCube that implements this vision.
(Sandy, feel free to delete this last paragraph if you don’t want commercial products to be referenced in the comments)
We carried on our on internal discussion on the topic that I sharing with you:
Maybe I am all wet, but this should not be that difficult. If we were a bakery:
– Policy may say that we will only bake whole grain bread.
– Procedure would tell us exactly how to prepare the dough to make whole grain bread.
– Process would be what happens to the whole grain bread in the oven without further intervention (until we open the door as per the procedure – ‘when the oven buzzes, open the door and remove the bread’).
– Rules would be the rules of physics and chemistry that control what happens to the bread in the oven. These rules do not change, thus ensuring consistency.
So, in our technology world:
– Policy may say that we will only buy HP DL Series servers.
– Procedure would tell us exactly how to initiate the request to get a new HP DL series server.
– Process would be what happens to the request once you hit submit.
– Rules could be the rules that you may be breaking (too little memory, to many processors, etc.) by trying to buy the server, causing the process to fail (or take some exception flow). These rules may change from time to time, but should ensure consistency of process.
In the technology world example, what is a process to you may be a procedure to someone else, like the someone that potentially has to follow the procedure to create an order to initiate HP’s fulfillment process.
I am not sure that I agree that a process is always customer centric. The customer (whoever that may be) surely gets considered along the way, but I would not put the customer at the center of the process. I also agree with Jim that policy is set by many more people than just legal and compliance. Just in our world we set policy around Arch Reviews without necessarily involving legal. I think policy should be set and enforced wherever appropriate, and sometimes that may well be legal and compliance.
Actually, I think I spotted a weakness in Ms. Kemsley’s post that Denny also did not comment on. Ms. Kemsley spends a great deal of time talking about how companies tend to conflate policies and procedures, then hand them both of to Legal and Compliance as if that’s all that has to be done. Clearly, as both she and Denny point out, that’s a serious mistake in several ways.
Policies describe the “what” that needs to be done. Legal should get a voice and a vote in determining what policies are appropriate for running a business. However, Legal is most definitely not the only unit that should be responsible for creating policy. There are far too many factors that require expertise in several areas.
Procedures are normally considered to be the “how” things get done to meet policy. As Denny and Ms. Kemsley rightly point out, there is generally a governing body of some sort responsible for overseeing that procedures are properly defined. If I understand Denny’s analysis correctly, he is assuming that there should be much more automation in achieving this goal than Ms. Kemsley makes allowances for. If I’m correct, I think I see why there is come confusion. DD>> Actually, I was in a big hurry so I just cherry picked two parts of her email to start a discussion, i.e. I did not fully analysis the email in its entirety. The two parts I cherry picked were (1) “… I see policies as the rules, or laws, of an organization, whereas the procedures are the processes used to enact the policies….” where I took exception to the phrase “…policies as the rules…”, which seems to equate policies with rules, which I disagree with, and (2) I wanted to take a shot at answering the question she posed on polices vis-a-vis procedures: “What’s the distinction between a policy and a procedure?”.
However, there’s a second mistake that I think a lot of companies make that Ms. Kemsley misses. It’s a mistake that I think we’re all guilty of at times.
Many people, including myself, tend to treat “process” and “procedure” as synonyms, but they’re really not. DD>> Indeed. That’s a big mistake, which is why I decided to bite on that question. Merriam-Webster’s second definition of a process calls it “a series of actions or operations conducing to an end; especially : a continuous operation or treatment especially in manufacture”. By contrast, a procedure is defined as “a particular way of accomplishing something or of acting” or “a set of instructions for a computer that has a name by which it can be called into action.”
In other words, a process can be automated (especially if it runs continuously). A procedure can describe how a process works, although it can also describe a stand-alone set of steps that occur infrequently or even just once. DD>> But processes and procedures are both subject to automation. The key distinction is that a process is customer-centric. I my last email, I spoke of the distinction between policies and procedures to answer the question posed by Sandy. I don’t recall addressing the distinction between processes and procedures, which is –> How vs. What vs. Why: As stated in my previous email, a procedure focuses on “how” to accomplish a task or reach a goal (procedures sometimes involve an explicit or implicit reference to the “what” or result of the procedure and sometimes even the “why” but procedures are often stand-alone and are rarely closed-loop, customer-centric structures) whereas a process encapsulates the “how”, the “what” and the “why”. The “how” of a process is represented by the activity work breakdown structures that pull inputs, push outputs, etc. The “what” of a process are the results of the process, i.e. the customer deliverables that are linked to customer requirements, in a closed-loop. The “why” of a process are again the customer deliverables that are linked to customer requirements. One might ask: Why is the “what” the same as the “why”? This is the beauty of a process, i.e. processes are designed in such a way that “what” a process does provides its own justification, i.e. producing customer deliverables that meet customer requirements within a GRC context is its own justification. This is the power of the process concept that few “process” people appear to grasp. This is a subtle but important distinction that I think frequently gets lost when discussing policies, procedures, and processes in a common context.
With that distinction in mind, I’m tentatively treating Denny’s description of a BPM/BRE model as the procedure which can describe the process by which we are supposed to operate. A truly solid governance model would then verify two things. First, that a BPM/BRE model correctly described a solution which met existing policies DD>> …and customer requirements, i.e. customer requirements are the center of the universe but customer requirements must always be met within the context of a GRC framework and associated GRC policies. GRC policies include enterprise policies (e.g. risk management policies) and procedures as well as regulatory policies (e.g. GLBA mandated privacy). Notice I didn’t say “regulatory procedures” because these often do not exist and in any case there’s a broad trend towards outcome- and/or principles-based regulation vs. rule- or procedure-based regulation. Second, that the processes were actually being followed regardless of whether or not they were automated.
Basic, obvious stuff, I know. However, as Ms. Kemsley points out, companies get it wrong all the time. Sometimes it pays to revisit the obvious. 🙂 DD>> Sandy is right to shine a light on these issues but I think they must be addressed in a more rigorous way, which includes precisely defining terms, alignment (where it makes sense) with common use of terms in the industry, linking these terms to relevant industry standards, etc. Cheers, Denny
Sandy Kemsley posted the following message on her blog (www.column2.com) today. I feel she raises some very good questions about the intersection of business rules(policy) and business process. It appears that this intersection is much like a cloud, when you’re in the cloud there’s not much to get a hold of and manipulate. Your comments on this topic are welcome!!
Mark, thanks for sharing your internal email thread on this, I’d love to hear any follow-up on this.
could you write examples of policy , procedure and rule ?
I am currently reviewing the 6th Edition of the PMBOK Guide, which has some Project Management specific definitions regarding policies, processes, procedures and rules. As the definitions I found within the PMBOK sometimes use the words being defined as part of the definition, I adjusted them after reviewing multiple online sources (including this one) as well as reviewing Webster’s New Universal Unabridged Dictionary, Copyright 1996. The definitions I came up with, based on the above material, as well as from my own experience in the areas of education, law and project management are as follows:
POLICY – A set of basic principles that govern an organization’s conduct through a structured pattern of actions
PROCESS – A systematic series of activities or actions directed towards causing an end result such that one or more inputs will be acted upon to create one or more outputs
PROCEDURE – An established course of action for accomplishing a consistent performance or result that is consists of a sequence of steps that will be used to execute a process or action
RULE – Explicit or understood law, regulation or known principle governing conduct or actions within a particular activity or sphere; things that can or must be done or things that cannot or must not be done