Process Vs Procedure

[tdc]

Hi All,

Can anyone tell me what the difference is between a "Process" and a "Procedure"? We've just had a lively debate about it in our office, because I am trying to document our Incident Management Process (or is it procedure?) for the first time. Despite lots of plausible sounding suggestions, I am still not sure that we've got it right.

Many thanks
tdc

[blamblam]

This is how it works for me:

A process is a series of steps, tasks or activities that converts inputs to a desirable output, i.e. a process is what will be done. I present the process as a diagram.

A procedure is a specific course of action required to achieve each of the process stapes, tasks or activities, i.e. how it will be done and who will do it. A procedure details to the process. I present the procedures as a table that includes the process step along with the roles engaged in that step using the ARCI model.

The process sits over the procedure. Sitting over them both are organisational policies... but that's another story.

[tdc]

Thanks for your help. That's made it much clearer!

[Aussie FF]

Hi Newbie

I was looking on the web for the difference between process and procedure as well for the purpose of identifying our Incident Management Process as well. Are you interested in discussing this?

[rjp]

I'm actually quite intrigued by this one

I've had a chat with a few folk in my corner of the ITIL world - and the consensus is: they're synonyms.

Technical domains do frequently require sub-technical definitions for words with 'common' meanings in non-technical contexts. But the process / procedure distinction is not significant enough to require such a definition.

The ITIL books use the terms interchangeably (most likely reflecting more the personal style of the authors of specific sections than some subtle nuance of meaning).

Of course processes / procedures require qualifications from time to time to dsitinguish a global or 'abstract' process from a specific one. But ordinary qualifications and modifiers would be adequate to the task.

[tdc]

The plot thickens!

In the case that process and procedure are synonyms, should one develop two procedures?
The first possibly for very high level viewing (no detail, the sort of process that can be supplied to a customer in a service definition document), and the second one at a very detailed level for employees to follow.

I am not sure that our customers would be interested in a blow-by-blow account of how we resolve their incidents, but they do want to know the basic process that we follow.

Would these two processes be known as anything different (other than summary and detail)?

[rjp]

Would they be known as anything different?

Well I have frequently seen the term 'sub-process' used - even used it myself on occasion.

Processes are (like a squillion other things) recursive. Structurally they can be self-same. And big complicated processes can be broken down into simpler processes, which may in turn be broken down...etc.

Formally there are 'atoms': Inputs, Actions, Decisions, Outputs, etc. But when turning the real world into your process model, it is often the case that if you were insane enough you could break these down also. For example: An 'action' defined as 'update client contact details' - could be written as a process. But why would you if the action is clearly going to make sense as an action. (UI engineers on the other hand may have a good reason to break this down into a formally defined process).

So it is entirely appropriate to abstract (simplify) your prcoess model appropriate to the context in which it will be communicated. The abstraction should remove detail, without altering the 'meaning' of remaining description. Just like a flow-chart where you use 'procedure' boxes to refer to other flow-charts. In an SLA you do this in a narrative or outline format, like a nested list with only the top levels showing.

Another more specifically ITIL factor in deciding what to 'expose' to your customers / end-user is the requirement for customer facing (i.e., their context, not ours) descriptions of service deliverables. There is no requirement to publish the internal processes you use to meet your agreements with the customer. That would violate the KIS principle.

[tralfamadorian]

Process = WHAT we do
Procedure = HOW we do it
My Quality Manager says it's as simple as that...

[rjp]

Sorry but that is disingenuous. 'What' and 'how' are also synonyms - which in English is quite common.

Eg.....

A: Build me a house. What do I do? Well, first you buy some land, then you...

B: Build me a house. How do I do that? Well, first you buy some land, then you...

Unless by 'what' you mean the objectives of a Process - in which case you are now using 'Process' rather idiosyncratically' as kind of a reverse synecdoche, where the whole is representing one of it's parts: and not, I think, in the way it is intended in the ITIL books.

Sub-technical stipulations of concepts such as you described are actaully very important for clarity, and I am sure that your quality manager has provided value by providing one in your context.

But they actaully don't pull much semantic wieght in an open context. The test of this is to reverse the terms in the narrow context and see what happens. So if your quality manager had said:

Procedure = What we do.
Process = How we do it.

It would mean the same thing - and you would derrive the same semantic (and operational) value - because that comes from the sub-technical distinction itself - not the placement of the terms and definitions.

So he isn't wrong. You can't be wrong when you stipulate in this way. But while you can use available synonyms to stipulate sub-technical concepts, you can't regeneralise back from the stipulation to alter the meaning of the concept on which it was based.

Occam's razor:

[LizGallacher]

I could not disagree more. Process and Procedure are NOT synonyms. How and What are most certainly not synonyms either!
Example
Proces - Pay credit card bill
Procedure - Log on to internet banking, go to correct account, select recipient, enter amount to be paid etc.
_________________
Liz Gallacher,
ITIL EXPERT
Accredited ITIL and ISO/IEC20000 Trainer and Consultant - Freelance

[tralfamadorian]

