SITEC-IT Service Management Process Profiles v4 26Mar10.pdf

U.S. Special Operations Command

(USSOCOM)

Special Operations Forces

Information Technology Enterprise

Contract (SITEC)

IT Service Management

Process Profiles

Table of Contents

1.0 Introduction and Purpose

1.1. IT Process Transformation Overview

1.2. Components Reviewed

2.0 Process Maturity Overview

2.1. Process Maturity Approach

2.2. Overall Process Maturity Results

3.0 Current IT Service Management Architecture

3.1. Remedy Support Environment

3.2. Process Documentation

4.0 Process Profiles

4.1. Central Service Desk

4.2. Incident Management

4.3. Problem Management

4.4. Change Management

4.5. Release Management

4.6. Configuration Management

4.7. Asset Management

4.8. Service Level Management

4.9. Demand Management

4.10. Capacity Management

4.11. Availability Management

4.12. Event Management

5.0 Integration of SIF and SIT Procedures with ITIL Processes

6.0 Conclusion

1.0 Introduction and Purpose

The United States Special Operations Command (USSOCOM) was formed in 1987 and is a unified combatant command of the Department of Defense (DoD). USSOCOM’s mission is to provide fully capable Special Operations Forces (SOF) to defend the United States and its interests; and plan and synchronize operations against terrorist networks. USSOCOM is responsible for training and equipping all DoD SOF to perform missions anywhere in the world at any time. Specific responsibilities of

USSOCOM include: developing, acquiring, integrating, fielding, and supporting special operations peculiar equipment, material, supplies and systems and ensuring the interoperability of equipment and forces.

Information Technology (IT) and its associated support processes are significant enablers of the

USSOCOM mission. USSOCOM requires continuing support for the operations and maintenance of the

Command’s IT environment and supporting processes. USSOCOM is moving from a single provider of services and seeks IT services from best-of-breed providers covering the full spectrum of IT requirements on a global scale. USSOCOM and its Components have existing support processes of various maturities.

Through the new SOF IT Enterprise Contract (SITEC) acquisitions, USSOCOM is seeking service providers for the integrated delivery of the Commands mission supporting IT infrastructure and operations. To clarify the vendor communities understanding of the USSOCOM IT environment and its underpinning IT

Service Management processes, USSOCOM developed this document to communicate the current state of its IT delivery processes. USSOCOM recognizes the need to define, develop, implement, and manage an enterprise IT process framework that will enable successful service delivery within the scope of the

SOF Information Technology Enterprise Contract (SITEC) acquisitions.

1.1. IT Process Transformation Overview

In support of SITEC, USSOCOM is conducting an Enterprise process transformation project. The first step of this project is to develop a baseline maturity assessment for key IT operational management processes and functions. USSOCOM will include the following processes in the initial transformation planning:

Demand Management

Capacity Management

Service Level Management

Availability Management

Asset Management

Change Management

Configuration Management

Release Management

Incident Management

Problem Management

Service Desk (Function)

Event Management

Transformation project goals include:

Develop a maturation plan based on the results of the process assessments with rapid transition plans and requirements to chart a path to improved IT service management for the SIE

Create a process taxonomy that is designed to help mitigate the common misunderstanding of terms based on the varied background of SIE participants. The taxonomy will serve to provide a classification of terms and their definitions for IT service management. The output of this effort will include a glossary of terms and the context within which each is applied relevant to service

Refine the SIE governance decision making framework and development of governance transition requirements

Implement Enterprise process improvement for select processes as determined by the process maturation plan to include targeted process modeling, workflows, and transition planning

Develop a preliminary IT Services Catalog

Develop a Process Reference Architecture

USSOCOM will build out select process components to serve as a common framework for key process standardization across the Command. USSOCOM will determine specific processes according to the process maturation plan and roadmap. USSOCOM is designing this approach to get to a synergistic point in process maturity to move from a reactive process and service management activity to a proactive state and begin managing their IT services portfolio in an on-going manner and promote continuous service and process improvement. The aim of this activity is to promote the improvement of the quality of services, overall maturity of the ITSM service lifecycle and its underlying processes within three areas of the SIE delivery model:

Overall health of SIE IT Service Management as a discipline

Continual alignment of the SIE portfolio of IT services with the current and future USSOCOM mission needs

Maturity of the enabling IT processes required to support mission processes in a continual service lifecycle model

1.2. Components Reviewed

USSOCOM conducted a rapid process assessment through interviews, data collection, and analysis. For the purpose of this activity, USSOCOM conducted the assessments and analysis for the USSOCOM

Enterprise, the five service Components and the USSOCOM Headquarters (USSOCOM HQ) as a

Component. The Component Commands include:

AFSOC – Primary focused on facilities located at Hurlburt Field and AFSOC functions in around

Ft. Walton Beach, FL, Cannon AFB, NM, and functions providing reach-back support of forward deployed units.

USSOCOM Headquarters (HQ) – Primary focused on IT facilities located at Tampa, FL area.

