Identification of Best Practice Operations Management for the DCAC

Microsoft Operations Framework

White Paper

Published: April 2020

Best Practices in Change,

Configuration, and Problem

Management

Contents

Preface

Background to the Best Practice Investigation

Management Summary

Approach Taken for the Best Practice Investigation

Introduction to MOF

Configuration Management

Change Management

Problem Management

Conclusions and Recommendations

Acknowledgements

Preface

This white paper is one of a series about Microsoft® Enterprise Services (ES) frameworks. For a complete list of these publications, please see the ES Web site at http://www.microsoft.com/es .

This white paper describes best practices for configuration, change, and problem management as identified by the Data Center Advisory Council. Anyone reading this paper already should have read the Microsoft Operations Framework

Executive Overview white paper, which contains important background information for this topic.

4

6

10

13

17

19

1

2

2

3

2 Microsoft Operations Framework White Paper

Background to the Best Practice Investigation

Microsoft has a working relationship with customers responsible for large-scale business systems based on Microsoft technology. This relationship is managed through a forum called the Data Center Advisory Council (DCAC) and has strong support from Microsoft management in the United States and United

Kingdom.

The forum seeks to ensure that Microsoft understands the implications of deploying technologies in a large-scale, business-critical environment. As part of this working relationship, Microsoft has agreed to provide project support to identify best practice solutions for service management areas identified by

DCAC.

DCAC agreed that the priority areas are configuration, change, and problem management. To identify best practices for these service management topics,

Microsoft Consulting Services (MCS) set up a project to investigate DCAC member companies’ views on best practice service management for these areas.

To gather best practice information, MCS investigated details of operations practice within individual DCAC member companies. Then, these DCAC companies participated in a series of workshops to discuss and document the agreed best practice for each operations management area.

This project also had the objective of contributing to the broader requirement, within Microsoft, for an operations management framework that can provide service management guidelines for all Microsoft enterprise customers. To achieve this objective, the questionnaires used for gathering operations management information examined a specific set of service solutions as well as the processes associated with the selected service management topics.

Management Summary

The Data Center Advisory Council has identified the need for best practice standards for service management. The service management topics seen by

DCAC as priority areas were configuration, change, and problem management.

This report sets out the findings of an investigation set up to look for best practice solutions, covering these service management functions.

This report provides the best practice advice on configuration, change, and problem management that was obtained from interviews and workshop sessions with experienced service managers from DCAC member companies.

The report explains the relationship of Microsoft Operations Framework (MOF) to the Central Computer and Telecommunications Agency (CCTA) IT

Infrastructure Library (ITIL) and these service management guidelines.

Then for each service management topic, the report presents the best practice advice under the following headings:

Business justification (why this is important)

Implementing (how the service should work)

Commitment (how to maintain commitment)

Supporting systems and tools (what supporting technology is needed)

Ошибка! Используйте вкладку "Главная" для применения Heading 1 к тексту, который должен здесь отображаться. 3

This report does not cover technical solutions and methods used to support service management within a Microsoft environment. The investigation did not cover this aspect of service management, but Microsoft is producing a report to cover the technical aspect of service management based on service scenarios that will complement the best practice advice in this report.

The DCAC representatives from Marks and Spencer Ltd., AstraZeneca Ltd., and

Marconi Communications Ltd. provided the service management expertise for this investigation. The advice given is essentially the consensus on best practice for these companies.

These guidelines explain what managers would expect within a best practice service management solution. The guidelines will help managers responsible for enterprise-scale service management assess and refine their own approach to configuration, change, and problem management.

The advice complements the guidelines provided by the CCTA ITIL modules, giving a different perspective but common purpose. It confirms that the core principles for service management can be defined in a way that is generic to many businesses. This work has shown that a common language and taxonomy presented in an open framework is applicable to Microsoft solutions within a heterogeneous service management environment.

DCAC members’ support of this investigation has been strong. At each workshop session, members reiterated that Microsoft should continue with service management initiatives.

The strong support for this work and the cooperation between Microsoft enterprise customers highlights the principle that a common language for service management will benefit both the customers and suppliers of service management solutions. The benefit for customers is the ability to select service management solutions with the confidence that they follow industry standards for best practice and will therefore integrate with work practice and supporting tools. For the suppliers, the benefit is the opportunity for greater market acceptance of products and/or services in the service management area, resulting from a best practice status and the alignment with more clearly defined customer needs.

