50217A-EnU StudentManualAppendix 02

Intelligent Training De
Colombia
Microsoft Operations Framework Foundation Training for SC Service Manager
Handouts
These Handouts are extension from MOFv4 Solution Accelerators and that’s the reason why the numbers
are not chronology. You can find all the Solution Accelerators on www.microsoft.com/mof
1. Change and Configuration Management
Table 1.4. Activities and Considerations for Baselining the Configuration

Activities Considerations Students notes
Define and collect Key questions:

the configuration · What information should be captured?
data to track in the
· Which users need access to service and/or system
CMS
component information?
· In what format would the information be most useful to
each user?
· Does any information in the CMS need to have
restricted access?
· How often does data need to be updated?
· How will this data be used?
Inputs:
· Service level agreements (SLAs) (see Business/IT
Alignment SMF)
· Operational level agreements (OLAs). (see Business/IT
Alignment SMF)
· Underpinning contracts (UCs) (see Business/IT
Alignment SMF)
· Applicable regulations and laws (see Policy SMF)
· Internal policies (see Policy SMF)
· Risk and impact analysis (see Governance, Risk, and
Compliance SMF)
· List of needed and desired CMS reporting requirements
Outputs:
· RFC and CMS requirements
Best practices:
· Define both business (services interdependencies) and
technical (system components) use of data.
· To obtain the most complete idea of needs, involve all
relevant people in assessment and planning. This
group might include individuals from Solution
Development, Enterprise Architecture, Operations,
Service Desk, and the business.
· Start by tracking as little data as possible, and add
more as needed. Keeping configuration records up-to-
date takes resources. Be sure the return on the
additional data collected is worthwhile. Know why you
are tracking the data you are tracking.
· When you add a new type of CI, re-evaluate the
configuration data to be tracked.
1
Jun 3 2011 9:33PM
Warning: This is Intelligent Training De Colombia's unique copy. It is illegal to reprint, redistribute, or resell this content.
The Licensed Content is licensed “as-is.” Microsoft does not support this Licensed Content in any way and Microsoft gives
no express warranties, guarantees or conditions. Please report any unauthorized use of this content to
Colombia
Handouts
Audit the CMS Key questions:

content · Are audits mandated by regulatory compliance
requirements or policy? How often should audits be
done?
· How will CMS information be confirmed? Who will
confirm it?
· Will access restrictions need to be enforced?
Inputs:
· CMS
· Access restriction requirements
· Policy and regulatory requirements
· Production environment
Outputs:
· Current state accuracy report
· Remediation plans for inaccuracies
Best practices:
· Don’t let your CMS go too long between audits. Smaller
corrections are much easier to do than larger
remediations.
· If the CMS frequently gets out of date, consider your
processes and adjust them to improve accuracy.
Table 1.5. Activities and Considerations for Initiating the Change

Initiate a request Key questions:

for change (RFC) · What kind of information is to be included in the change
description? For example, the service that will be
affected, the business benefit, and the exact description
of the configuration items to be changed.
· Who can initiate a change? Can anyone in the
organization initiate a change?
· How will the RFC be categorized and tracked?
· Does each service maintain its own set of RFCs?
· How are RFCs interlinked and cross-referenced?
· Is there a specific RFC for common or standard
changes?
Inputs:
· Request for a change
· Description of the change
Output:
· New RFC
Best practices:
· Keep RFC forms as simple as possible while capturing
sufficient information to manage risk.
· The RFC should be continually updated throughout the
process; it can be initiated without a thorough analysis
or detailed information about the change and then
updated later. It is important to have easy access to the
RFC so that additions to it can be made. Additionally,
2
Jun 3 2011 9:33PM
Colombia
Handouts

organizations can use role authentication to ensure that
read and write access is applied at the right time during
the process. Determine who should have permission to
read or change the RFC in each process.
· The organization can streamline the RFC process by
using pre-populated fields and drop-down lists for
information such as the type of change, the service
affected by the change, and the applicable technology.
· There should be a point of contact for each change
request. This can be the Change Manager or the
change initiator. The point of contact should have
access to the most recent history, understand the
technical and resource implications, and appreciate
how this change will affect other planned changes and
the day-to-day work of the business.
· Do not confuse the RFC process with a Service Desk
request. The latter is a request for such things as
existing services or questions about existing services,
and is handled through the Customer Service SMF. An
RFC is completed by the IT group to ensure that
changes to the production environment are well thought
out and planned.
· Ensure that the RFC form is self-explanatory and that it
is clear how to seek assistance, if needed, for
completing the form.
Check the Key questions:

technical · Has the RFC identified all CIs that will be affected or
configuration that will require a change?
· How many actual CIs will be affected? If this is a global
change such as a software update, is there an accurate
account of all services or production devices that will be
affected?
· When looking at the configuration database information,
are there additional CIs that may be affected?
Inputs:
· CIs
· Service map
· Impacted services gathered from the RFC
Output:
· CIs impacted by the RFC
3
Jun 3 2011 9:33PM
Colombia
Handouts
Check the Key questions:

business process · What business processes are potentially affected bythis
and application proposed change?
configuration
· What will need to change to accommodate this RFC?
· What applications will be affected by this RFC?
· Which users and business groups need to know about
this change?
· Best practices:
· Dependencies on business processes and functionality
must be identified. If you change the workflow or howthe
application is used, the business must be involvedto
identify impacts.
· Consider services, process, and impacted applications
when considering what communications are required.
Identify the Key questions:

business impact · How will the organization benefit from the change? If
and assess the the change is not done, is there a potential risk to the
risk organization?
· How will the business justification or impact be

explained and quantified? For example, if a change is
requested to increase the demand of a particular
service, the demand can be expressed in terms of
capacity data or an upcoming business event.
· What are the risks associated with this change?
Inputs:
· Request for a change
· Identification of the IT service and business group
impacted by the change
Output:
· Documentation of a clearly stated business reason and
the impact and risk of the change request
Best practice:
· For more information about assessing risk, see the
Governance, Risk, and Compliance SMF.
Table 1.6. Activities and Considerations for Classifying the Change

Identify the priority Key questions:

of the change · Is this a low, medium, high, or emergency priority
change?
Priority levels should be designed with specific time
frames and should support the business requirements.
A typical priority ranking includes:
· Low. The change can wait until the next scheduled
release.
· Medium. Because of its impact level, the change
cannot wait until the next scheduled release.
· High. The change needs to be released as soon
as it is complete and has been tested.
4
Jun 3 2011 9:33PM
Colombia
Handouts

