GO-ITS 36 Enterprise Service Asset Configuration Management (eSACM)

1. Introduction

Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the IT standards adopted through the Office of the Corporate Chief Information Officer (OCCIO) and IT Executive Leadership Council (ITELC) for use across the government’s information and information technology (I&IT) infrastructure.

These publications support the responsibilities of the Treasury Board Secretariat for the coordination and standardization of I&IT in the Government of Ontario. In particular, this GO IT Standard describes where the application of an IT standard is mandatory and specifies any qualifications governing the implementation of the IT standards.

2. Summary

2.1. Standard name and description

This document defines Government of Ontario Information Technology Standards number 36 (GO-ITS 36); the Ontario Public Service (OPS) Standard for Service Asset and Configuration Management. The GO-ITS 36 was originally developed in 2003 as a high level portable guide, intended as a starting point for local implementations of configuration management across the OPS. This process standard was initially part of a portable set of Information Technology Service Management (ITSM) process documentation intended for use as a reference across the OPS. A key objective identified during an OPS ITSM Planning workshop held in December 2003 was to “Define Standard Portable Elements for All ITSM Processes”. As a result, guides were designed to be portable across all IT Clusters as well as any parties in the end-to-end supply chain and to include only the process components that were deemed necessary and common across the OPS.

2.2 Background and rationale

2.2.1 Background

A further requirement for an enterprise wide OPS Configuration Management standard was predicated by the positioning of all infrastructure service and support within Infrastructure Technology Services (ITS). ITS was a new organization within the OPS created in 2006; its goal was to deliver all infrastructure technology services to the OPS. Establishment of this goal required an update of the requirements for the GO-ITS Standard for Configuration Management based on the situation described above and compliance to Information Technology Infrastructure Library (ITIL) v3.0.

Updates to the existing GO-ITS included:

• principles, roles, responsibilities and governance are the high-level process flows required to support an enterprise Configuration Management Database (CMDB)
• incorporation of ITIL v3.0 (2007) concepts, introduction of an enterprise Service Asset and Configuration Management process and the evolution of IT Service Management disciplines within the OPS

2.2.2 Rationale

In May 2012, the Service Management Branch of ITS was identified as the owner of Enterprise Service Asset and Configuration Management (eSACM) process by the IT Service Management Leads (ITSML) forum. eSACM was presented with the task of updating GO-ITS 36 to establish a standard common process for use by the OPS.

This document establishes the eSACM principles, roles and the associated process model resulting in a single unified eSACM process within the OPS. Use of this single process and supporting information will enable OPS-wide management and reporting through the establishment of common data and associated metrics.

2.3. Target audience

The target audience for this document includes, but is not limited to:

• Infrastructure Technology Services (ITS)
• OPS Enterprise Service Providers
• OPS IT Clusters
• External Vendors

2.4. Scope

2.4.1. In scope

• Planning and Management activities will produce the eSACM Plan. The eSACM Plan informs CMDB planning activities by defining how the classes and types of assets and configuration items (CIs) housed within the OPS, as well as, any non-OPS environment such as off premise Cloud Hosting Services are to be selected, grouped, classified and defined by appropriate characteristics. The eSACM Plan is a living document and is periodically updated to reflect evolving configuration and asset informational requirements.
• Status Accounting and Reporting ensures that all configuration data and documentation is recorded as each asset or CI progresses through its lifecycle. It provides the status of the configuration of a service and its environment as the configuration evolves through the service lifecycle.
• Verification and Audit activities include a series of reviews and audits to ensure conformity of documented configurations and physical environment.
• Configuration Control ensures that there are adequate control mechanisms over CIs while maintaining a record of changes to CIs, location, ownership, and enterprise-wide foundational data.

2.4.2. Out of scope

• Maintaining a document management database. The physical documents are stored and maintained by their owners.
• Control of components that the organization has elected not to control. These are under the control of the OPS Enterprise Change Management (eCM) process.
• Depreciation accounting including the tracking of the costs, contracts and financial status of a CI during its lifecycle. These are under the control of Asset Management under accounting practice.

2.5. Applicability statements

2.5.1.Organization

All Ministries and I&IT Clusters are subject to Government of Ontario IT Standards.

All adjudicative and advisory agencies are subject to Government of Ontario IT Standards.

