Docstoc

USAMITC Enterprise Service Desk _ESD_ Concept of Operations

Document Sample
USAMITC Enterprise Service Desk _ESD_ Concept of Operations Powered By Docstoc
					                                                          Style Definition: Emphasis: Font: 12 pt, Bold




  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 ...................................................................................... 98
           3.2.1 Overview and Policies .......................................................................... 998
           3.2.2 Roles and Responsibilities ....................................................................... 9
           3.2.3 Incident Severity ..................................................................................... 10
           3.2.4 Interface Information....................................................................... 121211
           3.2.5 High-level Incident Management Process Flow .............................. 131312
           3.2.6 Internal Incident Resolution Process Flow...................................... 161615
       3.3 Problem Management .................................................................................. 1817
           3.3.1 Overview and Policies ........................................................................ 1817
           3.3.2 Roles and Responsibilities ............................................................. 191918
           3.3.3 Interface Information....................................................................... 191918
           3.3.4 High-level Problem Management Process Flow ............................. 202019
       3.4 ITIL Processes to be Implemented ...........Error! Bookmark not defined.Error!
           Bookmark not defined.21
           3.4.1 Change Management ... Error! Bookmark not defined.Error! Bookmark
                 not defined.21
           3.4.2 Release Management .. Error! Bookmark not defined.Error! Bookmark
                 not defined.22
           3.4.3 Availability Management..................Error! Bookmark not defined.Error!
                 Bookmark not defined.22
           3.4.4 Configuration Management .............Error! Bookmark not defined.Error!
                 Bookmark not defined.22
           3.4.5 Information Technology Continuity Management .... Error! Bookmark not
                 defined.Error! Bookmark not defined.22
4.0 BENEFITS DERIVED ................................................................................................................. 424222
5.0 PROJECT CONSTRAINTS AND CONSIDERATIONS ............................................................. 444323


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........................................................................ 444323
      5.2    Constraints ............................................................................................... 444423
      5.3    Deployment Considerations ..................................................................... 444424
      5.4    System Support ....................................................................................... 454524
6.0 REFERENCES ........................................................................................................................... 454525




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 .............................................. 131312
Figure 3.       Incident Management Process Flow Narrative ................................... 1413
Figure 4.       Internal Incident Resolution Process Flow ..................................... 161615
Figure 5.       Internal Incident Resolution Process Flow Narrative ...................... 171716
Figure 6.       High-level Problem Management Process Flow ............................. 202019
Figure 7.       Problem Management Process Flow Narrative .............................. 212120




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)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 Information Management/Information Technology (IM/IT)
support 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 service agentstechnicians. The ESD has been able to dramatically improve                            Comment [U1]: Service agents are what they
                                                                                                            call computer programs that monitor or initiate
service for the customers at CRDAMC in the following ways:                                                  control of a desktop computer.

          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.
          ITIM/IT Service Continuity Management.
          Configuration Management.

1.2    Mission Description
This project maintains that the level of ITIM/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 ITIM/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, MTF and the Commanders , and MTF Information Management
Officers (IMOs) at the MTFs and MSCs. The functional proponent is Ms. Terry                                  Comment [t2]: Here and throughout the entire
                                                                                                             document, there is no mention of the Major
Gregurvich, HQ MEDCOM Information Management Directorate (IMD).                                              Subordinate Commands that have activities
                                                                                                             other than MTF/patient care and will also need
                                                                                                             ESD service. MSCs must be included – they
2.0    BUSINESS NEED                                                                                         are part of the MEDCOM.


This section describes the current ITIM/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 is an unnecessary and duplicationve ary redundancy and
           wastes of hardware, software, and personnel - quite apart from the resulting
           failure to exploit and share valuable data. The hardware, resources and
           maintenance, and duplicative personnel costs fail to achieve alone cost the
           MEDCOM’s goals 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                           Comment [t3]: Shouldn’t this be more of a
                                                                                                             “simple” problem listed, rather than major
           particular subject area. Less funded sites must often engage high-cost                            outages and failures? Using expensive
           outsourced resources for major outages and system failures.                                       engineers to resolve a password reset is the
                                                                                                             waste I think you are alluding to.


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 often wait until a thier
           local support center is open. Downtime, Ffrustration ed customers, and
           lowered productivity are often the 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.

