Process Vs Procedure

[afka]

Process - a logically related series of activities conducted toward a defined objective

Procedure - a description of logically related activities, and who carries them out

They are not synonyms. The most important thing is, that procedure description is always role-related.

Process description gives us the overall set of procedures (main tasks). Description of the procedure (of one main task) explains how we do this and who is doing what.

Example. Your incident management process can have procedures like this:

- incident/call registration
- incident resolution
- incident tracking
- complaint handling
- incident closure
etc.etc.

In every procedure you will explain, how it works, who is doing what and in which order. Incident closure - what steps are made specialist, what is doing service desk agent etc

[rjp]

Hmmm, another vote from the sound-bite society


To reply adequatley to your plea for brevity, I have to go back to the summer of '67. I remember it well because my sisters were arguing over who broke the Sally-I-really-wet-my-pants doll, and that mean we were too late to get to the screening of Mary Poppins we were going to that afternoon. To this day I still dont understand what the torn up note was about...anyway where was I. Oh yes, it was a very hot summer, the kind of skin shrivelling hot you get in Melbourne from time to time around mid January. The wind blows a gale down from the deserts up north and everything withers and the tar on the streets starts to melt. It was finally decided that my older sister was going to take the blame - which wasn't strictly fair becasue I happened to know that my younger sister ripped out Sally's arm with a par of monkey-grip pliers playing Spanish Inquisition in the garden shed. Sally, to her credit did not recant here heresy - my memory is a little hazy but I think ols Sal after being pressed into a lacivious game of hump-the-ken-doll had declared herself to be a Menonite - which was a red rag to a bull for my God is optional Anglican sister - who wasn't going to have any fanatical holier than thou toys in her collection. I fear the irony of my sister's actions was lost on one so young at the time. Well, I could have made the movie I guess - but I didn't want to be a snitch.....

[Ninja]

First I'd like to say "RJP: you go boy!" ('course you could just as easily be a girl!). Long or short or pithy your posts reflect your obvious expertise, knowledge and thoughtfulness. And I read all your posts on this debate, sometimes twice, to try to understand what you were trying to convey!

I too apologize for coming so late into this discussion but I simply cannot resist. A few weeks ago I asked one of our resident ITIL experts some questions and referred to processes and procedures in what she thought was a rather cavalier interchangeable way. She indignantly corrected me that the two were quite different. Cowed and humbled I believed her...until now.

In an effort to understand the difference then, and as a requirement for some of my own work deliverables, I happened upon this site as part of my information gathering. Now, thanks to you all, I feel better armed to enter into a battle about the so-called differences should such a last resort become necessary.

As it turns out RJP is quite right in advising a flexibility of mind about this matter and the dictionary backs him up. The words "process" and "procedure" can and do often mean the same thing. To wit:

"process: a...phenomenon marked by gradual changes that lead toward a particular result; ...a series of actions or operations conducing to an end..."

"procedure: a particular way of accomplishing something or of acting;...a series of steps followed in a regular definite order..." and mysteriously self-referentially and recursively: "...a step in a procedure..."

These are from the Merriam-Webster and my head spins.