All other agencies that are using OPS information and information technology products or services are required to comply with Government of Ontario IT standards if they are subject to either the Governance and Management of Information Technology Directive or Government of Ontario IT Standards by memorandum of understanding.

As new GO IT Standards are approved, they are deemed mandatory on a go-forward basis (go-forward basis means at the next available project development or procurement opportunity).

When implementing or adopting any Government of Ontario IT standards or IT standards updates, ministries, I&IT clusters and applicable agencies must follow their organization’s pre-approved policies and practices for ensuring that adequate change control, change management, and risk mitigation mechanisms are in place and employed. For the purposes of this document, any reference to ministries or the government includes applicable agencies.

Requirement levels

Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:

• Must - This word, or the terms "REQUIRED" or "SHALL", means that the statement is an absolute requirement.
• Should - This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (for example, business functionality, security, cost) must be understood and carefully weighed before choosing a different course.

3. Technical specification

The following requirements apply to all I&IT assets and operations within the scope of the Governance and Management of Information Technology Directive.

3.1. eSACM Process definition

The eSACM process underpins and enhances the effectiveness of other ITSM processes. It is used to identify and track a holistic view of the CIs in the IT infrastructure. Periodic audits will ensure that reliable and accurate information is available when and where it is needed.

3.2. Process purpose

The key objective of eSACM is to ensure that accurate and reliable information about service assets and the relationships between those assets is available when needed by establishing an authoritative Configuration Management Database (CMDB). The CMDB is a central source of CI information to support OPS I&IT services; and ensures that control processes and procedures are implemented to maintain the integrity of this critical operational information.

The purpose of eSACM is to:

• identify, control, record, report, audit and verify service assets and configuration items, including versions, baselines, constituent components, their attributes, and relationships.
• account for, manage and protect the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle by ensuring that only authorized components are used and only authorized changes are made.
• ensure the integrity of the assets and configurations required to control the services and IT infrastructure by establishing and maintaining an accurate and complete CMDB.
• provide foundational data and support to other ITIL v3.0 processes including but not limited to Enterprise Change Management (eCM) and Enterprise Incident Management (eIM).

3.3. Value to the business

Optimized performance of service assets and their configurations improve the overall performance of I&IT service. Reduction of the costs and risks caused by poorly managed assets, such as, service outages, fines, correct licence fees and failed audits.

eSACM provides visibility of accurate representation of a service, release and other environments that enable:

• Risk Reduction - Decisions based on accurate information provided by eSACM reduce unanticipated downtime. Appropriate authorization requirement to make changes to the IT infrastructure / CMDB increases security and reduces the risk of uncontrolled environment changes.
• Cost Reduction - Faster, simpler, and more thorough identification of CIs, their attributes and their relationships by other processes. Multiple ITSM processes depend on information provided by eSACM – duplication of this effort is avoided in these processes. eSACM also facilitates adherence to legal obligations and aids budgeting and financial planning. CMDB provides a platform to initiate CI standardization – which leads to substantial reduction in support costs.
• Service Agility Improvement - A clear understanding of how CIs participate in provisioning IT services enables IT organizations to react quickly to changing business needs, lessen time to market and the enhancement of service offerings.
• Service Quality Improvement - Providing a facility for storage and retrieval of documented customer expectations makes it easy to compare and improve service delivery. As well as improvements to support for Incident, Problem, Continuity, Change, Release and Security Management.
• Information Management Improvement - Enables IT organizations to monitor Service Level Agreements (SLAs) and maintenance contracts with greater precision. Retrieved data can be sorted, summarized, and reported in whatever manner makes sense. Following up on reported data (“drill down”) is facilitated.

3.4. Basic concepts

The eSACM process identifies IT environment components as CIs. The CIs managed by this process include hardware items, software components and object code, cloud hosting instances, network items, selected documentation and any other elements within the IT infrastructure that the OPS wish to control. CI information is stored in a logical entity called the, CMDB, which typically consists of multiple distinct databases.

The CMDB represents the current known-state of the IT environment and therefore must be updated in conjunction with modifications to the IT Environment. As a result, the eSACM process ensures that only authorized CIs are released to production, in addition to the management and control of revisions of all managed components of the IT infrastructure.

eSACM begins with the development of the eSACM Plan that addresses the definition of the scope and depth of the in-house OPS and out sourced IT infrastructure being managed. There is an important balance that needs to be achieved and maintained to set parameter limits on what level of information is made available to related processes, while keeping intact the effort and resources required to consistently maintain the CMDB to an acceptable level of quality, on the other. This planning is followed up with the identification, labelling and naming of individual CIs and their attributes and relationships with other CIs.

