USAMITC Enterprise Service Desk _ESD_ Concept of Operations

					  USAMITC Enterprise Service
       Desk (ESD) Concept of
       Operations (CONOPS)




                      Prepared By:
US Army Medical Information Technology Center (USAMITC)
                                       USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




DOCUMENT HISTORY
                             Description of
Ver.         Date                                  Status                   Document No.
                                  Change
                          Initial development    Initial         MCMR-ISP-ESD-CONOPS-
1.0      27 Nov 2006
                          and submittal          Release         2006-11-27-1.0
                          Content update and
                                                 Approval        MCMR-ISP-ESD-CONOPS-
1.1      13 Dec 2006      staffing approval
                                                 Release         2006-12-13-1.1
                          submission
         9 February                                              MCMR-ISP-ESD-CONOPS-
1.2                       Update                 Release
         2007                                                    2007-02-09-1.2
                                                                 MCMR-ISP-ESD-CONOPS-
1.3      1 May 2007       Review                 Release
                                                                 2007-05-01-1.3

SUGGESTED IMPROVEMENTS: Send comments, suggested improvements, or
recommendations to US Army Medical Information Technology Center (USAMITC),
ATTN: MCMR-ISP, Project Management Division, 2710 Howitzer, Fort Sam Houston,
TX 78234.

DISTRIBUTION STATEMENT: Distribution is limited to US Government agencies and
their contractors who have a need-to-know as imposed by AR 380-5.

TRADEMARKS AND REFERENCES:

US Government Restricted Rights: Trademarked names may appear throughout this
document. Rather than list the names and entities that own the trademarks or insert a
trademark symbol with each mention of the trademarked name, the publisher states the
names are used only for editorial purposes and to the benefit of the trademark owner
with no intention of infringing upon that trademark.




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                  i
1 May 2007
                                                              USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




TABLE OF CONTENTS
1.0 INTRODUCTION .................................................................................................................................. 1
       1.1 ESD Background ............................................................................................... 1
       1.2 Mission Description ............................................................................................ 2
       1.3 Stakeholders and Customers ............................................................................. 2
2.0 BUSINESS NEED ................................................................................................................................. 2
       2.1 Current MEDCOM Support Model ..................................................................... 3
       2.2 Current ESD ITIL Implementation ...................................................................... 4
3.0 ESD SOLUTION ................................................................................................................................... 4
       3.1 ESD Support Model at a Glance ........................................................................ 4
           3.1.1 Support Tiers ............................................................................................ 5
           3.1.2 Support Services ...................................................................................... 6
           3.1.3 Support Tools ........................................................................................... 7
           3.1.4 Customer Relations .................................................................................. 8
           3.1.5 Quality Management ................................................................................ 8
       3.2 Incident Management ........................................................................................ 9
           3.2.1 Overview and Policies .............................................................................. 9
           3.2.2 Roles and Responsibilities ....................................................................... 9
           3.2.3 Incident Severity ..................................................................................... 10
           3.2.4 Interface Information............................................................................... 12
           3.2.5 High-level Incident Management Process Flow ...................................... 13
           3.2.6 Internal Incident Resolution Process Flow .............................................. 16
       3.3 Problem Management ...................................................................................... 18
           3.3.1 Overview and Policies ............................................................................ 18
           3.3.2 Roles and Responsibilities ..................................................................... 19
           3.3.3 Interface Information............................................................................... 19
           3.3.4 High-level Problem Management Process Flow ..................................... 20
       3.4 ITIL Processes to be Implemented ...........Error! Bookmark not defined.Error!
           Bookmark not defined.
           3.4.1 Change Management ... Error! Bookmark not defined.Error! Bookmark
                 not defined.
           3.4.2 Release Management .. Error! Bookmark not defined.Error! Bookmark
                 not defined.
           3.4.3 Availability Management..................Error! Bookmark not defined.Error!
                 Bookmark not defined.
           3.4.4 Configuration Management .............Error! Bookmark not defined.Error!
                 Bookmark not defined.
           3.4.5 Information Technology Continuity Management .... Error! Bookmark not
                 defined.Error! Bookmark not defined.
4.0 BENEFITS DERIVED ......................................................................................................................... 41
5.0 PROJECT CONSTRAINTS AND CONSIDERATIONS ..................................................................... 43


MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                                              ii
1 May 2007
                                                              USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



       5.1    Existing Systems Affected................................................................................ 43
       5.2    Constraints ....................................................................................................... 43
       5.3    Deployment Considerations ............................................................................. 44
       5.4    System Support ............................................................................................... 44
6.0 REFERENCES ................................................................................................................................... 44




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                                             iii
1 May 2007
                                              USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




TABLE OF FIGURES
Figure 1.       Incident Severity Criteria ........................................................................ 10
Figure 2.       Incident Management Process Flow ...................................................... 13
Figure 3.       Incident Management Process Flow Narrative ....................................... 13
Figure 4.       Internal Incident Resolution Process Flow ............................................. 16
Figure 5.       Internal Incident Resolution Process Flow Narrative .............................. 17
Figure 6.       High-level Problem Management Process Flow ..................................... 20
Figure 7.       Problem Management Process Flow Narrative ...................................... 21




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                          iv
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




SUBMITTED BY:



_____________________________                               Date: ______________________

DAVID A. TUTTLE
Project Director, Project Management Division
US Army Medical Information
 Technology Center


APPROVAL:



_____________________________                             Date: _______________________

PATRICIA B. RICHARDSON
Acting Chief, Project Management Division
US Army Medical Information
 Technology Center



ACCEPTANCE:



_____________________________                             Date: _______________________

PAUL D. KENNEDY
Chief, Customer Service Division
US Army Medical Information
 Technology Center




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                v
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




1.0     INTRODUCTION
The purpose of this Concept of Operations (CONOPS) document is to describe the
current state of support services within the Army Medical Command (MEDCOM) and
how to improve these Information Management/Information Technology (IM/IT) support
services. This document describes the shortcomings of the current help desk support
solution and compares them to the benefits of the Enterprise Service Desk (ESD)
solution. This document also covers the future improvements the ESD will implement to
improve its efficiency and level of service.

1.1    ESD Background
In March 2005, the ESD was established at the United States Army Medical Technology
Center (USAMITC) to provide IM/ITsupport to customers within MEDCOM. ESD started
by providing Tier 2 support for Microsoft Active Directory (AD) and Microsoft Exchange
services across the MEDCOM enterprise and by providing local Tier 1 and Tier 2
desktop support for USAMITC.

Since that time the ESD has expanded its services for the MEDCOM enterprise to
include full support for BlackBerrys, Common Access Card (CAC) provisioning, and
wireless and remote access. The ESD has also expanded to system health monitoring
for the AD domain controllers at 45 MEDCOM sites and for the Microsoft Exchange
servers at the six MEDCOM messaging centers at the Tier 1 level.

In September 2006, as part of a pilot program, the ESD expanded its staff and assumed
responsibility for Tier 1 support for the Carl R. Darnall Army Medical Center (CRDAMC)
at Fort Hood, Texas. To provide top-notch technical support for CRDAMC customers,
the ESD offers remote desktop support in conjunction with the on-site Tier 2 desktop
support technicians. The ESD has been able to dramatically improve service for the
customers at CRDAMC in the following ways:
          Expanded service hours from five days a week only during business hours, to
           24/7/365 support.
          Lowered average call time-to-answer from 34 seconds to 12 seconds.
          Reduced call abandonment rate from 4% to less than 1%.
          Greatly increased the first call resolution rate from 28% to over 61%.

The pilot program at CRDAMC is intended to determine whether a centralized ESD can
effectively provide superior customer service with lower costs to the various medical
treatment facilities (MTFs) and major subordinate commands (MSCs) within MEDCOM.

In an effort to continue to improve itself, the ESD will be implementing a number of best
practices as described in Information Technology Infrastructure Library (ITIL)
framework. Specifically, the ESD will be analyzing and implementing various concepts
from ITIL including the following:
          Incident Management.


MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                1
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




          Problem Management.
          Change Management.
          Release Management.
          Availability Management.
          IM/IT Service Continuity Management.
          Configuration Management.

1.2    Mission Description
This project maintains that the level of IM/IT technical support across MEDCOM is very
inconsistent; some sites have excellent customer service, while others provide less than
the basic service. It also maintains that it is almost impossible to measure and gauge
the levels of customer service across the enterprise; moreover, there is a high amount
of redundant effort as each pocket of support works to solve issues and improve service
independently with little or no information shared between sites.

It is the mission of the ESD project to show that a single, centralized, remote service
desk can provide consistent, high-quality IM/IT support services on an enterprise level
to all Army Medical Department (AMEDD) customers at or below current funding levels
for these services. Specifically, this project will accomplish the following:
          Prove that maintaining a single service desk for the entire MEDCOM
           infrastructure can be done at a lower cost than maintaining multiple service
           desks at many locations.
          Provide consistent, high-quality service desk support to all (local and remote)
           MEDCOM customers.
          Demonstrate that a high customer satisfaction rating can be established and
           maintained regardless of location.
          Establish complete and mature service desk procedures that include incident,
           problem, escalation, change, and configuration management.

1.3    Stakeholders and Customers
Major stakeholders consist of the Office of the Surgeon General (OTSG), AMEDD,
MEDCOM, USAMITC, and the Commanders and Information Management Officers
(IMOs) at the MTFs and MSCs. The functional proponent is Ms. Terry Gregurvich, HQ
MEDCOM Information Management Directorate (IMD).

2.0    BUSINESS NEED
This section describes the current IM/IT technical support solution in MEDCOM and the
many disadvantages of this solution. It also describes the current ITIL implementation at
the ESD.




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                 2
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




2.1    Current MEDCOM Support Model
MTFs and MSCs throughout MEDCOM currently maintain their own local service desk
operations with local personnel and locally operated service desk systems. In most
cases, there are dedicated people whose primary job is to receive, log, and track
service calls for each facility. In some locations, the same people not only receive and
monitor the calls, but also provide hands-on support. The systems and methods used to
provide technical support services range from pencil-and-paper trouble tickets to service
desk applications, such as REMEDY, CA Unicenter Help Desk, LAN Desk, HEAT,
TRACK-IT, and others. All known service desk implementations in the MEDCOM today
are point solutions that only address local or regional needs.