· Emergency. The change needs to be released as
soon as possible; many of the approval and the
development steps are abbreviated.
Best practices:
· The Change Manager and RFC initiator might need to
negotiate the priority if they are not in agreement about
it. Define an escalation process.
· If there are too many emergency and high-priority
changes, review the reasons for the volume. This may
indicate that staff members are avoiding the process or
that the process is not effective.
Identify the Key questions:

category of the · What category does the change belong to?
change Categories take into account the resource requirements
for the change, the impact to the business of doing or
not doing the change, organizational experience with
the change, and new technology or processes. Typical
categories include:
· Standard change. This category is low risk
because it has a set release path that has been
proven to be successful, it has minimal business
impact, and it has a known set of release
procedures.
· Minor change. This category affects a small
percentage of users and resources. Also, the risk
of an outage is less because of the organization’s
experience in implementing this type of change.
· Significant change. This category has a
moderate effect on users, resources, and the
business. It might involve downtime of services
and may also involve a situation in which the
organization has less experience with the product,
infrastructure, or the client involved in the change.
· Major change. With a high risk and high cost, this
category involves the greatest potential impact on
users and resources. It might also affect a
business-critical system and could involve
downtime of the service.
· Emergency change. This category is high risk
because of the urgency of release and the minimal
time in which to test it. It is relatively uncertain if
the change will succeed, and there is a big impact
on the business if it fails. This type of change is
often a result of an urgent incident. These changes
are escalated to the Change Advisory
Board/Emergency Committee (CAB/EC) for fast-
track approval. (For more information about the
CAB, see Process 4: “Approve the Change.”)
· Unauthorized change. This level involves
changes that occur outside of the agreed-to
change management policies or that are
specifically forbidden.
5
Jun 3 2011 9:33PM
Colombia
Handouts

Best practices:
· Effective use of standard changes is important for
keeping the process manageable and usable. Evaluate
minor changes that go through the CAB process for
recategorization as future standard changes.
· Be as specific as possible in defining what is and is not
a particular type of change.
Update RFC Input:
· Check and validate the configuration
· Assess risk
· Updates about the change
Output:
· Updated RFC
Table 1.7. Activities and Considerations for Approving the Change

Route the change Key question:

to the correct · According to the IT governance processes, what
approving body governing body has the approval authority for this
change based on its classification?
Input:
· Governance structure (steering committees, forums)
(see the Governance, Risk, and Compliance SMF for
more information)
Outputs:
· RFC added to the CAB’s agenda or given to the
Change Manager
· Standard or minor changes given to the Change
Manager
Best practices:
· Approving bodies should have some members that
participate in change approvals on an ongoing basis.
These standing members should be well versed in
weighing the broader implications of making changes.
· In addition to standing members, include personnel and
experts from parts of the organization affected by the
change or who can add value to the discussion of the
change. These additional members are chosen on a
case-by-case basis.
· Beware of the “this is obvious, just do it” decision.
Solicit sufficiently broad input by involving a variety of
parties in the approval body so that there is rigor in
identifying trade-offs.
6
Jun 3 2011 9:33PM
Colombia
Handouts

Process standard Key questions:
changes torelease
· Has this change been classified as a standard change?
· Are the change tasks well known and proven?
· When this standard change has been performed, has it
always resulted in expected outcomes?
· Does this change fit in the next available change
window?
Inputs:
· The RFC under consideration
· List of approved standard changes
Outputs:
· Identified standard changes proceed directly to
development (if needed) or to release
· Documentation of a standard change having passed
through approval (see Process 6: “Release the Change”
for more information)
Best practices:
· ”Tried, Tested, and True”. These are characteristics of
standard changes. Early examples of these changes
were not standard, but as more examples of these
changes were done, knowledge about them was
captured. There is a high level of predictability and
confidence that a standard change will yield expected
results, without exception.
· Because the types of changes that have been pre-
approved as standard changes are known to have a low
impact on the environment and are a low risk to it, they
do not need to be reviewed again by the CAB or even
the Change Manager. This, however, means that care
must be taken during the initial screening to ensure that
a change request that has been categorized as
standard is, indeed, one of the pre-approved change
types and fits in the change window.
· Document the approval of a standard change including
when it was approved and the intended results of the
change.
7
Jun 3 2011 9:33PM
Colombia
Handouts

Analyze theimpact Key questions:
of thechange and
· Who can best perform and evaluate an impact analysis
identify reviewers
for the change?
· Does the impact analysis support the classification ofthe
change?
· Will policies, procedures, or any aspect of regulatory
compliance be affected by this change?
· Has the business case changed since the change was
initiated?
· Who in the business is most likely to be affected by this
change in terms of either its success or failure?
· Who has the most relevant IT technical knowledge?
· Who would best understand the implications to the
business of not making this change?
· Who will best understand the security and privacy
implications?
· Who can represent the policy and compliance issues
that might result?
Inputs:
· The RFC and any related RFCs under consideration
· Additional information about impacted areas needed in
the review process
Outputs:
· Standing members of change review bodies
· Invited experts and affected user representatives
Best practices:
· Completeness in impact analysis includes looking
across all requests for changes affecting a service so
that impacts are evaluated comprehensively. The
evaluation procedures include processes to evaluate
the costs of the changes and a means to verify that the
expected business benefit exceeds cost (or that the
change is mandatory).
· Revisit the business case and impact analysis of the
change to help ensure that the change and the business
case still make sense. Use the impact analysis to
determine the areas of the organization that should
participate in change review and to identify the potential
experts or user representatives who should participate
in the review.
· Record how reviewers were identified and the fact that
they agreed to participate in the review. Demonstrate
that the impact of the change was considered from a
broad perspective when identifying reviewers so that
best efforts could be given to the approval decision.
8
Jun 3 2011 9:33PM
Colombia
Handouts