eSACM maintains the status of a CI (for example, functional / administrative status, relationships, etc.) It includes links to documentation related to that CI. It creates, maintains, tracks, controls and reports on information that enhances the ability of other supporting processes to be effective, especially the Change, Problem, Incident and Release Management processes.

eSACM includes “Verification and audit” services which may be executed using discovery tools to automatically scan specific infrastructure components and produce CI discrepancy reports based on a match against the data in the CMDB.

Each CI has an owner who is responsible for keeping the CI information accurate and current. This enables the autonomy of CIs at the workgroup level while still providing for consistency of CIs at an enterprise-level in the CMDB. eSACM may on pre-authorization by CI Owners, automate updates to CI data based on a predefined set of criteria. It is important for CI Owners to maintain accountability and as such define what level of automation best meets their functional, operational and financial needs.

3.4.1. Inputs to the process

Inputs to the eSACM process may include:

• Change Requests & Work Orders
• Component usage & performance data
• CI status data
• Cost data
• Service data
• All ITIL v3.0 processes
• Service Design Packages

3.4.2. Outputs from the process

Outputs from the eSACM process may include:

• Up-to-date CI information and relationship data
• Configuration baselines
• Management information (for example, CI status reports and audit reports)
• eSACM performance reports

3.4.3. eSACM Plan

The eSACM Plan informs CMDB planning activities by defining how the classes and types of assets and configuration items are to be selected, grouped, classified and defined by appropriate characteristics. The eSACM Plan is a living document and is periodically updated to reflect evolving configuration and asset informational requirements.

3.5. Process principles

IT organizations define principles to guide the design and delivery of services to customers or users. Principles can be common – that is they apply to all functions and groups or local and apply to a specific function or group.

The absence of well-defined common principles may result in processes that are neither aligned with customer expectations nor with the standards set for delivery of service.

3.5.1. eSACM Process principle 1:

The CMDB represents the current known-state of the IT environment.

Rationale:

• Ensures all authorized CIs are under eSACM control.
• Enables the eCM process to determine the impact to the IT environment for each proposed change.
• Supports and enhances the Incident, Problem, Change, Operations and Release Management processes via the use of the CMDB.

Implications:

• The level of detail of the CMDB will need to be determined by business needs and the cost (efforts) of maintaining the information.
• Without effective automated discovery tools, certain aspects of building and maintaining the CMDB become very difficult.
• CI relationship matrices need to be developed and maintained.
• Different types and levels of training will be required for ITSM process roles, especially around CMDB usage.

3.5.2. eSACM Process principle 2:

Each CI has an owner who is responsible for keeping the CI information accurate and current.

Rationale:

• Accurate and current CI information is made available.
• Ensures that only authorized changes can be made to the CMDB.
• Clear accountability.

Implications:

• The CI Owner needs to be notified of all changes made to the owned CIs.
• All CI Owners, including External Service Providers, will adhere to the eSACM process.
• Access policies are required for the CMDB to control what can be changed and who can change it.

3.5.3. eSACM Process principle 3:

Each component (CI in the CMDB) is uniquely identified with a Configuration Item ID. In addition, Asset tags may be applied to CIs and recorded in the CMDB. This enables the proper management of the environment as a whole.

Rationale:

• All CIs will be easily identified and located to enhance environment control.
• Verification and audits are facilitated.
• Unsupported CIs can be readily identified.

Implications:

• Standard CI naming convention needs to be developed, implemented and adhered to.
• CIs need to be labelled.
• Relationship information, such as parent/child, needs to be recorded and tracked.

3.5.4. eSACM Process principle 4:

A formal CMDB plan (eSACM Plan) is defined and executed on a regular basis.

Rationale:

• Ensures that the CMDB matches closely to the IT environment.
• Ensures high level of process compliance.

Implications:

• Resources are required to perform the audits.
• Automated audit tools are needed to enable checks to be made at regular intervals since manual operation is likely to be error prone especially when the volume of CIs is high.
• Physical audits require travel and physical access to the equipment.

3.5.5. eSACM Process principle 5:

All parties involved in the creation, modification, removal, or inquiry of CIs within the scope of eSACM are required to actively participate in the eSACM process and adhere to the eSACM process and procedures.