Local management of service desks has resulted in varying levels of success
depending on funding priorities and procedures established at each location. Clearly,
some of the largest MTFs and MSCs have expended extensive resources that
adequately support their customer communities; however, the results of these
expenditures have only benefited these pockets of fortunate customers, while
customers at other locations with smaller budgets receive less than adequate support.
Even more disturbing, there is no mechanism in place to adequately measure these
relative successes and failures on an enterprise level. Consequently, leadership is not
provided with enough data on which to base decisions evolving optimization of
information resources.

Currently, the distributed manner in which the MEDCOM performs service desk support
causes significant inefficiency. Inefficient activities include, but are not limited to, the
following:
          Tier 2 and Tier 3 expertise at one site rarely gets communicated to other sites
           facing similar issues. Even though one site with excellent support finds many
           solutions to problems, other commonly smaller sites, may languish with these
           same problems. This problem persists largely because there is no means to
           share these resources and centrally manage the knowledge across the
           enterprise.
          Each location maintains its own ticket tracking system and knowledge
           database. This unnecessary duplication wastes hardware, software, and
           personnel - quite apart from the resulting failure to exploit and share valuable
           data. The hardware, maintenance, and duplicative personnel costs fail to
           achieve MEDCOM’s goal for increasing efficiency through exploitable
           economies of scale.
          Under exploited resources result when local sites use their expensive Tier 2
           and Tier 3 support resources to perform simpler Tier 1 services. Smaller sites
           in particular must staff more expensive experts equal to their most difficult
           problems, or endure service attenuation in the form of partial system failures
           and/or reduced functionality which result when they lack expertise in a
           particular subject area. Less funded sites must often engage high-cost
           outsourced resources for major outages and system failures.



MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                 3
1 May 2007
                                       USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




          Few MTFs and MSCs can justify the cost of the most advanced automated
           service desk solutions because they do not have enough local customers.
          When 24×7 support is unavailable, customers must wait until thier local
           support center is open. Frustration and lowered productivity result.
          Most customers must now communicate issues to four individual service
           desks, depending on the issue. Support requests can be addressed to:
            The local service desk for desktop support or issues of an unknown origin.
            Military Health Systems (MHS) Help Desk for MHS application support,
              such as AHLTA or the Joint Patient Tracking Application (JPTA).
            Army Network Enterprise Technology Command (NETCOM) Help Desk
              for network and connectivity issues.
            USAMITC Service Desk for AD, Microsoft Exchange, BlackBerry, and
              other enterprise application support.

The current distributed systems approach results in a confusing, frustrating situation for
customers and delays in the resolution of their problems.

2.2    Current ESD ITIL Implementation
Although the ESD does provide top-notch service and support, the current ESD
procedures do not embody all the various best practices as described in the ITIL. To
date, the ESD has fully implemented ITIL Incident Management and partially
implemented Problem Management. The ESD recognizes that the practices described
in ITIL have far-reaching benefits to the level of technical support the ESD can provide
to its customers. The lack of solid, mature processes plus a shallow understanding of
ITIL practices have created the following difficulties:
          Inconsistent terminology outside the established ITIL standards has created
           some confusion while establishing processes and procedures.
          Lack of understanding of IM/IT Service Level Management concepts has
           resulted in a lack of direction for implementing better procedures and
           processes.

3.0    ESD SOLUTION
This section describes the aspects of the ESD solution: the ESD support model at a
glance, the services provided by the ESD and how they do business, and the details of
the various ITIL procedures that the ESD has implemented and will implement in the
future.

3.1    ESD Support Model at a Glance
The ESD provides a measured variety of services and support to its customers. This
section covers the following topics:
          The different tiers of support and their areas of expertise.


MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                  4
1 May 2007
                                       USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




            The various service offerings available from the ESD.
            The tools used to provide support.
            The working relationship the ESD has with its customers.
            Service Level Agreement, (or Quality Management), at the ESD.

3.1.1 Support Tiers

The ESD has four tiers of service. Each tier has a focus on certain types of support as
shown below. These areas of support will be explained later in section 3.1.2.

Tier 1

Tier 1 support is the customer’s point of contact (POC), focusing on customer
relationships; primarily consisting of these activities:
            Provides the initial customer POC..
            Provides remote desktop support.
            Provides remote application support.
            Logs and tracks incidents.
            Follows up on unresolved incidents.
            Confirms incident resolution actualizing the Service Level Agreement.

Tier 2

Tier 2 support matches customers with systems experts, handling more complex
support issues that require a higher skill level or high levels of system access (e.g.,
administrator privileges). Tier 2 support divides into 3 categories:
         1. Providing support for MEDCOM enterprise systems software:
             Microsoft AD.
             Microsoft Exchange.
             BlackBerry.

         2. Monitoring MEDCOM hardware and facilities for both physical and logical
            outages:
             MEDCOM AD domain controllers.
             MEDCOM messaging center domain controllers.
             MEDCOM Exchange servers.
             MEDCOM Routers and Virtual Private Networks
             Data Center environmentals

         3. Provides Problem Management functions including:
             Root cause analysis (RCA).
             Outage communications and escalation.
             Known error tracking.




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                  5
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



Tier 3

Tier 3 support is focused on system design, development, testing, and implementation
services. Tier 3 includes post implementation support correcting customer identified
problems involving:
         1. Operational Systems.
             System Management Server (desktop management).
             Microsoft AD (authentication).
             Microsoft Exchange (e-mail).
             Networking and VPN layering (communications).
         2. Change Request analysis (enhancements).
         3. Problem resolution development, testing, and release (fix management).

Tier 0

In addition to these traditional levels of support, new automated tools have become
available to enable the customer to resolve their own issues on a “self-help” basis.
These automated tools are sometimes referred to as Tier 0 support tools and are
normally implemented in larger organizations. Tier 0 applications, such as a website,
allow customers to create their own tickets, review the status of a ticket, or look up the
resolution to a common problem in a database.

3.1.2 Support Services

ESD provides support for a wide range of services. This section describes each major
area that the ESD supports.

Remote Support

The ESD provides remote support for desktops and desktop applications for MEDCOM
MTFs and MSC activities. The ESD operates within the MEDCOM network
infrastructure allowing agents to securely access a customer's desktop and to assist the
customer during the call. This remote access is in full compliance with the Department
of Defense (DoD) regulations for secure remote access. This type of access allows the
ESD service agents to quickly resolve many issues that a third-party service desk would
not be able to resolve.

System Monitoring

The ESD service agents monitor the computer systems at the six MEDCOM messaging
centers around the world. ESD service agents monitor a variety of events from
overheating to network outages. Any outages or anomalies in these computer systems
are immediately reported to the appropriate local support group who can respond
quickly to restore service or prevent an outage. For example, ESD service agents can
detect overheating in a server room and can contact the local server administrators to
have them check the air conditioning system and potentially avoid systems shutting
down. When outages do occur, ESD service agents work closely with the appropriate

MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                 6
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



support group to communicate estimated time for repair, and report back to the
customer and other MEDCOM stakeholders.

AD/Exchange Support

ESD Tier 2 service agents have an enterprise view of all the MEDCOM messaging
centers and have rights and permissions to manage e-mail services across all of
MEDCOM around the world. The ESD is often called upon to assist military personnel
find and move mail accounts as they are being deployed, changing duty stations, or
going on temporary duty (TDY). The ESD is the definitive source for Microsoft AD and
Exchange support for MEDCOM.

3.1.3 Support Tools

Phone System

The ESD is installing a top-of-the-line phone system that provides the following
services:
       4. Skill-based routing: Incoming calls are immediately routed to the appropriate
          support tier based on geographic location. For example, certain sites that the
          ESD supports only require Tier 2 support services. Any calls from these sites
          are automatically routed to a Tier 2 service agent.
       5. Accurate call metrics: The ESD can track how long it takes for a call to be
          answered, how long agents are on the phone, the number of abandoned
          calls, and the amount of time customers are on hold.
       6. Voice menu tree: Callers from another location, who may be needing a wider
          range of support, are greeted with a voice menu system. Callers can either
          speak directly to a service agent or navigate the menu system to speak with
          the appropriate tier of service.

Ticket Tracking System

The ESD has an integrated ticket tracking system that it maintains for itself and for the
sites it supports. This tracking system is available to customers either as a web
interface for end users or as an installed client for local support agents or local system
administrators. Customers, accessing the ticket tracking system via the web, can track
open incident records online and view the status of a ticket. Technicians with an
installed client application can access the ticket tracking system to track open issues
assigned to them, to create new tickets, or to assign tickets to other technicians.

Monitoring Tools

The ESD uses a variety of monitoring tools that allow service agents to monitor the
health of various MEDCOM systems. The monitoring tools are displayed on a large
video wall for viewing by all service agents. In addition, the monitoring tools are
available on all Tier 2 service agents’ desktops where they can look at specific data
centers and specific servers.

MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                 7
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



Customer Feedback Tools

The ESD has a robust customer survey tool that it uses to gather customer feedback
about the ESD support services. Every customer who gets assistance from the ESD is
invited to take a survey where they can rate the performance of the ESD service agent
and leave comments on how the ESD can improve customer service. The invitation to
take the survey is sent out when the customer’s incident record is closed. A link at the
bottom of an e-mail notification presents the survey to the customer. It is not a separate
e-mail and is therefore very non-intrusive and does not harass the user for feedback.
Customers are free to leave feedback if they choose. Currently the ESD has an average
of a 30% return rate on all surveys sent to customers.

3.1.4 Customer Relations

The ESD meets weekly with its customers to gather feedback for ways to improve
service. At this time, ideas are being exchanged about increasing the amount of access
or permissions the ESD service agents require to perform more support functions during
the first call. The ESD also gathers suggestions for improving escalation processes,
expanding communications channels, and increasing awareness for sensitive issues.
The ESD also uses these meetings to exchange planned outage information, and other
planned maintenance windows that might affect call volume. In all, the ESD works very
hard to stay in constant communications with the sites we support so they are
constantly aware of the customer’s circumstances and current needs.

3.1.5 Service Level Agreement (Quality Management)

The ESD employs a Service Level Agreement Team to monitor customer service,
service agent performance, overall service metrics, and adherence to our Service Level
Agreement standards. The ESD SLA Team meets weekly to discuss ways to improve
customer service processes and procedures. The ESD SLA Team monitors service
agents’ calls to verify that agents are following the call script, being professional, and
providing the appropriate level of service for the customer. For accountability purposes,
the ESD SLA Team also provides a variety of reports to commanding officers and
senior management.