This leads toThe current distributed systems approach results in a confusing,
frustrating situation for customers and often leads to delays in issuethe 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 ITIM/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 wide measured variety of services and support to its customers.
This section covers the following topics:

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




             The different tiers of support and their areas of expertise.
             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; and primarily consistings of these activities:
             Provides the initial customer POC. for both local and off-site ESD customers.
             Provides remote desktop support.
             Provides remote application support.
             Logs and tracks incidents in incident records.
             Follows up on unresolved incidents.
             Confirms with the customer that incidents have been resolvedincident
              resolution actualizing the Service Level Agreement..

Tier 2

Tier 2 support is primarily focused on repairing systems that are not operating within
customer expectations, andmatches 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 usually consists of the following
activitiesdivides into 3 categories:
             1. Provides ProvidingTier 2 support for the MEDCOM enterprise in the                              Formatted: Bullets and Numbering
               followinsystems softwareg areas:
                Microsoft AD.
                Microsoft Exchange.
                BlackBerry.

             2. Monitorsing the following systems for outages and potential                                    Formatted: Bullets and Numbering
               outagesMEDCOM 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                                                   Formatted: Bullets and Numbering
                Computer roomData Center environmentals




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



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

Tier 3

Tier 3 support is primarily focused on system design, development, testing, and
implementation services that will best support the customer. Tier 3 support usually
consists of the following activitiesincludes post implementation support correcting
customer identified problems involving:
         1.    Operational Provides Tier 3 support in the following areas:Systems.                           Formatted: Bullets and Numbering
              System Management Server (SMSdesktop management).
              Microsoft AD (authentication).
              Microsoft Exchange (e-mail).
              Networking and VPN layering (communications).
         2.    Change Request analysis (enhancements).                                                       Formatted: Bullets and Numbering
         3.    Problem resolution development, testing, and release (fix management).
                                                                                                             Comment [t4]: Should maybe call this “Self-
Tier 0                                                                                                       Help” somewhere. Everyone recognizes that
                                                                                                             term.

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.                                                                Comment [JH5]: Should the URL be inserted
                                                                                                             here at the end of the sentence?
                                                                                                             Comment [t6]: Some other Support Services
3.1.2 Support Services                                                                                       that should be included are Application Support
                                                                                                             (i.e. Aefss) and Escalation Services (i.e. MHS
                                                                                                             apps to MHS Help Desk, WAN to NETCOM
ESD provides support for a wide range of services. This section describes each major                         TNOSC)
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                        Comment [t7]: Should reference by name at
                                                                                                             least one regulation either here or in a
ESD service agents to quickly resolve many issues that a third-party service desk would                      Reference section. This is too vague.
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 wide variety of events from

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



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
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.
                                                                                                             Comment [t8]: Also include Knowledge
3.1.3 Support Tools                                                                                          Management as a Support Tool. Maintaining a
                                                                                                             central knowledge database of problems and
                                                                                                             resolutions is paramount to support.
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                                Formatted: Bullets and Numbering
           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

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



                                                                                                            Comment [t9]: List some, i.e. MOM
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.

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 we being exchanged ideas for 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 Quality ManagementService Level Agreement Team (QMT) to
monitor customer service, service agent performance, overall service metrics, and
adherence to our service Service level Level agreementAgreement standards. The
ESD QMT SLA Team meets weekly to discuss ways to improve customer service
processes and procedures. The ESD QMT 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
QMT SLA Team also provides a variety of reports to commanding officers and senior
management.

In addition to the ESD QMTSLA 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

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