During the workshops sessions, the focus of the service management discussions was on improving efficiency and effectiveness of staff and systems supporting the business information technology (IT) needs of a company. But in all service management areas the business justification has made it clear that this efficiency and effectiveness is not just concerned with economy and impact of IT resources, it is concerned with the full exploitation of IT capability and the ability to change IT systems to respond to new business opportunities.

Approach Taken for the Best Practice Investigation

To establish a reference point for looking at best practice service management solutions, MCS used the ITIL modules for configuration, change, and problem management to develop questionnaires for the DCAC member companies supporting the investigation. Recognizing that each company had different business objectives and organizations, an additional questionnaire was developed to collect background information on the individual IT functions.

4 Microsoft Operations Framework White Paper

The service management topic questionnaires covered the following areas:

The definition of the service management topic.

The interpretation of this service management activity within the DCAC member companies.

The application of the service management methods to specific services and problem scenarios.

Using the questionnaires, MCS interviewed each company individually about its approach to configuration, change, and problem management. The information collected at the interview sessions was written up during the interview so that participants could see and approve the statements being recorded. With nine interview sessions (three companies and three topics) completed, the questionnaire results were distributed to the three companies supporting the work so that each company could study the approach of the other two companies.

To bring together the experience of the service management staff from each of the DCAC member companies, workshop sessions were conducted for each topic. Those attending were asked to consider the service management advice that would apply to a merger of the three companies and therefore acceptable to all companies. The workshops used a questionnaire approach to cover the following topics:

A common definition of the service management topic.

Agreed best practice for implementing the service management function.

Applying the service management best practice to specific services.

What Microsoft can do to help.

With the main topic, (agreed best practice for implementing the service management function), DCAC members were asked to explain the important characteristics of each service management function in terms of implementation and commitment. As part of the recommendations on maintaining commitment, the DCAC representatives also provided information to explain the business justification for supporting each service management area.

This report draws on the workshop results, the individual company interviews and the material from the CCTA ITIL modules to present the best practice solutions outlined by the DCAC members.

Introduction to MOF

MOF and ES

Microsoft Operations Framework is a collection of best practices, principles, and models. It provides comprehensive technical guidance for achieving missioncritical production system reliability, availability, supportability, and manageability on Microsoft’s products and technologies.

Ошибка! Используйте вкладку "Главная" для применения Heading 1 к тексту, который должен здесь отображаться. 5

MOF is one of the three frameworks of Enterprise Services. Each ES framework targets a different, but integral, phase in the IT life cycle. Each framework provides useful and detailed information on the people, processes, and technologies required to successfully execute within its respective area. The other two ES frameworks are Microsoft Readiness Framework (MRF) and

Microsoft Solutions Framework (MSF). The following diagram depicts how each of the frameworks fits into ES.

Enterprise Services Frameworks

Microsoft Readiness Framework helps IT organizations develop individual and organizational readiness to use Microsoft’s products and technologies. This guidance includes assessment and readiness planning tools, learning roadmaps, readiness-related white papers, self-paced training, courses, certification exams, and readiness events.

Microsoft Solutions Framework provides guidance in the planning, building, and deploying phases of the project life cycle. This guidance is in the form of white papers, deployment guides, accelerated solutions, solution kits, case studies, and courseware in the areas of enterprise architecture, application development, component design, and infrastructure deployment.

Microsoft Operations Framework includes a comprehensive suite of operational guidance in the form of white papers, operations guides, assessment tools, operations kits, best practices, case studies, and support tools that address the people, process, and technologies for effectively managing systems within today’s complex distributed IT environment.

MOF and ITIL

MOF recognizes that current industry best practice for IT service management has been well documented within the CCTA IT Infrastructure Library.

The CCTA is a United Kingdom government executive agency chartered with development of best practice advice and guidance on the use of information technology in service management and operations. To accomplish this, the

CCTA charters projects with leading IT companies from around the world to document and validate best practices in the disciplines of IT service management.

6 Microsoft Operations Framework White Paper