In addition to the ESD SLA Team, each tier has an operational team lead that regularly
reviews incident tickets to make sure the appropriate information is being gathered from
the customer and that incident tickets are being filled out completely. They also review
tickets that have been transferred to another support tier to see if those issues could be
handled without transferring the ticket. The operational team leads look for additional
process improvements or training that would allow more issues to be handled at a lower
tier level, thereby increasing first call resolution and improving support for the customer.




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                 8
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




3.2    Incident Management
This section provides an overview of the services and interfaces related to the ESD
Incident Management process.

3.2.1 Overview and Policies

The ESD serves as a single POC for all technical support issues; ESD service agents
field all phone calls, e-mails, walk-ins, and web submissions requesting any kind of
IM/IT technical support.

When receiving a request, an ESD Tier 1 service agent will check for the ESD
customer’s contact information in the problem reporting tool's contact database (adding
a record for them if necessary), will create a request record, will document the details of
the request in the record, and will either handle the request directly or forward it to the
appropriate group.

The ESD has established a policy of never turning away a customer until some level of
support has been given to the customer. At the very least, customers will be given
contact information for the appropriate group and if possible, warm transfer (i.e, transfer
of a customer that does not require the customer to initiate another call) the customer to
the appropriate group. This applies to any situation from facility problems to technical
support.

To ensure customer satisfaction, the ESD has established a policy: within certain
guidelines, no incident record will be closed until the customer has been contacted and
the customer has confirmed that the incident has been resolved. However, if an ESD
service agent has attempted to contact a customer by phone or e-mail for five
consecutive business days without a customer's response, the record may be closed
without confirmation.

3.2.2 Roles and Responsibilities

This section describes the various roles and responsibilities within the ESD.

All ESD service agents have the following responsibilities:
       7. Responding to incoming requests by phone, e-mail, transfers, walk-ins, and
           web.
       8. Recording all requests in the ticket tracking system.
       9. Gathering the appropriate information for each request.
       10. Assessing the severity and priority of requests.
       11. Fulfilling requests for which the ESD is responsible for resolution.
       12. Documenting all actions taken for the request in the associated request
           record.
       13. Assisting the customer in determining the type of problem with the
           application.


MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                 9
1 May 2007
                                        USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



       14. Assisting the customer with appropriate user action to resolve problem.
       15. Transferring requests to the appropriate USAMITC or MHS group as required
           to resolve incidents.
       16. Informing the ESD customer of the status of existing requests.
       17. Contacting the ESD customer for further information as required.
       18. Performing initial request escalation on behalf of the ESD customer.
       19. Obtaining ESD customer agreement for closing the record for resolved
           issues.
       20. Documenting and maintaining ESD processes and procedures.

In addition to the responsibilities listed above, ESD Tier 2 service agents handle the
following specific categories of incidents:
       21. Microsoft AD.
       22. Microsoft Exchange.
       23. BlackBerry.
       24. Computer room environmentals
       25. Applications (e.g., Office, AEFSS, etc.)

3.2.3 Incident Severity

   Figure 1.   Incident Severity Criteria
                                                                                             Service
 Severity                             Characteristics                                      Restoration
                                                                                             Target
                  The patient care system is inaccessible.
                  The complete patient care system is down.
                  The patient care system aborts and does not run.
                  The patient care system puts erroneous information into
                   patient records.
                  The patient care system performance degrades
                   dramatically.
 Level 1
                  Patient safety is compromised by the software (i.e.,
 Severe
                   software fails to notify providers of panic values in lab                 24 hours
Business
                   tests or drug/allergy interactions).
 Impact
                  A problem causes a personal computer (PC) not to be
                   operational in any exam room regardless of the clinic.
                  The patient care database is corrupt.
                  A critical system, network, or key application outage
                   critically impacts patient care service delivery.
                  The entire customer set loses production service.




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                  10
1 May 2007
                                        USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




                                                                                             Service
 Severity                             Characteristics                                      Restoration
                                                                                             Target
                  Patient care function does not work but a workaround
                   exists.
                  Correction to the problem must be addressed within 24–
                   48 hours.
                  Delay of response will affect other areas.
                  Functions of software, network, or hardware components
 Level 2
                   are restricted.                                                            Three
  Major
                  A critical function or network is down, degraded, or                      calendar
Business                                                                                       days
                   unavailable.
 Impact
                  A problem may critically impact service delivery.
                  Service performance is degraded and impacts service
                   delivery.
                  Entire function (or more) is unavailable/degraded.
                  A problem affects a part of the customer set.
                  This is the default priority for new tickets unless covered
                   by situation described as Severe or Major severity.
                  One desktop gives an error, but other desktops at the site
                   do not.
                  Help messages are incorrect.
                  Spelling on screens/templates is incorrect.
                  Errors occur that inconvenience or annoy users.
                  Errors occur that do not affect operational or mission
                   essential function.
                  A customer requests information/procedures.
 Level 3          A customer calls for information on software loads.
                                                                                              Seven
  Minor           Problems only affect a few individual patient records that                calendar
Business           are routine and of a non-critical nature.                                   days
 Impact           A component, minor application, or procedure is down,
                   unusable, or difficult to use.
                  A problem causes some operational impact, but does not
                   immediately impact service delivery.
                  A service outage occurs but an alternative workaround is
                   available.
                  Problems occur that degrade service, but do not prevent
                   delivery of service.
                  A problem may impact delivery of service.
                  A problem affects only some scattered customers.



MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                  11
1 May 2007
                                        USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



3.2.4 Interface Information

This section describes the various possible ways for a customer to contact the ESD.

   Figure 2.   ESD Interfaces

          Contact                                         Description

     By Phone              1-800-USAMITC (1-800-872-6482)

                           E-mail requests can be sent to:
     By E-mail
                           enterpriseservicedesk@amedd.army.mil

                           Users can access Help Desk Expert Automation Tool (HEAT)
                           Self Service to submit their requests by using their CAC pin and
     By Web
                           logging on to the following URL:
                           https://usamitcselfhelp.amedd.army.mil/heatselfservice/

                           When a customer initially submits a request, the ESD creates a
                           ticket for the request in the ESD’s ticket management system.
     Status                When a ticket is created, an e-mail is sent to the customer that
     Requests              includes the ticket number. Customers can reference this ticket
                           number for any future inquiries they may have about their
                           request, including status requests.




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                  12
1 May 2007
                                       USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



3.2.5 High-level Incident Management Process Flow

The following high-level ESD interface flows illustrate the interfaces between USAMITC
ESD service agents and MEDCOM customers.

   Figure 3.   Incident Management Process Flow




The ESD interface narrative describes each of the boxes as show in the flow diagram
above.

   Figure 4.   Incident Management Process Flow Narrative

    Role          Step                              Description
                          Submit incident or request.
MEDCOM                    Submit a request or an incident (issue) via phone, web, or e-
                    1
Customer                  mail to the ESD. Provide an ESD Tier 1 service agent with
                          information appropriate to the incident or request.




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                 13
1 May 2007
                                        USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




    Role          Step                           Description
                          Receive incident and create record or accept incident
                          transfer.
                          Tier 1
                          If this is a new incident, create an incident record to capture
                          and store all the information about the request. Give the ESD
                    2     customer the incident record number (also known as the ticket
                          number) to facilitate future communication about the incident
                          or request.
                          Tier 2 and 3
                          If it is an incident transfer accept the transfer and assume
                          ownership of the incident using the ticket tracking system.
                          Evaluate incident and determine if it can be handled at the
                          current tier.
                    3
                          The issue is evaluated and categorized according to the type
ESD Service               of issue or request it is.
Agent                     Current tier will handle?
                          Determine if the current ESD tier will handle the resolution of
                          the incident or the fulfillment of the request based on the
                          evaluation in step 3. For example, ESD Tier 1 may handle
                    4     requests to resolve incidents on supported applications and
                          ESD Tier 2 will handle AD and Exchange issues.
                             If Yes, proceed to Attempt Successful? (step 6).
                             If No, proceed to Transfer incident to appropriate support
                              group or tier (step 5).
                          Transfer incident to appropriate support group or tier.
                          If the current ESD tier is not directly responsible for resolving
                    5     the incident or fulfilling the request, or after attempting to
                          resolve the issue is unable to do so; transfer the request to the
                          appropriate support group work queue or provide the
                          appropriate contact information to the customer.
                          Attempt successful?
                          Was the ESD service agent able to resolve the incident or fulfill
                          the request?
ESD Service
                    6        If Yes, proceed to Request concurrence from requester to
Agent
                              close record (step 7).
                             If No, proceed to Transfer incident to appropriate support
                              group or tier (step 5).




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                  14
1 May 2007
                                         USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




    Role          Step                                 Description
                          Request concurrence from ESD customer to close record.
                    7     Obtain the ESD customer’s concurrence that the request has
                          been fulfilled or that the incident has been resolved to the
                          customer’s satisfaction.
                          Concur to close record?
                          When the ESD customer provides concurrence to the ESD
                          service agent, the service agent closes the record. Notification
                          is sent to the customer that the request has been fulfilled or
                          the incident has been resolved, and the record will be closed.
                          If the customer does not agree that the record should be
AMEDD               8     closed (e.g., they are still experiencing the reported issue),
Customer                  then they will notify the ESD service agent so the request
                          record may be reopened.
                             If Yes, proceed to Close record (step 9).
                            If No, return to Evaluate incident and determine if it can be
                             handled at the current tier (step 3).
                          Close record.
                    9     When all request/incident processing is complete and the
                          request record has been updated to contain all required
                          information, close the record.
ESD Service
Agent                     Submit relevant information to the Knowledge Base.
                   10     ESD service agents will submit any pertinent information to the
                          Knowledge Base to be shared with the other ESD service
                          agents.




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                   15
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



3.2.6 Internal Incident Resolution Process Flow

The following internal incident process flow shows how the different Tiers of support
within the ESD interact with each other.

   Figure 5.   Internal Incident Resolution Process Flow




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                16
1 May 2007
                                         USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




   Figure 6.   Internal Incident Resolution Process Flow Narrative

  Role         Step                                  Description
                        Receive incident and create record.
                        If this is a new incident, create an incident record to capture and
                        store all the information about the request. Give the ESD
                 1
                        customer the incident record number (also known as the ticket
                        number) to facilitate future communication about the incident or
                        request.
                        Evaluate incident and determine what kind of incident it is
                        and if it can be handled at the current tier.
                        The issue is evaluated and categorized according to the type of
                        issue or request it is.
                           If incident is an MHS-related issue, proceed to Transfer to
                            MHS Help Desk (step 3).
                           If incident is a local application issue, proceed to Transfer to
                            local Tier 2 application support (step 4).
                 2
                           If incident is a local hardware issue, proceed to Transfer to
                            local Tier 2 hardware support (step 5).
 ESD                       If incident is a local network issue, proceed to Transfer to
 Tier 1                     local Tier 2 network support (step 6).
