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!!

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)

Sandy had a great post this week – Policies, procedures, processes and rules - where she discusses some of the very real challenges in managing new ways of documenting our businesses. If we use business rules and process maps to say…