1
Q
What is service management?
A
Set of specialized organizational capabilities for providing value to customers in form of services
2
Q
Definition of Service
A
Means of delivering value to customers by facilitating outcomes customers want to achieve, without the ownership of specific costs and risks
3
Q
Function
A
Units of organizations specialized to perform certain types of work and responsible for specific outcomes
4
Q
Processes
A
Closed-loop systems that provide change and transformation towards a goal. Have the following characteristics –
- measurable
- specific results
- customers
- responds to a specific event
5
Q
Purpose of Service Operation
A
Purpose of Service Operation is to coordinate and carry out the activities and processes required to deliver and manage services at agreed levels to business users and customers
6
Q
Scope of Service Operations
A
The scope includes:
- the services themselves
- Service Management processes
- technology
- people
7
Q
Down side to Value to Business
A
- once service designed and tested, it is expected to run within the budgetary and ROI targets established earlier in cycle
- difficult to obtain funding during operational phase to fix flaws or unforeseen requirements
- difficult to obtain additional funding for tools or actions aimed at improving efficiency of Service Operation
- Once service operational for a time, it becomes part of the baseline expectation of business
8
Q
Service Operation Optimization
A
- long-term incremental improvement
- short-term ongoing improvement
9
Q
Processes within Service Operation
A
- Event Management
- Incident and Problem Management
- Request Fulfillment
- Access Management
10
Q
Functions within Service Management
A
- Service Desk
- Technical Management
- IT Operations Management
- Application Management
11
Q
Interfaces to other Service Management Lifecycle Stages
A
- Change Management
- Capacity and Availability Management
- Financial Management
- Knowledge Management
- IT Service Continuity
- Service Reporting and Measurement (CSI)
12
Q
Definition of Group
A
Number of people who are similar in some way – who perform similar activities.
13
Q
Definition of Team
A
Formal type of group – work together to achieve a common objective.
14
Q
Definition of Department
A
Formal organizational structures that exist to perform a specific set of activities on an ongoing basis.
15
Q
Definition of Division
A
A number of departments group together.
16
Q
Definition of Role
A
Set of connected behaviors or actions performed by a person, team, or group in a specific context.
17
Q
Internal IT vs. External Business View
A
- External view of IT is the way in which services are experienced by users and customers.
- Internal view of IT is the way in which IT components and systems are managed to deliver services.
Organizations need to achieve a balance between external and internal focus.
18
Q
Stability vs. Responsiveness
A
Service Operation needs to ensure that the IT infrastructure is stable and available as designed. At the same time, SO needs to recognize that business and IT requirements change.
19
Q
Balancing Service Quality and Cost
A
- Early in lifecycle possible to achieve significant increases in service quality with small amount of money
- Later, small improvements are very expensive
20
Q
Reactive vs. Proactive
A
- Reactive – no action unless prompted to do so by an external driver
- Proactive – always looking for ways to improve
Proactivity dependent on variables, such as:
- maturity of organization
- culture of organization
- role IT plays in business and mandate it has to influence strategy and tactics of business
- level of integration of management processes and tools
- maturity and scope of knowledge management
21
Q
Service Design and Service Operation
A
Service Design Processes offer –
- clear definition of IT service objectives and performance criteria
- linkage of IT service specification to performance of the IT infrastructure
- definition of operational performance requirements
- mapping of services and technology
- ability to model effect of changes in tech and business requirements
- appropriate cost models
22
Q
Operational Health
A
Isolate a few “vital signs” that are defined as critical for the successful execution of a business function. Leads to self-healing systems –
Self-healing system characteristics:
- resiliance built into system (redundant disks)
- software, data, and operating system resilience built in (mirror databases)
- ability to shift processing from one physical device to another without disruption
- built-in monitoring utilities
- correlation engine (determine significance of each event)
- set of diagnostic tools (database of known errors)
- ability to generate a call for human intervention (raising an alert or generate an incident)
23
Q
Communication
A
- Routine operational communication
- Communication between shifts
- Performance reporting
- Communication in projects
- Communication related to changes
- Communication related to exceptions
- Communication related to emergencies
- Training on new or customized processes and service designs
- Communication of strategy and design to SO teams
24
Q
Types of Meetings
A
- Operations meetings
- Department, group, team meetings
- Customer meetings
25
Documentation
IT Operations Management, Application Management, Technical Management teams involved in documentation.
* process manuals
* technical procedures manuals
* planning documents (capacity and availability plans and service continuity plans)
* creation and maintenance of Service Portfolio
* Definition and maintenance of Service Management tool instructions to meet reporting requirements
26
Event Management
Monitors all events that occur through the IT infrastructure to allow for normal operations and also detect and escalate exception conditions.
Event defined as any detectable or discernable occurrence that has significance for the management of the IT infrastructure or delivery of IT service and evaluation of the impace a deviation might cause to the service.
Events created by --
* IT service
* Configuration Item
* monitoring tool
Event management basis of operational monitoring and control
Provides a way of comparing actual performance and behavior against design standards and SLAs
27
Monitoring Tools
* Active -- poll key CIs to determine their status and availability
* Passive -- detect and correlate operational alerts or communications generated by CIs
28
Scope of Event Management
* Configuration items
* Environmental conditions (fire and smoke detection)
* Software license monitoring
* Security (including intrusion detection)
* Normal activity (use of an application or performance of a server)
29
Difference between Monitoring and Event Management
Event management is focused on generating and detecting meaningful notifications.
Monitoring is broader
Event management works with occurrences that are specifically generated to be monitored
Monitoring tracks occurrences, but also actively seeks out conditions that do not generate events
30
Event Management Value to Business
* EM provides early detection of incidents
* Allows some types of automated activity to be monitored by exception
* Allow for early response by appropriate person or team
* Reduce use of expensive human resources for monitoring
31
Types of Events
* Regular operation
* Exception
* Unusual, but not exceptional operation
32
Event Management Process Flow
* Event occurs
* Event notification
* Event detection (by agent running on server)
* Event filtering (communicate to management tool or ignore it)
* Significance of events (informational, warning, exception)
* Event correlation (what is significance of event)
* Trigger (initiate a response)
* Response selection
* Review actions
* Close event
33
Event Notification
* Device interrogated by a management tool collecting targeted data -- polling
* CI generates a notification when certain conditions are met. Ability to produce notifications must be designed and built into CI
In Service Transition -- event generation options should be set and tested.
Most of the time events are defined by trial and error.
More meaningful the data the more targeted the audience, the easier to make decisions abou the event.
34
Event Correlation Examples
* Number of similar events
* Number of CIs generating similar events
* Is action associated with code or data within event
* Does event represent exception
* Comparison of utilization information in event with maximum or minimum standard
* Is additional data required to investigate event further?
* Categorization of event
* Assigning priority to event
35
Response Selection
* Event logged
* Auto response (rebooting device)
* Alert and human intervention
* Incident, problem, or change processes triggered?
* Open an RFC
* Open an incident record
* Open a problem record
* Special type of incident
36
Event Management Interfaces
* Interface with business applications and/or business processes to allow potentially significant business events to be detected and acted upon
* Primary ITSM relationships with Incident, Problem, and Change Management
* Capacity and Availability Management define what events are significant and appropriate thresholds
* Configuration Management uses events to determine status of CIs
* Asset Management uses EM to determine the lifecycle status of assets
* Events are rich source of information for Knowledge Management systems
* EM play role in ensuring potential impact on SLAs detected early and failures rectified as soon as possible
37
Information Management
* SNMP messages
* Management Information Bases (MIBs) -- database on each device containing information about the device including operating system, BIOS version, configuration parameters
* Vendor monitoring tools
* Correlation engines (determine significance)
* Event record
Should also have metrics that check on the effectiveness and efficiency of EM process.
38
Event Management Challenges
* Obtaining funding
* Setting correct level of filtering
* Rolling out monitoring agents
* Acquiring necessary skills
39
Keys to Correct level of Filtering
* Integrate EM into all service management prcesses
* Design new services with EM in mind
* Trial and Error
40
Design Areas for Event Management
* Instrumentation (how to monitor and control IT infrastructure and services)
* Error messaging
* Event detection and alert mechanisms
* Identification of thresholds
41
Incident Management
Incident defined as an unplanned interruption to an IT service or reduction in the quality of an IT service.
Incident Management is process for dealing with all incidents -- including failures, questions, or queries reported by users, technical staff, or automatically detected by event monitoring tools
Goal -- restore normal service operation as quickly as possible and minimize adverse impact on business operations
42
Incident Management Value to Business
* Ability to detect and resolve incidents, resulting in lower downtime to the business
* Ability to align IT activity to real-time business priorities
* Ability to identify potential improvements to services
* Help Desk identify additional service or training requirements
43
Incident Management Concepts
Items to consider in Incident Management include:
* Timescales
* Incident Models
* Major Incidents
44
Incident Management Process
* Incident Identification
* Incident Logging
* Incident Categorization
* Incident Prioritization
* Initial Diagnosis
* Incident Escalation
* Investigation and Diagnosis
* Resolution and Recovery
* Incident Closure
45
Interfaces with Incident Management
* Problem Management
* Configuration Management
* Change Management
* Capacity Management
* Availibility Management
* SLM
46
Information Management
Information used in Incident Management comes from the following sources:
* Incident Management tools
* Incident Records
* Access to the Configuration Management System
* Known Error Database
47
Metrics
Metrics should be monitored and reported to judge the efficiency and effectiveness of IM.
48
Incident Management Challenges
* Ability to detect incidents as soon as possible
* Convincing all staff that all incidents must be logged and encouraging use of self-help web-based capabilities
* Availability of information about problems and known errors
* Integration into CMS to determine relationships between CIs
* Integration into the SLM process
49
Incident Management Critical Success Factors
* Good Service Desk
* Clearly defined targets as defined in SLAs
* Adequate customer-oriented and technically trained support staff
* Integrated support tools
* OLAs and UCs capable of influencing and shaping correct behavior of suppot staff
50
Incident Management Risks
* Inundation of incidents
* Incidents being bogged down because of inadequate support tools
* Lack of adequate or timely information sources due to inadequate tools or lack of integration
* Mismatches in objectives or actions because of poorly aligned or non-existent OLAs and UCs
51
Service Request
* Low risk
* Frequently occurring
* Low cost
52
Request Fulfillment Objectives
* Channel for users to request and receive standard services under a pre-defined approval and qualification process
* Provide information for users and customers about the availability of services and the procedure for obtaining them
* Source and deliver components of requested standard services (licenses and software media)
* Assist with general information, complaints, or comments
53
Value of Request for Fulfillment
Provide quick and effective access to standard services that business staff can use to improve their productivity or the quality of business services and products
Request fulfillment reduces bureaucracy in requesting and receiving access to services, thus reducing cost of providing services.
Centralizing fulfillment increases level of control over services and can reduce cost of support.
54
Ownership of Service Requests
Service Desk owns service requests which monitors, escalates, dispatches, and often fulfills the user request.
55
Financial Approval of Requests
When request approved, the request fulfillment process must also include the charging for the work done
56
Closure of Request Fulfillment
After request fulfilled -- Service Desk should close the ticket no matter who fulfilled it.
57
Primary Interfaces to Request Fulfillment
* Service Desd/Incident Management
* Relase, Asset, and Configuration management
58
Information for Service Requests
Request fulfillment dependent upon information from:
* Service request
* Request for change
* Service portfolio
* Security policies
59
Request Fulfillment Challenges
* Clearly defining and documenting type of requets handled through request filfillment --- as opposed to the Service Desk or Changement Management process
* Establishing self-help front-end capabilities allowing users to interface with request fulfillment process
60
Request Fulfillment Critical Success Factors
* Agreement on what services will be standardized and who is authorized to request them
* Publication of services to users as part of the Service Catalog
* Definition of a standard fulfillment procedure for each service being requested
* Single point of contact where service can be requested
* Self-service tools needed to provide front-end interface to users
61
Request Fulfillment Risks
* Poorly defined scope -- people unclear about exactly what process should handle
* Poorly designed or implemented user interfaces -- making it difficult for users to file requests
* Badly designed or operated back-end fulfillment processes incapable of dealing with the volume or nature of the requests
* Inadequate monitoring capabilities so metrics cannot be gathered
62
Definition of Problem
Cause of one or more incidents
63
Objectives of Problem Management
* Prevent problems and resulting incidents from happening
* Eliminate recurring incidents
* Minimize impact of incidents that can't be prevented
64
Scope of Problem Management
* Activities required to diagnose root cause of incidents and determine resolution to problems
* Responsible for ensuring resolution is implemented through the appropriate control procedures -- especially Change Management and Release Management
* Problem Management strong interface with Knowledge Management
65
Problem Management Processes
* Reactive - -covered under Service Operation
* Reactive -- covered under CSI
66
Problem Management Flow
* Problem Detection
* Problem Logging
* Problem Categorization
* Problem Prioritization
* Problem Investigation and Diagnosis
* Workarounds
* Raising a Known Error Record
* Problem Resolution
* Problem Closure
* Major Problem Review
* Errors detected in development environment
67
Problem Record Triggers
* Majority of problem records triggered by incidents (perhaps from Service Desk)
* May also be created during testing
68
Interfaces of Problem Management
Service Transition
* Change Management
* Configuration Management
* Release and Deployment Management
Service Design
* Availability Management
* Capacity Management
* IT Service Continuity
Continual Service Improvement
* Service Level Management
Service Strategy
* Financial Management
69
Known Error Database
Purpose is to allow storage of previous knowledge of incidents and problems and how they were overcome -- to allow quicker diagnosis and resolution if they recur.
KEDB is part of the Service Knowledge Management System (SKMS).
70
Problem Management Critical Success Factors
* Linking incident and problem management tools
* Ability to relate incident and problem records
* Second and third-line staff should have good relationship with first-line
* Ensure business impact is understood by all staff working on resolution
Problem Management's ability to use all Knowledge and Configuration Management resources
Ongoing training of technical staff
71
Access Management Definition
Process of granting authorized users the right to use a service, while preventing access to non-authorized users.
AKA -- Rights Management or Identify Management
Execution of policies and actions defined in Security and Availability Management
72
Scope of Access Management
Enables organization to manage the confidentiality, availability, and integrity of data and intellectual property.
AM ensures users are given right to use a service, but does not ensure access is available at all times -- that is Availability Management.
Access Management is executed by all Technical and Application Management functions and is usually not a separate function. However, there is likely a single point of coordination -- usually IT Operations Management or Service Desk.
AM can be initiated through SR through Service Desk.
73
Access Management Value to Business
* Controlled Access to services ensures organization confidentiality
* Employees have right access to execute jobs effectively
* Less likelihood of data errors by unskilled user
* Ability to audit use of services and identify abuse
* Ability to revoke access rights when needed
* May be needed for regulatory compliance
74
Access Management Basic Prinicples
* Access -- level or extent of a service's functionality or data a user is entitled to use
* Identity -- information that distinguishes individual and verifies their status within organization
* Rights -- actual settings where user is provided access to a service or group of services
* Services or Service Groups
* Directory Services -- specific tool to manage access and rights
75
Access Management Activities
* Requesting Access
* Verification
* Providing Rights
* Monitoring Identity Status
* Logging and Tracking Access
* Removing or Restricting Rights
76
Access Management Critical Success Factors
* Ability to verify identity of user
* Ability to verify identity of approver
* Ability to verify that a user qualifies for access to a specific service
* Ability to link mutliple access rights to an individual user
* Ability to determine status of user at any time (e.g., whether still employed, etc.)
* Ability to manage changes to user's access requirements
* Ability to restrict access rights to unauthorized users
* Database of all users and rights they have been granted
77
Service Operation and Change Management
* Submitting RFCs as needed
* Participating in CAB meetings to ensure Service Operation risks, issues, and views are taken into account
* Implementing changes as directed by Change Management when they involve Service Operation components
* Backing out changes as directed by Change Management relating to SO components
* Helping define and maintain change models relating to SO components
* Receiving change schedules and ensuring all SO staff are made aware of and are prepared for all relevant changes
* Use Change Management process for standard, operational-type changes
78
Service Operation and Configuration Management
* Informing Configuration Management of any discrepancies between CIs and the CMS
* Making any amendments necessary to correct any discrepancies, under Configuration Management, where they involve Service Operation components
79
Service Operation and Release and Deployment Management
* Implementation actions regarding deployment of new releases where they related to SO components
* Participating in the planning stages of major new releases to advise on SO issues
* Physical handling of CIs from/to the DML as required to fulfill their operational roles
80
Service Operation and Capacity Management
* Capacity and performance monitoring
* Handling capacity- or performance-related incidents
* Capacity and performance trends
* Storage of Capacity Management data
* Demand Management
* Workflow Management
* Modelling and application sizing
* Capacity Planning
81
Service Operation and Availability Management
* Review of maintenance activities
* Major problem reviews
* Involvement in specific initiatives
82
ITIL
flashcards
Decks in class (3)
# Cards