JSOC – Primary focus on locations in and around Fayetteville, NC plus other global sites. For the purposes of this summary JSOC information is provided as informational only. JSOC IT Services are not Contractor managed, Government personnel manage all aspects of the IT Services with assistance from Contractors when supplemental resources or special skills are needed.

MARSOC (HQ) - Primary focused on IT facilities located at Camp Lejeune that support functions in and around Jacksonville, NC and Camp Pendleton located in Southern California, with reach back support provided as need to forward deployed IT Services from MARSOC (HQ) and

USSOCOM.

NAVSOC – Focused on facilities in Coronado, CA with coverage of the Little Creek, VA location, OCOUNS locations, and functions providing reach-back support for forward deployed sites.

USASOC – Primary focused on locations in and around Fayetteville, NC plus 9 additional CONUS sites and 4 OCONUS prime locations (approximately 30 sites that reach-back to USASOC or

USSOCOM for services).

2.0 Process Maturity Overview

2.1. Process Maturity Approach

Through a series of interviews and investigations of the operational environment, USSOCOM determined a process maturity for a core set of elements. Each element of each process has its own definition of maturity. The elements are:

Process documentation/implementation - documentation and compliance

Integration – integration with supporting processes

Skills and personnel – knowledge and ownership of process

Tools and automation – tools that help automate the process

Metrics and governance – process metrics, policies, and guiding principles

Scores were developed for each of these elements by process. These scores for each element use a

Capability Maturity Model (CMM) -like scale of 1 to 5 to measure the maturity of the process within each of the maturity buckets:

5-Optimized: Highly mature, fully optimized

4-Controlled: Proactively managed and controlled.

3-Defined: Moderately mature, consistently defined process across the enterprise

2-Repeatable: Starting to be seen in silos across the organization, but may be executed differently across various groups

1-Adhoc: Immature process with no leverage, ad hoc

For each process, USSOCOM determined which processes had not been documented or are not well defined (e.g., workflows, operating assumptions, ownership); whether or not the people performing these processes leverage the experiences of others performing similar processes; and if there is agreement for how each process should be performed. Additionally, USSOCOM determined whether policy documents were published to all stakeholders, containing, at a minimum, scope, definition, roles and responsibilities, lead times, exception processing, principles, and documentation related to each process; lists of key contacts, suppliers and resources.

Further, USSOCOM identified whether each of the processes were integrated with other IT delivery processes, including if each process was performed in silos, independent of other operational processes;

if process integration analysis had been conducted, and if any "hand-off" points were manual.

USSOCOM, for each process, reviewed skills and personnel activities as well as the tools and automation used for each process. USSOCOM examined each environment to determine if tools had not been identified to perform or assist in performing each process, and the level of progress toward tool/automation goal setting, and adoption of extensive tool sets to support "end to end" automation goals.

USSOCOM reviewed the metrics, measurement, and governance for each process to determine how far each Component had progressed towards the identification, capture, and reporting of metrics across all dimensions (e.g., efficiency, effectiveness, risk). This included whether established baselines and thresholds are known, and whether reporting has moved to a dynamic (i.e., real-time) model.

USSOCOM also identified if metrics are consistently used for process improvement feedback and if metric trends are analyzed and understood.

Finally, USSOCOM used the following industry standard definitions from the IT Infrastructure Library

(ITIL) V3 to ensure a common understanding of the processes that were analyzed and assessed:

Service Desk Function - (Service Operation) The Single Point of Contact between the Service

Provider and the Users. A typical Service Desk manages Incidents and Service Requests, and also handles communication with the Users.

Incident Management (Service Operation) - The Process responsible for managing the Lifecycle of all Incidents. The primary Objective of Incident Management is to return the IT Service to

Customers as quickly as possible.

Problem Management (Service Operation) - An Activity that identifies the Root Cause Analysis

(RCA) of an Incident or Problem. RCA typically concentrates on IT Infrastructure failures.

Change Management- (Service Transition) The Process responsible for controlling the Lifecycle of all Changes. The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT Services.

Release Management and Deployment Management - (Service Transition) The Process responsible for both Release Management and Deployment.

Asset Management - (Financial Management) Asset Management is the Business Process responsible for tracking and reporting the value and ownership of financial assets throughout their Lifecycle.

Configuration Management - (Service Transition) The Process responsible for maintaining information about Configuration Items (CIs) required to deliver an IT Service, including their

Relationships. This information is managed throughout the Lifecycle of the CI. Configuration

Management is part of an overall Service Asset and Configuration Management Process.

Demand Management (Service Strategy) - Activities that understand and influence Customer demand for Services and the provision of Capacity to meet these demands. At a Strategic level

Demand Management can involve analysis of Patterns of Business Activity and User Profiles. At a Tactical level it can involve use of Differential Charging to encourage Customers to use IT

Services at less busy times.

Capacity Management - (Service Design) the Process responsible for ensuring that the Capacity of IT Services and the IT Infrastructure is able to deliver agreed Service Level Targets in a cost effective and timely manner. Capacity Management considers all Resources required to deliver the IT Service, and plans for short, medium and long term Business Requirements.