those issues could be handled without transferring the ticket. The 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.

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
ITIM/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,                           Formatted: Bullets and Numbering
           and web.
         8. Recording all requests in the ticket tracking system.                                            Formatted: Bullets and Numbering
         9. Gathering the appropriate information for each request.
         10. Assessing the severity and priority of requests.

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



         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.
         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.                                                                                  Formatted: Bullets and Numbering
         22.   Microsoft Exchange.
         23.   BlackBerry.                                                                                    Formatted: Bullets and Numbering
         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




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
                  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.
                  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.




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




                                                                                            Service
 Severity                              Characteristics                                     Restoration
                                                                                             Target
                  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.
                                                                                                               Comment [t10]: Reformat for easier reading,
3.2.4 Interface Information                                                                                    maybe a table.

This section describes the various possible ways for a customer to contact the ESD.
                                                                                                               Formatted: Bullets and Numbering
   Figure 1.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


     By Web                Users can access Help Desk Expert Automation Tool (HEAT)
                           Self Service to submit their requests by using their CAC pin and


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




                           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.


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




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



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.
                          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.




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
                          Attempt successful?
                          Was the ESD service agent able to resolve the incident or fulfill
                          the request?
                    6        If Yes, proceed to Request concurrence from requester to
                              close record (step 7).
ESD Service
Agent                        If No, proceed to Transfer incident to appropriate support
                              group or tier (step 5).
                          Request concurrence from ESD customer to close record.
                          Obtain the ESD customer’s concurrence that the request has
                    7
                          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 ITIM/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 ITIM/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.                                                               Formatted: Bullets and Numbering
          27. Reduce the number of incidents.
          28. Prevent recurrence of problems.

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



          29. Address primary root causes of problems.
          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.                                                                    Formatted: Bullets and Numbering
          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.                                                                      Formatted: Bullets and Numbering
          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
                                                                                                             Formatted: Heading 4
3.3.3.1        PROBLEM ESCALATION                                                                            Formatted: Bullets and Numbering

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)


                                                                                                            Formatted: Heading 4
3.3.3.2        PROBLEM COMMUNICATIONS                                                                       Formatted: Bullets and Numbering

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 ITIM/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 ITIM/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                                        Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
       51. Provides input into important decisions regarding Change Management                              Alignment: Left + Aligned at: 0.5" + Tab after:
           supporting technology requirements                                                                0.75" + Indent at: 0.75"
       52. Raises Change related issues to the appropriate level of management                              Formatted: Bullets and Numbering
       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                              Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
           supporting technology requirements                                                               Alignment: Left + Aligned at: 0.5" + Tab after:
       62. Raises Change related issues to the appropriate level of management                               0.75" + Indent at: 0.75"
       63. Analyzes change records to detect any trends or problems and proposes                            Formatted: Bullets and Numbering
           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                       Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                             Numbering Style: 1, 2, 3, … + Start at: 1 +
           the change                                                                                        Alignment: Left + Aligned at: 0.5" + Tab after:
       69. Follows the Change Management process for submitting a CR including                                0.75" + Indent at: 0.75"
           getting approval for the change from their management                                             Formatted: Bullets and Numbering
       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,                      Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                             Numbering Style: 1, 2, 3, … + Start at: 1 +
           business and/or application) to assist in determining the risk and impact of a                    Alignment: Left + Aligned at: 0.5" + Tab after:
           Request for Change (CR)                                                                            0.75" + Indent at: 0.75"
       76. Creates requests for changes (CRs) when required with responsibility                              Formatted: Bullets and Numbering
           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.
                                                                                                             Formatted: Block Text Char
(Note – The Change Verifier and Implementer should not be the same person.)

