Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: AhmedMoor
New Today: 39
New Yesterday: 83
Overall: 141561

People Online:
Visitors: 45
Members: 1
Total: 46 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Process Vs Procedure
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Process Vs Procedure
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Related Topics
View previous topic :: View next topic  
Author Message
tdc
Newbie
Newbie


Joined: Aug 17, 2005
Posts: 3
Location: UK

PostPosted: Thu Aug 18, 2005 9:17 pm    Post subject: Process Vs Procedure Reply with quote

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
Back to top
View user's profile
blamblam
Itiler


Joined: Jan 16, 2005
Posts: 37
Location: New Zealand

PostPosted: Fri Aug 19, 2005 11:14 am    Post subject: Reply with quote

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.
Back to top
View user's profile Visit poster's website
tdc
Newbie
Newbie


Joined: Aug 17, 2005
Posts: 3
Location: UK

PostPosted: Sat Aug 20, 2005 1:55 am    Post subject: Reply with quote

Thanks for your help. That's made it much clearer!
Back to top
View user's profile
Aussie FF
Guest





PostPosted: Wed Aug 31, 2005 9:19 pm    Post subject: Incident Managment Reply with quote

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?
Back to top
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Wed Aug 31, 2005 11:55 pm    Post subject: Reply with quote

I'm actually quite intrigued by this one Confused

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.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
tdc
Newbie
Newbie


Joined: Aug 17, 2005
Posts: 3
Location: UK

PostPosted: Thu Sep 01, 2005 6:29 pm    Post subject: Reply with quote

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)?
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Fri Sep 02, 2005 11:22 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
tralfamadorian
Newbie
Newbie


Joined: Sep 02, 2005
Posts: 5
Location: Denmark

PostPosted: Fri Sep 02, 2005 9:06 pm    Post subject: Reply with quote

Process = WHAT we do
Procedure = HOW we do it
My Quality Manager says it's as simple as that...
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Sat Sep 03, 2005 1:28 am    Post subject: Reply with quote

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:
Quote:
One should not increase, beyond what is necessary, the number of entities required to explain anything.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
LizGallacher
Senior Itiler


Joined: Aug 31, 2005
Posts: 550
Location: UK

PostPosted: Tue Sep 06, 2005 6:19 pm    Post subject: Process v Procedure Reply with quote

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
Back to top
View user's profile Send e-mail Visit poster's website
tralfamadorian
Newbie
Newbie


Joined: Sep 02, 2005
Posts: 5
Location: Denmark

PostPosted: Wed Sep 07, 2005 7:08 pm    Post subject: Reply with quote

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.
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Thu Sep 08, 2005 11:42 am    Post subject: Reply with quote

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 Smile ).

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 Smile
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
tralfamadorian
Newbie
Newbie


Joined: Sep 02, 2005
Posts: 5
Location: Denmark

PostPosted: Thu Sep 08, 2005 6:25 pm    Post subject: Reply with quote

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 Wink
Back to top
View user's profile
teejnar
Guest





PostPosted: Fri Nov 11, 2005 6:28 am    Post subject: Process vs. procedure Reply with quote

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,
Back to top
Roger
Itiler


Joined: Aug 02, 2004
Posts: 35

PostPosted: Wed Nov 23, 2005 10:10 pm    Post subject: Reply with quote

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 !
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Related Topics All times are GMT + 10 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.