Rationale:

• Ensures consistency.
• Service providers can play key roles in the process.
• Service providers own configuration items.

Implications:

• Process provisions will apply to Internal and External Service Providers.
• Contracts with service providers must reflect the eSACM activities, tasks and linkages associated with their role.
• Management of the CIs stored in a data repository external to OPS CMDB (for example, Cloud registration database or third-party vendor’s CMDB) must adhere to the eSACM process and procedures.

3.5.6. eSACM Process principle 6:

Any changes to an Asset or a component in the IT environment with corresponding CI records tracked in the CMDB must adhere to the Enterprise Incident Management (eIM), Enterprise Change Management (eCM), Enterprise Release Management (eRM) processes.

Rationale:

• Ensures control of all CIs in scope.
• Ensures currency and accuracy of CMDB data.

Implications:

• Required integration with the eIM, eCM, eRM, Standard Change Work Order processes.
• Significant analysis and planning are required to reach an informed decision on the scope and depth of tracked CI data.

3.5.7. eSACM Process principle 7:

Managed CI Owners are accountable for assets not owned by OPS I&IT but managed by the OPS I&IT through or with an external provider, as governed by the provider’s contractual agreement(s).

Rationale:

• Ensures clear, in-house accountability for assets that are critical to the OPS I&IT service delivery, even if they are not owned by OPS I&IT.
• Provides accurate and current CI information to those who need it across the organization.
• Enables the eCM process to determine the impact and risk to the IT environment and customer-facing services for each proposed change.
• Supports and enhances the Incident, Problem, Change, Standard Change Work Order, Service Level Management, Operations and Release management processes via the use of the CMDB.

Implications:

• The level of detail of the CMDB will be determined by business needs and the cost (efforts) of maintaining the information.
• CI relationship matrices for non-owned OPS I&IT assets will be developed and maintained.
• Different types and levels of training will be required for ITSM process roles, especially around CMDB usage.
• The Managed CI Owner will be notified of all CI changes.

3.6. Process roles and responsibilities

Each process has specific roles with defined responsibilities for process design, development, execution and management. In an organization, one person can take on multiple roles as per the requirements specific to the organization. This person may choose to delegate these responsibilities. Additionally, responsibilities of one role could be mapped to multiple individuals.

Regardless of specific organizational mapping, specific roles are necessary for the proper operation and management of the process. These roles are required at the Enterprise level and may also be applied at local levels of Configuration Management. This section lists these roles and their responsibilities.

In addition to process roles, service-specific roles may be defined as part of the management and governance structure for a specific service. Other roles will also be involved in the eSACM process activities, including other ITSM process roles, operations, and service providers.

One role is accountable for each process activity. The role may assign one or more people who are responsible to carry out the task. However, it is ultimately the job of the person who is accountable to ensure that the “job gets done”.

Legend:
R=Responsible
A=Accountable
C=Consulted
I=Informed

3.6.1. eSACM Process Owner

The eSACM Process Owner is accountable for policy, leadership and direction for the development, design and integration of the eSACM process as it applies to other applicable frameworks and related ITSM processes being used and or adopted in the OPS. The eSACM Process Owner shall be accountable for the overall health and success of the process.

Responsibilities:

• Ensures that the process is defined, documented, maintained and communicated at an Organizational level through appropriate vehicles.
• Undertakes periodic review of the process to ensure that a methodology of Continuous Service Improvement (CSI), (including applicable process-level supporting metrics) is in place to address shortcomings and evolving requirements.
• Ensures the process requirements are developed, documented and implemented with enabling technology.
• Defines and evolves enterprise process Key Performance Indicators (KPIs) and reporting for the process.
• Defines the CMDB audit priorities for the enterprise.
• Consults with the ITSM Leads forum to ensure the process is meeting the needs of all affected stakeholders.

3.6.2. eSACM Process Manager

The eSACM Process Manager is accountable for planning, implementing and managing the ongoing execution of the eSACM process, managing the operation of the ITSM Tool and consulting with all OPS I&IT services that participate in Enterprise SACM. This includes ensuring that accurate information regarding the value, relationships and ownership of all assets is maintained during their lifecycle.

Responsibilities:

• Develops and maintains the eSACM Plan, which identifies the items that are to be controlled, and the information that is to be recorded for each Configuration Item.
• Develops, implements and maintains Service Asset and Configuration Management procedures.
• Defines activities required to establish and maintain accuracy of asset CI information and relationships.
• Identifies Configuration Management functional requirements for the ITSM Tool in conjunction with other Enterprise ITSM Process Managers, and conducts acceptance testing for modifications to enabling technology.
• Develops and maintains ESACM managed audit priorities and scheduling.
• Develops and maintains criteria for CIs to be uniquely identified with naming conventions; ensures that staff comply with identification standards for object types, environments, processes, lifecycles, documentation, patterns, versions, formats, baselines, releases and templates/classes.
• Plans and manages population of configuration data into the ITSM Tool; manages ITSM Tool, central libraries, tools, common codes and data; ensures regular housekeeping of the ITSM Tool.
• With the assistance of Cluster and ITS eSACM process coordinators, ensures there is an effective eSACM process activation awareness campaign, and that changes to the process and enabling technology are communicated accordingly.
• Supports the eSACM Process Coordinators in the training of staff.
• Proposes and/or agrees on procedural interfaces with other Enterprise ITSM Process and Operational Managers.
• Develops and produces reports, including: process health metrics specified by the Process Owner; identifies operational management and configuration status reports, ensures analysis of reporting to identify issues and make corresponding recommendations to address them.
• Develops and maintains the eSACM plan, with assistance from the process coordinators, based on priorities approved by the eSACM Process Owner.
• Executes internal audits, and assists external auditors to audit the operational activities of the Enterprise SACM process. To ensure compliance with the process, procedures and eSACM Plan; confirms that recommended corrective action is completed.

3.6.3. eSACM CI Owner

The assigned owner during each CI lifecycle state must ensure that the CI information and any underlying relationships to other CIs documented in the CMDB is accurately and reliably. The owner is ultimately accountable for the accurate representation of the known state and relationships of an IT asset.

Responsibilities:

• Maintains accuracy of specified information for CIs owned by them, either by
  • Directly updating certain CI information and relationships, as specified by the eSACM Plan and in accordance with the eSACM process, procedures and work instructions where applicable.
    or
  • Providing updated CI information, relationships and evidence of control mechanism approval to a Configuration Analyst who will update the CI.
    or
  • Reviewing the status and accuracy of their assets, often through reporting, and advising a Configuration Analyst and/or eSACM Process Coordinator of any discrepancies.
• Follows specified control procedures prior to providing updated CI information to the eSACM Configuration Analyst.
• Identifies evolving informational requirements for all elements to the eSACM Process Manager for possible inclusion in the eSACM Plan.
• Executes action items as defined by the eSACM Process Manager, to ensure audit discrepancies are addressed.

3.6.4. eSACM Managed CI Owner

A Managed CI is owned and delivered by a third-party vendor. Managed CI Ownership must be assigned to an individual within OPS to ensure in house accountability. The assigned owner must ensure accurate and reliable CI information and relationships are documented in the CMDB.

Responsibilities:

• Manages assets owned by an external provider, as governed by the provider’s contractual agreement(s)
• Maintains accuracy of specified information and relationships which can include Vendor contact information for CIs owned by them, either by:
  • Directly updating certain CI information, as specified by the eSACM Plan.
    or
  • Providing updated CI information and evidence of control mechanism approval to the Configuration Analyst, who will update the CI.
    or
  • Reviewing the status and accuracy of the vendor’s assets, often through reporting defined by an appropriate Underpinning Contract (UC), and advising a Configuration Analyst and/or eSACM Process Coordinator of any discrepancies.
• Follows specified control procedures prior to providing updated CI information to the eSACM Configuration Analyst
• Identifies evolving informational requirements for all elements to the eSACM Process Manager for possible inclusion in the eSACM Plan.

Note: Unlike owners of OPS-owned assets, Managed CI Owners are not responsible for:

• Amortization of asset
• Refresh duties
• Underlying technology
• Audit of physical assets

Ultimately, these duties should be defined within a corresponding Underpinning Contract (UC).

3.6.5. eSACM Process Coordinator

There is a large degree of complexity and workload involved in managing and administering an eSACM process across ITS and all the clusters. The Process Coordinator role is defined to assist the eSACM Process Manager in undertaking a number of responsibilities.

Responsibilities:

• Planning and Management
  • Assists with the creation, implementation and maintenance of the eSACM Plan, ensures Cluster and/or ITS requirements are met through a single, consistent information model.
  • Identifies items that are to be controlled, and the information that is to be recorded.
  • Assists with the development of eSACM data model, which define the repeatable representation of a number of CI classes and their relationships.
  • Ensures that new service patterns are consistently applied by assisting Configuration Analysts and, where necessary, defines organizational-specific (for example, Cluster or ITS) work instructions.
• Configuration Control
  • Assists the eSACM Process Manager with development and implementation of procedures and provides associated training to eSACM users within their respective organizations.
  • Develops and communicates new / modified organizational work instructions in support of the eSACM procedures.
• Status Accounting and Reporting
  • Collects reporting requirements and solicits feedback for new or modification to existing reporting views for the eSACM Process Manager.
  • Captures baselines (for example, report) for changes that meet predetermined criteria (for example, release-managed or major changes), and compares baselines to updated CIs to ensure process compliance and information integrity.
• Data Verification and Audit
  • Monitors day to day procedural execution to identify and correct areas of process, procedure or work instruction non-compliance to ensure adherence to organization-specific (for example, ITS or Cluster) work instructions. Non-compliance is reported to the eSACM Process Manager.
  • Monitors process effectiveness, identifies and addresses operational gaps, and proposes continuous service improvement opportunities to the eSACM Process Manager.
  • Assists the eSACM Process Manager with the identification, monitoring and validation of audit action items within their respective organization.
  • Executes organization information audits in accordance with the eSACM Plan using existing reports and the ITSM Tool user interface.

3.6.6. eSACM Configuration Analyst

The Configuration Analyst is the primary user of the CMDB. Any user aside from the Process Manager or Coordinators who interacts with and/or updates the CMDB is considered a Configuration Analyst. Thus, the role is often executed by operational staff throughout their normal System Development Lifecycle (SDLC) and/or operational management lifecycle duties.

Primarily responsibilities include ensuring that appropriate control mechanisms have been followed prior to loading new or updated information into the CMDB and validating the CMDB accurately reflects the known state of an asset. Different Configuration Analysts may be assigned only a subset of the responsibilities defined for the role.

Responsibilities:

• Planning and Management
  • N/A
• Configuration Control
  • Complies with the identification standards for classes, environments, processes, lifecycles, documentation, versions, formats, baselines, releases and templates prior to entering provided information into the CMDB.
  • Following implementation of an approved change, updates the CMDB with the provided CI information.
  • Assists the CI Owner on population of the CMDB.
  • Updates CIs in the CMDB with information identified/provided by the CI Owner as defined in the eSACM Plan.
• Status Accounting and Reporting
  • May execute available reports to assist in other day-to-day duties including but not limited to incident diagnosis, root cause analysis, change impact analysis, capacity analysis, availability analysis, financial analysis, inventory control, etc.
• Verification and Audit
  • Performs configuration audits to check that the physical IT inventory is consistent with the CMDB and recommends any necessary corrective action to their respective organizational process coordinator(s).

3.6.7. Linkages with other OPS roles

Service Owner

Specific to the eSACM process, during the operational phase of the Service Lifecycle, Service Owners become CI Owners meaning the Service Owner is accountable for the accuracy of the asset and configuration information for their service and its constituent CIs in the CMDB. This includes an end-to-end view of the service, including all support services, components and service agreements required to deliver the end-to-end service.

Although they may delegate responsibility for maintaining asset and configuration information to CI Owners, the Service Owner retains overall accountability for the information.

If verification and audit activities surface inaccuracies, Service Owners are responsible for correcting their data and taking measures to prevent recurrence. Note that correction must be made to the source data (which may reside outside the CMDB) using the applicable control mechanism for that data.

Configuration Management System (CMS) Administrator

The CMS Administrator has the following accountabilities:

• Monitors the performance and capacity of the existing ITSM Tool and recommends improvement opportunities to the Process Owner, through the pre-defined ITSM Tool governance model, and undertakes standard housekeeping and fine tuning under change control.
• Assists with the creation of new classes, attributes, relationships and categories within the ITSM Tool as required and as defined by the eSACM Plan.
• Performs complex ad hoc queries to assist the eSACM process coordinators when (pre-) approved by the eSACM Process Manager.
• Processes approved, bulk updates to the CMDB, ensuring adherence to the eSACM Plan.
• Liaises with the eSACM Process Manager on population of the asset in the ITSM Tool.
• Provides technical administration and support for the CMDB, including the tools’ common codes and data; undertakes regular technical housekeeping of the ITSM Tool.
• Ensures the integrity and operational performance of the ITSM Tool.
• Conducts CI archiving activities in accordance with ITSM Tool archival principles and OPS information retention policies.