rjp, I presented your arguments to my QM and asked him to come up with a better distinction.
His reply was basically the same as the distinction presented by blamblam earlier in this string: A Process is a series of steps, a Procedure is a specific course of action required to complete one of these steps.
You might then argue that there is no distinction between "a step" and "a course of action". Following the example presented by Liz Gallacher, you could argue:
1) that logging on to internet banking might be considered a process, as it is a series of steps (turning on your PC, entering the URL, entering logon ID and password)
2) that paying a credit card bill might be considered a procedure, i.e. a specific course of action required to complete one of the steps in the process called "bookkeeping".
In other words, what some people think of as a process, is a procedure for other people. I realized that this morning: I think of "get dressed" as a procedure that is part of the "get ready to go to work" process, my 7-year-old think of "put on shirt" as a procedure that is part of the "get dressed" process, and my 2-year-old think of "put left arm in left sleeve" as a procedure that is part of the "put on shirt" process.
But the fact that the same thing is considered a process by some and a procedure by others, does not mean that the two concepts are synonymous.
How about these pragmatic definitions:
Procedures are what you hand out to the people who should do the actual work. They tell them how they should do it.
Processes are what you hand out to managers and supervisors. They tell them what their staff are doing.
I know that these definitions will not survive academical scrutiny, but I guess that no attempt to make a clear process/procedure distinction will.

[rjp]

Hello again. Let me start by saying this is the last post I'll make for this topic - after all this is an ITIL forum, not a Linguistic Philosophy forum.

The underlying intention on my comments to date is quite simple:

It is not helpful (to newbies in particular) to extending site specific, sub-technical stipulations that differentiate the meanings of the terms 'process' and 'procedure' to assertions about the public meanings of those terms in an ITIL/business process context.

When someone asks what is the difference between a process and a procedure (in a business activity context) - the answer remains: There is not enough difference to think that 'ITIL compliance' is dependent on understanding the difference. It isn't.

ITIL has enough sub-technical (and therefore counter-intuitive) definitions to be getting on with. Eg., the difference between incidents and problems. No need to add more.

Note that I did acknowledge the value within a specific organisation of leveraging 'synonyms' to further clarify and detail practices in one's own work place. I only 'objected', and gently I think, to the assumption that such 'definitions' were applicable to all usages of the terms.

WRT to the issue of whether 'process' and 'procedure' are synonyms, which seems to vex some folk, it is worth noting that 'synonym' relationships are not blunt equivalences between two sets of definitions.

Synonyms are word pairs where one may be substituted for another in the same sentence with no alteration of the intention of the sentence. So while 'what' and 'how' are synonyms - as the equivalence of the sentences in my example demonstrates, they do not have exactly the same definitions as words. Moreover synonym pairs are not always symmetrical: 'What' is frequently used as a synonym for 'how', but 'how' does not work very well as a synonym for 'what'. (There are a lot of strained arguments waiting for those who think of synonyms as definition equivalence ).

In common usage 'process' and 'procedure' have some core differences: Process has a central concept of a 'material change', directed to the object undergoing the change. So we talk of some thing being processed. Procedure is more focused on indicating the actions of the agent effecting the change. So where these ideas are in play the terms are not 'very' synonymous. And the alternative opinions expressed in this thread are obviously drawing on those differences.

On the other hand they share the same base concept of describing an ordered sequence of events that change something from one state to another in a consistent and repeatable manner. (More formally: they are based on the same Idealised Cognitive Model.) Where 'process' or 'procedure' is used declaratively - in a 'what is it' statement, they are effectively synonyms.

This is backed up by common usage in relevant parts of the business community. The Business Process Modeling Initiative, for example, did not find it necessary to define 'procedure' in the BPML (Business Process Modeling Language). It allows processes to be broken down to whatever level of detail you require by defining sub-processes. And this means professional business analysts are out there using the word 'process' to describe what those of you taking exception to my 'argument' would call 'procedures'.

So everything that needs to be defined in order to specify processes down to the finest level of detail, can be defined without recourse to an alternative term for process. Which means that such differences as there are between the words 'process' and 'procedure' are not significant in a business activity context.

And in the end, not worth getting hung up on, or arguing over.

Still, it was fun

[tralfamadorian]

rjp, re your two concluding remarks: I couldn't agree more.
Let's see if we can find an appropriate time and place and let's have a Linguistic Philosophy Showdown

[teejnar]

Hi, am joining the debate a little late, but it is an interesting one....

Could we say that when we reach a point when an action doesn't need to be explained further, we have a procedure?

Eg. The process for throwing a party is:

1. Make a guest list
2. Send out invites
3. Arrange for catering
4. Arrange for music
5. Get dressed and wait for the guests to arrive

To execute each of these steps, you need a procedure. Lets take step 2. "Send out invites" and break it up:

2.1 Buy invitation cards
2.2 Write the invitee's name on it
2.3 Put it in an envelope
2.4 Put the invitee's address on the envelope
2.5 Post the envelope

Now, if a normal person who knows the meaning of 'invitation card', 'write', 'envelope' and the rest of it, she does not need any further explanation. So here we have a procedure. The smallest step in the process which can be executed by the user of the process.

I think one can only decide on what constitutes a process and what constitutes a procedure in the context of the user and not as standalone concepts. Does that make sense?

Cheers,

[Roger]

I vote rjp as the "poster" capable of providing the absolutely longest answers.

Now I'm sure that there is some really good information from rjp; but I am afraid anything that can't be written in simple language loses my interest quickly.

c'mon rjp shorten it up as I want to learn more from you !