Service Level Management (SLM) – (Service Design) The Process responsible for negotiating

Service Level Agreements, and ensuring that these are met. SLM is responsible for ensuring that all IT Service Management Processes, Operational Level Agreements, and Underpinning

Contracts, are appropriate for the agreed Service Level Targets. SLM monitors and reports on

Service Levels, and holds regular Customer reviews.

Availability Management - (Service Design) The process responsible for defining, analyzing, planning, measuring and improving all aspects of the Availability of IT Services. Availability

Management is responsible for ensuring that all IT Infrastructure, Processes, Tools, Roles, etc.

are appropriate for the agreed Service Level Targets for Availability.

Event Management (Service Operation) The process responsible for managing Events throughout their Lifecycle. An event is a change of state that has significance for the management of a Configuration Item or IT Service. Notification or Alert may occur by any IT

Service, Configuration Item or Monitoring tool. Events typically require IT Operations personnel to take actions, and often lead to Incidents being logged.

2.2. Overall Process Maturity Results

The current USSOCOM average level of maturity is below 2.0 and is within the process re-engineering

“Chaotic/Reactive” range as of early 2010. In contrast, the overall industry average was 2.6 for those clients Gartner, Inc. has worked with as part of process maturity assessment. For the future state of

SITEC, Gartner recommends establishing a level 3 target which is moving towards the “Proactive

/Defined” range of service delivery. The USSOCOM IT Service Management Process Maturity is based on

IT Infrastructure Library (ITIL), Control Objectives for IT (CoBIT), and SEI’s Capability Maturity Model

(CMM).

Figure 1 USSOCOM IT Service Management Process Maturity

USSOCOM recognizes that a tool-based approach, however important, is only part of their proposed future state; it will only provide workflow and the measurement framework to establish proactive service delivery and the construct to define process workflow within the tools. USSOCOM recognizes the importance of a total process approach that addresses people, process, and technology by establishing goals for process, governance, and technology.

Additionally, there are other processes and functions which USSOCOM has expressed an interest in developing, but do not currently have a measurable level of achievement. An example of this would be the IT Service Catalog (not listed). Although various entities within USSOCOM have attempted to develop a version of a catalog over the years, it has not gained wide acceptance to date. Additional integration support from all service providers will be expected as process maturity increases.

3.0 Current IT Service Management Architecture

The current USSOCOM IT Service Management environment consists of a combination of people, process, and technology. Currently, USSOCOM’s focus is less on process to assure achievement of IT

Service Management and more on people and technology. USSOCOM has a significant amount of “tribal knowledge” integrated in the knowledge of their support teams. Further, USSOCOM heavily depends on the workflow built into tools that provide the process for many support functions. The IT Service

Management process that have been defined within USSOCOM are supported more by a few non-complex process documents/ policies and the processes functions that are defined within the IT Service

Management Suite provided by the BMC Remedy software. This is primarily the service processes that support the service desk and change requests. This architecture is hosted in multiple (3) environments according to their associated network classification.

3.1. Remedy Support Environment

Figure 2 below depicts the instances of Remedy supporting the three-tiered network environment for

USSOCOM. Note the manual integration of data between NIPRNET/ SIPRNET/ and JWICS. The majority of Remedy supported information is managed out of the SIPRNET environment where possible. Often ticket stubs will be created to flag the existence of a ticket in a Remedy instance at another classification. This is manual, however, and not always followed due to resource loads and security implications. In general this procedure relies upon the diligence of the service desk analyst and there is no guarantee the tickets are updated across all Remedy instances.

Figure 2. Integrated Service Desk – Three Network Architecture

As shown, the architecture is the same on each implemented network—Unclassified, Secret, and SCI.

The specific capabilities provided by the functional elements include:

Remedy 1 - Primary application/web server for the Remedy software suite and hosts the web interface for users.

Remedy 2 - Backup application/web server that mirrors the primary server (the two server concept provides redundancy should one fail).

Remedy Database – The core Configuration Management Database (CMDB) resides here.

Remedy Reports/Backup - All transactions are sent to the backup server via a Distributed Server

Option (DSO) component; thus, a backup is always available should communication with the primary site be disrupted.

Data Transfer - Asset and ticket data will be transported from the SCI and Unclassified networks to the Secret network for consolidated reporting purposes. The data transfer is a manual effort in accordance with USSOCOM security policies.

Remedy Development Environment - A complete single network environment to develop ISD capabilities. Currently, this environment is located at current contractor’s office in Tampa, Florida.

System Administration - Presently, there are ISD System Administrators who perform all system administrator tasks for each of the three networks; administration occurs at USSOCOM HQ and at AFSOC. All configuration changes they undertake are in response to an approved CR processed via the Change Management Process.

3.2. Process Documentation

Process documentation within all Components was limited at the process level. The majority of the documentation referenced “USSOCOM DIRECTIVE Number 25-5, Information Management—

Management of Sub-disciplines, INFORMATION TECHNOLOGY CHANGE, CONFIGURATION, AND RELEASE

MANAGEMENT” – Published 19 April 2005 (22 Pages) along with the current vendor developed