MOF combines these collaborative industry standards with specific guidelines for using Microsoft products and technologies. MOF also extends ITIL code of practice to support distributed IT environments and current industry trends such as application hosting and Web-based transactional and e-commerce systems.

Configuration Management

Business Justification for Configuration Management

Configuration management is the service management discipline that underpins

IT service reliability and therefore helps provide stability for business IT systems. This service is also an enabler for efficient business growth where change, expansion and acquisition can be implemented more rapidly.

This service management function provides the discipline for managing and controlling all components that are used in the IT operational environment and covers both the application environment and the IT infrastructure.

To be effective, the configuration management discipline must be applied to the full life cycle of activity involved in building and implementing business applications and the IT infrastructure. The discipline consists of a set of processes that produce and validate components such as Configuration Items

(CIs) for the business IT systems environment. All components that are to become part of the IT systems environment (including IT inventory information) need to be deposited and maintained within a Configuration Repository (CR) where the information can be referenced by other service management functions.

Implementing Configuration Management

Configuration management provides the discipline for clear identification and change of all items that make up the business applications services and IT infrastructure.

Components of the application environment and IT infrastructure are called

Configuration Items. CIs will include hardware items, software components, network items, and any part of the IT infrastructure or items associated with it that the organization wishes to identify and change.

For all CIs, information on status, owner, and relationship with other CIs needs to be maintained in the Configuration Repository. The IT inventory registry is seen as an integral part of the CR, where an inventory item is an instance of one or more Configuration Items.

The CR must accurately represent an IT infrastructure but only as far as it is practical and necessary. If implemented and maintained correctly, the configuration and inventory information within the CR will represent the IT infrastructure being managed.

Configuration management is concerned with the full life cycle of the components that are used to build business applications and IT infrastructure.

This life cycle covers initial development through to implementation and eventual retirement of the configuration item.

Ошибка! Используйте вкладку "Главная" для применения Heading 1 к тексту, который должен здесь отображаться. 7

A service management function cannot have total control of the components required within the applications and infrastructure environment. For this reason configuration management is regarded as a discipline or set of disciplines that many component contributors (including suppliers) can follow. The activities that contribute to the configuration management discipline will include:

Identification. Identifying infrastructure components and the relationship between components.

Control. Authorization for component changes.

Status accounting. Recording and reporting CI data.

Verification. Audit of CI records and infrastructure position.

Inventory. Identification of a CI instance.

Support. Identification of CI attributes that can assist with problem resolution.

Contacts. Authority and users of the CIs and/or CI instances.

Each configuration management discipline will have a defined set of rules to ensure that CIs are suitable for the enterprise computing environment. Some of these disciplines and rules are outlined below:

Identification of a valid configuration item

Is it practical to manage as a CI?

Is the information about the item required by a number of people?

Will the CI need to be replicated?

Will the CI need to be supported?

Is the CI likely to change?

Is the intended use of the CI understood?

Are other CIs dependent on the state of this CI?

Does the CI have adjustable properties?

Will the CI be subject to company and/or IT policies?

What will be the change impact of introducing this CI?

Defining the attributes of the CI

Definition of CI (name and purpose)

Intended use

Physical items that make up the CI (including other CIs)

Installation and removal procedure

Position in the CI hierarchy

Ownership and authority

Relationship with other CIs

Known faults and issues for CI

Version identification

Valid states for a CI (development, testing, and release stages)

What attribute changes would force a new CI definition?

Use authorization (who determines users of a CI)

Maintenance of CIs

8 Microsoft Operations Framework White Paper

The owner is responsible for ensuring that the CI information is correct.

CIs are subject to change authorization process.

Attribute changes can force a new CI definition.

Validation of infrastructure CIs

Known state checks

Instance checks

License compliance

Configuration management directly supports the change management function but also supports most of the service management activity in some way, as the repository for configuration information. The change authorization process essentially demands commitment to the configuration management discipline, because change management covers the control of a CI’s implementation into the live infrastructure.

A comprehensive and up-to-date Configuration Repository will support many service development and service management tasks. Configuration management policies and procedures must therefore ensure commitment to the maintenance and use of the CR for all those in the organization who are responsible for introducing or changing IT components within the business IT environment.

Commitment to Configuration Management