Approve or rejectthe Key questions:
change, orseek
· Are all members of the change review body prepared to
additionalinformation
make the decision?
· Is there a predetermined approach to resolving
impasses in approving decisions or determining tie-
breakers in voting?
· Does the change really need to be made?
· Is the timing right to make the change or is there a
better change window?
Input:
· The RFC with change log and any other accompanying
information from the analysis process
Outputs:
· The RFC is approved and scheduled or rejected or
returned
· Any required contingencies for implementation
· Documentation of the approval process
Best practices:
· Implement all approved requests on a timely basis.
Keep the business case and impact analysis close in
time to the approval of a change to help ensure that the
change is still relevant and the right thing to do.
· Retain minutes of the change approval meetings as part
of the documentation of the process and participants.
· Identified contingencies should be kept as simple and
direct as possible to minimize additional judgments or
interpretations of the RFC.
9
Jun 3 2011 9:33PM
Colombia
Handouts

Update the RFC Key questions:
· Is all information available to complete the
documentation requirements for the RFC?
· Who will update the RFC?
· Who needs to know the results of the CAB review?
Input:
· The RFC and change log
Output:
· Updated RFC and change log
· Communication to affected groups
Best practices:
· Timely completion of documentation and status of the
RFC will reduce confusion or ambiguity around the
status of the change.
· Timely documentation also aids management’s
assessment of change, risk mitigations that depend on
changes moving into production, and accurate metrics
indicating the maturity of the change process (for
example, the number of changes authorized per week,
the number of changes denied approval, and thenumber
of standard changes automatically approvedeach
week).
· When a change is approved and scheduled, update the
CMS with the future state and date of the configuration
change. This will be used in evaluating other proposed
changes.
10
Jun 3 2011 9:33PM
Colombia
Handouts
2. Customer Service Management SMF
Table 2.1.5. Activities and Considerations for Recording the User’s Contact Information
Open a Help Key questions:

request and · Is the caller an internal employee, an outside user, a
record the user’s partner, or a service provider?
contact
· What is the user’s contact information: call back
information
number, e-mail address, and physical address?
· Is the call regarding a new Help request?
· Does the caller have an existing Help request still
open?
· Is the caller reporting an issue for another user?
Inputs:
· Information provided by the user
· HR database
· User contact list
Output:
· A Help request with a unique number provided to the
user that records basic information about the request.
This should include the time of the initial contact so that
CSR time can be tracked
Best practices:
· Capture a call-back number and other user contact
information immediately. In some scenarios, the user
may have just endured a long time on hold to reach a
CSR. If a phone error occurs and the user is
disconnected, the CSR should call the user back
instead of requiring the user to get back in the call
queue.
· Keep call routing systems simple. After more than three
layers of questions, user frustration will grow
exponentially. The flow of the questions should be
changed as infrequently as possible since users who
call often will memorize the sequence. If a change is
made in the sequence, an announcement should inform
the user at the beginning of the call.
· Make good use of pre-recorded messages. For
example, if IT knows that the network is down for an
entire building, the Service Desk is not going to add
value by starting a Help request for every person
affected. Instead, a front-end message should be
recorded and played to all Service Desk callers
informing them of the scope of the incident, its current
status, an estimate of the time it will take to fix it, and
the time that the front-end message will be updated
next.
· These concepts should extend to self-help portals as
well. When there is a known service failure, it should be
posted on the portal site. Use patterns and traffic
11
Jun 3 2011 9:33PM
Colombia
Handouts

statistics should be tracked for the portal to demonstrate
its value.
Receive a Help Key questions:

request · Is the information in the request complete and
automatically accurate?
generated by an
· Does the request include user contact information?
alert
· Can the recorded symptoms be correlated to other
events to provide the CSR with suggested incident
causes?
· Is there sufficient data to set an initial classification and
priority?
Input:
· System alerts from Microsoft System Center Operations
Manager
Outputs:
· Basic contact information and a description of the
incident
· The name of the service or feature affected by the
incident
Receive an Key questions:

automatically · Is the information in the request complete and
generated Help accurate?
request resulting
· Does the request include user contact information?
from a user-
initiated self- · Can the recorded symptoms be correlated to other
service request events to provide the CSR with suggested incident
causes?
· Is there sufficient data to set an initial classification and
priority?
Inputs:
· E-mail templates from embedded support links
· Templates from self-help portals
Outputs:
· Basic contact information for the user experiencing the
incident and a description of the incident
· The name of the service or feature affected by the
incident
Best practices:
· Use templates with a limited number of free-form fields.
This drives consistency in the data collected and
simplifies the process, in turn improving the user
experience.
· Make it quick and easy for users to report non-critical
incidents from within applications and Web pages by
embedding links to automatically generate Help
requests. This creates the opportunity to capture data
about the system state during the incident and
automatically populate it into the request.
· When a request is generated from a self-help portal, the
automation routine should capture a list of the
knowledge base articles or FAQs that the user reviewed
prior to opening the Help request. This can later be
12
Jun 3 2011 9:33PM
Colombia
Handouts

reviewed and used to improve the self-help content.
· Where possible, a confirmation message should be
sent to the user (for e-mail and portal-generated help
requests) that notifies the user of CSR response time
for incidents raised in this manner. The confirmation
should also provide a unique incident record reference
number.
· Some of the best-designed self-help portals go unused
as the result of poor awareness and education
programs. Users must be informed of available self-help
tools and be educated on when and how to use them
effectively. Companies with advanced maturity in
financial management sometimes offer a discount to
business units with users who make effective use of self-
help portals.
Table 2.6. Activities and Considerations for Recording Details of a User’s Request
Record details of Key questions:

the user’s request · What technology or service is the request concerning?
· Has the user made this request before?
· What can’t the user do or what does the user want to
achieve?
· What does the user consider to be a successful
outcome of his or her request?
· If the user is reporting a failure, what does the failure
look like?
· How should the service or feature be performing?
· If the user is reporting an incident, what evidence exists
to confirm the incident?
· If the user is reporting an incident, what are the steps to
recreate the incident?
Inputs:
· Review of previous user requests
· The user’s description of what a failure looks like
· The user’s understanding of how the service or feature
should be performing
· If the user is reporting an incident:
· Evidence provided by the user to confirm the
incident
· The steps provided by the user to re-create the
incident
· Direct experience by re-creating the incident on
another system or by witnessing the incident
through a remote control tool
· Event logs or monitoring tools
Output:
· Help request updated with the details of the user’s
13
Jun 3 2011 9:33PM
Colombia
Handouts