Note: All Changes to the ITSM Tool will be executed in accordance with the ITSM Tool Governance model, and through eCM when/where applicable.

3.7 Process activities

Unlike other ITSM processes which have sequential workflow and task dependencies, eSACM utilizes asynchronous and independent activities that may span multiple service provider organizations. eSACM utilizes an activity model to coordinate activities across multiple service provider organizations. The primary activities include:

• Management and Planning activities will produce the eSACM Plan which informs CMDB planning activities by defining how the classes and types of assets and configuration items are to be selected, grouped, classified and defined by appropriate characteristics.
• Configuration Identification This activity selects and identifies the configuration structures for all Configuration Items, including their owners, their interrelationships and configuration documentation. It should also include setting up an identification scheme for all items, allocating identifiers and version numbers to CIs, labelling each physical item and recording details in the CMDB.
• Configuration Control ensures that there are adequate control mechanisms over CIs while maintaining a record of changes to CIs, versions, location and ownership.
• Status Accounting and Reporting ensures that all configuration data and documentation is recorded as each asset or CI progresses through its lifecycle. It provides the status of the configuration of a service and its environment as the configuration evolves through the service lifecycle.
• Data Verification and Audit activities include a series of reviews and audits to ensure conformity of documented configurations and environment.
• CMDB Access Audit In addition, a series of reviews and audits to ensure least privilege principal is being followed when granting individual access to the CMDB.

Diagram 1 eSACM: process workflow

A workflow diagram that outlines the asynchronous and independent activities of the eSACM process.

• Management and Planning involves planning, management resources, time management support working relationships resources, facilities, CMDB and tools, training and guidance. Output is configuration management plan contract.
• Configuration Identification involves requirements, design, maintenance, release, deployment, operations plans. Output is CI identification, naming, labelling, data and documentation, baseline and release ID. Output is update CRQ, updated CI.
• Status Accounting and Reporting involves change and configuration records and documentation. Output is status record/report, configuration information and performance.
• Verification and Audit involves physical CIs, test results, audit/discovery tools. Output is action items, confidence in service and infrastructure.

3.8 Linkages to other processes

Table 1 Linkages to other processes

3.9 Process quality control

In parallel to the execution of the eSACM process, there are activities related to the management of the process to control quality as well as to ensure that the process is both effective and efficient.

Monitoring of the service delivered by the eSACM team is performed regularly by the eSACM Process Manager This allows the Configuration Manager to answer any questions about service quality as well as ensure that the eSACM process is not running into resource or ownership issues. The Configuration Manager is responsible to take corrective actions if bottlenecks are identified in the process.

Reporting involves measuring the process via metrics and recording how well it behaves with respect to its metrics. It provides the eSACM personnel with feedback on the process. It provides the eSACM Process Owner with the necessary information to review the process performance and initiate required improvements.

Evaluating the process involves regular reviews of the performance of the process and identification of possible improvements or actions to address performance gaps. Every process is only as good as its last improvement; hence, the feedback loop of continuous improvement is inherent in every process.

3.10 Common process metrics

Metrics are intended to provide a useful measurement of a process effectiveness and efficiency. Metrics are also required for strategic decision support. The following need careful consideration:

• Reporting metrics should be readily measurable (preferably automated collection and presentation of data)
• Metrics need to be chosen to reflect process activity (how much work is done?), process quality (how well was it done?) and process operation (to review and plan job on hand). Depending upon the needs of the organization, metrics can be classified as “hard (must have)” or “soft (desirable)”.
• Hard metrics will be common across an organization

The following common metrics are suggested for the eSACM process:

• Discrepancy between CI data and discovery tool
• Number and percentage of CIs tracked within the CMDB
• Number and percentage of CIs added/deleted/ changed by category
• Life cycle via status change of CI.
• Number and percentage of orphan CIs by category

3.11 Standard process parameters