“Information Technology Service Support Process Definition” February 2007, Document #: TE070221EC-

CM1040F (40 Pages). Additionally, each Component Command has developed a version of USSOCOM

Directive 25-5 that is very similar if not identical to the USSOCOM Directive. The USSOCOM Directive covers centrally managed services such as the networks managing SCI and Secret levels of information whereas the Component Command 25-5 Directive covers locally-provided services such as the NIPRNET hosted network, often provided by the Component’s primary Service aligned force. Additionally, some

Components developed their own appendices for the “IT Service Support Process Definition” document

(e.g. NAVSOC).

Within this documentation there was typically a common ITIL based definition of the process and a very high-level description of major activities focusing on the “why” and “when” of each activity, and limited details around the “how.” It should be noted there was a robust number of operational procedures not tied to any individual process used by local help desks within the Components and HQ to perform administrative and end-user support tasks (password resets), report security issues, define user accounts, etc. See the proceeding table for a summary of the current state documentation of the IT operational processes by Component.

Table 1. Documentation Summary for Each Process by Component Command Reviewed

Process Definition Definition Exists and Published

Scope

Defined

Workflow

Documented

Owner

Assigned

Supporting

Policy in Place

Roles

Defined

Integrate with other

Processes

(Formal)

Service Desk

AFSOC

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

NAVSOC

USASOC

AFSOC

NAVSOC

USASOC

AFSOC

HQ

JSOC

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

JSOC

MARSOC(HQ)

NAVSOC

USASOC

HQ

USASOC

AFSOC

NAVSOC

USASOC

Incident Management

AFSOC

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

JSOC

NAVSOC

USASOC

AFSOC

JSOC

NAVSOC

USASOC

AFSOC

HQ

JSOC

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

JSOC

MARSOC(HQ)

NAVSOC

USASOC

HQ

USASOC

AFSOC

NAVSOC

USASOC

Problem Management AFSOC

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

NAVSOC

USASOC

AFSOC

NAVSOC

USASOC

AFSOC

HQ

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

MARSOC(HQ)

USASOC

AFSOC

NAVSOC

USASOC

Change Management AFSOC

HQ

MARSOC(HQ)

NAVSOC

USASOC

HQ

NAVSOC

AFSOC

USASOC

JSOC

HQ

NAVSOC

AFSOC

USASOC

JSOC

AFSOC

HQ

JSOC

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

JSOC

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

MARSOC(HQ)

USASOC

AFSOC

NAVSOC

USASOC

Release Management AFSOC

HQ

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

JSOC

NAVSOC

USASOC

AFSOC

HQ

JSOC

NAVSOC

USASOC

AFSOC

HQ

JSOC

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

JSOC

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

MARSOC(HQ)

USASOC

AFSOC

NAVSOC

USASOC

Asset Management

AFSOC

HQ

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

NAVSOC

USASOC

AFSOC

HQ

NAVSOC

USASOC

AFSOC

HQ

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

NAVSOC

USASOC

Configuration

Management

AFSOC

HQ

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

NAVSOC

USASOC

AFSOC

HQ

NAVSOC

USASOC

AFSOC

HQ

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

MARSOC(HQ)

NAVSOC

USASOC

AFSOC

HQ

NAVSOC

USASOC

Demand Management None None None None None None None

Capacity Management None None None None None None None

Service Level

Management None None None None None None None

Availability

Management None None None None None None None

Event Management None None None None None None None

4.0 Process Profiles

The following service processes and functions detail the current state of the USSOCOM process environment. The first activity is not an actual process, but rather the service desk function. This function is a user of the other processes, most notably incident, problem, and change. Although mature services desks benefit from the data utilization from configuration and asset data and information, the

USSOCOM activities have not achieved a maturity level in order to realize the benefits of integration between these processes via a CMDB. As a result, USSOCOM has architected a current solution which focuses on keeping the data current within a Configuration Management Database (CMDB) and maintains one common CMDB of reference that other databases feed at an enterprise level.

4.1. Central Service Desk

There is a virtual central service desk provided by USSOCOM commonly referred to as the Central

Service Desk (CSD). The CSD has primary service hours between 07:00 and 20:00 Eastern Time zone.

Global Network Control Center (GNCC) data center supports IT service management outside of these hours for service desk functions. This Service Desk fields a customer facing personnel during operational hours including management activities. The personnel averages between 4,000 and 5,000 in-bound calls a month, between 300 to 500 email requests, and approximately 1,400 requests or interactions via portal applications. The service request volumes were based on a sample of 10 months; however, the

CSD has recently seen volume spikes as high as 2,000 calls within a week attributable to organic growth and consolidation of call activity from Components into CSD. Approximately 20% of tickets are resolved by the service desk, 70% are escalated to tier 2 and 10% require tier 3 involvements. In addition to the usage of BMC Remedy, agents interact with remote and chat capability. All Service interactions occur within a SCIF environment and the primary network supported is at the Secret level and resides on

SIPRNET. Two additional networks are maintained with instances of Remedy that support Top Secret-

