Procedures have a requirement for logical "order of presentation" to be maintained as in a causal chain. Processes, however, may be discussed (even including the logical relations inherent in the process) without necessarily adhering to a strict order of presentation. That's because the focus is on the "How to get it done," not the "What to do."

#2.
Please ignore this original comment on "sub-technical." The ITIL expert here at work just explained the meaning of sub-technical in ITIL. Clearly I am ignorant of ITIL. But I maintain the linguistic/phiosophical statements I made above are correct with regard to the distinctions between process and procedures.

The ITIL expert also stated that ITIL maintains a clear distinction between Processes, Procedures, and "Work instructions."

A policy describes the goal. A process describes the map. A procedure describes how one gets from one part of the map to the next.

In Incident Management, for example:
The policy is (too simply) that workarounds are to be found for incidents as quickly as needed.
The process is the flowchart that include Detection and Recording, Classification, etc.
An IM procedure is how to determine the urgency and the impact to come up with an incident's priority.

For reasons that can only be described as 'preverse' I am strangley attached to this thread, and of course, look it up when I visit the forum, much the way I would an old friend in a city far from home.

I am amazed it is still creating posts here in '08. I have the rather diconcerting feeling that the my words here may actually outlive me.

To add to the discussion now could have no constructive bennefit for those of you serious about nailing these wayward terms to a definition.

There is, however, a minor matter of my honour in the face of BD's assertion that I am a philosophical dilletante.

Delletante! Moi? Der ist sehr unhoflicher junger Mann/Frau!!

I have in fact undertaken both under and post-gradute studies in philosophy, and quite successfully). My majors were in ontology and metaphysics, with a focus on Hiedegger and post-Hiedeggarian thought. But before you dismiss me as a addle-brained phenomenologist, or worse a deconstructivist, I have also worked in the anglo-american tradition and of course classical Greek philosophy. (I admit to by-passing the 'school-men' but I always felt the likes of Aquinas were of more interest to theology.) On language I've ranged through Black, Whitehead, Chomsky, Whittgenstien, Foucault, and a whole lot more...

I no longer work in the field, but I have still an avid reader in the history of western thought and philosophy.

You may, dear sir, dissagree with your interlocutor, and marshal your best arguments. (For in doing so you challenge me to my best thought.) You should take care, however, not to confuse your opinions with knowledge my friend...for that is very bad philosophy. It is in fact a fallacy that also has a fancy latin name "Argumentum ad Hominem". (Basically: discredit the argument by discrediting its advocate.)

By the way, my 'sources' for the comments I posted in this thread are manifold, but a simple 'philosophical provenance' may be found in the works of Mark Johnson and George Lakhof. Whom provide excellent critiques of both 'subject-predicate' liguistics as well as 'object-attribute' metaphysics.

I am particularly fond of "Women, Fire and Dangerous Things: What Categories Reveal About the Mind". Also I highly recommend to you, Mark Johnson's work on Kant - It's lucid, insightful and in some places sublime.

Let us be practical. Forget synonyms and philosophy. The shades of meaning are vast and irrelevant.

What is required for each organization is a common understanding and consistent use of business terminology.

So make up your own minds and make it stick.

For me it has always been simple.

A process is something that is done.

A procedure is the prescriptive description of something to be done.

In other words procedure documents process prescriptively. By creating procedures you ensure consistency in the quality of process.

Just as processes are related to one another, procedures will have documented relationships. These can include sub-processes, work instructions etc. if you like.

I have used this approach for a long time and it stops a lot of wasted time because it renders the two as very different things.

For those still worried about meaning, you will find this distinction consistent with the definition of the two words in the Shorter Oxford English Dictionary._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

Can't resist this. The best definition of policy I have come up with is:

"A statement of principles, established within an organization, intended to influence and determine decisions, actions and other matters in relation to a defined purpose."

You cannot have meaningful policies until you have goals. Therefore policy does not describe goals; it is informed by goals and by other contexts relevant to the organization.

Policies are not strategies. Strategy is the defined means, consistent with policy, intended to achieve goals.

To give more context, procedures must address policy requirements as well as output requirements._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

You read through this thread more than once??? - That is some problem!!!

If you ever have a relapse, let us know and we will find some other interesting threads for you to try _________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718