Service
                           If incident is an AD, Exchange, or BlackBerry issue, proceed
 Agent
                            to Transfer to ESD Tier 2 (step 7).
                          If incident is resolvable by Tier 1, proceed to Resolve incident
                           (step 8).
                        Transfer to MHS Help Desk.
                 3      The ESD Tier 1 service agent will warm transfer the customer to
                        an MHS service agent and close the incident record. The MHS
                        service agent will resolve the incident.
                        Transfer to local Tier 2 application support.
                        The ESD Tier 1 service agent will warm transfer the customer
                 4      and the incident record to a local Tier 2 service agent. The Tier 2
                        service agent will resolve the incident and close the incident
                        record.
                        Transfer to local Tier 2 hardware support.
                 5      The ESD Tier 1 service agent will transfer the incident record to
                        a local Tier 2 service agent. The Tier 2 service agent will resolve
                        the incident and close the incident record.


  ESD            6      Transfer to local Tier 2 network support.

MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                   17
1 May 2007
                                        USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




 Role         Step                                 Description
 Tier 1                 The ESD Tier 1 service agent will transfer the incident record to
Service                 a local Tier 2 service agent. The Tier 2 service agent will resolve
 Agent                  the incident and close the incident record.
                        Transfer to ESD Tier 2.
                        The ESD Tier 1 service agent will warm transfer the customer
                 7      and the incident record to an ESD Tier 2 service agent. The Tier
                        2 service agent will resolve the incident and close the incident
                        record.
 MHS,                   Resolve the incident and close the incident record.
ESD, or                 The service agent (local, Tier 1, or Tier 2) resolves the incident
 Local           8      and closes the incident record.
Service
 Agent

3.3    Problem Management
This section provides an overview of the services and interfaces related to the ESD
Problem Management process.

3.3.1 Overview and Policies

The Problem Management process is used by the ESD to manage incidents that are
similar in nature and appear to be symptomatic of a larger problem. It is an ongoing
process concerned with minimizing the impact of problems affecting the availability and
services of the service delivery environment. This is done through analysis, tracking,
and prevention of problems impacting managed IM/IT resources.

In ITIL, a "problem" is defined as any event resulting in a loss or potential loss of the
availability or performance to a managed IM/IT resource or its supporting environment.
This includes errors related to systems, networks, workstations and their connectivity,
hardware, software, and applications. The recognition of problems can come from any
point in the environment and can be identified using a variety of automated and non-
automated methods. Problems usually start out as a series of similar related incidents.
These incidents are evaluated and researched to determine if they are all stemming
from the same source. If so, these incidents are grouped together as a problem and
solved all together. For example, a number of related tickets concerning a new printer
driver would be grouped together as a problem. As a consequence, solving the issue of
the bad printer driver solves all of the incidents collectively.

The Problem Management process is designed to:
       26. Minimize the duration of problems.
       27. Reduce the number of incidents.
       28. Prevent recurrence of problems.
       29. Address primary root causes of problems.

MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                  18
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



       30. Minimize problem life cycles.
       31. Optimize time and effort spent resolving problems.

There are three outputs of the Problem Management process, namely:
       32. Known error identification.
       33. Change requests.
       34. Problem resolution notifications.

3.3.2 Roles and Responsibilities

Problem Management duties are performed primarily by ESD Tier 2 service agents.
The duties include:
       35. Opening a problem record.
       36. Gathering all required information for the problem.
       37. Assessing the initial severity classification of a problem.
       38. Maintaining ownership and accountability for the problem.
       39. Recording additional information and actions taken in the problem record.
       40. Checking whether the problem is a duplicate of an existing problem that is
           already being addressed or a repeat occurrence of a problem that has
           already been resolved.
       41. Participating in RCA as required.
       42. Documenting the causes of a problem, the problem's contributing factors, and
           the details of all actions taken to resolve the problem.
       43. Documenting and communicating known errors and any temporary solutions
           to all ESD service agents.
       44. Preparing and submitting a change request to the Change Management
           Review Board (CMRB).
       45. Checking the resolution and documenting resolution actions.
       46. Communicating problem status to appropriate customers and management.
       47. Obtaining concurrence from the appropriate parties before closing the
           problem.
       48. Notifying the ESD customer that the problem has been resolved.
       49. Closing the problem record.

3.3.3 Interface Information

3.3.3.1        PROBLEM ESCALATION

Similar incidents are grouped together and communicated to Tier 2 ESD service agents
as a problem. A record in the ESD ticket tracking software is opened and all incidents
related to the problem are linked to the problem record.




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                19
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



3.3.3.2        PROBLEM COMMUNICATIONS

Information about any problems is communicated to the customer when appropriate and
is always communicated to senior management.

3.3.4 High-level Problem Management Process Flow

The following high-level Problem Management process flow shows how a problem is
handled.

   Figure 7.   High-level Problem Management Process Flow




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               20
1 May 2007
                                        USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




   Figure 8.   Problem Management Process Flow Narrative

    Role         Step                                  Description
                          Submit notification of a problem.
  Problem                 Notify ESD Tier 2 that a problem exists. Create a problem
                   1
  Reporter                ticket and associate any appropriate incident tickets to the
                          problem ticket.
 Problem                  Review problem and assign to Problem Resolver.
Mgt Group          2      Validate the assignment of the problem record and assign the
 Leader                   problem record to an appropriate Problem Resolver.
                          Perform problem determination.
                          Identify the failing component and diagnose the cause of the
                          problem. Based on that information, use the proper recovery
                          procedure to minimize the impact to other customers. Update
                   3      the problem record with the complete findings and actions,
                          including date and time stamp for contacts made and actions
                          taken. Then begin determining the root cause of the problem.
                          If the initial root cause is known, document root cause findings
                          in the problem record.
                          Implement temporary resolution.
                          Implement a temporary resolution, if needed (e.g., such as a
                   4      restoration of service) that is achieved when the symptoms of
  Problem                 the problem have been eliminated. Additional work may be
  Resolver                required later to implement the permanent resolution.
                          Perform RCA.
                   5      RCA is performed to be sure the actual problem is fixed, not
                          just the symptoms of the problem. It is beneficial to document
                          results of a RCA in the problem record.
                          Change Management required?
                   6         If Yes, proceed to Change Management (step 7).
                            If No, proceed to Develop permanent resolution (step 8).
                          Change Management
                   7      Create a fully documented Change Request (Work Order).
                          Invoke the Change Management process.




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                  21
1 May 2007
                                         USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




      Role       Step                              Description
                          Develop permanent resolution.
                          Use the composite of all available information to develop the
                          permanent resolution and preventive actions:
                             Symptom description.
                             Problem determination documentation.
                   8
                             Results of bypass/recovery activities.
                             RCA.
                          If no permanent resolution for the problem can be found (e.g.,
                          problem cannot be recreated), then the situation must be
                          documented in the problem record and closed.
                          Implement permanent resolution.
  Problem                 Once a permanent resolution or preventive action has been
  Resolver         9
                          identified, check the solution, document the results in the
                          problem record, and implement the solution.
                          Obtain concurrence from Problem Reporter to close
                          problem.
                          Obtain concurrence from the customer that the problem was
                   10     resolved. If the problem is resolved, the Problem Resolver will
                          close the problem record once all activities, including those
                          taken to assure permanent resolution, are complete and
                          documented in the problem record.
                          Close problem record and update Knowledge Base as
                          required.
                   11
                          Close the problem record and update the Knowledge Base as
                          required to reflect new or updated resolutions.

3.4     Change Management

3.4.1 Overview and Policies

The purpose of Change Management Process is to control the IM/IT infrastructure
changes through standardized, repeatable methods and procedures. The Change
Management Process supports efficient handling of changes, and provides accurate
timely information on changes to minimize its impact.

The primary goal of the Change Management process is to manage the initiation,
review, approval, and implementation of all proposed changes to the IM/IT
infrastructure.

Input to the Change Management process is the Change Request (CR). The Change
Management Process is triggered by other ITSM Processes whenever there is a need


MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                   22
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



for Change, an Incident or Problem requiring a change to the system, a proposed
upgrade to some component of the infrastructure, or a formal System Change Request
(SCR) originating from the USAMITC customer base.

Outputs of this process include implemented, verified, and closed change records,
Change Advisory Board (CAB) minutes and actions, and Change Management reports.

The Change Management process enables Configuration Item (CI) changes to be
planned and executed to minimize service disruption and risk. This process helps in
gauging the business and infrastructure impacts from a change and making quick
decisions by categorizing changes as Standard (Manager Approved), Significant
(Change Advisory Board (CAB) Approved) or Urgent (Government or Emergency CAB
Approved). The Change Advisory Board (CAB) does the Change assessment, approval,
and schedule authorization of changes

3.4.2 Roles and Responsibilities

3.4.2.1        CHANGE MANAGER

The Change Manager operates the Change Management process and therefore has
end-to-end responsibility for process performance and quality.

The Change Manager is responsible for ensuring that all changes are reviewed and for
ensuring that changes flow through the Change Management Process. For “CAB
Approved” changes, the Change Manager chairs the CAB meetings and ensures that all
changes are thoroughly considered for approval. The Change Manager can approve
Manager Approved changes. [In the case of a more complex CAB structure for possible
future consideration, there could be different levels of Change Managers. In the case of
multiple levels, the levels of accountability and authority and process linkages would be
clearly defined.]

Responsibilities
       50. Ensures changes conform to process standards and policies
       51. Provides input into important decisions regarding Change Management
           supporting technology requirements
       52. Raises Change related issues to the appropriate level of management
       53. Analyzes change records to detect any trends or problems and proposes
           actions to rectify apparent weak areas in the Change Management process
       54. Ensures that the Change Management process and working practices are
           effective and efficient
       55. Ensures that all stakeholders are sufficiently involved in the Change
           Management process
       56. Ensures the appropriate motivation and performance of the Change
           Management staff in the organization




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               23
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



       57. Ensures tight linkage between Change Management Process and the Build
           and Test as well as Configuration Management, Release to Production
           Processes
       58. Produces regular and accurate management reports
       59. Participates in other ITSM process initiatives and process reviews
       60. Maintains his/her individual knowledge, skill level and performance