SCI computing environments. Unclassified network data is maintained in the Remedy SIPRNET instance.

Agents currently have a maximum of 3 calendar days to clear a trouble ticket. If the customer is not available the ticket is closed after 3 days. This is common in cases of temporary duty (TDY) or deployment issues. For high or urgent tickets, the CSD has less than 30 minutes to acknowledge working of the ticket. All urgent tickets are supposed to have a response in 4 hours, with routine tickets requiring a response in 24 hours. This metric is often ignored when supporting Information Assurance (IA) related tickets which in its nature may take longer and require more coordination and details in its response.

Tickets below urgent are acknowledged and worked on a First-in-First-Out (FIFO) basis. The BMC

Remedy auto response is used to acknowledge all tickets. When a customer uses self service portal, only medium or low priority may be set. The CSD may increase the priority. Urgent and high priority tickets come in via phone or monitored email queue as a backup to phone service. VIP flagged tickets are always assigned as urgent or high response. Medium is a new priority that has recently been implemented. Low priority has no priority and falls under the 3-day rule, often these show up on 30 day aged ticket reports. This report is the real active monitor mechanism for low priority tickets. The CSD provides routing to Component tier-2 service desks for incident, problem, and change requests.

Currently these Component desks provide tier-1 services for their users.

USSOCOM has an active initiative to consolidate into a virtualized Enterprise Service Desk at two sites

(Little Creek, VA (NAVSOC) and Tampa, FL (USSOCOM HQ)). Phase 1 of the consolidation included stand up and infrastructure changes to the targeted sites to support the consolidation and is complete. Phase

2 includes the implementation of tier 1 services for NSW-West and is currently underway. Phase 3 covers the migration of USASOC and is scheduled to begin the first of March 2010 and the AFSOC schedule has yet to be determined. USASOC also has several subordinate commands within CONUS that have their own help desks that reach-back to their current Component help-desks for tier 2 in addition to the TACLAN supported forward deployed services desks. USSOCOM’s current rationale is that the subordinate commands will go through TACLAN supported Service Desks for reach-back and tier 2 support. Future delivery will dictate that TACLAN reach back to CSD for support and production personnel will be dedicated for level 2 and 3 tier support. Current TACLAN repair activities averages between 50 and 75 interactions monthly.

Service desk queues are set up for each Component, and BMC Remedy is the system used. Remedy

CMDB contains configuration information accessible to the service desk for all USSOCOM supported assets. In some cases these are only enterprise assets within the CMDB as some Components support their own end-user devices and are specialty networks with government resources (i.e. AFSOC CSA and

USASOC Bravo 24 personnel). CSD personnel make the greatest differentiation of ticket types and separate change from incident, problem from incident, and changes from tasks or service requests. The service desk processes are documented to some degree with the workflow being documented within

Remedy only, an incident and problem process owner assigned, supporting policies, and some metrics in place.

A majority of tickets are logged for areas that are supported by Remedy or users are asked to contact their area help desk to open a ticket. The exception is areas such as USASOC schoolhouse or training locations where a volume spike between classes occurs and walk-up service is available. Still, even for these sites logging is estimated to be between 60 and 85%.

4.2. Incident Management

USSOCOM follows general ITIL guidelines for incident management across the board. Problem groups are established and defined in Remedy queues to help differentiate between problems and incidents.

However, there is little usage of the problem queues and related ITIL defined functions. Once classified as an incident, tickets are generally worked as an incident and they are not likely to be reclassified as a change request when entered as an incident by a user. Impact and urgency are considered when selecting ticket priority, but USSOCOM has no consistent incident prioritization criteria across any

Components. Ticket priority is ultimately the responsibility of the help desk manager or watch officer depending upon incident type. USSOCOM uses BMC Remedy at Components and SharePoint for some

USASOC subordinate commands that have their own help desks. Status updates are made when changes in tickets occur. The CSD and Component helpdesks do not send out ticket links via email or other communication. A portal does, however, have links and a CR Status page for user information.

The primary BMC Remedy instance used for incident management resides on SIPRNet. Two additional networks are maintained with instances of Remedy that support Top Secret-SCI computing environments. Unclassified networks data is maintained in the Remedy SIPRNet instance.

Roles are not well documented beyond simple documentation or organizational documentation. This usually consists of some simple swim lane diagrams of a page or less workflow showing major activities as defined in ITIL. Process integration is closely limited to out-of-the box tool integration which includes integration to configuration management to look up CI information, the change management tab on the ticket for related changes that need to be requested to restore service, the ability to designate a ticket as a problem or relate the incident to one. There are no interfaces defined to service level management, availability management, or capacity management.

Matching capabilities are limited by knowledge management and data capture for comparison to known errors, permanent fixes, and temporary work-a-rounds. Today, this is based on SharePoint archives, past incident records, and work documents, and a business portal where the current contractor posts all deliverables which contain some trip reports and meeting minutes that document related information.

The primary ability to match to previous records comes in the form of basic tribal knowledge among support personnel. The most mature knowledgebase for this is located at the NAVSOC Component which has 18 months of data captured. It should be noted that there is currently a business based knowledge management initiative that may help in this area. Finally, metrics are limited to Remedy based reports, and service desk SLA reporting.