Configuration management is a discipline that must be followed by all those who contribute components to the application environment or IT infrastructure of the business. Because such a broad range of component contributors can be involved, rules and commitments are needed to ensure that the components that are provided are valid Configuration Items. The commitment to configuration management therefore rests with those who have direct responsibility for the production of Configuration Items.

The responsibilities that directly relate to configuration management can be explained in terms of the generic titles of process owner , process enforcer, and configuration item owner . These roles are explained below.

The process owner will be a senior position in the IT organization with authority to define staff objectives for adherence to the configuration management disciplines. The process owner must:

Demonstrate business awareness and credibility in the business to ensure the processes support the business priorities.

Appoint the process enforcer and be responsible for reviews of the commitment to the configuration management disciplines.

Have sufficient authority to set the standards and rules for configuration management across the company.

Ensure that the skills and culture within the service management function provide full commitment to the configuration management.

The process enforcer will be responsible for overseeing adherence to configuration management disciplines. The process enforcer must:

Ошибка! Используйте вкладку "Главная" для применения Heading 1 к тексту, который должен здесь отображаться. 9

Have credibility within the organization to encourage a broad range of CI producers to work within the constraints of the configuration management disciplines.

Show attention to detail, be organized and persistent, and have the ability to work with technical staff.

The configuration item owner is responsible for providing a configuration item for the business IT systems environment. The CI owner must:

Have knowledge and understanding of the CI technology.

Be experienced and responsible, and demonstrate commitment to process and concern for standards.

Fully understand the configuration management disciplines and tools used by the configuration management function.

Development groups within the organization must adhere to the configuration management disciplines. Throughout the development life cycle, there will be a requirement to update or refer to the Configuration Repository items to ensure new Configuration Items are compatible with existing components.

Development staff will be CI owners within the component development stages but ownership may be passed on to service management staff as the configuration item is prepared for change management and implementation in the operational environment.

Although the need for a process owner/authority has been highlighted, it is essential that all staff commit to and follow the disciplines for configuration management. Every CI must have an owner who is responsible for ensuring the component definition is correct and the CI must be subject to authorization disciplines from initial definition, through development, into deployment and maintenance.

Supporting Systems and Tools for Configuration Management

A Configuration Repository is required together with application tools supporting the maintenance of the Configuration Repository information. This repository needs to support both the Configuration Items and the inventory information.

The repository will require tools to support registration and status tracking of components as well as tools for maintenance of inventory information.

It will need additional tools to provide automated data collection of component and inventory information. This capability supports the auditing and validation of the application architecture and IT infrastructure.

Integration with change and problem management together with links to the IT procurement systems would improve overall service management efficiency and help ensure the integrity of the Configuration Repository.

Configuration automation can eliminate the possibility of human error when used as part of the component development as well as the component installation and component auditing activity.

10 Microsoft Operations Framework White Paper

The technology that supports the Configuration Repository is typically seen as a discrete set of capabilities with databases providing some information environments and file store or Web-addressable storage supporting other parts of the Configuration Repository. The requirements set out for configuration management above clearly require a more integrated Configuration Repository solution. Microsoft and other enterprise partners have an opportunity to respond to the requirements in this service management area.

Change Management

Business Justification for Change Management

The change management discipline gives business managers control of the IT service priorities. It provides the procedures to safeguard existing services and safely introduce new services. The procedures will increase service availability and IT efficiency by reducing the number of unnecessary changes and ensure that no service issues are caused by application or infrastructure changes.

Change management requires a permanent (cultural) commitment to disciplines for introducing IT changes that need to be recognized throughout the organization. IT customers and the service provider must work together to make the change management process efficient and effective.

The change disciplines are a set of processes for coordination, authorization, and communication required to ensure the right people know about and approve a change to the IT infrastructure or services. Liaison is required between those making the change and those affected by the change. This liaison must communicate the impact on services that results from changes and establish the schedule for the changes.

Implementing Change Management

Change management ensures that all changes are accurately represented in the

Configuration Repository and the IT infrastructure. To maintain the business IT environment in a reliable state, it is necessary to follow an ordered process to validate and accept changes. The change management process therefore involves the following sequence of actions:

Register and define the change requirements.

Validate the change—cost, resource, technical, business commitment, risk, and recovery (back out).

