I'd prefer it if the next version of ITIL left other IT domains outside of Service Management along; for example, I don't believe ITIL should have any purview into Software Development Lifecycles or IT Asset Management. The folks in charge of defining ITIL should stop the IT land grab and leave things like SDLC and ITAM to experts in those domains._________________DrGroove
ITIL Architect | Moderator, Devshed.com | Technology journalist

I would actually go the other way. Those 2 specific areas are creating frictions in implementations and a better integration, especially in the application management space, would be appreciated.

But I do agree that ITIL shouldn't re-define those spaces. Instead, I think it should focus on making recommendations for successful integration.
For instance, how good is your release Mgt process if it doesn't integrate well with your software projects? Whether you use Agile or RUP, there needs to be a plan that helps operational teams absorbing large software changes.

Asset Management is an area that I know fairly well and it is true that there is no reason to maintain 2 different systems to keep track of assets._________________BR,
Fabien Papleux

1. Make Event Management a function.
2. Take Service Measurement and Service Reporting, and make one process
3. Separate Asset and Configuration Management
4. Take the development approval portion of Change Management, and move to Continual Improvement
5. Define Quality Assurance function
6. Shorten Process names, and do away with acronyms.[/list]

One of the best improvement in ITILv3 compared to ITILv2 was giving emphasis to Service Request.. and creating seperate process for it - "Request fullfillemt" or "Service Request Management" (I still dont know which one is official) is a very good decision.

If ever ITILv4 rolls out I would like to see some changes on how Incident Management triggers Problem Management. In all ITIL versions, Problem Management is triggered manually - either someone raises it or reports it. I think recurring Incidents should trigger a Problem ticket "AUTOMATICALLY".. I have seen and experienced some cases wherein a recurring incident cotninous to be.. well just that- continous. Although the system gets restored to normal operations "as soon as possible" by restarting the server, It goes on and on because no one "manually" raises a Problem ticket. But if it is "automatic" - meaning if this same incident occurs lets say at least three times, the owner should automatically escalate it into a problem ticket - no ifs no buts.. then link those incident tickets to the new problem ticket.. then solve the issue permanently

Sadly, and inexplicably, V3 downgraded Problem Management - The relevant paragraphs are headed "Incident and Problem management" and the time allocated in the Foundation class is very short - yet this was often the "light bulb moment" when people started to realise the benefits of the framework. I would re-instate it, and place even more emphasis on it than before.

The ridiculous division into Technical?Applications/Operations Management functions -which bears very little resemblance to modern organisations needs to be re-done.

High-lighting the touch points between Project management frameworks and Transition should have been included

CSI should not be a separate stage of the lifecycle - this is a logical nonsense -it should be included as part of each other phase - like Blackpool through rock.
Re-emphasise the CSI nature of Problem, SLM

Stop trying to take over every other management area - cultural or business change is NOT part of Transition, although success depends on it. - ITSCM cannot take the place of BCM