Home » Currently Reading:

Service Operations (Processes & Data Collection)

The following six processes are used by the application support team to support service operation functions:

Event Management

The team receives and acknowledges application support trigger events.  Examples of these trigger events are notifications from:

  • Users requesting assistance
  • IT operations department
  • System software

The team reviews all trigger events and creates an appropriate work event (incidents, service requests, change requests) in the Tracer® tool.  When appropriate, the team notifies the source of the trigger event that a work event was created and then closes the trigger event.

Incident Management

The team quickly restores normal service when there is an interruption to a service or a reduction in the quality of service.  Throughout this process the application support team tracks and captures incident status data in the Tracer® tool.  Activities within this process are:

The goal of this process is to minimize any negative business impact that may result from an incident.  The team is also responsible for ensuring that service quality and availability are maintained in accordance with Service Level Agreements (SLAs).

Problem Management

The team identifies the root cause of an incident, determines a resolution, and then ensures that the incident does not occur again.  Throughout this process the application support team tracks and captures problem status data in the Tracer® tool.  Activities within this process are:

  • Detect
  • Log the problem event in the Tracer® tool
  • Classify
  • Prioritize
  • Diagnose
  • Resolve
  • Close

The team balances the goals of Problem Management and Incident Management.  The goal of Incident Management is to restore service as quickly as possible.  The goal of Problem Management is to implement permanent solutions.

Request Fulfillment Management

The team manages service requests (support calls) that are received from the application users.  Throughout this process the application support team tracks and captures support call status data in the Tracer® tool.  Activities within this process are:

  • Log the call support event in the Tracer® tool
  • Classify
  • Prioritize
  • Consult or Investigate
  • Resolve
  • Close

It is important to distinguish between incidents and technical support calls. Incidents are unplanned and require Change Management approval prior to resolution.  A support call, on the other hand, is unplanned, but is considered pre-approved by Change Management.  For example, a support call may be an informational inquiry or user technical assistance on an application function.

Access Management

The team manages the access rights that are given to users to access the applications.  The process describes how the team coordinates communication between the application user and security administration regarding access to application functions.

Application Life-cycle management

The team develops, enhances, maintains, and manages applications within their scope of responsibility.  The team uses this process to govern all activities related to the management of applications.  Throughout this process, the application support team tracks and captures maintenance or enhancement status data in the Tracer® tool.  As defined in the Tracer® tool, this process contains the following steps:

  • Requirements Definition
  • Design
  • Build and Test
  • Quality Review
  • Deploy
  • Optimize

In all the above service operation processes, data are collected and the teams performance is measured against defined service metrics for each work event type.

4a - Service Operations_a

Our Sponsors

IT Support Services Comments

  • Bob Anderson: Daniel, from a certain point of view you are correct. CMMI- DEV deals primarily with software development best practices, the old CMM Level-5 dealt a great deal with defects. However, as you know the ...
  • Bob Anderson: Gunter, there are many possible SLA components and metrics that can be defined for any application software support. First I would recommend that you read this article which I had published in Compute...
  • Bob Anderson: Amiet, I would put it under the "Incident" process and track dates, number of occurrences, how much lost time, cause (who did it). You will need data for management if the practice has to stop. If you...
  • Bob Anderson: Amit, first of all why is the customer powering down the equipment? This should be brought to the attention of management and a very strong note sent to whoever is doing this.  If they are doing it on...
  • Bob Anderson: Mark, it is doubtful that you can fix the problem, it is mainly a management issue. The best you can do is to gather statistics on the backlog of enhancements, the number and severity of incidents, an...

ITIL V3 Application Support Q & A

If you have any question on the blog content or have some specific question on how ITSM & ITIL can dramatically improve performance and reduce the cost of your Application Support service "Ask Bob"
Question :
Hi Bob, Since I have make a control of doubts from our dealers questions, that uses our SW, is possible to see evaluation of our intern SLA. Me question is: I find only three metrics using to compare months to months our evolaution: error programs, legislation, improvem...
Answer :
Gunter, there are many possible SLA components and metrics that can be defined for any application software support. First I would recommend that you read this article which I had published in Computer World on "How to create Meaningful IT Support SLA's"  use this link...
Question :
In your answer to "Question : bugs, known errors and kb articles". You refer to CMMI-DEV and talk about defects and say that CMMI-DEV is for software development and does not deal with operations. So, is that another way of saying that CMMI-DEV ignores operations? Isn't...
Answer :
Daniel, from a certain point of view you are correct. CMMI- DEV deals primarily with software development best practices, the old CMM Level-5 dealt a great deal with defects. However, as you know the folks who developed the original CMM  were not really initially inter...
Question :
Hi Bob, Continuing on the question i posted yesterday. I understand your comment and we have actually done that. It is a reactive approach and we now want to move to a praoctive approach and want to understand if these activities should be managed under the change proce...
Answer :
Amiet, I would put it under the "Incident" process and track dates, number of occurrences, how much lost time, cause (who did it). You will need data for management if the practice has to stop. If you want to be "proactive" in stopping this practice" you must capture bu...
Question :
The chaos in applicaiton support in my company is in part due to the limited resources assigned to aging applications and very little documentation. How do I suggest that we need help?
Answer :
Mark, it is doubtful that you can fix the problem, it is mainly a management issue. The best you can do is to gather statistics on the backlog of enhancements, the number and severity of incidents, and how many technical support calls from users you get and the average...
Question :
If a customer is powering down equipment at his site and it will bring down the services during that time, should this be recorded as a change. You will not have any control over this activity and this activity is managed by the customer himself. These activities may ha...
Answer :
Amit, first of all why is the customer powering down the equipment? This should be brought to the attention of management and a very strong note sent to whoever is doing this.  If they are doing it on their own without any instruction to do so and it affects other user...

Popular Content