Process 2: Implement New Service

  • Article

 

Figure 4. Implement new service

Activities: Implement New Service

Successfully implementing a new service requires ensuring that it aligns with what is already in place. The first activity ensures that the new service meshes with existing IT processes and functions; the second concerns the service’s impact on the people within IT. Finally, the third activity brings the service in line with existing IT tools and processes.

Implementing a new service involves the following activities:

  • Align new IT service to existing processes and functions.
  • Align new IT service to existing IT organization.
  • Align the new IT service to existing SMC tools.

The following table describes these activities in greater detail.

Table 5. Activities and Considerations for Implementing Service

Activities

Considerations

Align new IT service to existing processes and functions

Key questions:

  • Does the new service require any changes to existing process descriptions?
  • Will the new IT service affect other SMFs (which will then require SMC process description changes)?
  • Will the new service change existing or add new SLAs, OLAs, or UCs?
  • Will the new service necessitate changes to existing escalation policies?
  • What are the KPIs for the new IT service?
  • How will the new service be monitored after it is in production? For example, can an SMC agent be installed to reflect the health model, or are there restrictions as to what can be installed locally? Is an agent needed?
  • Is there a plan for how unforeseen errors can be incorporated quickly into the monitoring process after release?

Inputs:

  • Existing process descriptions
  • IT service description
  • New or updated service requirements (SLAs, OLAs, UCs)
  • KPIs for the new service

Outputs:

  • Updated SMC process descriptions
  • Updated SMC policies, procedures, and standard operations procedures

Best practices:

  • Check all existing escalation routines for workflow changes. Ensure that there are documented escalation routines if they don’t already exist.
  • Test the service several times before placing it into production to ensure that every part of the process description is in place and that the process maps correctly to the workflows.
  • Document the service end-to-end to ensure that it is monitored as a whole—not just as a group of components.

Align new IT service to existing IT organization

Key questions:

  • Which group(s) will do the monitoring?
  • Who will be responsible for the new IT service?
  • Is the existing organizational structure sufficient to handle the increased workload?
  • What type of training will team members receive?
  • Is all relevant documentation up to date?
  • Have all service descriptions been updated, including organizational details such as contact information, hours of operation, and service windows?

Inputs:

  • Updated SMC process description
  • Existing organizational structure and organization chart
  • List of people involved in the SMC function and their job descriptions

Outputs:

  • Updated organizational structure
  • Updated service descriptions with contact information
  • Training plan and training material
  • Updated job descriptions
  • Updated information related to escalation policies

Best practices:

  • Ensure that proper training is given to the appropriate people. Document and understand all organizational dependencies.
  • Make sure that all team members understand day-to-day SMC roles and responsibilities.

Align new IT service to existing SMC tools

Key questions:

  • Is monitoring currently done at the component level or at the IT business service level?
  • What load will monitoring put on the servers?
  • Should all technologies be monitored, or only a subset?
  • Do the existing SMC tools have the capability to monitor all technologies and platforms (network, hardware, OS, middleware, application) according to SLA and monitoring requirements?
  • Are there alternative solutions for the technologies and platforms that cannot be monitored?
  • Does existing documentation describe the design and configuration for IT services?
  • Does the existing service monitoring tool support industry standards (for example, Service Monitoring Language or Service Definition Model)?
  • Will monitoring be agent-based or agentless?
  • How many technologies and solutions are used to monitor IT services?
  • Is there a standard for documenting CIs and services?
  • Is there a description of how the SMC systems are configured?
  • Can synthetic transactions be defined to monitor end-to-end scenarios?
  • Should we be monitoring any sub-services that we do not control?
  • Can the monitoring system handle the new IT service requirements (availability, performance load on monitoring system, reporting capabilities)?
  • Are there any infrastructure constraints that will prevent monitoring (network access, server access, user access)?
  • Is the IT system tuned according to SMC standards?
  • Can the role responsible for the IT service be defined within SMC?
  • Can any fixes be automated?
  • Who has access to information about the service?

Inputs:

  • Definition of IT service monitoring according to SLA requirements
  • Requirements from other SMFs
  • Alert and event definition according to CIs in the IT service
  • A monitoring service model describing all CIs for the application and its relationship to other CIs
  • A complete health model describing each CI with a list of sub-components
  • Availability defined and measured for every CI and service via a health model
  • Incident categorization, aggregation, and correlation guidelines for SMC tool
  • Platform and applications requirements for monitoring system
  • IT service reporting and availability requirements for the monitoring tool
  • Alerting and health requirements for the monitoring tool
  • Infrastructure requirements for monitoring the IT service
  • Operational guidance from vendor, if applicable
  • Monitoring requirements from operations plan

Outputs:

  • IT service monitoring requirements defined in the monitoring tool
  • IT service monitoring requirements defined for manual handling
  • Service model (distributed application) defined in the monitoring tool
  • Ability to generate reports according to SMF requirements (SLA, availability, capacity, KPI)
  • User roles for the IT service defined in the SMC tool
  • All CIs monitored by the SMC tool
  • Knowledge defined for IT service alerts, such as a checklist that defines what actions can be taken to solve issues related to incoming alerts and events
  • Views and tasks defined for the IT service
  • Alerts and states tuned as required by the IT service
  • SMC tool with automatic actions and manual tasks defined for IT service

Best practices:

  • Tune the system so the alert or state showing at the SMC system is actionable, informational, and relevant.
  • In the event of an alert, make sure that as much information and guidance as possible is available to the monitoring console user.
  • Ensure that the console user sees only relevant alerts.
  • Ensure that error descriptions and troubleshooting hints are available for every alert that can come from a CI.

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.
Download

Get the Microsoft Operations Framework 4.0
Solution Accelerators Notifications

Sign up to learn about updates and new releases
Feedback

Send us your comments or suggestions