Responsibilities
       84. Coordinate with the Change Implementer during the change implementation.                          Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                             Numbering Style: 1, 2, 3, … + Start at: 1 +
       85. Validate the successful implementation of the change, (this may be delegated                      Alignment: Left + Aligned at: 0.5" + Tab after:
           to the appropriate Change Domain Expert).                                                          0.75" + Indent at: 0.75"
       86. Validate that the service impacted during the change implementation has                           Formatted: Bullets and Numbering
           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)

                                                                                                            Formatted: Bullets and Numbering

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)                                                                  Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
       88. User managers and user group representatives                                                     Alignment: Left + Aligned at: 0.5" + Tab after:
       89. Change Domain Experts                                                                             0.75" + Indent at: 0.75", Tab stops: Not at
       90. Contractors or 3rdthird- party representatives                                                   0.5"

       91. Other USAMITC process owners                                                                     Formatted: Bullets and Numbering
       92. ITIM/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                              Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
           Manager                                                                                          Alignment: Left + Aligned at: 0.5" + Tab after:
       94. Reviews all submitted CRs to determine their risk and impact, resources                           0.75" + Indent at: 0.75"
           required to implement them, and any implementation or ongoing costs                              Formatted: Bullets and Numbering
       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
ITIM/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



                                                                                                                                                                                                  Formatted: Heading 4
3.4.3.1           STANDARD PRE-APPROVED CHANGE (MANAGER APPROVED)                                                                                                                                 Formatted: Bullets and Numbering


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.
                                                                                                                                                                                                  Formatted: Heading 4
3.4.3.2           SIGNIFICANT CHANGE (CAB APPROVED)                                                                                                                                               Formatted: Bullets and Numbering

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.
                                                                                                             Formatted: Heading 4
3.4.3.3        URGENT CHANGES AND RESTORATION OF SERVICE (BREAK/FIX)                                         Formatted: Bullets and Numbering

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.
                                                                                                             Formatted: Heading 4
3.4.3.4        UNPLANNED CHANGES                                                                             Formatted: Bullets and Numbering

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 ITIM/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                        Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
          Management.                                                                                       Alignment: Left + Aligned at: 0.5" + Tab after:
       101. Plan for resources required for Release implementation                                           0.75" + Indent at: 0.75"
       102. Ensure that master copies of all software are secured in the Definitive                         Formatted: Bullets and Numbering
          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.
                                                                                                            Formatted: Emphasis, Font: Not Bold
Responsibilities
                                                                                                            Formatted: Bullets and Numbering
           Responsibilities:
       105. Ensures that the Release Management process and working practices are                           Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
          effective and efficient                                                                           Alignment: Left + Aligned at: 0.5" + Tab after:
       106. Ensures that all stakeholders are sufficiently involved in the Release                           0.75" + Indent at: 0.75"
          Management process                                                                                Formatted: Bullets and Numbering
       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




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



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,
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.
                                                                                                            Formatted: Emphasis
Responsibilities:
       110. Coordinates activities necessary for the implementation of release and                          Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
          other production change work-orders in an effective and efficient manner                          Alignment: Left + Aligned at: 0.5" + Tab after:
       111. Ensures the service owner of impacted services formally accepts all                              0.75" + Indent at: 0.75"
          planned implementations                                                                           Formatted: Bullets and Numbering
       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.
                                                                                                            Formatted: Emphasis
Responsibilities:
       117. Ensures the accurate and timely recording of all software within the CMDB                       Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
       118. Ensures version information about software components is up-to-date and                         Alignment: Left + Aligned at: 0.5" + Tab after:
          accurate in both the test and production environments (these data are stored                       0.75" + Indent at: 0.75"
          in the logical CMDB)                                                                              Formatted: Bullets and Numbering
       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

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



       121. Distributes and maintains version control of specific copies of software
          used within a controlled release
       122. Conducts software release planning effort
       123. Ensures that software used in a controlled release is distributed on
          schedule, accurately and within budget

3.5.3 High Level Process Flow
                                                                                                             Formatted: Heading 4
       OPERATIONAL SCENARIOS                                                                                 Formatted: Bullets and Numbering

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.
                                                                                                             Formatted: Heading 4
3.5.3.1        TEST SETUP                                                                                    Formatted: Bullets and Numbering

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.
                                                                                                             Formatted: Heading 4
3.5.3.2        RELEASE NOTIFICATION                                                                          Formatted: Bullets and Numbering