4.3. Problem Management

As mentioned under incident management, the CSD has problem groups established and defined in

Remedy queues. However, these receive very little volume due to limited resources and lack of formal defined processes besides basic ITIL knowledge that has not been extensively localized at each site.

Problems today are typically worked as incidents with a few exceptions dependent upon impact and visibility of reoccurring or large incidents. One USASOC site is conducting some proactive problem management in which QA/QC reviews change requests looking for circular movement. This site is just beginning to raise CRs as a result of problems. NAVSOC is beginning to focus on related incidents as problems. All other sites including HQ are focusing on reactive tasks. Methods to address problems and identify errors are very immature and more an art than science with the exception of AFSOC where aids are developed as part of test lab activities and placed on end-user support portal for government client support administrator (CSA) desk-side support personnel to use in diagnosing, trouble shooting, and fault tree usage. Roles, metrics, workflow, tools, and policies are still emerging in this area.

4.4. Change Management

Change management is defined in the USSOCOM Directive 25-5, Information Management-

Management of Sub-disciplines, INFORMATION TECHNOLOGY CHANGE, CONFIGURATION, AND RELEASE

MANAGEMENT; this includes scope, purpose, policy, activities, and roles. As part of standardizing this process, USSOCOM has established Configuration Control Boards (Charter is defined in Directive 25-5) and Enterprise Standards groups (Deputy level chaired group that along with TSOCs provide input to CIO

Council). Additionally, input is provided by various contract principles as part of an informal CIO Council advisory group. All of these groups provide input to an approving authority or as an approving authority, prioritize and approve requirements as needed. Local Components have had to localize these policies as needed to interface with their parent organization for approvals and data from business systems. For example, all request and business requirements approval come from the AFSOC PWRR (Project

Workflow Requirement Resource) system. As part of establishing interfaces, AFSOC has had the current vendor develop MS-Access databases that contain and track, change and service request/ tasking approval information. These local access databases shadow Remedy in order to accomplish interfaces to

PWRR. These databases include a CMDB, a change (CRSD – Computer Systems Requirements

Documents), Service Level (SLATE – Service Level Tracking Environment), and Task/ Request database

(TCNO - Time and Compliance Network Order) within MS-Access. However, the system of record is BMC

Remedy. Reporting occurs from the MS-Access CMDB database to account for true-ups, in progress moves, etc. Printers and end-user devices are not tracked in either CMDB for AFSOC or managed by vendors; however they are tracked at the Command and Unit level as part of their business procedures and maybe tracked in the Air Force ITAMS. ISD CMDB does not support AFSOC requirements for links to

ITAMS (Information Technology Access Management System), and Microsoft System Center

Configuration Center Manager (SCCM is replacing Microsoft SMS – Systems Management Server). The

MS-Access based system has a real time posting to Remedy to keep data synchronized.

Additionally, local Components have established informal local CABs that are limited to odd changes, big local projects, server upgrades, and patches. The CCB consists of G6 plus Information Management

Officers from each Component. Attendance is adjusted by topic and agenda as needed. Formal Impact

Assessment Process (IAP) documents are required to be completed to support changes (part of Directive

25-5). The IAP consists of a formal checklist designed to raise visibility of impacts prior to release. There is no operational level conduit outside of the CIO council that provides input and coordination activities for individual Enterprise changes.

Emergency Change procedures are not documented, but are Command driven based on Watch Officer or Command approving a change for immediate release. In many cases the change is followed up with official change record for documentation, although this does not always happen, there will be an entry in the GNCC log. In general, site personnel felt that the emergency path is often abused via Command’s directive over-ride of the standard procedures. The issue appears to be with the current governance model for changes and configuration management.

No Forward Schedule of Change (FSC) were observed (outside of JSOC), however scheduled maintenance windows do exist for a 90-day look-ahead only. Most site managers maintained their own calendars in addition to the maintenance windows. The maintenance windows, in most cases, are developed with awareness of mission critical times to avoid for implementing releases and were tied to the Authorized Service Interruption (ASI) request procedure.

For USSOCOM HQ and any CSD managed tickets, NIPRNet related items are submitted into the SIPR

NWR Remedy instance where they are managed.

4.5. Release Management

Release management is also defined in the USSOCOM Directive 25-5. The Directive covers both internally developed and acquired solutions. The Directive covers three main areas including:

Solution Development and Test

Certificate to Operate

Fielding and Installation

Both HQ and AFSOC have a formal process for hand-over from development to operations and all

Components had a segregation of duties between development, packaging, testing, and production deployment activities. All Components supported a separate test environment and allowed sufficient time for the release and deployment processes for most changes. However, most were quick to point out that their test and QA environments (if available) did not mirror production. It is a standard procedure to release common upgrades and enhancements to the NIPRNET environment as a form of live-fire production test before moving common enhancements into the SIPRNET or other secure environments. Stakeholders are encouraged to be involved in the release, testing, deployment, training and transition processes, although availability of resources may limit follow-through on their part. It is, however, mandated as part of Baseline Acceptance Test (BAT) procedures. BAT is performed by the developers, system administrators, users, and the system integrators who collectively verify that the solution meets the user’s needs, security standards, and command standards.

