Demand Management is a critical aspect of service management and can be seen in two forms:
1) Demand for a new service
2) Demand for Enhancement
Organizations can handle or executes Demand Management depends on specific needs. In my experience, Service Management needs to develop a process by which a client sends in a new request for Demand Management. I can simplify it in a step by step guide:
1) Client needs to have a template that they fill in with the new service/enchancement. This template will ask for all the information that is needed for basic assesment
2) Once template is complete, it will be sent to Service Desk or Service Management Team. This new request is now added to a tracking tool
3) New request is then assigned to specific team for initial assessment
4) This new request is then discussed in management meeting. Here cost/need/urgency/priority/impact will be discussed
5) Depending on Priority team works on delivering the service
6) Testing/Release Management is involved for testing in test environments and for scheduing
If you have any specific questions regarding Demand Management, then please ask.
Thursday, June 24, 2010
Monday, March 1, 2010
Incident Management
Incident Management:
Goal of Incident Manager is to restore the service to normal operations asap with minimum impact to client/business.
Incident Manager is responsible for Incident Management and Critical Incident Management Processes that needs to be triggered for every Incident ( With SLA targets in mind). Incident Managers often separate their tickets into 2 separate streams:
1) Incidents: Any event which is not part of standard operation of service and causes disruption, outage or degradation of service.
2) Request for Service: Any request from the user for support, information or advice
Response to Incident is based on Priority, which depends on Impact and Urgency of Incident. There are basic 2 type or response for Incident Management:
Critical or High Priority Incident: this triggers Critical Incident Management Process. Usually there is a Team of subject Matter Experts who are always available and start working on the incident with Incident Manager within few minutes of the incident. Once this team figures out the issue and what will fix it, they call Emergency Change Approver committee to approve a change and fix the issue.
Non Critical Incidents: This kind of incidents follow a normal path where incident is assigned by service desk to a specific group and someone from that group works on the incident and gets back to client within set time frame.
Various Processes for Incident Management are:
• Incident detection and recording
• Classification and initial support
• Investigation and diagnosis
• Resolution and recovery
• Incident closure
• Incident Entry Template
• Continuous Monitoring Procedure
• Critical Incident Management Procedure
• Escalation Process
KPI’s for Incident Management:
• % SLA Achieved
• % of incidents closed within target RTO
• % of incidents handled within set response time
• % of incidents incorrectly prioritized
Goal of Incident Manager is to restore the service to normal operations asap with minimum impact to client/business.
Incident Manager is responsible for Incident Management and Critical Incident Management Processes that needs to be triggered for every Incident ( With SLA targets in mind). Incident Managers often separate their tickets into 2 separate streams:
1) Incidents: Any event which is not part of standard operation of service and causes disruption, outage or degradation of service.
2) Request for Service: Any request from the user for support, information or advice
Response to Incident is based on Priority, which depends on Impact and Urgency of Incident. There are basic 2 type or response for Incident Management:
Critical or High Priority Incident: this triggers Critical Incident Management Process. Usually there is a Team of subject Matter Experts who are always available and start working on the incident with Incident Manager within few minutes of the incident. Once this team figures out the issue and what will fix it, they call Emergency Change Approver committee to approve a change and fix the issue.
Non Critical Incidents: This kind of incidents follow a normal path where incident is assigned by service desk to a specific group and someone from that group works on the incident and gets back to client within set time frame.
Various Processes for Incident Management are:
• Incident detection and recording
• Classification and initial support
• Investigation and diagnosis
• Resolution and recovery
• Incident closure
• Incident Entry Template
• Continuous Monitoring Procedure
• Critical Incident Management Procedure
• Escalation Process
KPI’s for Incident Management:
• % SLA Achieved
• % of incidents closed within target RTO
• % of incidents handled within set response time
• % of incidents incorrectly prioritized
Monday, January 18, 2010
Change Management and Emergency Change
Purpose behind Change Management Process: ITIL is all about Standardizing methods and then continuously improving them, And same goes for CM(change management).
CM is to ensure we standardize our processes
CM ensures proper recording of changes in assets and configuration items
Reduce risk to the business/operations
Fixing Incidents
Objective of CM: CM process ensures that the change is recorded, evaluated, approved, prioritized, planned, tested, implemented and reviewed.
Now we will start with first step and that is Recording of change or standardizing the recording:
I suggest that organization follow 1 template for every change request. This ensure the appropriate information is available to begin with. Some basic template questions can be decided into these areas:
Description of Change: Change required, Duration of change, Implementation group, change driver
Justification: Reason for change, Benefit of change, Ramifications of not implementing change
Service Impact: Service interruption and change impact
Risk of Change Failure: Chances of change failing, ramifications of change failure
Testing: Was the test successful, backout plan
Logs: Implementation Details
If organization follows a template as above, I can almost guarantee that all approvers will be very happy and the approval cycle will be fast. This will also show that the SME is ready and has all the information about the change. Improves confidence and also outcome. This will cover us in next few steps: Evaluation, Approval.
Next is Prioritization: This is where Release Manager comes into play. With the help of release manager this can be prioritized and planned for release. If this change is to fix an incident then we will go to end of this post to Emergency Change.
Testing and Implementation is done by various teams to make sure that the change does not result into any unwanted incidents.
Review: This is done by Change Manager at the end to see if there is anything we can learn from this.
Now comes the fun topic: Emergency Changes
When a Critical Incident or Priority 1 incident is going on and a change is suggested by the techs we need to follow Emergency Change policy. There is no time in this situation to follow regular change policy so Incident Managers asks ECAB(Emergency Change Advisory Board) to approve the change. Once approved Change is implemented and confirmed by the client is issue is resolved. ECAB and Emergency changes mostly are executed by Incident Manager and also controlled. Change Record is still created by SME.
KPIs for Change Management:
1) % of failed change
2) % of change causing Incident
3) Change Success rate
CM is to ensure we standardize our processes
CM ensures proper recording of changes in assets and configuration items
Reduce risk to the business/operations
Fixing Incidents
Objective of CM: CM process ensures that the change is recorded, evaluated, approved, prioritized, planned, tested, implemented and reviewed.
Now we will start with first step and that is Recording of change or standardizing the recording:
I suggest that organization follow 1 template for every change request. This ensure the appropriate information is available to begin with. Some basic template questions can be decided into these areas:
Description of Change: Change required, Duration of change, Implementation group, change driver
Justification: Reason for change, Benefit of change, Ramifications of not implementing change
Service Impact: Service interruption and change impact
Risk of Change Failure: Chances of change failing, ramifications of change failure
Testing: Was the test successful, backout plan
Logs: Implementation Details
If organization follows a template as above, I can almost guarantee that all approvers will be very happy and the approval cycle will be fast. This will also show that the SME is ready and has all the information about the change. Improves confidence and also outcome. This will cover us in next few steps: Evaluation, Approval.
Next is Prioritization: This is where Release Manager comes into play. With the help of release manager this can be prioritized and planned for release. If this change is to fix an incident then we will go to end of this post to Emergency Change.
Testing and Implementation is done by various teams to make sure that the change does not result into any unwanted incidents.
Review: This is done by Change Manager at the end to see if there is anything we can learn from this.
Now comes the fun topic: Emergency Changes
When a Critical Incident or Priority 1 incident is going on and a change is suggested by the techs we need to follow Emergency Change policy. There is no time in this situation to follow regular change policy so Incident Managers asks ECAB(Emergency Change Advisory Board) to approve the change. Once approved Change is implemented and confirmed by the client is issue is resolved. ECAB and Emergency changes mostly are executed by Incident Manager and also controlled. Change Record is still created by SME.
KPIs for Change Management:
1) % of failed change
2) % of change causing Incident
3) Change Success rate
Thursday, January 14, 2010
ITIL
IT world today is bombarded with various acronyms and certifications. There are so many options available in the market yet, organizations are still struggling with more problems than never before. IT Companies still face the same issues of cutting costs and increasing efficiencies, and at the same time struggling to keep up with the technology.
My suggestion: Let’s get back to the drawing board and see what we really want:
Most of IT Companies are looking for 2 things:
Excellent customer service, leading to happy customers
and
Great productivity
Now, this does not mean that we don’t have $ on our mind. But these are the basics that drive us: Productivity and Customer Service
ITIL: If I have to define ITIL, I will say that ITIL is the way to achieve our basic goals inline with our $ value. And in ITIL terms it is a set of concepts and practices for managing IT Services and Operations. It is built on a service life-cycle model and encompasses “Good Practice”Actually in today’s competitive world we need to follow ITIL if we want to succeed. Most successful service providers, today, are using ITIL or their own versions of ITIL.
Now that we know a little bit about ITIL, I can go to next important topic: Why Adopt ITILTo achieve success as a service provider we need to adapt to this model as it helps us achieve our goals by improving alignment between IT and other business processes, improve the quality of service provided and reduce costs.
Service Lifecycle Approach: The ITIL approach is very basic and is very easy to understand, for example: when we start a business we will first develop a strategy then we will design our product/service, then we will transition to operations and lastly we will continuously improve our service/ product depending on feedback or market. ITIL uses the same approach and gives it 5 stages:Stage 1: Service Strategy
Stage 2: Service Design
Stage 3: Service Transition
Stage 4: Service Operation
Stage 5: Continual Service Improvement
For most of it you can easily get reading material on Google, so I will jump straight to Service Transition.
Transition includes first key process:
Change Management:
Change Management is an approved/useful/standardized/fool proof set of processes to handle change in a way that the desired outcome is achieved with no unwanted impact to other related services or operations.
There are many performance indicators related to Change Management such as:
• Number or % of failed changes
• Number or % of changes causing incident
• Number or % of unapproved changes
• Number or % of emergency Changes
Management needs to set these targets depending on the business needs as different environments can lead to very different targets. It is also important to note that Change Management needs to identify a person or a group which will be responsible for the approval of emergency changes. Also to have a standardized request for change it is suggested, that one template be used by the whole organization.
Service Operations: This is where the fun begins. All starts with a channel through which client contacts IT; mostly it is the Service Desk. I won’t go into details of the Service Desk but would like to say that the Service Desk is a gateway to your organization and your customer service skills are required the most at this point. So make sure you have excellent reps with good CS Skills. What comes next, any guesses? For sure Incident Management. Clients call when they have an issue. So Service Desk Logs an Incident.
1) Incident Management: Goal of this guy is to restore service with minimum disruption to business. Depending on SLA and priority of the incident the Incident Manager should make sure that the issue is resolved within the set time frame. It is also suggested that the Incident Manager develops a Critical Incident Management Process for Critical Incidents and an Incident Management Process for incidents with low impact and urgency. Mostly Incident Manager also has a clear escalation process to be followed in times of critical incidents.
Few Key Performance Indicators are:
% of Incidents Resolved in set RTO timeframe( Return Time Objective )
Achieve SLA
Response time for incidents( time taken for Incident to go from open to working status)
2) Problem Management: Goal of Problem Management is to ensure that the incident that got resolved by the Incident Manager never happens again. PM is responsible for conducting root cause analysis and coming up with action plans. This is where the issue is fixed permanently
Key Performance Indicators are:
% of reoccurring Incidents
% of Problems resolved
3) Event Management: An Event is any occurrence detected (mostly by monitoring teams using software’s such as Tivoli) that can impact Infrastructure or services. Event Management is responsible for detecting events, understanding them and determining appropriate action.
Now we are on last section of the cycle and that is Continual Service Improvement: Here the goal is to improve efficiency and effectiveness of the operations by continues enhancements to the processes.
Once the operations is up and running, we needs to go back and review our achievements, outputs, customer service, our methods and the come up with result oriented action plans on continues improvement. ITIL says this in 7 steps:
Step 1: Define what you should measure
Step 2: Define what you can measure
Step 3: Gather the data
Step 4: Process the data
Step 5: Analyze the data
Step 6: Present and use the information
Step 7: Implement corrective Action
What we read above is very basic and simple, but that is what ITIL is. It is a back to basics approach, follow the same steps daily and make sure you keep going back keep improving what you do daily
My suggestion: Let’s get back to the drawing board and see what we really want:
Most of IT Companies are looking for 2 things:
Excellent customer service, leading to happy customers
and
Great productivity
Now, this does not mean that we don’t have $ on our mind. But these are the basics that drive us: Productivity and Customer Service
ITIL: If I have to define ITIL, I will say that ITIL is the way to achieve our basic goals inline with our $ value. And in ITIL terms it is a set of concepts and practices for managing IT Services and Operations. It is built on a service life-cycle model and encompasses “Good Practice”Actually in today’s competitive world we need to follow ITIL if we want to succeed. Most successful service providers, today, are using ITIL or their own versions of ITIL.
Now that we know a little bit about ITIL, I can go to next important topic: Why Adopt ITILTo achieve success as a service provider we need to adapt to this model as it helps us achieve our goals by improving alignment between IT and other business processes, improve the quality of service provided and reduce costs.
Service Lifecycle Approach: The ITIL approach is very basic and is very easy to understand, for example: when we start a business we will first develop a strategy then we will design our product/service, then we will transition to operations and lastly we will continuously improve our service/ product depending on feedback or market. ITIL uses the same approach and gives it 5 stages:Stage 1: Service Strategy
Stage 2: Service Design
Stage 3: Service Transition
Stage 4: Service Operation
Stage 5: Continual Service Improvement
For most of it you can easily get reading material on Google, so I will jump straight to Service Transition.
Transition includes first key process:
Change Management:
Change Management is an approved/useful/standardized/fool proof set of processes to handle change in a way that the desired outcome is achieved with no unwanted impact to other related services or operations.
There are many performance indicators related to Change Management such as:
• Number or % of failed changes
• Number or % of changes causing incident
• Number or % of unapproved changes
• Number or % of emergency Changes
Management needs to set these targets depending on the business needs as different environments can lead to very different targets. It is also important to note that Change Management needs to identify a person or a group which will be responsible for the approval of emergency changes. Also to have a standardized request for change it is suggested, that one template be used by the whole organization.
Service Operations: This is where the fun begins. All starts with a channel through which client contacts IT; mostly it is the Service Desk. I won’t go into details of the Service Desk but would like to say that the Service Desk is a gateway to your organization and your customer service skills are required the most at this point. So make sure you have excellent reps with good CS Skills. What comes next, any guesses? For sure Incident Management. Clients call when they have an issue. So Service Desk Logs an Incident.
1) Incident Management: Goal of this guy is to restore service with minimum disruption to business. Depending on SLA and priority of the incident the Incident Manager should make sure that the issue is resolved within the set time frame. It is also suggested that the Incident Manager develops a Critical Incident Management Process for Critical Incidents and an Incident Management Process for incidents with low impact and urgency. Mostly Incident Manager also has a clear escalation process to be followed in times of critical incidents.
Few Key Performance Indicators are:
% of Incidents Resolved in set RTO timeframe( Return Time Objective )
Achieve SLA
Response time for incidents( time taken for Incident to go from open to working status)
2) Problem Management: Goal of Problem Management is to ensure that the incident that got resolved by the Incident Manager never happens again. PM is responsible for conducting root cause analysis and coming up with action plans. This is where the issue is fixed permanently
Key Performance Indicators are:
% of reoccurring Incidents
% of Problems resolved
3) Event Management: An Event is any occurrence detected (mostly by monitoring teams using software’s such as Tivoli) that can impact Infrastructure or services. Event Management is responsible for detecting events, understanding them and determining appropriate action.
Now we are on last section of the cycle and that is Continual Service Improvement: Here the goal is to improve efficiency and effectiveness of the operations by continues enhancements to the processes.
Once the operations is up and running, we needs to go back and review our achievements, outputs, customer service, our methods and the come up with result oriented action plans on continues improvement. ITIL says this in 7 steps:
Step 1: Define what you should measure
Step 2: Define what you can measure
Step 3: Gather the data
Step 4: Process the data
Step 5: Analyze the data
Step 6: Present and use the information
Step 7: Implement corrective Action
What we read above is very basic and simple, but that is what ITIL is. It is a back to basics approach, follow the same steps daily and make sure you keep going back keep improving what you do daily
Subscribe to:
Posts (Atom)