April 28, 2016 • IT Service Management, ITIL V3 for Application Support

Senior executive business man

 Application Support teams are mainly composed of IT technical staff, however, due to the nature of their close interaction with the business they must maintain a strong service management orientation and an awareness of service level expectations.  Their performance and activities are usually governed by service level goals that are consistent with the Service Level Agreements that the IT organization has established with its customers.

 ITIL presents the IT Service Management life cycle and processes in a way that is independent of how the IT Organization is structured. However, ITIL’s process disciplines can still be used to describe good practices for managing a service-oriented Application Support team.

Processes and documents that are used by an application support team can be found in all of the ITIL life cycle phases, from Service Strategy to Continual Service Improvement. 

The ITIL Service Management life cycle is a broad service management model that can apply to any IT service-related activity. The following graphic illustrates how the V3 Service Life cycle can apply specifically to the application support function and demonstrates a life cycle implementation approach to managing an application support function.    

ITIL V3 Process Flow

ITIL V3 Lifecycle and related material Copywrite by Office of Government Commerce, Norwich, UK, 2007.

Related Posts


  1. cna training says:

    Keep posting stuff like this i really like it

  2. Denise says:

    I am hoping you might be able to shed some light on a problem I am having. I am in the process of implementing Service-now in my organization. The development and test teams want to track bugs in the Incident Management System. I am discouraging them from doing this and explaining that the bugs they find in development and test should not be tracked in the same system with Production Incidents. I site the fact that the risk of mixing bugs and incidents are too high. If someone incorrectly assigns a bug ticket to the production environment the effects could be costly. They feel that they could adequately separate the Incidents and bugs by having a field for environment with a drop down that list Development, Test and Production. What are your thoughts on this? Should you keep bugs from Development and Test in the same system that you track your Incidents in the production environment? I have always kept the dev and test bugs in a separate bug tracking system.

    In looking at the Service Transition book, page 135 it looks like one system is used. Could you shed some light on this?

    I having a meeting today with the teams and would appreciate any feedback you could offer to clear this up for me.

  3. I would like to express some thanks to the writer just for rescuing me from this particular dilemma. As a result of surfing throughout the the net and meeting methods that were not helpful, I believed my entire life was over. Living without the solutions to the problems you have solved by way of your entire short post is a critical case, and ones that could have in a wrong way damaged my career if I had not noticed your website. Your own personal talents and kindness in dealing with all the things was valuable. I don’t know what I would’ve done if I had not come upon such a point like this. It’s possible to at this point look ahead to my future. Thanks for your time very much for this expert and results-oriented guide. I won’t hesitate to propose the blog to any individual who needs and wants support about this matter.

« »

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.