Components have release policies that contain release naming and numbering conventions that are informally adhered to. (It is to their advantage to avoid collisions and re-work, so they usually are followed.) Only AFSOC and HQ formally had release policies outlining issuing emergency fixes (e.g., only strict emergency fixes to be issued in between formally planned releases of enhancements and non-urgent corrections). Project managers schedule rollout meetings for managing personnel and groups involved in each release to review set targets/objectives of a release/ build as needed. This is part of

Project Manager’s Implementation Planning Phase; however there is no oversight to assure it is conducted. Mission critical times to avoid for implementing releases have been identified by most

Components as mentioned under the Change management current state. These tend to have ties to deployments, exercises, year end, and for NAVSOC during peak daily workloads (prime shift for garrisoned personnel). Back out plans are required, but not necessarily tested before production release. Finally, metrics are limited to Remedy based reporting.

4.6. Configuration Management

Configuration management is also defined in the USSOCOM Directive 25-5. This Directive covers:

Configuration Management Plan (CMP)

Configuration Identification

Configuration Control

Configuration Status Accounting

Configuration Verification

Additionally, this Directive provides the requirement for a Configuration Management Database

(CMDB). SIPRNet Remedy (ISD) has been chosen as the official system of record for configuration management. All other systems (AFSOC MS-Access CMDB [real-time updates]), Navy-East Asset

Management, etc. [every 30 days]) post their changes to this system. SMS or SCCM (replacement for

SMS) is reconciled against this database.

Only current contractor managed items are in the CMDB. These include: Servers, Routers, Switches, Tape Libraries, Desktops, Laptops, and Network Printers. NAVSOC appends VOIP Phones, Hard Drives, USB Drives, Software, Cell/Mobile Phone/PDA, Scanners, External CD/DVD Writers, and Monitors. CI

Attributes are limited to Category, Type, Item, Region, Site, Department, Building, Room, Network, Status, Hostname, Serial Number, Cost Center, Received Date, Installation Date, Program, A System

Role, SLA Number, IP Address, Manufacturer, and CR Number. NAVSOC has appended the attributes with the following table:

Table 2. NAVSOC CI Attributes

AFSOC is maintaining their shadow database to provide linkages to operational data such as SMS/ SCCM snaps/dumps and indexing of records to their branch asset tracking systems. However, even without this interface, most sites believe valuable capacity and operational data are captured that could be leveraged for capacity planning and procurement activities. Finally, no metrics, workflow, or configuration management specific documentation is captured.

4.7. Asset Management

Asset management procedures integrate with HQ and Component procurement and change management processes, in general, at the point of entry into the Enterprise. No electronic tagging occurs today. USSOCOM conducts procurement for enterprise assets. Components are responsible for procuring all local managed assets, although the Components may order off of headquarters contracts.

Components are working to get better control of this process. Interfaces to business systems for the procurement side of asset management vary by Component. AFSOC interfaces directly with the business side of the change request and picks up the request off the PWRR system. USASOC just issued a draft

SOP that is currently in review that places the interface point between their business asset management systems (Property Book) with linkages to the IT Change Request (BMC Remedy). Currently this is a manual personnel responsibility for each change. This process builds the bridge to reconcile IT Assets inventoried with Property Book. For USASOC the roles of procurement are documented and well understood. For other Components, documentation and workflow is limited and standard process is beginning to emerge.

Automatic configuration detection and checking mechanism or scanning software is available for networks, PC/ workstation, and servers to detect network connected devices and their current configuration. Select software is bounced against SMS/SCCM every 30 days for tracking. This data is reconciled against the CMDB by Government personnel (Inventory Control). Hardware inventory is conducted at least annually. Currently, there are many problems with the visibility of patching and reconciliation. Patches are often pushed, dropped, re-pushed, and counted twice, causing reconciliation counts to be inaccurate. Patch reconciliation via SCANs of assets is not a simple or defined process.

USSOCOM and all Components have standard asset procurement guidelines and architecture lists (ASL).

Contracting often identifies alternative buys from alternate sources (small business or set asides). Often not enforcing standards, waivers are freely granted with no sunset dates for waivers. This results in some CI/ Asset diversity.

For hardware, the end of lifecycle is well managed. All Components have standard Defense Reutilization and Marketing Office (DRMO) processes in place for retirement and excess of devices. HQ focuses more on server lifecycle than workstation. Workstations are typically managed by default refresh rate established at time of purchase. Software is less structured and old versions often exist within secure storage archives. Software relies upon owners to identify when to stop paying for licenses and to retire/ archive. SMS/SCCM, but also Microsoft WSUS (Windows Server Update Services), and HBSS (Host Based

Security System) are all used to compare with assets of record. However, in the case of USASOC, a baseline has never been established with the CMDB/ Asset Database.