Once a controlled Release has been instituted in the ITIM/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.




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


                                                                                                            Formatted: Heading 2, Indent: Left: 0", Tab
                                                                                                            stops: Not at 0.88"
3.6    Availability Management
                                                                                                            Formatted: Bullets and Numbering
                                                                                                            Formatted: Heading 3, Tab stops: Not at 0.5"
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
ITIM/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.

The goals of this process are to:
       124. Ensure ITIM/IT Services are designed to deliver the levels of Availability                      Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
          required by the business                                                                          Alignment: Left + Aligned at: 0.5" + Tab after:
       125. Provide a range of ITIM/IT availability reporting to ensure that agreed                          0.75" + Indent at: 0.75"
          levels of Availability are measured and monitored on an ongoing basis.                            Formatted: Bullets and Numbering
       126. Optimize the availability (resilience, reliability and maintainability /
          serviceability) of the ITIM/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 ITIM/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 ITIM/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.




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


                                                                                                              Formatted: Heading 3, Tab stops: Not at 0.5"
3.6.2 Roles and Responsibilities                                                                              Formatted: Bullets and Numbering

                                                                                                              Formatted: Heading 4
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.
                                                                                                              Formatted: Emphasis
Responsibilities:


       130. Ensures that the Availability Management process and working practices                            Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                              Numbering Style: 1, 2, 3, … + Start at: 1 +
          are effective and efficient                                                                         Alignment: Left + Aligned at: 0.5" + Tab after:
       131. Ensures that all stakeholders are sufficiently involved in the Availability                        0.75" + Indent at: 0.75"
          Management process                                                                                  Formatted: Bullets and Numbering
       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
                                                                                                              Formatted: Heading 4

3.6.2.2        AVAILABILITY MANAGER                                                                           Formatted: Bullets and Numbering


The Availability Manager is required to ensure that availability requirements are met and
to advise senior ITIM/IT Management accordingly as well as to plan for, monitor and
control the availability of ITIM/IT services to meet business requirements, within
specified cost constraints.
                                                                                                              Formatted: Heading 4
3.6.2.3        AVAILABILITY ANALYST                                                                           Formatted: Bullets and Numbering

The Availability Analyst collects and analyzes data for reliability, availability, and
accessibility.
                                                                                                              Formatted: Emphasis
Responsibilities:
       134. Collects and analyses service performance data involving uptime for all                           Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                              Numbering Style: 1, 2, 3, … + Start at: 1 +
          customers for standard services on a regular basis.                                                 Alignment: Left + Aligned at: 0.5" + Tab after:
       135. Proactively identifies uptime issues, making recommendations for                                   0.75" + Indent at: 0.75"
          eliminating those issues.                                                                           Formatted: Bullets and Numbering
       136. Analyses actual data based upon projected data.

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



       137.    Generates and distributes reports on availability performance
                                                                                                             Formatted: Heading 2, Indent: Left: 0", Tab
                                                                                                             stops: Not at 0.88"
3.7    Configuration Management
                                                                                                             Formatted: Heading 3, Tab stops: Not at 0.5"
3.7.1 Overview and Policies
                                                                                                             Formatted: Body Text
Configuration Management is a process that underpins other ITSM Reference Model
processes. It is used to identify and control Configuration Items in the ITIM/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 ITIM/IT Support.

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.
                                                                                                             Formatted: Heading 3, Tab stops: Not at 0.5"
3.7.2 Roles and Responsibilities                                                                             Formatted: Bullets and Numbering

                                                                                                             Formatted: Heading 4
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

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



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.
                                                                                                            Formatted: Emphasis