Parameters used for the categorization and definitions of CIs require a certain level of standardization across OPS. Special attention needs to be given to parameters related to consistency of reporting. This is particularly important for the provision of reliable business intelligence and Analytics Component Category is a parameter used across Incident, Problem, Change, Service Level and Asset and Configuration Management. To ensure consistency of meaning and usage it has been defined in the Terminology Reference Model. Please refer to the Classification Model section of the GO-ITS 44 ITSM Terminology Reference Model Guide for standard process parameters and allowable values for Product Category.

Organization Values are a fundamental means of identification for CIs (via association) leveraged across I&IT, billing and reporting.  To ensure consistency of operational support, reporting, and billing activities, eSACM assumes governance of organization values in the ITSM Tool. Organization values in the ITSM Tool must comply with official naming standard as defined in Ontario Government Terminology (ONTERM).  CI Owners and Cluster consumers of data must follow agreed upon processes (Change, Release) for managing organization restructuring, general name changes, and ‘up keep’ of current organization status.  If Cl Owners fail to act, eSACM has the authority to update and modify organization representation within the ITSM Tool.

People records are essential to operational I&IT support.  They are used across all ITSM Best Practices, billing and reporting.  eSACM assumes governance of people records in the ITSM Tool.  A one to one relationship between people records and Active Directory users is required to adequately provide value. Additional people records will be managed based on operational requirements.

Location values are required for I&IT operational planning and support.  To ensure consistent representation, eSACM assumes governance of location records in the ITSM Tool.

Relationship association accuracy and documentation is essential to ensure consistency and integrity for Incident, Problem, Change, Service Level as well as Asset and Configuration Management

4. Related standards and impacted infrastructure

4.1. Impacts to existing standards

Identify any standards that reference or are referenced by this standard and describe the impact.

Table 2 Impacts to existing standards

4.2. Impacts to existing infrastructure

Identify any applications, systems, solutions and technology platforms that could be affected by this standard and describe the impact.

Table 3 Impacts to existing infrastructure

5. Compliance requirements

In order to manage the effectiveness and implementation of this standard, Ministries, I&IT Clusters and applicable agencies are expected to adopt and monitor compliance.

6. Roles and responsibilities

6.1. Accountable role (standard owner) definition

The individual or committee ultimately accountable for the process of developing and maintaining this standard. Where a committee owns the standard, the committee chair is accountable for developing the standard including future updates. There must be exactly one accountable role identified.

Accountable role:

Title: Chair, Service Management Executive Committee (SMX)

Responsible role definition

The organization(s) responsible for the development of this standard. There may be more than one responsible organization identified if it is a partnership/joint effort. (Note: the responsible organization(s) provides the resource(s) to develop the standard).

Responsible organization(s):

Ministry: Ministry of Public and Business Service Delivery (MPBSD)
Division: Infrastructure Technology Services (ITS)
Branch: Process & Operations

Support role definition

The support role is allocated to the resource(s) to whom the responsibilities for developing and maintaining this standard are assigned.

Support role (editor):

Ministry: MPBSD
Division: ITS
Branch: Process & Operations
Section: Service Asset & Configuration Management
Job Title: Senior Manager
Name: Arpad Martonosi
Phone: 519-830-6431
Email: arpad.martonosi@ontario.ca

7. Consultations

Areas consulted as part of the development of this standard. Include individuals and committees, councils and/or working groups:

Table 4 Consultation history

8. Document history

Table 5 Document history

9. Glossary

Table 6 Glossary

10. Appendices

10.1. Normative references

eSACM Manager will determine if procedures are a normative or informative reference and how they will be managed / evolved.

Note: a normative reference specifies a supporting document or GO IT Standard (in the case of the Government of Ontario’s I&IT infrastructure, often another OPS I&IT authorized publication) that must be read to fully understand or implement the subject matter of the main GO IT Standard. Such authoritative or de facto references may be external and may, or may not be, owned/controlled by the GO IT Standard owner.

10.2. Informative references

Differentiation: process, procedure, work instruction

Note: The following diagram depicts three levels of task descriptions that are often confused with one another:

Diagram 2: Differentiation of a process, procedure, work instruction

• Level 1 tasks are defined in a Process. They specify what action must be taken and who is involved.
• Level 2 tasks are defined in Procedures which decompose each level 1 task into more granular operational tasks, and additionally, prescribe how the activity should be performed.
• Level 3 tasks represent Work Instructions. Work Instructions are a further decomposition of procedure-level tasks which typically are defined to address any unique local requirements when performing a procedural task.