Schedule the change.

Communicate information about the change, progressing plans, and agreement for a change.

Establish approval for the change.

Implement the change.

Record the fact that the change has been made.

Review the impact or results of the change.

Ошибка! Используйте вкладку "Главная" для применения Heading 1 к тексту, который должен здесь отображаться. 11

Scheduling needs to be provided using a single change calendar so that planned changes can be seen in the context of other changes being planned. This change calendar needs to be available to all those in the organization who need it and it must accurately show past and future changes.

Because the change management procedures will not directly control technical resources required for implementing an IT system change, the change procedures must enforce the rule that resources needed to implement a change are secured before a change can be approved.

The change process ensures the appropriate disciplines are applied to all aspects of a change. These disciplines are:

The recording of the transition between two configurations.

The identification of who is affected by a change.

The effective communication with those affected by the change.

Planning and agreement for the change.

Establishing the schedule for the change.

Identification and resolution of conflicts associated with the change or change schedule.

Application of an appropriate level of control to a change.

Ensuring appropriate authorization is applied to a change.

Review of changes to raises the integrity of subsequent changes.

Commitment to Change Management

All staff in the business and IT function need to understand the change process and their role and responsibility within this process.

The roles that directly relate to the change management activity are given below with some guidelines on the positioning of these roles and responsibilities within the organization in terms of experience and objectives.

Business approver — a business representative who know the business area priorities and business processes supported by the IT systems that need to be changed.

Change proposer—a system or service specialist who know the business requirements.

Technical approver—technical specialists with an operational or applications background that have a broad understanding of how the infrastructure and services are delivered.

Change owner—a senior technical authority from a service management or development group with good business contacts.

Change implementer—technical specialist with appropriate skill and competence required for a specific change. This person must show commitment to procedure and concern for the impact of IT changes.

12 Microsoft Operations Framework White Paper

Change coordinator—someone usually based in the IT function who has the ability to work with a broad range of contacts such as suppliers, technical specialists, and business/user contacts. This person needs to have good communication skills and be persistent in establishing the change commitments.

In addition to the roles that directly relate to progressing individual changes, change management has two generic roles that are required to maintain the service management function. These are:

Change process owner—responsible for defining, validating, and maintaining the change process.

Change manager — must have the authority and accountability to influence the overall effectiveness of the change management function. This position and level in the organization will depend on impact and dependence that a business has on its IT capability. For example, if the loss of IT service has a major revenue impact, the position will be more senior.

Supporting Systems and Tools for Change Management

Change management systems will have many terms, roles, and change information headings that are specific to a service management function. The information below identifies some of the fields that will exist in a changecontrol record or request for change form. The information required to manage a change has been grouped into six categories:

Change approvals—proposer, owner, business approver, technical approver

Change identification—name, reference, type, priority

Change details—description, instructions/plan, justification, risk, recovery plan

Change schedule—date, time, duration, location, downtime, status, resource

(change implementer)

Change impact—services, systems, business areas, contacts

Change confirmation—review date, testing, results, problems cleared

The systems and applications (tools) need to support the following change management requirements:

Comprehensive communication, coordination, and scheduling.

Automated changes initiated by change management tools.

Automated validation of technical changes.

Integration with the Configuration Repository.

Automated synchronization of authorizations.

Change analysis and reporting facilities.

The system and application requirements for any organization will need to be individually assessed because the level of control, risk and investment will be very specific to a business needs and priorities.

Ошибка! Используйте вкладку "Главная" для применения Heading 1 к тексту, который должен здесь отображаться. 13

Problem Management

Business Justification for Problem Management

Problem management is concerned with reducing business loss from IT service outage. This is achieved by providing processes to efficiently and effectively respond to IT service problems in order to reduce their impact and recurrence.

The problem management service encourages the full exploitation of the IT capability within the business by ensuring customer confidence in the reliability of services.

Customer confidence and problem resolution efficiency established by the problem management function helps establish the best return and business impact from an IT investment. The reduced service costs and the enhanced value of an IT solution are due to the reliability and availability that is achieved.

Problem management provides the procedures for handling a situation that is causing or threatening a break in service. These procedures are designed to minimize the impact of problems when they occur and to use information collected during problem resolution to correct the root cause of a problem.