4.8. Service Level Management

Currently, service levels are not expressed in end-user business terms. Service levels are tightly woven around the original contract measures of the current service provider. It is the general consensus that the current metrics do no measure the real business and IT service delivery needs. The existing current state measurements have been in-effect since 01 April 2007.

Table 3. Current State Measurements

Measurement Weight (%)

SCAMPI WAN Availability

SCAMPI WAN Problem Resolution

LAN Services

Network Security Incident Reporting

Security Vulnerability Remediation

First Call Resolution

Help Desk Resolution

Customer Satisfaction – Help Desk

Contractual Deliverables

Web Services Availability

Database Service Availability

Network Attached Storage Service Availability

Exchange Service Availability

Asset Management

Management of Task Order Closeout

User Email Experience

Infrastructure CMDB Accuracy

Trouble Ticket Resolution

Under the terms of the existing contract, each SLA identified delivery points, descriptions, frequency, how measured service level values and exceptions. An exception was defined as an event beyond the control of the contractor. Vendor personnel working on non-Firm-Fixed-Price (FFP) CLINs were excluded from these measurements and are not calculated as part of the service level values. If a FFP function

“hands-off” responsibility for resolution to non-FFP functions, the resolution time was designed to stop or provide a “time-out” that was not part of the calculation. Timekeeping started again when the vendor

FFP functions take resolution responsibility again. The contractor was provided physical access to equipment and work locations in order to execute services and perform within the service level values described in this document. All high-side, TS or SCI SLA measurements were performed via help desk trouble ticket review until measurement tools were approved and implemented for use.

The current contractor updated the SLA document with an SLA Management Plan that clarified the collection, reporting, and review methodologies prior to the evaluation period and within 90 days of any

SLA changes throughout the life of the contract. The SLA Management Plan was intended to provide overall management guidance to the partnership for performance measurement, enterprise control, and status reporting. Modifications to SLAs and to the SLA Management Plan were expected to be necessary during the life of the contracts and could only occur with the concurrence of the Government.

The current contractor developed an automated means capable of storing and providing access to performance metrics and reports and provided USSOCOM approved personnel access to the performance, metrics and reports. This system provided input into the Integrated Process Team (IPT) hosted by the PCOR created for developing, implementing, and continuously improving Service Level

Management. The current contractor was a participant in these meetings. The IPT finalized the SLA

Management Plan with USSOCOM strategic IT planning and provided a system engineering approach.

(Included: Performance Category, Title, Description, Objective, Relationship to Business / Mission, Who, Sites / Locations, Hours of Service, and Scheduled Outages) The output defined the overall model for managing and implementing SLAs. The IPT developed the processes to collect SLA-relative data, how the tools will be configured and adjusted to collect this data, and the processes and tools needed to aggregate the data. The plan was updated with the policies and procedures for establishing a proactive approach to constantly monitor performance, and identify action if an SLA performance nears and/or falls below negotiated thresholds of performance. This System was developed in MS-Access and is commonly referred to as SLATE.

SLATE provides the necessary mechanics for reporting to the contract SLA requirements, but very little detail is provided on operational level metrics, and in general the current agreed to metrics do not provide the types of information to support operational improvement. Additionally, no Operational

Level Agreements/Associate Contractor Agreements, Underpinning Contracts, or Memorandums of

Understandings are established to underpin the SLAs or provide related monitoring and reporting to understand effectiveness of SLA component services. Current tools involved in collecting data include:

System Center, Solar Winds, HP Openview (to be retired), Ops Manager, and BMC Remedy at various

Component sites.

4.9. Demand Management

No formal IT demand management process exists within USSOCOM. This process occurs only as needed with USSOCOM driving and managing any demand management activity. Components have established storage utilization targets (e.g. 75%) and reorder points (e.g. 90%). Most Components monitor at the initial target and begin escalating at some threshold thereafter (usually 80%). These thresholds are localized and vary by Component. This is the most common demand management area and is really more part of capacity management. Roles, workflow, metrics, policies, and documentation have yet to be defined.

4.10. Capacity Management

Capacity planning is done on an as-needed basis and is part of forward planning. Only one area of modeling appeared to be performed for special access network, planning and maintaining bandwidth requirements. Otherwise, capacity management only occurs at the ITMO and is more closely tied to business/ mission requirements planning and needs for IT. Functions are typically more aligned with annual planning and used to provide budgetary or project input. Capacity management is informal and reactive today. Capacity is considered at some Components when sizing COOP options. At NAVSOC, some limited planning occurs for some for local applications; however Enterprise planning is still the responsibility of USSOCOM HQ. Plans are in place for failover between some sites. USSOCOM is responsible for any capacity planning for the SIPRNet Network as part of DR and COOP planning.

Capacity management is also hindered due to the need for a clear understanding of the architecture to the degree required to support capacity modeling and forecasting. Roles, workflow, metrics, policies, and documentation are not defined.

4.11. Availability Management

The goal of the Availability Management process is to ensure that the level of service availability delivered for USSOCOM services meets or exceeds the current and future mission needs in a cost-effective manner.