ITIL V3 and eTOM, the rapprochement begins
Following on from ITIL V3's after-the-fact attempts to link up with external standards such as ASL and ISO20000 (something one thought might have happened as part of the design and development of ITIL V3 rather than as a retrospective scrabble) we have eTOM.
Many readers will not be aware that the telecoms industry has had its own operational guidance for many years, eTOM. if you thought ITIL is aloof, it has nothing on eTOM. True to the proprietary and invent-it-here spirit of the telco industry eTOM has always been off on its own over there.
As the digital onslaught has finally conquered telecoms and dragged the telcos back onto standard platforms with standard systems, suddenly eTOM has shown an interest in ITIL.
But not necessarily a deep knowledge of it. Apparently ITIL is an "ISO/IEC international standard".
Everyone is being very polite and focused on the positive:
ITIL and the Business Process Framework are not in conflict; they are, in fact, complementary. Each possesses strengths that support the other.
A method by which ITIL and Business Process Framework can interwork has been developed, and is demonstrated through a series of worked examples.
Through this method, and worked examples, it has become clear that the scopes of ITIL and Business Process Framework overlap, but that they can work together successfully.
Reading between these lines I smell a similar situation to ASL: polite separation due to irreconcilable differences. Those of you who are eTOM registered users can access the draft of the paper. If either of you get it, I'd be interested to see a copy.
Just like COBIT/ITIL, the rest of us shall just have to wait.
Made in New Zealand 
Comments
For those interested in eTOM
For those interested in eTOM more there are some resources on TMForum website: http://www.tmforum.org/browse.aspx?catID=1647 However as eTOM has became part of ITU standandards it can be downloaded freely(!) from their site. It is available as ITU-R M.3050 series at http://www.itu.int - just search for eTOM.
I wouldn't be so skeptical in this case
I saw a webinar hosted by both TMForum and ITSMFi. One of the conclusions was to change/update some terms in eTOM to better fit with ITIL. That suggests to me that the mentioned "differences" are not so "irreconcilable" after all ;-) At least it seems TMForum is making steps towards ITIL.
Few years ago when I attended TeleManagement Forum in Nice, when talking about ITIL (v2 at that time), eTOM guys never failed to mention (with a bit of pride on their side and bit of disrespect towards ITIL) that ITIL in Incident Management does not differentiate between user requests and failures in infrastructure (whereas they have different Level 1 processes for Suppliers and Partners, Infrastructure, Services, Customers in Assurance vertical). It has always seemed to me that ITIL v3's service lifecycle approach is greatly "influenced" by eTOM's long existing horizontal cycle (Strategy & Commit -> Infrastructure Lifecycle Management -> Product Lifecycle Management -> Operations Support and Readiness -> Fulfillment -> Assurance -> Billing). This means to me that ITIL is/was/has been making steps toward eTOM as well.
requests v incident
It still amazes me how hard it can be to get an IT department to recognize this distinction, even though it excellent for PR witht he customer. Treat everything as an incident in your reporting and an improvement in fufilling requests actually looks like service is gettign worse because there are more incidents!
I think it is also true that most users have a clearer feel for how long a typical request should take to be completed, whereas they accept an incident sometimes takes as long as it takes. generally when I talk to senior customers their number one pain point is how long it takes to get a new user set up so they can be workign on their first day in the office.
The separation of the 2 in
The separation of the 2 in ITIL v3 is probably a good thing. However I wouldn't give up on ITIL v2 saying there is a distinction (in a real world) that is not covered there in ITIL v2. Not all Incidents are the same: i.e. as part of the Incident Management process (AFAIR) there are steps of categorization and classification which can enable you to make the distinction and thus be able to report these 2 types separately...
Not far enough?
It is true that v2 talked about classification and categorization, and that is where I would advise a decision between a request or an incident (some are a difficult call, such as password re-sets) and a request (or several) can also be generated as a result of an incident.
I think the request process in v3 was eagerly awaited by many of us, and a bit light on content when it appeared. I would like to see advice on workflow design and management to optimise throughput for instance.
eleven forms of request
They are all requests. Incidents are one form of request. ITIL will get their one day. See my article "The Evolution of the ITIL Request" on ITSMWatch, or read the new Real ITSM book which has eleven forms of request, one of which is Incident. Really.
blame culture
I've always taken the view that there is a basic meta workflow (I hesitate to call it either event or request workflow these daya) that a lot of ITIL processes are a variant on. On the other hand the issue here is about responsibnility, and in a third party scenario that leads to a commericial exposure that might as well be called blame. If my service provider manages an infrastruture that doesn't deliver the contracted service levels then I have incidents and want recompense.
All the more reason
All the more reason to separate out the different categories and have different service levels for each. A Request for Project is different to a request for a new copy of a manual is different to my monitor is on fire is different to how does this field work. The appropriate responses are different for each, and priority is not the right mechanism for gating them.