With the continual advances in IT capability facilitating business change, the commitment to problem management is required throughout the organization.

Technical specialists must give priority to service problems within their area of expertise and service customers need to understand and fully support the problem-resolution processes.

Implementing Problem Management

Explaining the problem management function requires a brief overview of other service management activities associated with the identification and resolution of a service issue. This explanation will help position the problem management activities and priorities.

The initial notification that a user or system requires attention is generally referred to as the “call.” A call can be generated by a person or automatically by an application or the IT Infrastructure components. This call can be received by phone, e-mail, fax, and an intranet or through automated alert systems. The key feature of the call is that it provides the initial information needed to show that someone or something requires the attention of the service management function.

A call will be filtered into just three (attention) categories: problems, request, and inquiry. These categories are defined below:

Problem. A situation causing or threatening a break in service.

Request. A request for an action to be taken to assist someone with the use of an IT service that is operating within its agreed service level.

Inquiry. All other call topics not filtered to a problem or request.

When a call has been classified as a problem, the events and actions that lead to the application of the problem management processes are as follows:

14 Microsoft Operations Framework White Paper

1.

A problem will be recorded as a result of call information. Calls are filtered into three categories: problem, request, and inquiry.

2.

As a result of the call and call filtering, a problem may be identified.

3.

Attempts will be made to isolate the type of problem.

4.

The business impact will be assessed and a severity level assigned.

5.

Additional information will be collected, based on the type of problem.

6.

The problem management process as defined by the roles and responsibilities below will then be applied.

When it has been established that a problem exists (after call filtering and verification), the following roles and responsibilities will cooperate to resolve the problem. An individual may take one or more of these roles, depending on the organization structure, business priorities, and service management objectives. They are:

Management. Responsible for defining, reviewing, and refining the problem management process.

Resolution. Responsible for the knowledge and experience required to fix the problem regardless of support level.

Ownership. Responsible for ensuring that the problem is fixed within the agreed severity-level schedule by directing activities performed by other roles. Ownership includes driving the root cause identification.

Coordination. Gathers information on a problem and ensures that this information is available for the other roles within problem management.

Analysis. Responsible for looking at a range of problems to identify trends.

Customer liaison. Responsible for keeping the customer informed of the problem status.

The problem management system provides the problem registration and tracking of the problem status. This system will support the cooperation between the roles and activities and is focused on the diagnosis, resolution, and elimination of a problem. This cooperation, aided by the registration and tracking system, defines the problem management process.

The severity codes need to be clearly defined in terms of business impact that the customer will see. The type of service will influence the assigned severity code. A severity level can be changed as the problem is progressed if the impact assessment changes.

The severity levels should also be used to set the schedule (including resolution timeline, escalation path, and customer response commitments) for the timely progression of a problem. This schedule should then be used to drive the problem management process.

Within the problem management system, a problem will eventually reach a status of “circumvented,” “resolved,” or “closed.”

Circumvented. Indicates customer is working again.

Resolved. Indicates customer is working and problem will not recur for this customer.

Closed. Indicates changes have been put in place to ensure that another customer will not see the problem.

Ошибка! Используйте вкладку "Главная" для применения Heading 1 к тексту, который должен здесь отображаться. 15

After a problem has been closed, the problem record should be retained for a limited period to be used in problem analysis activities.

Problem management has both reactive and proactive elements. The proactive activities and methods that can help service managers avoid major service problems include:

Early warning from automatic alerts.

Root cause analysis of a problem.

Periodic or ad hoc trend analysis of problems.

Additional proactive activities and methods of improving service reliability include:

Automated analysis of problem data.

Automated coordination of process roles.

Service impact predictions based on problem registration.

Support group performance statistics.

Customer feedback information and statistics.

Cost visibility for problem resolution identifying options and actions taken.

Monitoring, measuring, and reporting of problem statistics should be used as a means of improving overall service management effectiveness.

The problem management process established by the IT function need not be limited to organizing internal IT staff. With appropriate service contracts, external IT service suppliers can work with the rules and systems of the problem management solution.

Commitment to Problem Management

Problem management is a core feature of IT service delivery. Central to the commitment to problem management is the provision of staff with the appropriate skills needed to handle the scale and complexity of IT systems within the business.