Responsibilities:
       138. Ensures that the process is defined, documented, maintained &                                   Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
          communicated                                                                                      Alignment: Left + Aligned at: 0.5" + Tab after:
       139. Ensures organizational adherence to the process via the Configuration                            0.75" + Indent at: 0.75"
          Managers                                                                                          Formatted: Bullets and Numbering
       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
       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
                                                                                                            Formatted: Heading 4

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.




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



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.
                                                                                                            Formatted: Emphasis
       Responsibilities
                                                                                                            Formatted: Body Text, No bullets or
       155. Provides or updates CI-related documentation as required                                        numbering
       156. Escalates unauthorized CI changes or alterations to environment not                             Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
          reflected in CMDB to Change Management                                                            Alignment: Left + Aligned at: 0.5" + Tab after:
       157. Supports effective use of CMDB for other groups and processes                                    0.75" + Indent at: 0.75"
       158. Requests Change Management report metrics in support of the                                     Formatted: Bullets and Numbering
          Configuration Management process
       159. Produces process metrics reports
       160. Participates in Change Management process evaluation
       161. Approves structural changes to the CMDB
       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
                                                                                                            Formatted: Heading 4

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.
                                                                                                            Formatted: Emphasis
       Responsibilities
                                                                                                            Formatted: Body Text, No bullets or
       165. Provides or updates CI-related documentation as required                                        numbering
       166. Creates RFCs for CI moves, add and changes (for items contained in the                          Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
          CMDB)                                                                                             Alignment: Left + Aligned at: 0.5" + Tab after:
       167. Modifies CIs to address RFCs as part of the build and test activities                            0.75" + Indent at: 0.75"
       168. Maintains detailed documentation of their CIs and the integrity of the any                      Formatted: Bullets and Numbering
          identified relationships to their CIs
       169. Complies with the Configuration Management process
                                                                                                            Formatted: Heading 4

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).
                                                                                                            Formatted: Emphasis

       Responsibilities                                                                                     Formatted: Body Text, No bullets or
                                                                                                            numbering
            Ensures all CIs are accurately registered or deregistered                                      Formatted: Indent: Left: 0.25", Bulleted +
            Interfaces with other support organizations to ensure the effective use of                     Level: 1 + Aligned at: 0.75" + Tab after: 1" +
                                                                                                            Indent at: 1"
       the CMDB
                                                                                                            Formatted: Bullets and Numbering


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




              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
                                                                                                            Formatted: Heading 4

3.7.2.5        CONFIGURATION MANAGEMENT COUNCIL                                                             Formatted: Bullets and Numbering


The Configuration Management Council can be made up of various roles within the
ITIM/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.



Its purpose is to:
       170. Define, confirm and maintain the contents of the Configuration                                  Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
          Management Plan                                                                                   Alignment: Left + Aligned at: 0.5" + Tab after:
       171. Define relationships and entities within the CMDB                                                0.75" + Indent at: 0.75"
       172. Identify and define data sources for the CMDB                                                   Formatted: Bullets and Numbering
       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
                                                                                                            Formatted: Body Text
Its members consist of:
       175. CI Owners (various domains e.g., networking, applications, servers, etc)                        Formatted: Bullet 1, Numbered + Level: 1 +
                                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
       176. Configuration Manager*                                                                          Alignment: Left + Aligned at: 0.5" + Tab after:
       177. Change Manager*                                                                                  0.75" + Indent at: 0.75"
       178. Incident Manager*                                                                               Formatted: Bullets and Numbering
       179. Problem Manager*
       180. Release Manager*
       181. Service Level Manager*
       182. Configuration Data Analysts (operational or technical support of CMDB
          technologies)
                                                                                                            Formatted: Body Text
* Not all managers are required, as this will be dependent on need.




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


                                                                                                              Formatted: Heading 3, Tab stops: Not at 0.5"
3.7.3 High Level Process Flow                                                                                 Formatted: Bullets and Numbering

                                                                                                              Formatted: Heading 4
       OPERATIONAL SCENARIOS

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.
                                                                                                              Formatted: Bullets and Numbering
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
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.
                                                                                                              Formatted: Bullets and Numbering
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.


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


                                                                                                            Formatted: Bullets and Numbering
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.
                                                                                                            Formatted: Bullets and Numbering
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
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.
                                                                                                            Formatted: Bullets and Numbering
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.
                                                                                                            Formatted: Heading 4