3.4.2.2        CHANGE COORDINATOR

The Change Coordinator role may be performed by the Change Manager or delegated
to one or more individuals.

Conversely, the Change Coordinator is the backup for the Change Manager and may
actively perform all Change Manager functions as delegated and required by the
Change Manager.

The Change Coordinator performs the administrative tasks associated with a change.
This means the Change Coordinator ensures that all changes are recorded, scheduled,
and that all parties involved with the change have the information that is needed for the
change to progress through the process. The Change Coordinator is expert in the
working of the Change Management system and as such may be called upon by the
other roles for assistance and mentoring with system issues.

Responsibilities

Although the Change Coordinator has no formally defined responsibilities in the other
phases of the Change Management process, here are additional suggested
responsibilities:
       61. Provides input into important decisions regarding Change Management
           supporting technology requirements
       62. Raises Change related issues to the appropriate level of management
       63. Analyzes change records to detect any trends or problems and proposes
           actions to rectify apparent weak areas in the Change Management process
       64. Produces regular and accurate management reports including the Forward
           Schedule of Changes and other change reports required specifically for
           weekly CAB meetings
       65. Acts as the scribe for the weekly CAB meetings and publishes the meeting
           minutes and action items
       66. Participates in other ITSM process initiatives, Post Implementation Reviews,
           and process improvement reviews as appropriate
       67. Maintains his/her individual knowledge, skill level and performance on the CM
           process and enabling technology




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               24
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



3.4.2.3        CHANGE REQUESTER

The role of the Change Requestor applies to all people who need to introduce a change
to the production environment.

Responsibilities

The Change Requestor:
       68. Provides a clear description of the business needs, goals and objectives of
           the change
       69. Follows the Change Management process for submitting a CR including
           getting approval for the change from their management
       70. Provides additional information regarding the change when requested by the
           Change Manager
       71. Assigns an initial description of the change based on change impact, risk, and
           complexity (work to implement the change) definitions
       72. Works with the Change Owner and appropriate Service Providers (Change
           Domain Expert role) to arrive at a successful change
       73. Confirms the completed change can be closed
       74. Participates in the Post Change Review process if requested

3.4.2.4        CHANGE OWNER

The role of the Change owner applies to all staff given overall accountability for the
success of the change and responsibility for coordinating the development and
implementation of a change in the USAMITC production environment.

The primary role of the Change Owner is to successfully take a change through its
lifecycle. The Change Owner represents the change to the Change Advisory Board for
approval at all phases of the change, and monitors the progress of a change ensuring
that it progresses through the process according to schedule. The Change Owner is
accountable for the end result of the change. The person who initially requests or
initiates the change is often also appointed by the Change Manager the role of Change
Owner. The most important factor about the assignment of the Change Owner role is
that the accountability for change ownership and the subsequent change success is
clearly identified. It is often inaccurately assumed that the Change Manager / Change
Coordinator roles are accountable for the success of a change, when indeed; these
roles are solely accountable to ensure the process is effectively managed within the
organization.

In light of the accountabilities and responsibilities placed on the Change Owner to see
to the successful planning and management of changes, the Change Owner should
either have an excellent knowledge of the impact of their change or should enlist the
assistance of the appropriate subject matter experts who can assist with the
assessment of impact and risk.



MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                25
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



3.4.2.5        CHANGE DOMAIN EXPERT

Change Domain Experts bring knowledge of the USAMITC environment for which they
are responsible and their technical expertise to assist the Change Owner with tasks and
activities in the Change Management process. The Change Owner may hand off
process responsibilities to Change Domain Experts. Note that the Change Owner is still
accountable for the overall successful change implementation.

Responsibilities

All Change Domain Expert responsibilities are relative to tasks and activities which have
been delegated by other roles in the CM process, especially activities assisting the
Change Owner.

Example delegated Change Domain Expert responsibilities:
       75. Provides specialized skills and knowledge of one or more domains (technical,
           business and/or application) to assist in determining the risk and impact of a
           Request for Change (CR)
       76. Creates requests for changes (CRs) when required with responsibility
           delegated by Change Requesters registered in the CM system
       77. Maintains individual knowledge, skill level and performance
       78. Documents comprehensive and accurate information within CR records
       79. Adheres to authorized procedures and working practices
       80. If a vendor, he/she works closely with the Change Owner to document
           comprehensive and accurate information regarding CRs
       81. Is very involved in building, testing and implementing changes to the
           production environment
       82. May be called on to verify changes
       83. Performs root cause analysis on failed changes, identifies and documents
           corrective actions

3.4.2.6        CHANGE VERIFIER

Change Verifier validates the successful implementation of all change requests.

The Change Verifier and Implementer should not be the same person.

Responsibilities
       84. Coordinate with the Change Implementer during the change implementation.
       85. Validate the successful implementation of the change, (this may be delegated
           to the appropriate Change Domain Expert).
       86. Validate that the service impacted during the change implementation has
           been restored. The service should be tested in the same manner as to mimic
           the customer experience (this may be delegated to the appropriate Change
           Domain Expert).



MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               26
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



3.4.2.7        CHANGE ADVISORY BOARD (CAB)

The Change Advisory Board is a council chaired by the Change Manager to discuss,
offer advice, and approve CAB Approved changes prior to their introduction to the live
environment. Although the membership of the CAB is fixed, attendance at weekly CAB
meetings and approval via the on-line approval mechanism in the CCF tool will depend
on the changes being reviewed at the meetings and unique requirements of changes to
be approved. Anyone may be asked to assist to ensure that the change is assessed
adequately from a business and technical viewpoint. This could include:
       87. Change Manager (chairs the CAB)
       88. User managers and user group representatives
       89. Change Domain Experts
       90. Contractors or third-party representatives
       91. Other USAMITC process owners
       92. IM/IT Council representatives

Membership

The CAB consists of a Technical Review Board (TRB) and a Government
Representative. The TRB members are representatives from Architecture group,
Change Management and Security. The TRB provides recommendations to the
Government Representative for each change request the CAB considers. The
Government Representative is the branch chief for project that the change request falls
under. Final approving authority resides with the Government Representative.

The ECAB consists of key staff and management and is usually a subset of the fixed
CAB membership. Selection will depend on the nature of the ECC (urgent) or
emergency change requested. Meetings may just require a telephone conference, and
members must be prepared to be available after hours.

Responsibilities

The Change Advisory Board:
       93. Attends all relevant CAB or ECAB meetings as required by the Change
           Manager
       94. Reviews all submitted CRs to determine their risk and impact, resources
           required to implement them, and any implementation or ongoing costs
       95. Authorizes, disapproves or requests more information for each CR, (approval
           authority rests with the Government Representative).
       96. Participates in scheduling and coordination of the Forward Schedule of
           Changes
       97. Ensures all changes are adequately assessed and prioritized
       98. Supports all CAB decisions
       99. When requested, participates in change Post Implementation Reviews




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               27
1 May 2007
                                                                                              USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



3.4.3 High Level Process Flow

A typical Change Management process scenario would involve submitting a Change
Request (CR) to the Change Management Process. The Change Coordinator/Manager
would review the CR and ensure that all the required information is complete.
Depending on the scope of the requested change, the Change Coordinator/Manager
would then assign a category, change class and a Change Owner (knowledgeable and
accountable for the change success) to evaluate the risk and impact of the CR to the
IM/IT Infrastructure.

The diagram below shows the workflow for the change request process.

   Figure 9.      USAMITC Core Technology Process
           Change Request Process                                             USAMITC Core Technology Process v0.03



                                            Start
                                                                                                                                               End




                                                                    2 - Fill Out Change
                                   1 – Initiate Change                 Control Form
                                         Request




           Change Requestor                                                                                                                                   9.1 – Notification
                                                                                      6.1 – Notification



                                            3-Assign Class,




                                                                                                                                                                                   with Changes
                                                                                                                                                                                   Control Form
                                             Category and                                                  7 – Update CCF




                                                                                                                                                                                      Change
                                                                                                                                                                                      Update
                                            Change Owner                                                       with Work                     9 – Validation
                                                                                                             Instructions
                                                                                       Disapproved

                                                                      Standard (Pre-Approved)
           Change Manager



                                                    5 - Technical                     6 – Government         Approved
                              Significant              Review                              Review

           Change Approval
           Board
                                                                              Pilot



                                                    4 – Analysis                          7.1 Pilot                     8 – Implementation


           Change Owner




3.4.3.1           STANDARD PRE-APPROVED CHANGE (MANAGER APPROVED)

Standard changes do not require review by the change advisory board and instead
proceed directly to implementation. There are two scenarios for standard changes. If
the CR is a Manager Approved change, then the change could be designated as
“Approved” and the change would then be passed onto the Change Owner for
immediate implementation. Or if the Change Manager/Coordinator determines in
consultation with the Government that there is little-to-no impact to any other systems,
then the change could be designated as “Approved” and the change would then be
passed onto the Change Owner for immediate implementation.

3.4.3.2           SIGNIFICANT CHANGE (CAB APPROVED)

If the CR is a significant change that would impact several systems, then the CR will be
reviewed by the Change Advisory Board (CAB Approved change). The CAB discusses
the nature of the change together; taking into consideration the other projects, systems

MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                                                                                      28
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



and other CRs under review, and then decides upon the appropriate course of action, if
additional testing is required the CAB will determine if DT&E can support the needed
testing or if a Pilot is required. Once the change has been thoroughly tested or Piloted
to the satisfaction of the CAB, the CR returns to the CAB for their approval for
Implementation. All Test reports and documentation are required to be complete prior to
the Implementation. The CAB and the Change Manager decide upon the most
appropriate date to move the change to the Production Environment, and the
Implementation date is scheduled. The Change Schedule is the mechanism that tracks
the CR from initial submission to final Implementation.

3.4.3.3        URGENT CHANGES AND RESTORATION OF SERVICE (BREAK/FIX)

In this scenario, a critical Production Server (7x24) has experienced a service outage. If
all that is required to restore service (for the time being) is a reboot of the server, then
this is considered to be a service incident and will be logged accordingly. On the other
hand, if an actual change is required as part of the service restoration (e.g. operating
system patch applied, rerouting of network traffic, firmware or hardware upgrade, etc.)
then an Urgent Change Request would be issued. If the urgent change occurs within
duty hours, the Change Manager would review the request with the ECAB (Emergency
Change Advisory Board) and the affected users or user representatives could be
contacted to determine a “downtime” which would be acceptable to all to implement the
urgent change. If the urgent change occurs after hours, the Government On-Call
representative would coordinate the necessary resources to assess the change
required. Once this is complete, the change would be scheduled and deployed.