At a team and individual level, staff will need to be trained to perform the problem management roles. Problem management staff must also be given recognition, through the staff review process, for the contribution that they make to problem management and service delivery. Problem management requires some dedicated resources as well as dedicated commitment from other staff, such as technical experts who are not fully assigned to the problem management function.

The knowledge, skills, and competencies of those who are involved in problem management are outlined below.

Management. Organization and business process design skills. The ability to define and use process statistics to monitor efficiency and effectiveness.

Resolution. Appropriate technical skills and concern for standards.

Ownership. Business understanding and commitment as well as influencing skills.

Coordination. Communications and influencing skills as well as a good understanding of IT organization.

16 Microsoft Operations Framework White Paper

Analysis. Logical thinking and determination.

Customer liaison. Customer orientation, business knowledge, and influencing skills.

Core skills and competencies will be knowledge of the problem management roles, process, and the tools that support this process.

Supporting Systems and Tools for Problem Management

The basic requirement is for registration and tracking of problems. The problem management systems will have many terms, roles, and information headings that are specific to a service management function. The information below identifies some of the fields that will exist in the call and problem records. The type of information needed to progress a problem is also given below.

The following notes explain the basic characteristics of the problem management system. The fields defined in the problem registration system were seen to be common to a number of problem management solutions.

Call handling provides the initial information that may become classified as a problem. As validation, isolation, and problem resolution of a problem is progressed, additional information on the problem is recorded within the system.

The following list details the type of information that would be recorded in the problem management system.

Contact details—name, organization, location, and phone number.

Call origin, such as e-mail, phone, fax or automated system alert.

Call/problem code or ID.

Severity assigned including a planned schedule for resolution.

Current status.

Call/problem description and summary.

Systems, applications, or services involved.

Contact/operator advice or contact information. Includes routing information and call/problem-handling rules.

Problem owner.

Resolution description including the date and time the problem was resolved.

Call/problem history—records all changes to the call/problem record.

A work history field and audit trail mechanism shows record changes made as the call/problem is progressed.

Analysis tools are needed to provide problem statistics and information on how support groups use the problem management system. In addition to this, the problem management system needs to integrate with other service management tools such as the Configuration Repository and change management.

Problem resolution can also be assisted by the provision of problem analysis facilities built into an application or service—for example, the testing of response times using a dummy transactions facility.

Ошибка! Используйте вкладку "Главная" для применения Heading 1 к тексту, который должен здесь отображаться. 17

All infrastructure components and applications should have alert features with predefined diagnostic/resolution advice. With this information available, when a call is logged, the call filtering and problem resolution will be guided toward the most probable cause.

Tools are also needed to support the routine actions of problem management.

For example, it is common to see the corporate e-mail system providing services for problem management such as call notification, customer communication, and the coordination of problem management resources.

Conclusions and Recommendations

General Conclusions and Recommendations

The best practice investigation has taken ITIL service management standards as a starting point for service management methods. Working with experienced service managers, the ITIL material has helped to define best practice view of configuration, change, and problem management presented in this document.

The difference between the ITIL material and these best practice views is concerned with style and perspective more than substance and purpose.

The service management experience that has contributed to these best practice views has been provided by organizations with different business and IT service priorities. The differences in IT service management needs have helped to ensure that the process and disciplines advice is not limited to a particular technology, infrastructure, application service or business model, but is generally applicable.

In gathering the best practice advice, the objective had been to look at specific service solutions as well as the service management processes. From the initial interview sessions it was confirmed that best practice solutions needed to be applicable to any IT service that could be provided. As a result of this feedback, the work with the DCAC members has concentrated on the best practice processes and not advanced the more technical and supplier-specific solution scenarios.

The DCAC members accepted that Microsoft had requirements to provide technical advice for producing and maintaining specific IT services. It was agreed at the workshop sessions that this requirement would be progressed by

Microsoft using its own service management experts and that the results would be offered to the DCAC members as solution scenarios aligned with this best practice advice.

The best practice information is not intended to provide the detailed design for service management solutions. These notes provide an overview of how to implement and maintain each service management function.

The commitment given by the three companies involved in this project has been very significant. At each workshop session it was reiterated that service management was an area that Microsoft should continue to support. It was suggested that service management topics should be covered as part of