3.7.3.6        CMDB MONITORING                                                                              Formatted: Bullets and Numbering

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.


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



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.
                                                                                                            Formatted: Bullets and Numbering
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.
                                                                                                            Formatted: Bullets and Numbering
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
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.
                                                                                                            Formatted: Heading 2, Indent: Left: 0", Tab
                                                                                                            stops: Not at 0.88"
3.8    Information Technology Continuity Management
                                                                                                            Formatted: Bullets and Numbering
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.




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


                                                                                                             Comment [t11]: Add Knowledge
4.0    BENEFITS DERIVED                                                                                      Management as a benefit.


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                             Formatted: Bullets and Numbering
           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 ITIM/IT personnel can access the system via the Internet, the best ITIM/IT
           resources can be assigned based on criticality of the issue and not based on
           restricted availability because of ITIM/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 ITIM/IT service
           performance.
         186. Customer satisfaction: All customers will enjoy the same high level of
           ITIM/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
           ITIM/IT team will have access to standard service desk procedures stored in
           the knowledge database so that ITIM/IT service delivery will be more
           consistent and directly geared to customer requirements.
         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
           ITIM/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 ITIM/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.
         Industry standard policies, processes, and procedures: As the ITIM/IT industry
           makes the shift to ITIL, we will be on the leading edge of implementing proven

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



          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.
       189.                                                                                                  Formatted: Bullets and Numbering
        190. Risk Reduction: Control and management of change minimizes the risk of                          Formatted: Bullet 1, Numbered + Level: 1 +
          unexpected results due to the introduction of a change to the production                           Numbering Style: 1, 2, 3, … + Start at: 1 +
                                                                                                             Alignment: Left + Aligned at: 0.5" + Tab after:
          environment. Decisions based on accurate information provided by                                    0.75" + Indent at: 0.75"
          Configuration Management reduce unanticipated downtime. Appropriate                                Formatted: Bullets and Numbering
          authorization requirement to make changes to the ITIM/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 ITIM/IT Services enables ITIM/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.
        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 ITIM/IT organizations to monitor
          SLAs and maintenance contracts with greater precision. Retrieved data can
          be sorted, summarized, and reported in whatever manner makes sense.




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




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                                Formatted: Bullets and Numbering
          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 of existing
contracts. 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.

5.3    Deployment Considerations
Deployment of the ESD system should consider the following:
         196. Successful functionality testing.                                                             Formatted: Bullets and Numbering
         DOD Information Assurance Certification and Accreditation Program                                  Formatted: Font: (Default) Arial, 12 pt
          (DIACAP)Defense Information Technology Security Certification and
          Accreditation Process (DITSCAP).                                                                  Comment [t13]: Believe this is now officially
                                                                                                            “DIACAP”. Check with IA.
         197. Networthiness certification.
         198. Customer training.
                                                                                                            Comment [t14]: Don’t understand what this
         199. In-place support.                                                                             is?


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



The ESD will comply with the DITSCAPDIACAP. 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                    Formatted: Bullets and Numbering
          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                      Formatted: Bullets and Numbering
          required, for all support applications used by service desk personnel to
          provide ITIM/IT support.
         204. Establishing interagency memorandum of agreements (MOA) between the
          MEDCOM User Service Desk (USD) and other service desk service                                     Comment [t15]: What is this? The ESD?
                                                                                                            I’ve never seen this term before.
          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:                                                         Formatted: Bullets and Numbering
           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.
           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:                                           Formatted: Bullets and Numbering
           Army CIO/G6, Networthiness Certification Guidance (Draft); enforcement
              mandated by CIO/G6 Policy Memorandum, Army Networthiness
              Certification, 8 Apr 02.


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



DoD

The following standards are mandated:
         209. DoD Instruction 5200.40, DoD Information Technology Security                                  Formatted: Bullets and Numbering
          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               46
1 May 2007

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:8/22/2012
language:Latin
pages:52