request, which should provide input for classifying,
prioritizing, and resolving the request
Best practices:
· Use a tracking tool that provides customizable
templates and question trees to help the CSR record
the details of the request consistently. However, do not
restrict the CSR to the point that it affects the quality of
information captured.
· The tracking tool should use drop-down lists to drive
this activity; avoid free-form fields. Each drop-down list
should contain an “I don’t know” choice. It is more
valuable to record the number of times a CSR cannot
properly categorize a request than to force the CSR to
guess and choose incorrectly.
· CSRs should be accustomed to speaking in user terms.
Complex or technology-specific language should be
avoided.
Validate the data Key question:

included in an · Is the information in the automated Help request
automated help accurate?
request
Inputs:
· User information records, if available, from contact lists,
HR systems, or configuration management systems
· If necessary, contact the user directly to verify
information
· Help requests created from system alerts should be
validated by reviewing the alert data and checking logs
from the originating system
Table 2.7. Activities and Considerations for Categorizing the User’s Request
Determine if the Key questions:

request is an · Is the user asking ”how to” questions?
Information
· Is the user already using an existing service but has
request
concerns about not getting the desired results or wants
to learn how to use a particular feature?
Inputs:
· IT Service Catalog
Outputs:
· Determination that this is an information request (if not,
continue to the next activity)
· Updated Help request to reflect additional details about
the request
Best practices:
· CSRs should have easy access to a Frequently Asked
Questions (FAQ) document. This document should
include frequently reoccurring information requests
expressed in user-friendly terms.
· Categorizing requests by type (Information, Service, or
14
Jun 3 2011 9:33PM
Colombia
Handouts

Incident) and by area (Technology or Service) provides
important metadata that can be used to identify trends
and to locate possible requests for inclusion in the FAQ
document.
Is this a request Key questions:
for an existing
· Does the user want to gain access to a service or
service or feature?
feature that is already available in the IT Service
Catalog? For more information on service catalogs, see
the Business/IT Alignment SMF.
· Does the user already use the service and want
additional features?
· Is this a service or feature that the user has used in the
past?
· Will the user have any additional service or system
abilities after the request is fulfilled?
Inputs:
Outputs:
· Determination that this is a Service Fulfillment request
(if not, continue to the next activity)
the request
Best practices:
· First, try to determine if the request is for service
fulfillment or incident resolution. Users often say such
things as “I can’t access the monthly reports.” This kind
of statement can lead the CSR to attempt incident
resolution, such as determining if the report site is
down, only to find out later that the user didn’t have
access to the site. If, instead, the CSR had asked a few
additional questions at the beginning of the call, he or
she may quickly have determined that an account
needed to be created for the user on the report site.
· Ensure that the organization understands the difference
between a request for a new service (New Service
request) and a request for an existing service (a Service
Fulfillment request). A New Service request requires
modifying a service or system into a configuration for
which it was not originally designed, or involves creating
a service that doesn’t already exist. A Service
Fulfillment request involves enabling or extending an
existing service or system in a manner for which it was
designed, tested, and certified.
· The best way to avoid confusion is to maintain a list of
Service Fulfillment requests and a brief explanation of
how to identify them.
15
Jun 3 2011 9:33PM
Colombia
Handouts

Is this request fora Key questions:
new service or
· Is the user seeking functionality not provided by an
feature?
existing service or feature?
· What new service or feature is the user requesting?
· What is the justification for the request?
· When does the user want it completed?
· Does this request fit the profile of a standard change?
Inputs:
· Information provided by user
· Existing Requests for Change (RFCs). For more
information about change control and RFCs, see the
Change and Configuration SMF.
Output:
· Determination that this is a New Service request (if not,
continue to the next activity)
Best practice:
· There is a fine line between a request for an existing
service or feature and a new service request.
Requesting an existing service or feature requires
enabling it to perform in a manner for which it was
designed, tested, and deployed. For example, if a Web
server was designed, tested, and deployed to host 500
Web sites, then activating sites 1 through 500 requires
requests for an existing service or feature. A request to
add a 501st site would be a New Service request, which
would have to be reviewed for feasibility and impact. It
might even result in an additional New Service request
to add more hard disk space to accommodate the extra
site.
The dividing line isn’t just about capacity, though. If the
Web server was built to host only static Web sites and a
user submits a request to enable active server pages,
this would also require a New Service request.
Is this request Key questions:
about a failure
· Did the user have access to the service and then lose
with an existing
service or feature? it?
· When was the last time the user successfully used this
service or feature?
· Are others in the user’s work function able to
successfully use this service or feature?
· Has anything changed since the user last used the
service successfully? Has the user moved offices,
changed roles, installed new software, or received a
new computer?
Inputs:
· Information provided by user
Outputs:
· Determination that this is an Incident Resolution request

the request
Best practice:
16
Jun 3 2011 9:33PM
Colombia
Handouts

· In some organizations, up to 80 percent of failures are
attributable to changes in users’ environments. It is a
good idea to check this possibility right away. It is also
possible that an intentional change was made to
remove a service or feature from the user’s computer.
In this case, if the user requests that the service or
feature be returned, approval from Change Control
might be required, and this should be addressed
through a Service Fulfillment request.
Table 2.9. Activities and Considerations for Prioritizing the Request

Determine impact Key questions:
and urgency
· What services are affected or potentially affected?
· What is the likely impact?
· Are any business critical services likely to be affected?
Inputs:
· Service map. For more information about service maps,
see the Business/IT Alignment SMF.
· Help request
· User comments
· Investigation into the request
· Information from the IT Service Catalog. For more
information about service catalogs, see the Business/IT
Alignment SMF.
· The configuration management system (CMS). For
more information about a CMS, see the Change and
Configuration SMF.
Output:
· Metadata added to the Help request to assist with
locating resolution suggestions and priority selection
Prioritize the Key questions:

request · What is the criticality of the business process that is
affected?
· What SLAs are in place?
· How many people are affected?
· What groups are affected: back office support, external
users, or upper management?
Inputs:
· SLAs
· Availability plan
Outputs:
· Determination whether work on other requests should
stop in order to address a new, higher priority request
· Determination of how long the CSR should work on the
request before escalating it to a higher tier of support
· Determination whether a special communication should
be sent to inform users or IT managers of this request.
Should the IT Service Continuity plan be invoked?
Best practices:
17
Jun 3 2011 9:33PM
Colombia
Handouts