So those of you, myself included, who want neat little answers to make our lives easier, it just isn't going to happen. So I'm going back to using them interchangeably or based on how my manager of the day wants me to refer to them. (I'll be ok if he/she wants me to view a process literally as a box and a procedure as the written words that break down the steps associated within that box - which is often my professional experience!)

[itilimp]

Hmm, I managed to miss this post first time around... an interesting one which I've argued with myself about in the past.

Coming from a technical support / documentation angle rather than ITIL, I tend to talk about and work with policies, processes, procedures, and tasks.

Policies - top level strategic
Processes - high level concrete objectives (normally shown as a flow chart)
Procedures - make up an individual process (normally shown as a flow chart). Serves as a reminder for the order to do things in for those with the technical skills to do so without further documentation.
Tasks - the actual steps required to complete a procedure step by step (i.e. instructions normally shown as a numbered list). Tend to use these as initial training materials and detailed documentation.

So in our setup:

Incident Management is a process including:
- Lifecycle of a call (showing the incident management process flowchart)
- Call investigation (procedure - flowchart)
- Call escalation (procedure - flowchart)
- Call resolution (procedure - flowchart)
The latter 3 include links from task boxes to word documents that form the actual tasks, e.g. change the status of a call, close call (including checks etc.)

Does anyone else use the terms in this way or am I on my own here?

[rjp]

Despite being partially to blame for this thread I cannot but laugh

Jsut to muddy the waters further - I often use the term 'protocol' when defining er, um... shall we say... 'stepwise sequences of actions'.

Cheers.

[itilimp]

LOL.. protocol? Oh boy... we're a confused bunch!

[Ed]

Itilimp

I'm with you all the way - I suspect RJP has his tongue firmly in his cheek at this point

I also agree with him that this is an argument that no-one can win

Regards

Ed

[matrejekm]

Hello,

After reading this thread I would like to turn to solution:

process = general overview with STEPs listed
procedure = separate describtion to each process' step

I think this is a matter of our individual taxonomy.

Regards,

[billiamian]

Hi folks, Thought I'd weigh in on this ontological diatribe.

Etymologically speaking, sure, both "process" and "procedure"
derive from the same Latin root,
but then again, both "shirt" and "skirt"
derive from some Germanic/Gothic "scirt".
These clearly, at least in my eyes, are not synonymous.

Hats off to itilimp for proffering -

policies
processes
procedures
tasks

I guess you could continue to granularize (atom, et al.)
but it's a slippery slope,
and semantic antagonists
will always look to split quarks.

While there seems to be some level of consensus,
cult of industry seems to result in each faction
wanting to affirm its own retronym -
be it ITU, ISO, TMF, COBIT, BPML, or the AFLCIO.

I'm a lowly cleric in the church of telecom
(I guess you could tell from my accent).
Y'all're ITIL folk - have you no repository
of some standard definitions in your denomination?
No high council issuing decrees decrying definitives?

Anyone? Anyone? Bueller?

[JoePearson]

This is an interesting thread, and since it's been bumped from history a couple of times already I feel happy doing it again.

So far we have policy, process, procedure, and task.

Shame on you all. No one has mentioned the favourite at the company I used to work for: work instruction. And while 'sub-process' has already been mentioned, some of you must have come across the macro process.

So now we have the utterly ridiculous hierarchy: policy, macro process process, sub-process, procedure, work instruction, and task.

In trying to make sense of this we can first ignore policy because that's not the same kind of thing - policies address rules and requirements, not what or how. What's left is two similar kinds of things:

• the simple, prescriptive list of steps to be taken by one person - each step is a task; the list is a work instruction document. Some people would call this a procedure, but almost never a process.
  
• a flow of steps/activities/things that may have decision points, probably involves multiple people or teams, and where some of the steps need further breakdown to be fully understood. This is a process, and often when people talk about procedures they mean the same thing.
  

The thing that often gets ignored is that any process can be broken down (decomposed) into sub-processes - including the sub-processes themselves. If you've worked with Business Process Modelling you may recognise this. And also many processes (including ITIL processes) are in some ways part of larger processes, all the way up to "make profits" at the top of the business. There's no hard and fast limit to how many levels you may need, so when someone says 'a procedure is a sub-process' it's asking for trouble.

I think that's enough from me for now!

Joe

[Fabien]

Waaah I missed this post all the way til today. I think Itilimp has it right. While semantically the terms can be argued to be synonyms, in practice, they are not and they are commonly used to model repeatable series of actions at different levels. For me, the level is procedure = employee, process = management.

Is there a brilliant mind in the room that can summarize all that has been said and present it to the ITIL Refresh group?
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek

[Myturn]

Then what's the difference between procedures and "work instructions"

[dboylan]

The difference between a Procedure and a Work Instruction is the level of detail. A Procedure may say "Enter RFC ticket" where a Work Instruction would be "Double click on the Change Management Icon. Log in with your AD login name/password. Click on the New Ticket button. Enter the required fields..."

A Procedure should be able to executed by someone knowledgeable in the area that the Procedure applies. A Work Instruction is something you can give a new hire who has never performed the sequence of steps before.

[dumbgrunt]

Perhaps one more try is in order. I stumbled across this post while searching for those elusive definitions. Seems quite a few folks struggle with this and where you work and what your role is has an impact. For my use, I define as follows:
Process - the 30K foot gigh-level view. A simple flowchart that lays out the main items to be accomplished. For instance, A Change Mgt process may simply reflect Initiate Chg Rqst > Create RFC > Scope and Assessment > Approval and Planning > Implement > Close. No decision points, no "if..then" statements.

A procedure, on the other hand, contains more detail. It considers the decision points along the path and also adds roles It may look more like Initiate Chg Request > Submit RFC to Change Supervisor > Change Supervisor detemines Classification (Emergency, Normal, Routine) > If Emergency, then xxx / If normal, then yyy / If routine, then zzz.

The Work Instruction takes each step of the procedure and further defines the "how-to". How do I initiate a Change Request? How do I submit the Change Request to the Change Supervisor? etc.

Thanks for allowing me to add my two-cents.

[BD]

I'm a "newbie" to ITIL, as rjp would say. But rjp is apparently a newbie to philosophy, or what we in philosophy like to call a dilettante (or "dabbler.") Some corrections are in order:

1. Synonyms is not necessarily equivalences between words, they are often equivalences between words (and/or phrases) in a given context. Thus I can say, "What does that cost?" and equate that to the expression "how much does that cost?" without claiming that "what" and "how" are synonyms. The equivalency is not between "what" and "how," it is between "what does that cost?" and "how much does that cost?" If you doubt that what and how are not atomically synonymous, look them up. Here is the entry for "how" at thesaurus.com. Note that "what" appears only as part of a serious of phrases which are synonymous with the word "how":

Synonyms: according to what, after what precedent, by means of, by virtue of what, by what means, by what method, by whose help, from what source, through what agency, through what medium, to what degree, whence, whereby, wherewith.

2. "Sub-technical" is apparently not a word found in an English dictionary, but a compound word (just recently?) coined by rjp. In any case it is composed of a real word plus the prefix "sub." Sub- does not mean "less," so "sub-technical" cannot mean "less technical" as rjp seems to suggest. Here are the meanings of the prefix sub:

a. under, beneath (examples: subterranean, submarine)
b. subsidiary, secondary (example: subplot)
c. almost, nearly (example: subhuman)

So, unless sub-technical has some specific meaning in ITIL (I'm a newbie there, remember) I have to class this term as techno-babble.

3. In philosophy we have a type of counter argument we like to call reductio ad absurdum (reduction to absurdity.) It works by supplying one counter-example (to an argument) which all reasonable people will recognize as an absurd statement. Here is a counterexample for the what-how conflation:

"How was rjp thinking? Is he serious? What can he believe such a ridiculous thing?"

...sound silly? That's because it is. Clearly "what" and "how" are not interchangeable words, any more than "process" and "procedure" are.

4. teejnar has figured it out. Process and procedure are not synonymous (not linguistically at any rate.) They represent two perspectives on the same conceptual entity. They are indeed the "what" and the "how" of a goal oriented activity. But since any goal that is not conceptually atomic can be broken into intermediate goals (or what we in philosophy would call intermediate "ends") each intermediate goal/end can be described in turn as a process or a procedure depending on whether we focus on the "what" or the "how."
Thus the "what" of "get ready for work" can be recapitulated as a "how to" "get ready for work" (i.e., as a procedure.) (Notice that we have a supporting preposition, "to," in this context. Even in this simple example one word is not substituted for one other word.) And each step in the "how to" (or procedure) can in it's turn be rendered as a "what we will do," which in it's turn is broken down into a "how to do it." It's not simply a reduction of a whole to it's parts, however; but, rather, a transformation of a "what to do" (the goal itself, in all it's goal-oriented nuances) to a means to do it. Thus, in Aristotelian philosophy an intermediate end (goal) may be a means to another end (intermediate or final) but the goal, as a goal (i.e., qua goal) is not a means , per se.

The regression is not infinite, however, since eventually one reaches an atomic concept where the "what" cannot be reduced any further, at which point the "how to" becomes a meaningless question. Who, for example, would attempt to reduce the concept of "being" to a procedure. And yet it is an atomic process (i.e., something that changes) about which scores of philosophical works have been written. (See "Ontology" which is never about "procedure.")