3.4.3.4        UNPLANNED CHANGES

There may be some few occasions when changes need to be applied in the absence of
Government approval. In these instances the change must be recorded into the
Change Management process after the implementation has been completed. These
rare changes should be recorded as unplanned and stringently reviewed as part of the
Post Implementation Review activity of the process.

3.5    Release Management

3.5.1 Overview and Policies

Release to Production is a process that deploys one or more production copies of a new
or updated CI(s) under the overall supervision of Change Management.

The purpose of Release to Production is to introduce changes to the IM/IT infrastructure
in a sufficiently controlled manner to minimize disruptions to service while maximizing
responsiveness to customer needs.

The goals of this process are:


MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                29
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



       100. Agree on the scope, content and the rollout plan for Release with Change
          Management.
       101. Plan for resources required for Release implementation
       102. Ensure that master copies of all software are secured in the Definitive
          Software Library
       103. Maintain Definitive Hardware Store
       104. Ensure that hardware and software being changed is traceable, secure
          and that only correct, authorized and tested versions are installed.

Release to Production process receives inputs from Configuration Management in the
form of CIs (attributes and relationships). Inputs are also received in the form of test
results (Production, End User Acceptance and Back-out).

Release to Production Process outputs are successful implementation of Change,
change request if necessary, Release Notification to other processes, updated user and
support documentation, decommissioned CIs and elimination of Known Errors.

3.5.2 Roles and Responsibilities

3.5.2.1        RELEASE MANAGEMENT PROCESS OWNER

The Process Owner owns the process and the supporting documentation for the
process. The Process Owner oversees the process, ensuring that the process is
followed by the organization. When the process isn't being followed or isn't working well,
the process owner is responsible for identifying why and ensuring that appropriate
actions are taken to correct the situation. In addition, the Process Owner is responsible
for the approval of all proposed changes to the process, and development of process
improvement plans.

Responsibilities
       105. Ensures that the Release Management process and working practices are
          effective and efficient
       106. Ensures that all stakeholders are sufficiently involved in the Release
          Management process
       107. Ensures that (business) management is sufficiently informed as to volume,
          impact and cost of releases and other production changes
       108. Ensures the motivation and performance of the Release to Production
          organization
       109. Ensures tight linkage between Release to Production processes and the
          Build and Test as well as Configuration Management, Change Management
          processes

3.5.2.2        RELEASE MANAGER

In the situation where the activities have been split between a Release Manager and
Release Management Process Owner, the Release Manager takes on more direct,

MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               30
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



hands-on accountability for the day-to-day running of the process within the
organization. Release Manager is directly responsible for core process deliverables.
The Release Manager ensures effective co-ordination of activities to roll out a new
release or other production environment change. The Release Manger manages and
co-ordinates all activities necessary to respond to a release work-order by
communicating necessary actions and best practices that (potentially) affect the work-
order's successful implementation.

Responsibilities
       110. Coordinates activities necessary for the implementation of release and
          other production change work-orders in an effective and efficient manner
       111. Ensures the service owner of impacted services formally accepts all
          planned implementations
       112. Ensures smooth and efficient implementation of production changes in
          stable environments thereby minimizing the effects of releases and other
          production changes on service levels
       113. Ensures effective implementation - reduced rework and back-outs
       114. Ensures the accurate and timely updating of the CMDB with
          implementation data as part of the Release to Production process
       115. Ensures that comprehensive and accurate management information about
          the quality of production releases is available
       116. Ensures better utilization and productivity of CI Owners by only involving
          those necessary for implementation of the specific change under
          consideration

3.5.2.3        SOFTWARE CONTROL AND DISTRIBUTION MANAGER

Software Control and Distribution Manager is accountable for DSL and its integrity,
security and management as well as Distribution of software as a part of Release
rollout.

Responsibilities
       117. Ensures the accurate and timely recording of all software within the CMDB
       118. Ensures version information about software components is up-to-date and
          accurate in both the test and production environments (these data are stored
          in the logical CMDB)
       119. Ensures that software components associated with a specific master
          blueprint are acquired from the appropriate resource (e.g., supplier or
          Definitive Software Library), licensed, controlled, and made available for
          Release to Production activities
       120. Accepts and is involved in the approval of new or modified software for
          control and distribution to both test and production environments
       121. Distributes and maintains version control of specific copies of software
          used within a controlled release
       122. Conducts software release planning effort


MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               31
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



       123. Ensures that software used in a controlled release is distributed on
          schedule, accurately and within budget

3.5.3 High Level Process Flow

This section of the process guide describes Operational Scenarios of how the Release
to Production Process would respond to different types of situations and how this
process contributes to the value chain.

3.5.3.1        TEST SETUP

After receiving a work-order to perform a test of a CI, the Release to Production process
prepares the test environment by performing setup activities. After a successful test
Release to Production can issue its release notification to the appropriate processes,
that the CI is available for use, apply a version identifier to the final set of changes that
were carried out, thus creating a controlled release; and update the CMDB with the
version identifier and related controlled release information.

3.5.3.2        RELEASE NOTIFICATION

Once a controlled Release has been instituted in the IM/IT infrastructure and the CMDB
has been updated, notification to other processes needs to be made.

For instance, Operations Management needs to perform routine activities such as
backup. The backup requirements might have undergone a change with the
implementation of the new Release.

Incident and Service Request Management needs to keep abreast of support
procedures with the implementation of the new Release.

The notification also acts as an input to Service Level Management to schedule
performance reviews, and begin normal monitoring and reporting activities for this
service.

3.6    Availability Management

3.6.1 Overview and Policies

The Availability Management process plans for, monitors, manages and improves
Service availability, at acceptable costs, to Users in order to meet the service
requirements as per SLA.

The purpose of the Availability Management process is to optimize the capability of the
IM/IT infrastructure, services and supporting organization to deliver a cost effective and
sustained level of availability that enables the business to satisfy its business objectives.


MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                32
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



The goals of this process are to:
       124. Ensure IM/IT Services are designed to deliver the levels of Availability
          required by the business
       125. Provide a range of IM/IT availability reporting to ensure that agreed levels
          of Availability are measured and monitored on an ongoing basis.
       126. Optimize the availability (resilience, reliability and maintainability /
          serviceability) of the IM/IT infrastructure to deliver cost effective
          improvements that deliver tangible benefits to the business and user
       127. Achieve over a period of time a reduction in the duration of Incidents that
          impact Service Availability
       128. Ensure shortfalls in IM/IT availability are recognized and required
          corrective actions are identified and progressed
       129. Create and maintain a forward looking Availability Plan aimed at improving
          the overall Availability of IM/IT Services and infrastructure components to
          ensure existing and future business availability requirements can be satisfied.

The Availability Management process is triggered by Service Review Cycle.

Availability Management process receives inputs from Service Level Management in the
form of SLAs, Internal Design Specifications from Service Planning, CI attributes and
relationships from Configuration Management, trends from Incident and Problem
databases maintained by respective processes, business impact analysis from
Continuity Management as well as Availability design validation from Security
Management.

The Availability Management process outputs are System or Application architecture
documents that are useful in Impact assessment of Changes, costs of non-availability
that provides financial justification to address increased availability requirements,
assessment of availability requirements by Service Level Management and availability
criteria for Continuity Management.

3.6.2 Roles and Responsibilities

3.6.2.1        AVAILABILITY MANAGEMENT PROCESS OWNER

The Process Owner owns the process and the supporting documentation for the
process. The Process Owner oversees the process, ensuring that the process is
followed by the organization. When the process isn't being followed or isn't working well,
the process owner is responsible for identifying why and ensuring that required actions
are taken to correct the situation. In addition, the Process Owner is responsible for the
approval of all proposed changes to the process, and development of process
improvement plans.

If the organization does not require the separation of roles (Process Owner and Process
Manager), responsibilities listed below should be merged with that of the Availability
manager role that follows.

MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               33
1 May 2007
                                       USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



Responsibilities


       130. Ensures that the Availability Management process and working practices
          are effective and efficient
       131. Ensures that all stakeholders are sufficiently involved in the Availability
          Management process
       132. Ensures that (business) management is sufficiently informed as to volume,
          impact and cost of Problems
       133. Ensures tight linkage between Availability Management processes and
          other related processes

3.6.2.2        AVAILABILITY MANAGER

The Availability Manager is required to ensure that availability requirements are met and
to advise senior IM/IT Management accordingly as well as to plan for, monitor and
control the availability of IM/IT services to meet business requirements, within specified
cost constraints.

3.6.2.3        AVAILABILITY ANALYST

The Availability Analyst collects and analyzes data for reliability, availability, and
accessibility.

Responsibilities
       134. Collects and analyses service performance data involving uptime for all
          customers for standard services on a regular basis.
       135. Proactively identifies uptime issues, making recommendations for
          eliminating those issues.
       136. Analyses actual data based upon projected data.
       137. Generates and distributes reports on availability performance

3.7    Configuration Management

3.7.1 Overview and Policies

Configuration Management is a process that underpins other ITSM Reference Model
processes. It is used to identify and control Configuration Items in the IM/IT
infrastructure, to record and report the status of CIs and Change Requests as well as
conducting periodic audits to verify accuracy and completeness of CI data. The
purpose of Configuration Management is to provide accurate information about CIs to
other ITSM Reference Model processes, implement configuration control on CIs, and
facilitate adherence to legal obligations and organization security, as well as aid
Financial Management and continuity planning. This facilitates efficiency and
effectiveness in IM/IT Support.

MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                 34
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



Configuration Management process receives input such as Change Records, Work
Orders, Component Usage data, Performance data, CI Status, Cost data, Documents
and Service Metrics data, Incident Records and Problem Records from all ITSM
processes.

Configuration Management Process outputs are up to date CI information provisioned to
other HP ITSM Reference Model processes and Configuration Management
performance reports. This includes aiding impact assessment in other processes,
providing trend data too.

3.7.2 Roles and Responsibilities

3.7.2.1        CONFIGURATION MANAGEMENT PROCESS OWNER

The Configuration Management Process Owner owns the process and the supporting
documentation for the process. The person fulfilling this role oversees the process,
ensuring that the process is followed by the organization. When the process isn't being
followed or isn't working well, the Process Owner is responsible for identifying why and
ensuring that appropriate actions are taken to correct the situation.