· Instead of asking the user to prioritize his or her
request, ask the user to address specific business
impact questions. The user will be more likely to provide
good data to help establish the priority.
· When possible, priorities should be preset by service,
feature set, and business area affected. This should be
captured in the SLA. The classification selected for the
service should also assist in the priority selection. It
may be possible to build logic into the request tracking
tool to set the priority automatically, based on the
request classification.
Table 2.15. Activities and Considerations for Troubleshooting the Incident

Search for and Key questions:

locate applicable · What information is the user trying to obtain?
knowledge base
· Is the user’s question on the FAQ list?
articles or known
error · Is the question regarding something in the IT Service
documentation Catalog?
Input:
· The Help request should provide the information
required to locate applicable knowledge base articles
Outputs:
· Identification of the best-fit knowledge base article
· If an applicable knowledge base article cannot be
located, the CSR should provide the user with a best-
effort attempt to answer his or her inquiry
Best practices:
· Create and maintain a single interface to search for
knowledge base articles. The articles should be
flagged with metadata to organize the search results
by incident type.
· Usage statistics should be recorded to track the
usefulness of articles. This helps identify articles to
retire or enhance or, in some cases, to publish directly
to users through a self-help portal.
18
Jun 3 2011 9:33PM
Colombia
Handouts
Begintroubleshooting Key questions:

· What needs to be fixed?
· Is this a new, unique incident that no applicable
knowledge base articles or known errors can correct?
· Can a CSR effectively troubleshoot the incident?
· Will the fix require a change?
· Can the fix be executed now or should it be scheduled
for later?
Inputs:
· Help request
· User comments
Output:
· Updated Help request with answers to the above
questions
Best practices:
· The entire effort should focus on the resumption of the
service or resolution of the incident. If moving a user’s
network connection from port A to port B will get that
user working again, even though port A is still broken,
then this should be pursued.
· Troubleshooting should be a science and not an art.
Small methodical steps should be taken, changing one
variable at a time. Each step should be documented in
the Help request along with its results. For more
information on troubleshooting, see the Problem
Management SMF.
· Although there are training opportunities and
workshops on troubleshooting, sometimes the best
education is peer-to-peer. Consider establishing an
internal mentoring program to partner employees with
advanced troubleshooting skills with newly hired CSRs.
Is this a planned Key questions:

outage? · Is the outage on the Forward Schedule of Change?
This is a schedule that contains details of all the
changes approved for implementation and their
proposed implementation dates.
· Is this service outside of its standard operating hours?
· Is the user being migrated to a new service?
Inputs:
· Forward Schedule of Change
· Release plans
· Automated maintenance records
Output:
· Updated Help request
Best practice:
· If this is a planned outage, the Help request should be
updated and closed with a reason code to note that it
was a planned outage. This data can later be used to
track the effectiveness of communications around
changes and maintenance activities.
19
Jun 3 2011 9:33PM
Colombia
Handouts
Review the Help Key questions:

request history · What are the details of the incident?
· What has been attempted already?
· Has the service been resumed?
· Is the information complete and correct?
Input:
· Help request
Output:
· Determination of what has already been attempted to
resolve the incident
Best practice:
· The Help request should capture all of the details so
that anyone encountering the request can gain a full
understanding of the efforts previously taken. Help
requests may move between several teams before
being resolved. Word-of-mouth reassignment will lead
to misinformation or lost facts, prolonging the
troubleshooting efforts and often resulting in contacting
the user to answer the same questions again.
Are the Key questions:

classification and · Should this Help request be assigned to a different
priority correct? team?
· Did the Service Desk check the wrong categories in
the knowledge base and known error records?
· Is the priority correct?
· Has the scope of the request been expanded?
Input:
· Help request
Outputs:
· Decision to continue working on the request or transfer
it to another team for additional effort
· Properly updated Help request
Best practices:
· The insights used to correct the classification should
be captured in the Help request—including how it was
discovered to be the wrong classification and what
information was used to classify it correctly.
· When possible, a phone call directly to the CSR who
misclassified the Help request can help to ensure that
the CSR knows that the request is being returned and
that the CSR is prepared to accept it and resume
working on it.
· The Service Desk needs to stay informed of any
significant changes in the status of an incident.
Changing the priority of a request can have a major
impact on SLAs. Additionally, if the incident has moved
up in priority, it could require special notification and
communication procedures.
20
Jun 3 2011 9:33PM
Colombia
Handouts

Is the incident Key questions:
resolved?
· Has the service returned to its normal operating state?
· Can the user confirm that the service is working
correctly?
·
·
·
·
Inputs:
· Monitoring tools
· User comments
Outputs:
· Additional actions to resolve the incident
· RFCs to correct additional faults discovered during
service resumption
Best practices:
· Use monitoring and diagnostic tools correctly. For
example, confirming that a desktop is connected to the
network after rebooting it does not ensure that it has
restarted correctly and is ready for the user to log on to
it. However, starting a remote session to see what is
displayed on the user’s screen will tell a more accurate
story.
· Once the user is able to resume his or her business
function, attention should turn to any outstanding
activities that need to be performed to completely
correct the incident. In some events, it might be
necessary to transfer the Help request to a separate
group to address the outstanding activities.
· Know the difference between resolving an incident and
creating a change. Placing a system back into an
operating state is a resolution activity. Modifying the
configuration, setup, design, or appearance of a
system or service by placing it in a new state is a
change.
21
Jun 3 2011 9:33PM
Colombia
Handouts

If the incident is still Key questions:
not resolved, try
Problem · Does solving this incident require more research and
Management testing?
· Would solving this incident benefit from root cause
analysis?
Inputs:
· Help request
· Problem Management process. This process is not a
part of the Customer Service SMF, but is described in
detail in the Problem Management SMF
Output:
Best practice:
· Problem Management is a separate process that
involves documenting and filtering a problem, then
systematically performing research, developing and
testing hypotheses, performing root cause analysis,and
determining if a fix or workaround has been discovered.
It is a very important process that should be pursued if
an incident resists normal troubleshooting efforts.
Table 2.16. Activities and Considerations for Escalating the Request

