System Planning, Deployment, and Best Practices Guide

(1)

www.novell.com/documentation

System Planning, Deployment, and

Best Practices Guide

(2)

Legal Notices

Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes.

Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes.

Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the Novell International Trade Services Web page (http://www.novell.com/info/exports/) for more information on exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export approvals.

Copyright © 2014 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher.

Novell, Inc.

1800 South Novell Place Provo, UT 84606 U.S.A.

www.novell.com

Online Documentation: To access the latest online documentation for this and other Novell products, see the Novell Documentation Web page (http://www.novell.com/documentation).

Novell Trademarks

For Novell trademarks, see the Novell Trademark and Service Mark list (http://www.novell.com/company/legal/trademarks/ tmlist.html).

Third-Party Materials

(3)

About This Guide

The purpose of this System Planning, Deployment, and Best Practices Guide is to describe the items that need to be considered when designing a Novell Service Desk solution and deploying it across small and large scale enterprises.

The information in this guide is organized as follows:  Chapter 1, “Overview,” on page 7

 Chapter 2, “ITIL Primer,” on page 13

 Chapter 3, “Pre-Design Activities,” on page 23  Chapter 4, “Design Activities,” on page 39

Audience

This guide is intended for administrators.

Feedback

We want to hear your comments and suggestions about this manual and the other documentation included with this product. Please use the User Comments feature at the bottom of each page of the online documentation.

Additional Documentation

Novell Service Desk is supported by other documentation that you can use to learn about and implement the product. For additional documentation, see Novell Service Desk documentation Web site (http://www.novell.com/documentation/servicedesk7/)

(6)

(7)

1

Overview

Promoting a culture of service management, both internally and externally, is the key to being more relevant to customers within any market vertical. This allows an organization to shape its products and service based on the specific requirements of its customers and encourages business confidence by providing more reliable service and support.

Internally, IT service management encourages a clear understanding of actual IT capabilities, and promotes IT service continuity. In most cases, the largest percentage of the IT spend is on the day-to-day support costs and this can be reduced by an effective service management process.

Service management ensures IT resources are aligned with business requirements, and allows the IT department to appropriately identify points of flexibility and adaptability within the services they provide. This ensures service issues and change requirements are handled efficiently and effectively, to keep organizations running at an optimum level.

1.1 The Service Desk

The Service Desk provides the essential daily contact between customers, users, IT service and any relevant third-party support organization. The main objective of the service desk is to drive and improve service support to, and on behalf of an organization.

This customer-facing support service is a single point of contact that provides advice, guidance and rapid restoration of normal services to its customers and users. It handles Incidents, Problems and Change requests. More than this, it also manages maintenance contracts, software licenses, and provides Service Level Management, Configuration Management.

The successful implementation of a service desk results in a professional service that builds business confidence and provides greater customer satisfaction. This is a result of the professional service that is positioned to provide a consolidated and fiscally positive business activity that impacts all aspects of service beyond the IT department. The key to service desk success is the employment of

professional people, well-defined and repeatable processes and good tools, which in turn makes the product or service being supported, to some degree, immaterial.

Adopting a service management approach results in benefits across all level of any business:  Customers – obtain a sustainable, reliable, secure, quality service

 Line Management - achieve greater control over the change management process  Senior Management – can monitor performance and adjust resources appropriately

 Boards - gain confidence from the adoption of best practices service, which in turn mitigates personal risk

(8)

1.2 Customer Loyalty

The IT group within an organization can use customer feedback accessed through service and support, to continually improve . By responding consistently and appropriately to customer requests, IT is seen be delivering what the greater organization needs.

To be successful at this endeavor, organizations can use technology to enhance the business process, by harnessing IT to deliver improved customer satisfaction. Businesses can employ service

management best practices and measure its service results, in an effort to promote an environment of continual improvement.

1.3 Novell Service Desk for ITIL Service Management

Novell Service Desk for ITIL Service Management is a complete service management tool for the enterprise designed around ITIL. Based on open standards and a Web 2.0 interface, Novell Service Desk enables organizations to implement best practices in a matter of weeks, not months.

Supporting 11 core ITIL processes out-of-the-box and integrated CMDB, Novell Service Desk enables full visibility into the organization’s infrastructure and support services. Instantly identify whether your business is delivering against Key Performance Indicators (KPI’s) such as Service Level Agreements, response times and spot rates.

1.4 Scalable and Open

Novell Service Desk is highly scalable supporting thousands of concurrent users with quick response times. Installation and configuration is just as easy for a small organization as it is for a department with thousands of technicians and clients. Any browser can be used to access the system. And because the browser interface is pure HTML (no downloads or plug-ins) there is zero cost for client installation and maintenance.

1.5 Cost Effective

Novell Service Desk focuses less on consulting and more on solutions. The software license costs represents 98% of the total cost of the solution. The software has been specifically designed for customizing simple toggles directly in the user interface, as well as standard HTML and CSS. Novell and its partners are more interested in solving your business problems. Therefore, our consulting focuses more on business process re-engineering and training, not software programming.

1.6 Instant Upgrades

One of the significant advantages of Novell Service Desk is the ability to upgrade to the latest release with a single click. This is very rare in the Enterprise software segment, which traditionally focuses on upgrade fees and heavy consulting services.

1.7 Supported ITIL Processes

 Request Fulfilment: The Request Fulfillment process manages Service Requests for information or advice.

(9)

 Incident Management: The Incident Management process aims to restore normal service operation as quickly as possible.

 Problem Management: Problem Management is to prevent Incidents from happening and to minimize the Impact of Incidents that cannot be prevented.

 Change Management: The Change Management process ensures that standardized methods and procedures are used for efficient and prompt handling of all changes with minimum disruption to services.

 Configuration Management: Configuration Management provides a logical model of the infrastructure or a service.

 Knowledge Management: The primary purpose of Knowledge Management is to improve efficiency by reducing the need to rediscover knowledge.

 Service Level Management: The process of defining, agreeing, documenting and managing levels of customer service that are required and cost justified.

 Service Catalog Management: Service Catalogs provide the details, current status and service interdependencies on all operational services and those being prepared to be run operationally.  Service Portfolio Management: The process of designing a strategy to serve customers, and to

develop the service provider’s offerings and capabilities.

 Financial Management: Financial Management quantifies, in financial terms, the value of IT services for a business and IT department. This includes measuring the value of the

underpinning infrastructure used to provide IT services, as well as qualifying operational forecasts.

 Release and Deployment Management: The purpose of Release and Deployment Management is to maintain the integrity of an organization’s production environment when implementing releases.

1.8 Improved Service Support

At the point organizations are judged based on the quality of their service support, businesses need to assess how their IT services meet the customer and business requirements. Where a support service already exists, an organization needs to ask the following questions:

 Does our support team log and understand the technical nature of customer difficulty at first point of contact?

 Do they respond relevant to the degree of urgency stipulated by the customer?

 Does the support team communicate with the customer regarding the follow-up activity?  Do they meet the expectations outlined to the customer?

 Do they complete work with the minimum disruption to the customer, and in a positive and professional manner?

 Is customer follow-up action taken? For example, ensure the issue is resolved and the customer is happy.

Organizations need to know that all service requests are handled in a consistent manner and with good communication as business confidence is gained when customers know that a support service is managed in this way. Confidence is lost when service requests appear to go into a “black hole”.

(10)

To successfully differentiate an organization within any market, high quality and predictable IT service is required to drive increased business and revenue. However, this requires the IT service support process to move from an ad-hoc, chaotic process to an ideal of value-add service.

1.9 Achieving Service Support

To build a service support culture that underpins the success of an organization, strong leadership and vision is required. To develop a business based on service, an organization must:

 Understand its current position. Is the service offering: Chaotic? Reactive? Proactive? Service? Or Value?

 Set the goal, regarding the level of service management needed to best support the business.  Set the right personal performance metrics and rewards that will encourage staff beyond

fire-fighting and reactive support mode

 Dedicate time and training to document repeatable processes and become proficient at their execution

 Continually review the service, to ensure an active predictable service quality is maintained. The implementation of formalized processes provides cost-effective and consistent IT services, which allow organizations to handle service requests and change in an efficient way with minimal

disruption to customers. Such improvements to the quality of service and support, allows IT service to become a true business asset.

For organizations to successfully capitalize on the potential of IT services they must:  Develop a culture of IT operations excellence

 Create well-defined, repeatable processes that undergo continual refinement  Build an organizational structure that underpins the processes

 Measure and report on the success and failure of the processes

1.10 Conclusion

The implementation of service support standards provides organizations with the opportunity to differentiate their business and service offerings from their competitors. To be successful, an organization must make an honest assessment of its current position and use this as the basis for planning its future achievements.

To successfully provide predictable, high quality service, businesses must develop formalized processes that are constantly monitored and reviewed. In order to achieve this, the service desk application adopted by the organization must tightly integrate Incident, Problem and Change Management with an easy-to-use workflow engine and the Service Level Management process. To ensure the cost effectiveness of IT infrastructure, an embedded CMDB must be easily accessible to the change management team.

To guarantee the service desk is running at an optimum level and meeting its service targets, reports should be easy to generate and readily distributed to the relevant parties. And as customer

communication is paramount for maintaining satisfaction, this should be provided through multiple channels, including email and a customer portal. A central port of knowledge should also be readily accessible to re-cycle useful information and solutions, but also empower customers to provide their own fixes.

(11)

The change process required to implement a culture of service and support, requires support across the organization as a whole. A standards-based approach such as ITIL provides the guidelines for making the change, which result in the alignment of business objectives and customer needs with IT infrastructure that provides benefits across all facets of the organization and ultimately to the bottom-line.

(12)

(13)

2

ITIL Primer

 Section 2.1, “Introduction,” on page 13

 Section 2.2, “Service Strategy - Financial Management,” on page 14  Section 2.3, “Service Strategy - Service Portfolio Management,” on page 15  Section 2.4, “Service Design – Service Catalogue,” on page 15

 Section 2.5, “Service Desk - Service Level Management,” on page 16  Section 2.6, “Service Transition - Change Management,” on page 16  Section 2.7, “Service Transition - Configuration Management,” on page 17

 Section 2.8, “Service Transition - Release and Deployment Management,” on page 17  Section 2.9, “Service Transition - Knowledge Management,” on page 18

 Section 2.10, “Service Operation - Incident Management,” on page 19  Section 2.11, “Service Operation - Problem Management,” on page 19

 Section 2.12, “Service Operation - Request Fulfillment Overview,” on page 20

2.1 Introduction

You don't need to be certified in ITIL or have any intention of implementing it to use Novell Service Desk. However, you should have an understanding of the main concepts as ITIL is well on the way to becoming the de facto approach for running I.T within an organization.

The objective of ITIL is to provide IT services that are fit for purpose, stable and reliable so that customers trust them as a utility. This is achieved by encouraging adoption of a common framework of practices across all areas of IT with the single aim of delivering value to the business.

An ITIL approach to service management protects an organization's IT investment. It ensures baseline services and build capabilities to learn in one area of the organization while providing improvements elsewhere. ITIL delivers service management functionality with sound structure, stability and strength that is built on principles, methods and tools.

The essence of ITIL core practice is captured by the Service Lifecycle that demonstrates an iterative and multidimensional approach to providing services. The phases of the Service Lifecycle include:

 Service Strategy: sets the objectives and performance expectations for IT Services and IT Service Management in line with the organizational needs.

 Service Design: focuses on designing new or changed services for introduction into the production environment.

(14)

 Service Operations: coordinates and conducts activities and processes needed to deliver and support services at agreed levels to business users and customers.

 Continual Service Improvement: constantly aligns and realigns IT service to the evolving business requirements by identifying and implementing to the IT services that underpin the business processes.

With each core phase there are various processes that help to deliver the desired outcomes (Novell Service Desk has up to 11 process depending on version):

 Financial Management (Service Strategy)  Service Portfolio (Service Strategy)  Service Catalog (Service Design)

 Service Level Management (Service Design)  Change Management (Service Transition)

 Service Asset and Configuration Management (Service Transition)  Release and Deployment (Service Transition)

 Knowledge Management (Service Transition)  Incident Management (Service Operation)  Problem Management (Service Operation)  Request Fulfillment (Service Operation)

2.2 Service Strategy - Financial Management

Financial Management quantifies, in financial terms, the value of IT services for the business and IT department. This includes measuring the value of the underpinning infrastructure that provides the services and qualifying operational forecasts. Applying a services approach to IT, financial

management helps identify, document and agree on the value of services being provisioned by IT, and provides service demand modelling and management.

With a goal to ensure funding for the delivery and consumption of services, Financial Management focuses on the demand and supply requirements based on business strategy, capacity inputs and forecasting use. As a transitional role between an organization's corporate finances and service management, Financial Management calculates and assigns a monetary value to a Service and service components to allow costs to be spread across the organization.

The monetary value is derived by calculating the operating and capital costs, which include the investments made in hardware and software license costs, annual maintenance fees for hardware and software and personnel resources used to support and maintain the services, across the number of Users.

Tightly integrated throughout the application, Financial Management derives hierarchical costs from within the CMDB and considers Org Units as Cost Centers, while extending functionality built into the Service Item costs calculator. Used as a forecasting tool, it provides the service organization with information about pricing a service, by detailing the contributing cost factors and applying concepts such as cost splitting across services that leverage common infrastructure. Because the information is stored in the central CMDB repository, organizations can generate their own reports and all data is broken down by cost center, ready to be reassembled in real time for the User interface to assist with business planning and the budgeting processes.

(15)

2.3 Service Strategy - Service Portfolio Management

The Service Portfolio details the commitments and investments made by a Service Provider to its customers and within the markets they service. It contains current contractual obligations, services under development and continuing service improvement programs.

The Portfolio represents all engaged resources and resources being released during the different phases of the Service Lifecycle. It includes the Service Pipeline that consists of services under development and the Service Catalog, which includes customer visible active services that have the potential to recover costs or earn profits for the Services provided.

Service Portfolio Management is a dynamic and ongoing process that covers the following stages in work practices:

 Define - list services, confirm business cases and verify portfolio data  Analyze - maximize portfolio value, set priorities

 Approve - finalize portfolio proposal, authorize services and resources  Charter - communicate decision and allocate resources.

Service Portfolio Management in the system allows organizations to create Service Categories that include business-related attributes, such as business processes supported, business owners and business users. This ensures that organizations record all relevant information against the Service. Organizations can further optimize their Service Portfolio Management by tracking and reporting on Service Offering and Service Component usage, Service Level performance and costs. This includes the functionality to calculate break-even points (B.E.P.) for offering a service, which allows support organizations to charge the appropriate cost for offering the service to their internal or external customers. This is achieved by recording of financial attributes against services, including service cost, service charges and service revenue.

2.4 Service Design – Service Catalogue

The Service Catalogue provides the ability to contain critical information in a central repository accessible by both the IT department and the Business.

The information contained within the Service Catalogue relates to all Services provided by the IT department to the Business. The Service Catalogue is generic and can be applied across all platforms, environments or geographical locations of any organization.

ITIL only provides minim definition for a Service within the Service Catalogue. We'd suggest that the following make a good place to start:

 Service Description: The Service Description should be written in easy to understand, simple, non technical terms that almost any person within the organization could understand.

 Service Owner: The Service Owner is the person within the organization is responsible for the Service although this may not include the actual delivery.

 Criticality: The criticality of the Service is determined by the Business.

(16)

2.5 Service Desk - Service Level Management

The goal of Service Level Management is to maintain and improve the alignment between business activities and IT service quality. This is achieved through the cycle of:

 Agree on service level expectations and record them in Service Level Agreements (SLAs)  Monitor the service provided

 Report actual service delivery results

 Review IT service delivery results in relation to the SLA, and adjust accordingly A Service Level Agreement (SLA) is a formal, negotiated contract that outlines service level expectations and clarifies responsibilities between the Service Desk and its Customers. When unacceptable levels of service are noted throughout the service cycle, action can be taken to re-align expectations with actual service delivery results.

2.6 Service Transition - Change Management

The goal of Change Management is to ensure that standardized procedures are used to efficiently handle all changes, and minimize the impact of any related Incidents upon a service. The Change Management process prevents unauthorized CMDB modifications and reduces disruption to Customers. It does this by coordinating the build, test and implementation of any change that impacts the CMDB.

Changes may arise reactively in response to Problems or externally imposed requirements, for example a new or changed regulatory situation. They may also be proactive, instigated by management to improve an organization’s efficiency and effectiveness, or to enable or reflect new service improvement initiatives.

The Change Advisory Board (CAB) is responsible for approving any Request for Change (RFC). This involves assessing the impact, resources and priority of the RFC. The CAB then advises the Change Manager of their assessment and assigns an appropriate Workflow.

Change Workflows within the system ensure that each RFC is handled with consistency, based on the risk and impact assessment of the CAB. Change Workflows define the actions required to correctly implement the change, and define the responsibilities, authorization and timescale expected to manage the change.

Once a Workflow is assigned to an RFC, it is routed to an appropriate Technician based on the Change Workflow State. After a Technician completes their assignment, the RFC is forwarded to the next Technician based on the next state of the Change Workflow.

When the RFC has progressed through all of the required Workflow States, a change review is undertaken to verify that the RFC has achieved its objectives. If the change objectives are not met, the RFC’s associated backout procedure is implemented to rollback the change and restore the CMDB to a valid state.

As part of the Change Management Process, all requests related to a Change Request are

automatically closed when the related RFC is closed. The system views the request hierarchy from low to high as Service Request, Incident, Problem and Change Request, and if a related request of a higher type is closed, all the lesser type requests are automatically closed.

(17)

2.7 Service Transition - Configuration Management

The objective of Configuration Management is to provide a logical model of the IT infrastructure. It identifies, controls, maintains and verifies the versions of all Configuration Items (CIs) that form an organization’s IT infrastructure.

The fully embedded Configuration Management Database (CMDB) provides access to up-to-the-minute information regarding the state of any infrastructure item. It includes:

 Fully customizable Configuration Item Templates  Configuration Item Lifecycles

 Problem Classifications

The power of the CMDB is obtained by the quality and details of the CI relationships stored within it, which can be used by the Service Catalog. The Service Catalog maps the relationships between individual CIs and allows the Service Desk to assess the real impact of a loss of a service as opposed to an individual asset being off-line.

Once the CMDB has been successfully implemented, Configuration Management will help the Service Desk by:

 Reducing the time required to log a request

 Improving the accuracy of fault diagnosis and request allocation to Support Teams, thereby minimizing the overall resolution time

 Preventing outages caused by poorly planned changes by revealing the full impact and risk of any change to a CI inside the control of the CMDB

 Aiding recovery after a disaster by providing a rollback facility  Listing the authorized software for given desktop

 Recording and reporting on previous, current and planned states of the CI

The benefits of the CMDB are immense, especially when combined with other ITIL Service

Management disciplines of Request Fulfilment, Incident, Problem, Change and Service Management.

2.8 Service Transition - Release and Deployment Management

The purpose of Release and Deployment Management is to maintain the integrity of an

organization's production environment when deploying releases. Effective Release and Deployment processes allow your service organization to deliver change faster and with minimal risk to the business. It provides consistency in implementation approach and assures customers that they can use a new or changed service in line with business requirements.

Part of the Service Transition phase of the Service Lifecycle, Release is responsible for planning, scheduling and controlling changes and updates from Test to Live environments. It ensures the integrity of the Live Environment is protected and that the correct components are released. While Deployment includes the activities or tasks responsible for moving new or changed hardware, software, documentation and process to the Live Environment.

(18)

The capability to leverage relationship maps defined within the embedded CMDB allows the Release Manager to assess the impact of a release, as all related Items can be easily associated with a release package. The extensive use of CIs to represent all aspects of a release and the capability to directly associate any category of CI with the release itself provides a complete picture of how a release will impact the organization before any tasks are undertaken. The Release Manager can identify CI Types impacted by the deployment and CMDB information details users, organizational units and specific infrastructure affected by a release.

Complex and generally a lengthy process, large scale deployments require project management to ensure success. To this end, Release Management includes related activities that require scheduling in and around the internal activities of the service desk. The Release Manager can readily achieve this by exporting release package information to Microsoft Project and administering the full process using a dedicated project management tool.

Exported project files contain all related Change Requests for a Release, providing all relevant parties with an end-to-end schedule of change. The export can also be filtered to include deployment activities that can be merged into the final schedule once the Implementation of Changes is completed, resulting in a full historical account of the release cycle.

Within the system the Release Manager creates and manages the Release within the Change > Release tab. Within the Deploy tab of a Release, the Deployment Tasks are generated and made available as groups within the Change > Deployment tab, while the individual activities are available within the Change > Deployment Tasks tab.

2.9 Service Transition - Knowledge Management

Knowledge Management falls within the realm of Service Transition, as part of ITIL. Within an Organization it is the Process responsible for gathering, analyzing, storing and sharing knowledge and information. Its main role is to improve service management efficiency by reducing the need to rediscover knowledge.

To this end, the system includes the Knowledge Base as an integral part of the Configuration Management System, using the Classifications, Categories and Types of the CMDB as the filing system for all Knowledge Base Articles. Therefore, when new requests are logged with the Service Desk, the system automatically searches through its information store for any Articles related to the current issue.

The Knowledge Base includes a variety of Article types. These are defined as:

Article Type Description

Article A reference document for general information

FAQs Frequently Asked Questions

Solution Created within an Incident or Problem, to resolve a specific issue. Solutions are allocated an Assigned Request status, and can only be viewed by Users and Owners/Customers of the Item associated with the request.

Workaround Created within an Incident or Problem, to provide a possible workaround for a specific request.

Backout Procedure Created within Change Request as a fallback plan for withdrawing a change procedure.

(19)

2.10 Service Operation - Incident Management

The function of the Service Desk is to act as the point of contact between customers of IT services (end users) and the IT service provider (IT department). Its role is to handle all requests for service, including Incidents, and provide an interface for other activities such as Request Fulfilment, Change, Problem and Configuration Management.

An Incident is defined as any event that is not part of the standard operation of a service, and causes, or may cause, an interruption to, or a reduction in the quality of service. The goal of Incident

Management is to restore normal service as quickly as possible, with minimal disruption to the business. This ensures that the highest achievable levels of availability and service are maintained. Incident Management objectives include:

 Incident detection and recording

 Classification of all Incidents and initial support  Investigation and diagnosis

 Escalation

 Resolution and recovery  Incident closure

 Incident ownership, monitoring, tracking and communication

As part of the Incident Management Process, if an Incident is related to a Problem or Change Request and that related request in the other Process is closed, the Incident will be automatically closed. The system views the request hierarchy from low to high as Service Request, Incident, Problem and Change Request, and if a related request of a higher type is closed, all the lesser type requests are automatically closed.

2.11 Service Operation - Problem Management

Problem Management extends the process of Incident Management. An Incident is a non-standard operational event with the potential to harm the quality of an IT service. Incidents are reported by end-Users, encountered by technicians and system/database Administrators, or automatically detected by system management tools. In all instances, Incidents should be reported to the Service Desk.

A Problem describes the underlying cause of one or more Incidents that are being investigated. However, not all Incidents are investigated as Problems.For example, if the power-supply in a desktop computer blew up, it should be treated as an Incident, and the power-supply replaced. ( Although if the power supply is controlled by Change Management, it would need to be treated as a minor change request. ) However, if there was a spate of burntout power-supplies in the same model desktop, then an underlying Problem with the desktop may possibly exist and further investigation into the cause and potential solutions may be required.

For Incidents to be correctly categorized as a Problem, organizations must define the evaluation criteria. For example, raise a Problem if more than 10 Incidents are logged in the space of three hours that refer to the same Configuration Item.

(20)

In the case of the above example:

 Problem: Brand X Desktops no longer operating  Root Cause: Faulty power-supply in July ’09 models  Known Error: Warranty - replace with new power-supply

As part of the Problem Management Process, if a Problem is related to a Change Request and that related Change Request is closed, the Problem will be automatically closed. The system views the request hierarchy from low to high as Service Request, Incident, Problem and Change Request, and if a related request of a higher type is closed, all the lesser type requests are automatically closed.

2.12 Service Operation - Request Fulfillment Overview

The goal of Request Fulfillment is to manage the lifecycle of all Service Requests.

A Service Request is a generic term that describes the numerous and varied demands placed on the service and support organization. Many are small changes, which are considered to be low risk, frequently occurring and low cost in nature, such as change a password or install a software

application request. Alternatively, it may simply be a Customer asking for information. It is the scale, frequency and low-risk nature of the Service Requests that require that they be handled by the Request Fulfillment process, and not Incident or Change Management.

The frequent recurrence of Service Requests requires a predefined process Workflow be set with the support Technicians, service targets and escalation paths in place. To cater for the diverse nature of Service Requests, at minimum two Workflows should be customized for Request Fulfillment, one to handle simple requests for information and the other to deal with standard changes.

In the system, Service Requests are logged against Service Items in the Service Catalog and follow Workflows that ensure that each Request is handled with consistency. The Workflows define the actions required to correctly implement any changes to the Service and define the responsibilities, authorization and timeframe expected to manage the changes that may result from a Service Request. Once a Workflow is assigned to a Service Request, it is routed to an appropriate Technician based on Service Request Workflow State. After a Technician completes their assignment, the Request is forwarded to the next User based on the configuration of the next State for a standard change or closed, if it is a simple request for information.

When Service Requests are raised for Service Item breakdowns, the system allows them to be easily associated with an Incident within the Analysis tab of the Request. Or, if the Service Request results in a change to an Item that is not in the Service Catalog, a Change Request can easily be generated within the Service Request.

If a Service Request is related to an Incident, Problem or Change Request and that related request in the other Process is closed, the Service Request is automatically closed. The system views the request hierarchy from low to high as Service Request, Incident, Problem and Change Request, and if a related request of a higher type is closed, all the lesser type requests are automatically closed, or if the handshaking facility is enabled for the system, moved to the Pending-Approval State.

The Service Strategy volume provides guidance on how to design, develop, and implement service management not only as an organizational capability but also as a strategic asset. Guidance is provided on the principles underpinning the practice of service management that are useful for developing service management policies, guidelines and processes across the ITIL Service Lifecycle.

(21)

Service Strategy guidance is useful in the context of Service Design, Service Transition, Service Operation, and Continual Service Improvement. Topics covered in Service Strategy include the development of markets, internal and external, service assets, Service Catalogue, and

implementation of strategy through the Service Lifecycle. Financial Management, Service Portfolio Management, Organizational Development, and Strategic Risks are among other major topics. Organizations use the guidance to set objectives and expectations of performance towards serving customers and market spaces, and to identify, select, and prioritize opportunities. Service Strategy is about ensuring that organizations are in a position to handle the costs and risks associated with their Service Portfolios, and are set up not just for operational effectiveness but also for Distinctive performance decisions made with respect to Service Strategy have far-reaching consequences including those with delayed effect.

(22)

(23)

3

Pre-Design Activities

A firm understanding of the organization’s business and technical requirements that will take part is the first step in developing a solid design that meets the organization’s immediate and future needs.

IMPORTANT: Throughout this document, we refer to the need for proper documentation.

Documentation is of the utmost importance. Documentation is a complete and accurate reference to the system you have designed and built, but most importantly, it is a reference for the future. As individuals transition in and out of the IT organization, the design documents become a reference as new employees learn the infrastructure they support, including techniques, policies, and design decisions. Documentation is also a good reference for others inside the organization who might not be involved in the day-to-day management of Novell Service Desk but are involved in the

management of other projects that might have an impact on IT service delivery.

The following activities should be performed during the pre-design phase of implementing Novell Service Desk:

 Section 3.1, “Business Assessment,” on page 23

 Section 3.2, “Who Are Your Customers and What Business Function Do They Have?,” on page 25

 Section 3.3, “What Do Customers Need Support For?,” on page 27  Section 3.4, “What Types of Requests Will Customers Make?,” on page 29  Section 3.5, “What Response Are Customers Expecting?,” on page 30  Section 3.6, “Who Are The Support Staff?,” on page 32

 Section 3.7, “What Can The Staff Support?,” on page 32

 Section 3.8, “What Types of Requests Can the Staff Handle?,” on page 33  Section 3.9, “What Response Can the Staff Provide?,” on page 34

 Section 3.10, “What Metrics Will Be Used?,” on page 35

3.1 Business Assessment

Your first need is a detailed business assessment. If you do not have a solid understanding of the overall business (or individual business units) needs or desires, you cannot design a solution to meet them.

The best way to handle this is through a set of informal workshops, which include a high-level introduction to the technology, what it does, how the departments and end users benefit, and possibly a short demonstration of the product.

(24)

 Get their buy-in

 Get their feedback in the form of requirements

The meetings should sufficiently inform department members so they begin to give you feedback about how they will leverage the system. Remember that you are only gathering data at this point; do not make any commitments.

The following list presents some ideas on what you need to define. Think of these as the bare minimum; use your imagination and tailor them to your organization's unique landscape along with any industry methodology that you might be following, such as ITIL.

 Who are they and what business function do they have?  What do they need support for? For example, software

 What types of request will they make? For example, X is broken, how do I achieve Y, I need Z  What response are they expecting? For example, if X is broken, then it must be fixed within Y

hours

After you have your first set of meetings with the greater business, do the same with the IT department.

 Who are the support staff?  What can they support?

 What types of request can they deal with?  What response can they deliver?

There will be differences between what the business expects and what IT is capable of delivering. You will need to meet with the various parts of the business again, or even several times, to discuss these and obtain alignment. Only then should you move forward with implementation.

(25)

3.2 Who Are Your Customers and What Business Function Do

They Have?

The service desk must keep its customers happy and be able to respond to their needs in a timely manner. This means knowing who they are and what business role they have. Customers could be internal, external, or a mixture of both.

A good place to look for internal customers is your organizations directory service, such as

eDirectory or Active Directory. Depending on how the directory service has been configured, it will also tell you which department they are in and their job role. If none of this information is available in an electronic format, then HR will be your first point of contact.

(26)

Novell Service Desk can store a lot of information about each customer as shown in the following table:

Information Description

Title If enabled, select the appropriate title from the drop-down options

First Name Customer's first name

Last Name Customer's last name

User Name The login user name credentials for the user. If this is imported via LDAP or Active Directory, it can not be edited. Otherwise, enter a user name. Note that the value must be unique.

Password If you are using a directory service, then this is the customers normal login password.

If not, then the Default Password is set to the Customer's email address or a random string can be enabled by the Administrator

Web Access Web Access allows Customers to view their account information and Incidents via the Customer Portal

Email The Customer's email address. Messages are sent to

this addresses.

Organizational Units The Organizational Unit the Customer belongs to, most likely their department

Address 1 First line of Customer's address

Address 2 Second line of Customer's address

City Customer's city details

State Customer's State details. Options will be displayed for the State, once the Country is selected, if Regions are configured for the Country in the system

Zip/Postcode Customer's area code

Country Customer's country. The country selected will determine the time zone and state options for the Customer

Phone Enter phone details

Fax Enter the customer's fax number, if relevant

Pager Enter the customer's pager details, if relevant

Mobile A mobile number can be entered as a contact number or for use with SMS (Short Mail Service message)

Timezone The customer automatically adopts the default time zone set for the system. However, the time zone can be manually adjusted here for the specific customer

(27)

The minimum amount of information that you need for each customer is a subset of what is in the table:  First name  Last name  User name  Email

The more information that it is practical to collect, the better the customer profile will be. This is very useful customers contact service desk.

3.3 What Do Customers Need Support For?

Novell Service Desk has a centralized Configuration Management Database (CMDB) to manage and control infrastructure information. At the simplest level the CMDB can be used to store hardware, software and document asset details. At its most complex, the CMDB can be configured as an enterprise wide IT business service catalogue defining business services and the supporting infrastructure. Essentially, it's a list of 'stuff' to be supported and (potentially) relationships to each other.

Each department or group that you will be meeting will have items that they want supporting. To help focus these meetings, prepare a list of your own based on I.T understanding of the current environment. This should be at a high level looking at categories of items rather than specifics e.g Desktops, Laptops, Desktop applications, Printers etc.. You then can put specific items under each category and add additional categories if needed.

Novell Service Desk already has a number of categories defined which can be used as a starting point.

Last Login Auto-populated with the date the Customer last logged into the system

(28)

A good place to look for items to put onto the list is a configuration management tool such as Novell ZENworks Configuration Management. You can use this to audit your environment and then generate a report to help create the initial list.

After the initial set of meetings, you should end up with a list similar to the example below:

There will be items that the business is not aware of, but I.T are. An example of this would be backups. Make sure that you add these.

Category Item Department Description

Hardware Lenovo W500 Sales Standard laptop used by

sales teams

Hardware Dell R710 I.T ACME corporate standard

server

Printers HP LaserJet P4015DN Marketing Marketing department printer

Software Salesforce Sales , Marketing, Corporate

Company wide CRM system

Software Email All Company wide email

(29)

3.4 What Types of Requests Will Customers Make?

As you create the list of 'stuff' (any ITIL person is going to cringe every time we use that term - which is fine ) then you need to understand what type of request may be made against it. This will help determine what the service desk will be expected to deliver although you may choose not to service certain types of request immediately or not at all. ITIL ( I.T Infrastructure Library ) comes in handy at this point as it offers classifications for requests that can be made to the service desk.

Novell Service Desk also uses the same terminology. Here they are:

 Service Request: A request from a customer for information, advice, standard change or for access to an IT Service. For example, how to create a table in MS Word or can application X be installed. Alternatively look at Service Requests as being “Everything is working fine, I just want something”. The difference between Service Request vs Incident is a long running debate. We would advise that you treat everything as an Incident to begin with and then see if Service Request will add value in the future.

 Incident: An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. For example Blue Screen of Death on a Windows device. We like to think of Incident simply meaning “X is no longer working”.

 Change: The addition, modification or removal of anything that could have an effect on IT Services. For example, adding more memory to server or an application installation. Changes might require authorization from one or more people.

Adding this to our previous example of 'stuff' to support gives this:

Category Item Request Department Description

Hardware Lenovo W500 Incident Sales Standard laptop

used by sales teams

Hardware Dell R710 Incident, Change I.T ACME corporate

standard server. Changes will require approval

Printers HP LaserJet P4015DN

Incident Marketing Marketing department printer

Software Salesforce Incident, Change Sales, Marketing, Corporate Company wide CRM. System. Changes would be user addition, changes to rights, and deletion. All require approval

Software Email Incident, Change All Changes would be

user addition / deletion, Mailbox size increase, access to other users mailboxes.

(30)

3.5 What Response Are Customers Expecting?

Service Level Agreements ( SLA ) define response times. Typically a SLA will vary depending on what the request is for and the type of request. A SLA will also define the hours for which support is being provided. For example a printer running out of toner will have a low priority as opposed to the order processing application. The printer will only be supported 8 x 5 where as the order processing application will be supported 24 x 7.

Novell Service Desk always uses a SLA (Service Level Agreement) against every request. This is a time period in which the Support function should resolve the incoming request and will be active during certain hours. It is also possible to break the SLA down further into periods in which the request should be initially responded to and a workaround given within the overall resolution time period.

Priorities determine the response, restoration and resolution time. You will need to choose what time periods makes sense based on the priority. Example: SLA for normal business activities, active Monday to Friday, 9 to 5.

Here's some guidance to help sort what type of request should fall into a particular priority category.  Urgent:

Prevents the effective use of any major service.Seriously affects a substantial number of

computer users. In the opinion of the IT Help Desk Supervisor/Manager, is serious and requires immediate attention.

Example: EMail server failure.  High:

Prevents the effective use of any service and affects a substantial number of computer users. Causes inconvenience to a substantial number of computer users. Has very serious implications for an individual user. In the opinion of the IT Help Desk Supervisor/Manager, warrants this priority

Example: Printer not working that affects many users without alternative printer available.  Medium

Prevents the use of any fully supported service by an individual. Causes inconvenience to a small number of computer users. Affects an individual user, who does not know how to proceed in a fully supported application.

Example: A single customer cannot print.  Low:

Causes inconvenience to an individual.

Example: A user who wants to format a Word document in a particular way, for purely aesthetic reasons.

Priority Response Restoration Resolution

Urgent 1 hour 2 hours 5 hours

High 8 hours N/A 24 hours

Medium 16 hours N/A 40 hours

(31)

When this question of response times comes up in your meetings, the standard answer from your customers will be “Now” or in some cases “Yesterday”. You need to come prepared with an initial set of very generous SLAs along with guidance notes as to place 'stuff' into each SLA and priority. Example SLAs

Name: 8 x 5

Description: 'stuff' used during Monday to Friday , 9am to 5pm.

Name: 8 x 7

Description: 'stuff' used every day of the week, 9am to 5pm

Name: 24 x 7

Description: 'stuff' that is used 24 hours a day, every day

Record the desired SLA in your list of 'stuff' to support. Carrying on with our example and with the previously mentioned SLAs, we now

have:-Priority Response Restoration Resolution

Low 40 hours N/A 160 hours

(32)

3.6 Who Are The Support Staff?

In similar way to when you created customers and their profiles, we need to perform the same process for our support staff.

With the I.T department create a list of people who are involved in running the I.T systems that the business relies on.

The minimum amount of information that you need for each member of the support staff is:  First name

 Last name  User name  Email

3.7 What Can The Staff Support?

You already have a list of 'stuff' that the business is asking to be supported. Rationalise this list so that all duplicates are removed. Now you need to discuss with the support staff what skills they have. You should create a list showing each support staff with the 'stuff' they can support.

Hardware Dell R710 Incident

Change

24 x7 I.T ACME corporate

standard server. Changes will require approval

Printers HP LaserJet P4015DN

Incident 8 x 5 Marketing Marketing department printer

Software Salesforce Incident

Change 24 x 7 Sales, Marketing, Corporate Company wide CRM. System. Changes would be user addition, changes to rights, and deletion. All require approval.

Software Email Incident

Change 24 x 7 8 x 7 All Email is supported 24 x 7. However changes would only be actioned during business hours

(33)

When compared with what the business is asking for, it is likely that there will be differences. Investigate how these gaps can be filled and the cost of doing so. For example, online training can be used to skill up support staff. Put those items on the exception list for discussion.

3.8 What Types of Requests Can the Staff Handle?

In the discussions with the business, you covered what type of request that they would make at a high level. Possible candidates were Service Request, Incident and Change. There are more processes that the service desk can perform such as Problem Management where historical incident data is analysed to determine any underlying cause. For now, we are focusing on customer facing ones. Here are the definitions again:

 Service Request: A request from a customer for information, advice, standard change or for access to an IT Service.

 Incident: n unplanned interruption to an IT Service or a reduction in the Quality of an IT Service.

 Change: The addition, modification or removal of anything that could have an effect on IT Services.

A good starting point as to what requests to handle is Incident, followed by Change and then Service Requests.

At this point in time we are designing how these requests will function, merely if we should be doing

Support staff Category Item

Keith Richards Richard Jones Ron Hipcock Hardware Lenovo W500 Robert Miller Daniel Porter Hardware Dell R710 Keith Richards Richard Jones Ron Hipcock Printers HP LaserJet P4015DN Keith Richards Richard Jones Ron Hipcock Software Salesforce Robert Miller Daniel Porter Software Email

(34)

3.9 What Response Can the Staff Provide?

Traditionally managers determine SLAs in terms of time. That is, managers estimate how long they anticipate certain tasks will take in order to deal with a request. This is problematic as it's not the manager performing the tasks and they always tend to be optimistic at best.

We going to recommend a considerably different approach to determining times. First of all, a request may require work from an entire team not just an individual. Philosophically, this places an emphasis on collective effort. Second, we need to acknowledge that each request will have a certain degree of difficulty and effort to resolve. This is a major break from traditional methods: Instead of a manager estimating on behalf of other individuals and assigning SLA times based on conjecture, team members will use effort and degree of difficulty to estimate their own work.

In the response meeting, support staff sit down to estimate SLA times for each of priorities (Critical, High, Medium and Low ). For each of the priorities, use example requests to help determine what the

Service Request:  To provide a channel for users to request and receive standard services for which a pre-defined approval and qualification process exists

 To provide information to users and customers about the availability of services and the procedure for obtaining them

 To source and deliver the components of requested standard services (e.g. licences and software media)

 To assist with general information, complaints or comments

Incident:  Incident detection and recording

 Initial user support by the single point of contact (service desk)

 Investigation and diagnosis

 Resolution and recovery of service

 Incident closure

 Incident ownership, monitoring, and communication

Change:  Record requests for change

 Change logging

 Review the request for change

 Assess and evaluate the change

 Evaluation of change

 Allocation of priorities

 Change planning and scheduling

 Authorizing the change

 Coordinating change implementation

(35)

team members disclose their estimates simultaneously. When it comes to estimates, give the support staff a series of numbers that represent the time to choose from e.g Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.) Because individuals “show their hands” at once, this process is not unlike a game of poker. Some support staff have even developed their own decks of playing cards expressly for this process.

The support staff also needs to estimate how often they can meet a SLA. There will be times when regardless of the effort and dedication involved, times will be missed. Standard practice is to say that a SLA will be met a certain percentage over a set period of time e.g SLA x will be achieve 80% of the time during a six month window.

To arrive at a single SLA estimation that reflects the entire team’s sense of a requests difficulty, it often requires numerous rounds of estimation. Another output of these meetings is the justification behind them.

3.10 What Metrics Will Be Used?

Above all else, remember why we produce management reports and identify key performance metrics.

“To enable stakeholders involved in IT service management to make informed, rational decisions about the IT services and support offered to customers”.

Starting from this premise, some of this data is going to be more important to us than the rest. We will refer to the data which is important to us as Key Performance Data.

Your own choice of what is Key Performance Data should be influenced by:  The challenges you face in delivering IT services to customers

 The demands made of the IT Service Management function by stakeholders  The intended use of the reports

 Audience of the reports

For instance, you may provide an E-mail system and your organization requires the SLA to be met 90% of the time. In this case, it would make sense to include SLA target achievement data as part of the Key Performance Data.

At first glance, it might seem that identifying your Key Performance Data is a very difficult task, particularly as there will be a lot data to use in reports. To help, we are going to classify performance data into the requests types that we have used previously, those of Service Request, Incident and Change. In each case, you need to have a clear idea of what the data might tell you about the services you are providing to customers.

Service Request:

 The total number of service requests (for trend analysis)

 The breakdown of service requests at each stage (e.g. logged, work in progress, closed, etc.)  The size of the current backlog of outstanding service requests

(36)

 Show the average length of time taken to resolve incidents before and after implementing incident management

 Where possible, show the types of incident reported

 Show the percentage of incidents handled within the agreed response time

 Show the percentage of incidents closed by the service desk without the need for contacting technical support

 Show the number and percentage of incidents resolved remotely, without the need for a visit

Change:

 The number of changes implemented to services which met the customer’s agreed requirements, e.g. quality/ cost/time (expressed as a percentage of all changes)

 Reduction in the number of disruptions to services, defects and rework caused by inaccurate specification, poor or incomplete impact assessment of changes Reduction in the number of unauthorised changes

 Reduction in the number and percentage of unplanned changes and emergency fixes  Change success rate (percentage of changes deemed successful at review/number of RFCs

approved)

 Reduction in the number of changes where remediation is invoked  Reduction in the number of failed changes

 Average time to implement based on urgency/priority/change type  Incidents attributable to changes

 Percentage accuracy in change estimate

Along with metrics for each of these areas, you should also consider measuring the satisfaction of your customers that interact with the service desk. This is an area this is frequently overlooked but carries substantial value.

A good approach to measure customer satisfaction is case-by-case surveying. Each time a case is closed, which means the request has been resolved and the resolution has already been

communicated to the applicant, a short survey on the case is sent to the customer.

With the following example survey you might want to add options such as very satisfied, somewhat satisfied, somewhat dissatisfied and very dissatisfied. Do not use “NA” or “neutral”.

 Speed of response

 Was your question answered in full?  Knowledge of staff

 Ability for help desk to diagnose the problem quickly  Helpfulness of staff

 Professionalism of staff

 Ability to get through to a staff member promptly  Time to solve problem

 Kept informed of the progress of your ticket  Ease of opening your help desk ticket

You then might want an open ended question about how your customer sees how you could improve your overall service or anything else they may want to add.

(37)

Service Desk Proposal

Now it's time to bring together what the business has asked for, what I.T is capable of delivering, any gaps that exist and metrics to demonstrate delivery. This will then be discussed with the key

stakeholders that you have been meeting with to obtain alignment. Adjustments may need to be made to the proposal before alignment will be obtained. It is vital than any adjustment and the reason for it is recorded. More than one meeting may be necessary.

The proposal should cover:

 Who will be supported within the business: Departmental level, don't go down the level of individuals

 What will be supported: Categories and types of item e.g Laptops, Desktops, MS Office etc. Break out by department if needed

 What requests will be covered: Service Requests, Incidents , Changes Illustrate with examples for each type of request

 What response will be given: Baseline is SLA by categories and types Exceptions for certain departments and individuals

 What metrics will be used: The list of metrics that will indicate success

Depending on your organisation, the proposal can be a slide presentation or a more formal document. For either case make sure that you make it readable for the intended audience.

Service Desk Charter

Now that the proposal has been accepted you should create a Service Desk Charter. We would suggest that you obtain signatures from senior IT and business management to help give it authority within your organization and also make it visible to the greater organization e.g publish on your internal website.

It servers two main purposes:

 It lets your customers know what to expect  It lets you know what your goals are

This should not been seen as a something that is fixed in stone. You will need to revisit on a regular basis with your organization to make sure that these are what they require. Here's an example:

 To enable incidents and requests to be dealt with quickly and effectively.  To ensure that an incident only requires reporting once.

 To ensure that those providing technical support understand the details to enable them to resolve incidents as quickly as possible.

 To provide a system that is up and running, even if only a temporary repair, but to ensure it is fixed completely within a specified time.

 To get best value for money from those providing technical support by providing good quality information about incidents and requests.

(38)

System Planning, Deployment, and Best Practices Guide