In addition, the Process Owner is responsible for the approval of all proposed changes
to the process, and development of process improvement plans.

With regard to process design and / or re-engineering efforts, the Process Owner is
perhaps the most important person involved in the project, for it is the Process Owner
who provides both leadership and accountability for their individual process and all of its
various sub-processes.

The Process Owner is responsible for all of the process improvement efforts affecting
their process and its sub-processes - activities that may take anywhere from 25-75% of
their time. They should also be capable of spending a lot of time working on process
improvement efforts, and be able to maintain very good relations with top managers in
various business units and stakeholders with vested interests in the success of the
process.

Responsibilities
       138. Ensures that the process is defined, documented, maintained &
          communicated
       139. Ensures organizational adherence to the process via the Configuration
          Managers
       140. Establishes and communicates the process roles and responsibilities
       141. Ensures the requirements for the Configuration Management system / tool
          are defined and secures the appropriate funding
       142. Establishes and communicates the process service levels and process
          performance metrics



MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                35
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



       143. Ensures the process documentation complies to the organization's
          document control process
       144. Ensures adequate process training is available for the organization
       145. Establishes targets for process improvement
       146. Monitors and reports on the performance of the process
       147. Identifies and communicates opportunities for process improvement
       148. Initiates and sponsors projects to improve or reengineer the process
       149. Manages changes to the process, this includes reviewing and approving
          all proposed changes and communicating changes to all the participants and
          affected areas
       150. Benchmarks the process performance
       151. Ensures related process integration to ensure the smooth information
          exchange
       152. Participates in other ITSM process initiatives and process reviews as
          needed
       153. Owns and manages the Configuration Management Plan
       154. Configuration Manager/Domain Owners report into the Configuration
          Management Process Owner

3.7.2.2        CONFIGURATION MANAGER

The Configuration Manager owns responsibility to implement Configuration
Management and works with the process owner on the implementation and continuous
improvement.

In large organizations, it is not unusual to have multiple Configuration Managers at both
the business segment level and per domain. In such situations, the role of Enterprise
Configuration Manager can be adopted, providing leadership for other domain-specific
Configuration Managers.

In the situation where the activities have been split among a Configuration Manager and
Configuration Management Process Owner, the Configuration Manager assumes more
direct, hands-on accountability for the day-to-day management of the process and acts
as the escalation point for the business users. The Configuration Manager is directly
responsible for core process deliverables.

Responsibilities
       155. Provides or updates CI-related documentation as required
       156. Escalates unauthorized CI changes or alterations to environment not
          reflected in CMDB to Change Management
       157. Supports effective use of CMDB for other groups and processes
       158. Requests Change Management report metrics in support of the
          Configuration Management process
       159. Produces process metrics reports
       160. Participates in Change Management process evaluation
       161. Approves structural changes to the CMDB


MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               36
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



       162. Defines the procedures for granting access privileges (e.g., usage profiles)
          to the CMDB
       163. Initiates proceedings against defaulters
       164. Identifies opportunities to improve or reengineer the process

3.7.2.3        CI OWNER

The Configuration Item (CI) Owner is a role that applies to anyone who owns i.e., is
responsible for - supporting and maintaining one or more specific Configuration Items.

Responsibilities
       165. Provides or updates CI-related documentation as required
       166. Creates RFCs for CI moves, add and changes (for items contained in the
          CMDB)
       167. Modifies CIs to address RFCs as part of the build and test activities
       168. Maintains detailed documentation of their CIs and the integrity of the any
          identified relationships to their CIs
       169. Complies with the Configuration Management process

3.7.2.4        CONFIGURATION DATA ANALYST

The Configuration Data Analyst is focused on providing technical support for the
Configuration Management System and the Configuration Management Database
(CMDB).

Responsibilities
              Ensures all CIs are accurately registered or deregistered
              Interfaces with other support organizations to ensure the effective use of
       the CMDB
              Maintains and recommends improvements to facilitate data integrity and
       effective use of the Configuration Management system
              Creates reports and analyzes the CMDB when requested by the
       Configuration Manager
              Participates in the evaluation of the Configuration Management process
              Support CMDB verification and audit activities

3.7.2.5        CONFIGURATION MANAGEMENT COUNCIL

The Configuration Management Council can be made up of various roles within the
IM/IT organization. The council should have a defined charter, communication plan, set
meeting times, and a documented organizational structure. The primary chair is the
Configuration Manager.




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                37
1 May 2007
                                       USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



Its purpose is to:
       170. Define, confirm and maintain the contents of the Configuration
          Management Plan
       171. Define relationships and entities within the CMDB
       172. Identify and define data sources for the CMDB
       173. Agree upon and approve methods and technologies to discover
          configuration information
       174. Develop the auditing schedules to be included in the configuration
          management plan

Its members consist of:
       175. CI Owners (various domains e.g., networking, applications, servers, etc)
       176. Configuration Manager*
       177. Change Manager*
       178. Incident Manager*
       179. Problem Manager*
       180. Release Manager*
       181. Service Level Manager*
       182. Configuration Data Analysts (operational or technical support of CMDB
          technologies)

* Not all managers are required, as this will be dependent on need.

3.7.3 High Level Process Flow

This section of the process guide describes Operational Scenarios of how the
Configuration Management Process would respond to different types of situations and
how this process contributes to the value chain.

3.7.3.1        NEW SERVICE

The requirements definition of this new system - which spreads across multiple
locations, is done as a first step. Factors such as speed, capacity, availability, security
and cost go into design of this system.

Once the first step of requirement gathering is completed, USAMITC initiates the setup
of the infrastructure to fulfill the requirement. CMDB aids in the identification of
hardware that could be suitable for this purpose. Upon completion of required
infrastructure build, the new service after appropriate testing/DITSCAP goes into
production. Components participating in the delivery of the new service - such a
software, server hardware, network hardware and their relationships, location etc are
captured in the CMDB by the Configuration Management process.

With passage of time and increase in user population as well as increased customer
dependency, customers complain about bad performance. The Service Desk receives
multiple similar Incidents about the new service and decides to raise it with Problem

MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                 38
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



Management. Problem Management process looks up the Change / Incident history
based on information in the CMDB as well as performance characteristics of the
relevant mail servers. It is determined that the perceived slow response of the service is
on account of one of the backbone servers running on low physical memory – a change
request is initiated to correct the situation. The Change is implemented and quality of
Service restored. The Service Desk informs the Customer of the resolution and the
Incident / Problem records are closed after the post implementation review.

Security Management determines that the version of all servers needs to be upgraded
to address a serious vulnerability. A query on CMDB reveals the CIs running the flawed
version - which are then updated via the Change Management process.

3.7.3.2        CMDB REVIEW

In this scenario, during one of the regular CMDB reviews, the Configuration Manager
and other interested parties (e.g. CI Owners, Incident / Problem Managers, Change
Managers, etc.), identified lists of CIs to be added, removed and those CIs without
assigned CI Owners. The appropriate requests to add and remove CIs are submitted to
the Configuration Coordinator.

3.7.3.3        ADDITION OF NEW CIS

The Configuration Manager identifies and assigns CI Owners to the new CIs. The
Configuration Manager works with the interested parties to determine the new CI
requirements and have the Configuration Coordinator set up the CMDB to accept the
new CI requirements. Modification to existing CI record form(s) may be necessary.
Once the CMDB is set up, the Configuration Manager / Coordinator will initiate a change
request to record the new CIs in the CMDB. Relationships with other CIs are identified
and recorded. The respective CI owners are notified of the RFC.

Upon approval of the change request, the CMDB is updated with the new CIs and CI
attributes which may be accomplished with the help of automated discovery tools. When
the change request is completed, all CI owners and interested parties are informed and
the Configuration Manager updates the Configuration Management Plan accordingly.

3.7.3.4        REMOVAL OF CIS

The Configuration Coordinator confirms with the existing CI Owners on the removal of
CIs. Once confirmed, the Configuration Coordinator also assesses the impact of
removing these CIs by identifying any related / child CIs. The Configuration Coordinator,
together with all affected CI owners, determines the appropriate actions to take.
Consequently, the Configuration Coordinator submits the necessary change requests to
implement these actions and to remove the list of identified CIs.

Upon approval of change requests, the Configuration Coordinator updates the CMDB
(e.g. CI relationships, CI data via automated discovery tools, etc.) and change the


MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               39
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



status of the obsolete CIs. The Configuration Manager updates the Configuration
Management Plan accordingly. The obsolete CIs remain in the CMDB for the duration of
the retention period as specified in the Configuration Management Plan, before they are
finally deleted from the CMDB.

3.7.3.5        UNASSIGNED CIS

The Configuration Manager identifies and assigns the appropriate CI owners for these
CIs and updates the Configuration Management Plan and CMDB accordingly.

3.7.3.6        CMDB MONITORING

In this scenario, the CMDB is constantly monitored to ensure that it is up-to-date and no
unauthorized changes are made. Configuration monitoring is accomplished through the
help of automated discovery tools, which gather CI status and data and compare them
with the actual CMDB data. This is done regularly - as a routine Configuration
Management activity. If there is any CI data mismatch, a discrepancy report is
generated. The Configuration Coordinator verifies the discrepancies against the CMDB
and prepares a CI Unauthorized Change Report if unauthorized changes are found. The
report is distributed to the Configuration Manager who investigates the root cause.
When the responsible party for the unauthorized party is found, the Configuration
Manager sends a warning to the offender and a notification to their manager. The
Configuration Manager also decides if the Change Advisory Board needs to be informed
so that they can assess the impact of the unauthorized change(s) and implement the
appropriate actions to reconcile the CMDB.

3.7.3.7        CMDB CONTROL

In this scenario, a change request is submitted to change an infrastructure component.
When the change request is approved and scheduled, the Change Manager informs the
Configuration Coordinator who verifies that the change request has listed the
appropriate CIs. If an error is found, such as incorrect CIs listed in change request or
CIs missing from the change request, the Configuration Coordinator sends a CI
Discrepancy Report to the Change Manager to make the appropriate corrections to the
change request, which may require it to be re-submitted for approval by Change
Management. After the completion of the change request, the Change Manager sends
another notification to the Configuration Coordinator. This time round, the Configuration
Coordinator will verify that the CMDB is updated according to the change request. A CI
Discrepancy Report will be distributed to the Change Manager if discrepancies are
found. Again, the Change Manager will make the necessary corrective actions to correct
the change request.