Escalate or Key questions:
transfer the Help
· Is additional technology expertise required to resume
request
the service? (Escalate)
· Is there a different technology focus required? (Transfer)
Input:
· Help request
Output:
· A determination of which additional areas to involve in
resolution attempts
Best practices:
· Support organizations should classify team members by
their depth of expertise. This is often referred to as
tiered support. The higher the tier, the greater the
specialization or expertise and, often, the expense.
Therefore, it is always desirable to resolve incidents at
the lowest tier of support.
· All requests and incidents addressed by CSRs should
be counted toward the First Call Resolution metric.
Efficient IT organizations are able to achieve 80 percent
and higher first call resolution rates.
· Within each tier, resources should be grouped by area
of focus. The focus could be on a particular technology
or a specific line of business.
· The first tier, and broadest area of focus, is the Service
Desk. The Service Desk should maintain a level of
ownership for the Help request even if it is assigned to
different areas and tiers. This provides continuity in
communication between the user and the IT
organization. In addition to SLA monitoring, this also
22
Jun 3 2011 9:33PM
Colombia
Handouts

provides a layer of protection to keep things from
”slipping through the cracks.”
Table 2.17. Activities and Considerations for Applying a Fix or Workaround

Apply fix or Key questions:
workaround
· Are there any prerequisites for the fix or workaround?
· Will it take effect immediately?
· Are there follow-up actions? Is a reboot needed?
· Will the service resumption efforts be more disruptive
than the current incident?
· Does the CSR have the permissions required to apply
the fix or workaround?
Input:
Outputs:
· Decision to attempt resumption, defer until later, or
engage different resources to take action
· Results of resumption efforts
Best practice:
· Keep focused on the service and the business impact
of applying a fix or workaround. Although it is in IT’s
interest to fix any malfunctioning system, sometimes
the timing of a fix can have a major impact on the
business. Rebooting a VOIP router for a sales office
during peak call times in order to correct a complaint
about calls echoing could result in dropping active calls
and losing new users.
Set user Outputs:
expectations
· User informed of the expected time required to
complete the Help request
· Request updated with an estimated time of completion
Best practices:
· If possible, the request should be completed
immediately. This saves time that might be consumed
with follow-up activities if the user has to be contacted
later.
· Ensure that there is a method to track incomplete Help
requests and assign CSRs to follow up until they are
completed.
Initiate the service Key questions:
fulfillment
· Can this procedure be executed at any time?
procedure
· Are there any prerequisites?
· Is there an authorization required to proceed?
Input:
· Service fulfillment procedure
Outputs:
· Estimate of the time and effort required to complete the
Help request
· Begin the fulfillment procedure
23
Jun 3 2011 9:33PM
Colombia
Handouts

Best practice:
· Fulfillment procedures should follow a consistent
template that ensures that information such as
required authorization, prerequisites, license
requirements, and financial impacts are documented.
Table 2.18. Activities and Considerations for Confirming the Resolution and Closing the Request
Update the Help Key questions:

request with the · Which articles or known error records were applied?
knowledge base
· Was more than one article or known error record required
articles and known
to resume the service?
errors that were
reviewed or · Did any article or known error record used make the
applied incident worse?
· Did some articles seem to apply but have no effect?
Inputs:
· Help request
· Knowledge base articles
Output:
· Triggers to capture inaccurate information that is delaying
service resumption efforts
Best practice:
· Help requests should maintain a two-way association with
knowledge base articles and known error records.
Has the service Key questions:

been resumed? · Has the service returned to its normal operating state?
· Can the user confirm that the service is working correctly?
Inputs:
· Monitoring tools
· User comments
Outputs:
· Additional actions to resume the service
Has the incident Key questions:

been resolved? · Are there additional steps required to resolve the incident?
· Were modifications made to the environment in order to
resume the service that need to be backed out?
· If no further action is taken, will the service fail again soon?
· Were spare parts or standby systems used to resume
service?
Inputs:
· Monitoring tools
· User comments
Outputs:
· RFCs to correct additional faults discovered during service
resumption
24
Jun 3 2011 9:33PM
Colombia
Handouts
Verify successful Key question:

fulfillment · Is the user receiving the intended benefit of the service
requested?
Input:
· User feedback
Output:
· Updated Help request that indicates the outcome of the
service fulfillment procedure
Best practice:
· When possible, a CSR should contact the user directly to
verify that the request was completed correctly. Direct
contact can be in the form of a phone call or a
personalized e-mail. The key to success for e-mail
communications is to ensure that the message includes
the Help request’s unique reference number and that
replies to the e-mail are routed to a live person for a timely
response.
Close the Help Key questions:

request · Was the request fulfilled successfully?
· Are there any post fulfillment requirements or actions?
· Was the procedure easy to follow and accurate?
· Could the procedure have been executed by the user?
· Is there a way to improve the procedure?
Output:
· Key data points to generate improvements in the service
fulfillment process and improvements to fulfillment
procedures
Best practices:
· The Help request should have specific fields dedicated to
capturing closure data. Each field should be tied to a
specific outcome with well understood values. All such
fields should be mandatory and driven by drop-down lists
to ensure consistency in data for reporting and evaluation.
· Over time, it may become necessary to add fields or new
classifications. Providing regular training to new and
existing staff is critical to disseminating this information
and continuing to drive consistency in the execution of the
process.
25
Jun 3 2011 9:33PM
Colombia
Handouts
Table 2.19. Activities and Considerations for Providing Service Desk Quality Assurance
Verify the Key question:

resolution of the · Has the user been contacted directly and did he or she
Help request confirm the resolution of the Help request?
Input:
· Help request
Output:
· Determination to close the Help request or to continue
troubleshooting
Best practice:
· As part of the end-to-end ownership of a Help request
throughout its lifecycle, the Service Desk is accountable
for ensuring that the user is able to do his or her job.
However, there is a fine line between providing
customer service and annoying a user. If another group
has provided clear evidence in the Help request that the
user has confirmed resumption and resolution, then no
additional follow up is required.
Send user Input:

satisfaction survey · User satisfaction survey
Output:
· Feedback and data for continuous improvement
Best practice:
· Keep the survey short and to the point. The survey
should be tailored to the type of request and should
generate metrics that link directly to key performance
indicators. A 4-question survey that users answer 80
percent of the time is more useful than a 10-question
survey that they answer only 25 percent of the time.
Table 2.20. Activities and Considerations for SLA Monitoring and Metrics
Is the SLA 80 Key questions:

percent expired? · How is the SLA time measured?
· What is the target time?
· What is the target action?
· What is the appropriate SLA expiration threshold for
initiating action to meet the SLA?
· What SLA objective has been missed?
· How is it measured?
Input:
· SLA
Output:
· Alert trigger
Best practice:
· There should be default measurements for each priority
of Help requests. However, this should be overridden
by documented targets within an SLA.
26
Jun 3 2011 9:33PM
Colombia
Handouts