Microsoft Certified Systems Engineer (MCSE) qualifications and that Microsoft should also influence its partners to progress this area.

The following topics were proposed as additional service management areas that should be progressed next:

18 Microsoft Operations Framework White Paper

Service level management.

Availability management.

Capacity management.

Cross-platform systems management and cross-platform user authorization management.

In addition to new service management topics, the workshop sessions gathered feedback on the additional requirements that would help to advance the configuration, change, and problem management areas.

Additional Configuration Management Requirements

The review of configuration management indicated that this topic was not generally seen to be in the scope of service management. The initial view (at the individual company interviews) was that service management provided some build management solutions, but application development teams maintained control of the configuration data.

At the workshop session, DCAC members recognized the significance of configuration management and how this service management activity needed to be implemented. The drive for a configuration management solution was seen to be the requirement to handle the increasing complexity of service solutions and the pace of change in the technologies being implemented.

The configuration management advice presented in these notes is not based on the same type of experience and systems providing the change and problem management best practice. With configuration management, we found that standards and commitment to component management existed in many areas covering both the development and service management needs. However, the configuration management disciplines providing new applications, system builds, and inventory management were seen to be following common principles for component management.

In formulating the best practice advice, the DCAC representatives have identified the need for a more consistent approach to configuration management and in particular the need for a common repository for configuration information supporting all stages of the IT service life cycle. The need for this repository was also established by the best practice advice for change management.

Although the configuration management advice is based on real service management experience, you could argue that the common repository approach has not been verified as a best practice solution. For this reason, it is recommended that additional work be undertaken to identify or define the common technical solution that can deliver the recommended configuration management facilities.

Ошибка! Используйте вкладку "Главная" для применения Heading 1 к тексту, который должен здесь отображаться. 19

Additional Change Management Requirements

The main requirement in this area was for open standard interfaces between the service management solutions and technologies being managed. This requirement is concerned with facilities such as software component and version identification as well as the packaging of components implementing a change.

Microsoft and other enterprise suppliers need to put more effort into packaging of products ready for change. The DCAC members also felt that more research was needed into product change impact and risk reduction for the corporate customers.

A particular problem area for change management and Microsoft products was the requirement for service outage. This issue was seen to have a significant impact on customers’ perception of service availability. It was also requested that system upgrades be provided in a way that does not require a system restart.

Microsoft and other enterprise suppliers are making progress on the provision of change management solutions, but as the above comments indicate, at this time these contributions appear to be discrete initiatives rather than a more comprehensive solution.

Additional Problem Management Requirements

In general it was agreed that problem management was the most mature of the service management topics investigated. The following list of recommendations has been made to highlight how the problem management solutions could be improved. It was stressed that these requirements applied to all suppliers and not just to Microsoft.

Improve the build quality of products.

Provide help desk diagnostic information (checklists) for products.

Improved failure messages for users and system alerts for operations staff.

Support the development of service management process solutions as industry standards.

Find a way to define services based on components so that the solution provides integrated problem management facilities.

Support open standards for the electronic exchange of problem records with suppliers and external organizations.

Acknowledgements

The quality of service management advice presented in this report results from the experience and commitment of the DCAC members who supported this project.

The combined contributions of each of these companies equaled 12 days’ worth of interviews and workshops. It should also be noted that this commitment was given at very short notice. We would like to acknowledge and thank those (see below) who have contributed directly to this best practice advice.

20 Microsoft Operations Framework White Paper

We would also like to thank the CCTA ITIL for providing the open standards service management advice that provided a significant starting point for this best practice investigation.

The following companies have made a direct contribution to the content of this best practice service management advice:

Marks and Spencer Ltd.

AstraZeneca Ltd.

Marconi Communications Ltd.

Microsoft Corp.

Peter Musgrave

Anthony Baron

Andy Watson

Allan Dornan

2020 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR

IMPLIED, IN THIS DOCUMENT.

Microsoft, BackOffice, MS-DOS, Outlook, PivotTable, PowerPoint, Microsoft Press, Visual Basic, Windows,

Windows NT, and the Office logo are either registered trademarks or trademarks of Microsoft in the United

States and/or other countries.