3.7.3.8        CMDB AUDIT

The CMDB is audited regularly to ensure integrity of the CMDB data and compliance to
processes. The Configuration Manager plans for the audit schedule, audit methods and

MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               40
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



scope of audit. The Configuration Coordinator reviews the audit report and highlights
discrepancies that are valid i.e. discrepancies which potentially could be due to an
unauthorized change to the CMDB data or physical CI. Invalid discrepancies are
corrected immediately. The Configuration Manager investigates the valid discrepancies
for the root causes. When the responsible party for the unauthorized change is found,
the Configuration Manager sends a warning to the offender and a notification to their
manager. The Configuration Manager also decides if the Change Advisory Board needs
to be informed so that they can assess the impact of the unauthorized change(s) and
implement the appropriate actions to reconcile the CMDB.

3.8    Information Technology Continuity Management
Also known as a disaster recovery plan, this process will focus on developing
contingency plans for the ESD so that support services can continue even in the event
of a disaster of some kind.

4.0    BENEFITS DERIVED
The primary benefit of the ESD support model is greatly improving customer service
while reducing the total cost of ownership to the MEDCOM. This project provides the
following benefits:
       183. A single POC: Using the 1-800-USAMITC toll-free number, designated
          DSN numbers, a web portal, or e-mail contact methods; customers will have
          access to service desk services at all times, anywhere in the world with a
          phone or Internet connection. The ESD will be manned 24 hours a day, seven
          days a week, 365 days each year.
       184. A unified service desk team: Customer issues will be shared, assigned,
          and resolved using a team approach rather than in islands of isolation. Since
          all IM/IT personnel can access the system via the Internet, the best IM/IT
          resources can be assigned based on criticality of the issue and not based on
          restricted availability because of IM/IT resource location.
       185. A single service desk system: All trouble tickets and related data will be
          available from a single database repository, eliminating excessive numbers of
          servers and variety of incompatible software tools. This system will store
          standard procedures for problems already solved at other locations, and a
          consistent set of metrics for business managers to monitor IM/IT service
          performance.
       186. Customer satisfaction: All customers will enjoy the same high level of
          IM/IT service rather than only customers at the largest MTFs and MSCs
          receiving quality support while the customers at the smallest MTFs and MSCs
          continue with minimal tools and staff to provide adequate service. The entire
          IM/IT team will have access to standard service desk procedures stored in the
          knowledge database so that IM/IT service delivery will be more consistent
          and directly geared to customer requirements.



MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               41
1 May 2007
                                      USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



       187. A single point of accountability: Regardless if it is a network, MHS, locally
          unique, or USAMITC system; all MEDCOM trouble tickets are stored in a
          single database hosted at USAMITC. USAMITC will act as the MEDCOM
          IM/IT advocate for all system issues. Network and MHS issues will pass
          through the USAMITC Service Desk to the appropriate external service desk
          team (e.g., NETCOM, MHS, and other future service desks). USAMITC will
          conduct follow ups and customer satisfaction surveys including completion
          monitoring and reporting of all change requests documented in the system.
       188. Better IM/IT expense stewardship: Through the elimination of
          approximately 30 service desk systems and a variety of incompatible
          software, MEDCOM can purchase a single hardware suite and enterprise-
          class, feature-rich software for less money. Additionally, subsequent to all
          data being stored in a single repository, service level agreement (SLA)
          metrics can also be stored in the same location. This capability will allow the
          MEDCOM to measure the money spent on service desk services against the
          quality and quantity of services provided.
       189. Industry standard policies, processes, and procedures: As the IM/IT
          industry makes the shift to ITIL, we will be on the leading edge of
          implementing proven policies, procedures, and processes for the ESD. This
          will allow us to easily communicate with, share with, and learn from other
          service desks both in and out of the government. Adopting more ITIL
          practices ensures we align ourselves with the rest of industry in terms of
          organization, terminology, and practices.
       190. Risk Reduction: Control and management of change minimizes the risk of
          unexpected results due to the introduction of a change to the production
          environment. Decisions based on accurate information provided by
          Configuration Management reduce unanticipated downtime. Appropriate
          authorization requirement to make changes to the IM/IT infrastructure / CMDB
          increases security and reduces the risk of uncontrolled environment changes.
       191. Cost Reduction: Keeping records of changes facilitates continuous
          process improvement of operational processes in the production environment
          and expedites resolution of issues related to changes. Faster, simpler, more
          thorough identification of CIs, their attributes and their relationships by other
          processes. Multiple ITSM processes depend on information provided by
          Configuration Management - duplication of this effort is avoided in these
          processes. Configuration Management also facilitates adherence to legal
          obligations and aids budgeting and financial planning. A CMDB provides a
          platform to initiate CI standardization - which leads to substantial reduction in
          support costs
       192. Service Agility Improvement: Structured procedures of change
          implementation allow organizations to align quickly and effectively to
          changing business requirements. A clear understanding of how CIs
          participate in provisioning IM/IT Services enables IM/IT organizations to react
          quickly to changing business needs and a lesser time to market. This reduces
          the time to enhance range of Services offered as well as the time to market.



MCMR-ISP-ESD-CONOPS-2007-05-01-1.3                42
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



       193. Service Quality Improvement: Proper impact assessment of changes
          prevents unscheduled outages there by increasing service quality. Providing
          a facility for storage and retrieval of documented customer expectations
          makes it easy to compare and improve actual service delivery. Quality
          improvement also results from support provided to Incident and Service
          Request, Problem, Continuity, Change, Release and Security Management.
          Improved information management enables IM/IT organizations to monitor
          SLAs and maintenance contracts with greater precision. Retrieved data can
          be sorted, summarized, and reported in whatever manner makes sense.

5.0    PROJECT CONSTRAINTS AND CONSIDERATIONS

5.1    Existing Systems Affected
Approximately 30 service desk systems located at MTFs and MSCs worldwide will be
decommissioned. In addition, the existing ESD staff and infrastructure will grow as more
sites are migrated to the ESD.

5.2    Constraints
A successful implementation of a MEDCOM ESD will require support from MTF and
MSC commanders, yet must work within the framework of evolving industry best
practices and within Army goals and objectives. Two constraints are a solution that:
       194. Complements the ITIL model, an evolving industry best practice
          framework.
       195. Supports the initiatives as documented in Army Knowledge Management
          (AKM) Goal 3 (Consolidate and Enhance Information Technology Services
          Across the Theater).

From the MTF/MSC commander’s perspective, centralizing service desk operations will
be received with mixed enthusiasm. Those sites currently struggling with providing
quality service desk services and who invest minimal dollars in this area will likely
support the ESD concept. However, those MTFs that provide pockets of high quality
support may view this project as an infringement on their autonomy (budget) and a
short-term risk to the quality of services they currently enjoy.

MTF/MSC commanders may also have contractual obligations and established
relationships with vendors currently providing service desk services. Some MTF/MSC
commanders may require a gradual transition of services from incumbent vendors to
centralized services based on the contract termination terms and conditions. In some
cases, the organization may need to retain specific contracted and government
individuals who have unique corporate and mission knowledge specific to that
organization. A priority for the ESD project team is to ensure that these resources are
still available to MTF/MSC Commanders after ESD implementation.



MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               43
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)




5.3    Deployment Considerations
Deployment of the ESD system should consider the following:
       196. Successful functionality testing.
       197. DOD Information Assurance Certification and Accreditation Program
          (DIACAP)Networthiness certification.
       198. Customer training.
       199. In-place support.

The ESD will comply with the DIACAP. Additionally, in order for systems to operate on
the Department of the Army technology infrastructure, a Certificate of Networthiness
(CON) shall be applied for and approved by the Army CIO/G6. ESD systems must also
comply with the following:
       200. Public Law 104-191, Health Insurance Portability and Accountability Act of
          1996 (HIPAA), 21 Aug 96.
       201. Section 508, Rehabilitation Act Amendments of 1998, dated 7 Aug 98.
       202. Medical Sub domain of the Joint Technical Architecture (JTA) and JTA-
          Army (JTA-A).

5.4    System Support
USAMITC will be responsible for all life-cycle operations and maintenance support of
the ESD, including but not limited to:
       203. Project life-cycle documentation (Acquisition 5000 series processes), as
          required, for all support applications used by service desk personnel to
          provide IM/IT support.
       204. Establishing interagency memorandum of agreements (MOA) between the
          MEDCOM User Service Desk (USD) and other service desk service
          providers, such as the MHS Help Desk, the Tri-Service Information
          Management Program Office (TIMPO), and others, as required.
       205. Hardware and software support for any equipment purchased for the
          project.
       206. Training for service desk staff and other support personnel, as required,
          using service desk systems and other related enterprise applications and
          processes.

6.0    REFERENCES
Army
       207.    The following standards are mandated:
              Army Regulations 380-5: Department of the Army Information Security
               Program, 29 Sep 00.
              Army Regulation 25-1: Army Information Management, 15 Feb 00.
              AR 25-1, Army Information Management, 31 May 02.


MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               44
1 May 2007
                                     USAMITC Enterprise Service Desk (ESD) Concept of Operations (CONOPS)



              AR 25-2, Information Assurance, 14 Nov 03.
              AR 380-53: Information Security Monitoring, 29 Apr 98.
              AR 73-1, Test and Evaluation Policy, 7 Feb 03.
              DA PAM 73-1, Test and Evaluation in Support of Systems Acquisition, 30
               May 03.
       208.    The following standards are emerging but mandatory:
              Army CIO/G6, Networthiness Certification Guidance (Draft); enforcement
               mandated by CIO/G6 Policy Memorandum, Army Networthiness
               Certification, 8 Apr 02.

DoD

The following standards are mandated:
       209. DoD Instruction 5200.40, DoD Information Technology Security
          Certification and Accreditation Process (DITSCAP), 30 Dec 97. DIACAP
          now.
       210. DoD 8510.1-M, The Department of Defense Information Technology
          Security Certification and Accreditation Process (DITSCAP) Application
          Manual, 31 Jul 00.
       211. DoD Directive 8500.1, Information Assurance (IA), 24 Oct 02.
       212. DoD Instruction 8500.2, Information Assurance Implementation, 06 Feb
          03.
       213. OMB Circular A-130, Management of Federal Information Resources, 8
          Feb 96, Transmittal Memorandum #4 dated 28 Nov 00.




MCMR-ISP-ESD-CONOPS-2007-05-01-1.3               45
1 May 2007

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:127
posted:12/8/2011
language:English
pages:51