Alert the Help Key questions:
request owner · Who is currently working on this Help request?
· Is the current owner of the request now available?
· Should an alternate person be alerted?
· Is there an on-call or duty manager?
Inputs:
· Help request tracking tool
· Support schedule
· Microsoft® Windows Live™ Communications Server
(LCS) presence
Output:
· Alert trigger
Best practice:
· Alerts should be consistent and agreed upon. Where
possible, visual cues should flag Help requests within
the tracking tool. However, not all teams will visually
monitor the tracking tool at all times. In these cases,
alerts should be sent via e-mail or Short Messaging
Service (SMS) devices.
Alert management Key questions:

staff and business · Who needs to know about this SLA breach?
· How can the breach be explained in business impact
terms?
· What roadblocks exist to resuming service?
Input:
· SLA
Output:
· Informed and engaged management
Best practice:
· If an SLA is missed, IT management should not find out
from a phone call from a displeased user. Likewise,
users need to be informed that IT management is
engaged and working toward an expedient resumption
of service.
27
Jun 3 2011 9:33PM
Colombia
Handouts
3. Problem Management SMF
Table 3.4. Activities and Considerations for Documenting the Problem

Create a problem Key questions:
record
· What are the symptoms of the problem?
· Is there an existing problem record with the same
symptoms?
· Has a known error record already been created?
Inputs:
· Incident record
· Events from System Center Operations Manager
· Trends discovered from operational data
Output:
· A record that tracks the symptoms and scenario
surrounding the observation of the problem
Best practices:
· Detailed data is important. A Problem Management
tracking system should allow users to attach or link to
logs, screenshots, dump files, and other diagnostic
data.
· Tight integration between the customer service tracking
system and the Problem Management tracking system
is very beneficial. Whenever a problem record is
created as the result of a Help request, the two should
be linked together for future analysis and review.
Classify the Key Questions:

problem · What are the available classifications?
· Are there applicable sub-classifications?
· What is the best-fit classification to select?
Inputs:
· Working knowledge of the environment
Outputs:
· Metadata added to the problem record to help associate
it with other data previously collected
· Data to help properly document information coming out
of Problem Management to make it usable by the
customer service process
Best practices:
· Classification should be a best-fit approach.
· It is important to offer an “unknown” option. If the
problem does not fit into an existing classification, a
new classification might be required. Users of the
Problem Management tracking system should not be
forced to select an incorrect class, as this can skew the
data.
28
Jun 3 2011 9:33PM
Colombia
Handouts
Prioritize the Key questions:

problem · Is there a Help request from the customer service
tracking system associated with this problem?
· How many people does, or could, this problem affect?
· How significant is, or would be, the impact to important
business processes?
· Is this an obvious one-time occurrence?
· What is the criticality of the business process being
affected?
· What SLAs are in place?
· What groups of people are affected: back-office
support, external customers, or upper management?
Inputs:
· Data from the problem record
· Related Help requests
· Operational data and evidence
Outputs:
· A determination of the priority of this problem over
others
· A determination of whether this problem should be
deferred to a later time
Best practice:
· It is important to prioritize consistently. Building a matrix
into the Problem Management tracking system can help
guide users to setting meaningful priorities.
Table 3.5. Activities and Considerations for Filtering the Problem

Filter the problem Key questions:

· Has a problem record already been created for the
problem?
· What is the business justification for researching this
problem?
· How many hours will it take to reproduce the problem?
· What is the payoff if a fix is found?
Inputs:
· Data from the problem record
· Experience from past similar problems
Output:
· Determination to continue work on the problem or to
close the record
Best practices:
· Turning down a challenge can be difficult for motivated
and curious IT professionals. After all, technology is
driven by a desire to understand how things work and
how to fix them when they stop working. However,
when it comes to managing the IT resources in a
29
Jun 3 2011 9:33PM
Colombia
Handouts

business, a proper balance must be maintained. There
must be a justifiable reason for solving the problem.
· The filtering activity demands an objective review of the

problem. If the benefit of fixing it does not significantly
outweigh the cost of researching and fixing the problem,
then a fix probably should not be attempted. If more
data is discovered later that provides more details, the
problem can be revisited.
Table 3.6. Activities and Considerations for Researching the Problem

Reproduce the Key questions:

problem · Can the problem be reproduced at will?
· What user context or security access is required to
reproduce the problem?
· Will special lab equipment be required or can this be
reproduced on any system?
Input:
· Problem record
Outputs:
· An environment where the problem can be studied and
observed
· A new or updated known error record
Best practices:
· Production systems should not be used for Problem
Management work if at all possible. In scenarios where
the problem can only be reproduced in production,
extreme care must be taken so that the act of
observation does not affect the system. System
monitoring and debugging tools can cause drops in
performance. In some cases, the service might have to
be taken offline to use these tools. Activities like this
must be treated as changes and should be passed
through the Change Management and Change Control
processes. See the Change and Configuration SMF for
more information.
· It may be tempting to introduce small changes to
systems and services, disguising them as “Break-Fix”
activities. This should not be allowed. Change and
problem processes should work hand-in-hand to drive
stability and reliability into production services.
Circumventing reviews and approval activities for
changes can have negative impacts.
· The steps discovered to reproduce the problem should
be documented in full detail in the problem record. In
the event that others get involved in working on the
problem, this ensures that the steps are reproduced
exactly the same way each time.
30
Jun 3 2011 9:33PM
Colombia
Handouts
Observe the Key questions:

symptoms of the · What are the symptoms of the problem?
problem
· How can they be observed?
· What tools are required to capture and record the
occurrence of the problem?
Inputs:
· Problem record
· Lessons learned during reproduction
Outputs:
· An understanding of the timing, triggers, and results of
the problem
· New or updated known error record
Perform root Key question:

cause analysis · What technique should be used for performing root
cause analysis? To learn about some of the available
techniques, see “Root Cause Analysis Techniques” in
this guide.
Inputs:
· Selected root cause analysis technique
· Problem record
Outputs:
· Hypothesis to test
Develop a Key questions:

hypothesis · What actions might work around this problem?
· What actions might fix this problem?
· Could this problem be the result of another problem?
· Have changes been made to the service or system
recently that may have created the problem?
Inputs:
· Output from root cause analysis
· Problem record
Outputs:
Best practice:
· Document, document, document! Effort documented
today is effort avoided tomorrow. As the Problem
Management process is repeated, it can become
increasingly more efficient by using data created during
previous efforts. This means that all hypotheses should
be documented in the problem record. Information such
as the reasoning behind the hypothesis, how to test it,
and what the expected results are should be captured.
Test the Key questions:

hypothesis · What actions might work around this problem?
· What actions might fix this problem?
31
Jun 3 2011 9:33PM
Colombia
Handouts

· Could this problem be the result of another problem?
· Have changes been made to the service or system
recently that may have created the problem?
Inputs:
· Problem record
Output:
Best practices:
· Keep a control system in place to compare results of
the testing. This system should remain unmodified
during the testing of any hypothesis. This enables the
testers to determine if their actions have resolved the
problem or if some other uncontrollable factor has been
introduced.
· Test only one hypothesis at a time, and test each
hypothesis one step at a time. Introducing complex
modifications can make it difficult to pinpoint the actual
workaround or fix.
· Document all of the results—both positive and negative
outcomes.
· If circumstances force these activities to take place on
production systems, make sure that proper change
procedures have been followed and that back-out plans
are tested and in place.
Table 3.7. Activities and Considerations for Researching the Outcome

Activities Considerations
Has a workaround Key questions:

or fix been · Has a workaround or a fix been discovered?
discovered?
· Are there any prerequisites to applying this knowledge?
· What level of authentication is required to use this
knowledge?
Inputs:
· Problem record
· Research process
Output:
· Updated known error record with step-by-step
instructions for the workaround or fix for this problem
Best practices:
· If the workaround or fix requires a change and is
expected to be implemented many times, Change
Control should be engaged to provide guidance on
establishing a standard change. See the Change and
Configuration SMF for more information.
· Workarounds and fixes should be documented in great
detail. The known error record should be updated to
reflect that a workaround or fix is available, and the
record should be displayed when searching for
problems with similar symptoms.
· Known error record usage should be tracked and
32
Jun 3 2011 9:33PM
Colombia
Handouts
reported. Counting the number of times a workaround is
applied can provide justification for developing a fix.
Tracking the number of times a fix is applied can
provide justification for retrofitting existing systems with
the fix.
· If a known error record is seldom accessed, this may
indicate that the problem had a low value and shouldn’t
have been pursued, or that the record is poorly
documented and is not being displayed in searches, or
that the record is too difficult to follow. Use this
information to improve your processes.
Is a proactive Key questions:

action possible? · Could this workaround or fix be applied proactively?
· What tools are required to deploy it?
· What is the benefit of proactive action for this error?
Input:
· Research process
Output:
· Change Management engaged to start a Request for
Change (RFC)
Best practices:
· All Problem Management is reactive. You cannot
research and resolve an error before it occurs.
However, workarounds and fixes can be applied
reactively or proactively.
· After Problem Management has discovered a beneficial
action to alleviate the impact of an error, it can either
provide the knowledge for reactive use by entities such
as the Service Desk, or deploy the action proactively.
However, proactive work can sometimes require more
planning, preparation, and effort than the reactive
application of a workaround or fix. If the action is only
beneficial to a small number of systems, it may be more
economical to allow the Service Desk to address them
one-by-one as the problem is encountered. If the action
is beneficial to many systems or an entire department,
the effort to prepare and execute a large-scale proactive
deployment is justified.
To learn more about resolving problems proactively,
See “Proactive Analysis” in this guide.
33
Jun 3 2011 9:33PM
Colombia
Handouts
Close the problem Key Questions:

record · Is there any value to be added by continuing work on
this problem record?
· Has all of the appropriate known error recordinformation
been updated?
· Have all changes associated with this problem record
been completed?
Input:
· Problem record
Outputs:
· Updated problem record
· Validation that all meaningful efforts for this problem
have been concluded
Best practices:
· Do not confuse problem records with known error
records. Problem records track the work effort, actions,
and decisions associated with working on a particular
problem. When work on that problem has come to a
close, so too should the problem record.
The known error record lives on in the known error
database. That record should be tracked and reviewed
and possibly updated from time to time.
34
Jun 3 2011 9:33PM

50217A-EnU StudentManualAppendix 02

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

50217A-EnU StudentManualAppendix 02

Uploaded by

Copyright:

Available Formats

Intelligent Training De

1. Change and Configuration Management

Table 1.4. Activities and Considerations for Baselining the Configuration

Define and collect Key questions:

Activities Considerations Students notes

Audit the CMS Key questions:

Table 1.5. Activities and Considerations for Initiating the Change

Initiate a request Key questions:

Activities Considerations Students notes

Check the Key questions:

Activities Considerations Students notes

Check the Key questions:

Identify the Key questions:

· How will the business justification or impact be

Table 1.6. Activities and Considerations for Classifying the Change

Identify the priority Key questions:

Activities Considerations Students notes

Identify the Key questions:

Activities Considerations Students notes

Table 1.7. Activities and Considerations for Approving the Change

Route the change Key question:

Activities Considerations Students notes

Activities Considerations Students notes

Activities Considerations Students notes

Activities Considerations Students notes

2. Customer Service Management SMF

Activities Considerations Students notes

Open a Help Key questions:

Activities Considerations Students notes

Receive a Help Key questions:

Receive an Key questions:

Activities Considerations Students notes

Record details of Key questions:

Activities Considerations Students notes

Validate the data Key question:

Determine if the Key questions:

Activities Considerations Students notes

Activities Considerations Students notes

· Updated Help request to reflect additional details about

Activities Considerations Students notes

Table 2.9. Activities and Considerations for Prioritizing the Request

Prioritize the Key questions:

Activities Considerations Students notes

Table 2.15. Activities and Considerations for Troubleshooting the Incident

Search for and Key questions:

Activities Considerations Students notes

Begintroubleshooting Key questions:

Is this a planned Key questions:

Activities Considerations Students notes

Review the Help Key questions:

Are the Key questions:

Activities Considerations Students notes

Activities Considerations Students notes

Table 2.16. Activities and Considerations for Escalating the Request

Activities Considerations Students notes

Table 2.17. Activities and Considerations for Applying a Fix or Workaround

Activities Considerations Students notes

Update the Help Key questions:

Has the service Key questions:

Has the incident Key questions:

Activities Considerations Students notes

Verify successful Key question:

Close the Help Key questions:

Verify the Key question: