SUBMIT QUALITY WORK AFTER 24 HOURS ONLY.
marlenepetreaus931
chapter_21_2.docxWHAT IS SERVICE MANAGEMENT?
In an ideal world, the best-serviced customer is one who receives no service, assuming that the IT infrastructure and systems are seamless, fault free, and high performing. The next best option is where the faults are auto-corrected or a method exists where there is self-sufficiency and customers are IT aware and can resolve problems independent of the service desk. This is probably the reality that most CIOs dream of, but it is certainly a difficult goal to accomplish.
The process of effectively submitting, assigning, approving, solution provision (or resolving), and closure of a request coming into an IT organization can be called service management. How effective efforts are depends on the standards of a given organization and the criticality of the service delivery process in line with the organization's business needs. Most organizations measure service on the basis of critical parameters such as call volumes, handle time, resolution rate, and FCR. Other organizations use pure customer experience as the only performance measure. In reality, it is best to strike a balance between service desk measurement parameters and customer experiences.
The service desk serves as a single point of contact for users across all supported locations for all IT-related incidents, service requests, problem management, and change orders. IT customers typically use one of these channels to log their incidents or support requests:
· Self-service incident-logging e-mail tool
· Telephone call (typically a single internal number across geographies)
· Walk-in (in the case either of the other two options are not possible)
In the introductory paragraph, we mentioned that a lot of best practice scenario and details can be obtained from documented standards. As a result, here we focus on idiosyncrasies with service delivery, pragmatic understanding of real-life scenarios, and how organizations tackle the constant pressures from process management, cost optimization, and customer experience.
For the purpose of simplification, we use the terms service desk tickets and service desk calls interchangeably. It is of utmost importance to ensure that first-level ticket-handling staff members are IT generalists with operational awareness and good communication skills. We strongly emphasize communication skills in order to build a strong, centrally operating global desk. Later in the chapter, we touch on the challenges of dealing with an outsourced and/or remote service desk. With strong IT and communication skills, you will build a greater ability to resolve the call in the first attempt. If it is not resolved, you will ensure that the call is assigned to the right second-level (L2) support staff. Some organizations call the first-level staff L1 and others call them coordinators. Organizations striving for quick turnarounds and higher FCR rates tend to build technically competent L1 support models. The FCR rate of calls attended by L1 will be higher if those calls are relatively simple and routine, such as password resets. Chances of resolution during the first contact with IT have improved over time, based on some of these changes in support models:
· Evolution of technology has made it possible for the L1 staff to access end user workstations remotely and increase the FCR rate.
· Increased sophistication in knowledge management and self-service tools also increases the ability of end users to solve basic IT requests on their own. This does not necessarily increase the FCR. However, it does reduce the need to call for IT assistance in the first place.
· Categorization of tickets by the call coordinators along with an assurance that all pertinent request data are collected up front results in a faster turnaround time.
Figure 21.2 is a graphic representation of one support model that may be employed.
Figure 21.2: Service Management
Once the call has been logged, if it is not resolved by the front-end L1 staff, it needs redirection. Redirection to specialist groups (L2) within the service desk or specialist groups (L3) outside in other departments, such as information security, server infrastructure, or network teams, can be challenging.
Some organizations prefer to have multiskilled L2 specialists within the service desk; others prefer to have L2 specialists purely for services like access provisioning or remote connectivity. In some cases, the L2 layer is relatively thin, and many of these requests are passed on to L3 resources in other departments.
Having a larger L2 population within the service desk can be cost prohibitive. Also, having all access rights for troubleshooting and resolution of tickets may not be possible. As a result, some service requests must be assigned to L3 groups. This certainly impacts on resolution time, as calls are now assigned to other departments.
L3 assignments and resolution depend on two critical factors:
1. The assignment of calls to the correct resolving groups requires L1 and L2 staff with strong technology and business acumen.
2. The operating-level agreements (OLAs) between the specialist delivery organizations and the service desk have to be very strong. A typical service-level agreement is set between the service desk and the customer groups to which the service is provided; OLAs exist between the service desk and the specialist departments that are internal to the IT organization.
Service delivery organizations strive for a high FCR rate. FCR is measured as a percentage of calls resolved by L1 staff during the first contact compared to the total calls resolved by the service desk in a given period of time.
Measuring resolution time also requires effective tracking of call status. Resolution time is a typical measure of time difference between the time the service was requested and the resolution is provided, minus all the hold time required to obtain pertinent details from the requesting customers.
Modern-day service desk automation systems send out resolution messages (e-mail, Web, or text message-based update) to the serviced customers followed by an acknowledgment from the customers back into IT. The acknowledgment of resolution by end user customers moves a call from Resolved to Closure state.
We touched on what it takes to create a ticket, assign the ticket to various resolving groups, resolve the ticket, and close the ticket with customers. In the next sections, we review other elements of service delivery like call management, service catalog, knowledge management, and asset management.
Service requests for password or user management can be managed either using a self-service mechanism or some degree of automation based on employee events. For example, creation of accounts for new hires, closing accounts for terminated employees, and changing access privileges based on job changes are closely tied with the human resources (HR) system. The changes in the HR system should be recognized automatically to ensure quick changes in account privileges. Other service requests that do not require special handling by the L3 organization can be managed within the service desk, and ones that require changes to the infrastructure, such as firewall configurations, network changes, and application changes, are redirected to other support groups.
Categorization of a ticket as a service request or an incident should be managed by the call-handing staff. IT incidents impacting wider customer population often result in a lot of tickets (calls) created for the same problem. Management and closure of these issues can be expensive if not handled appropriately. In such cases, all the individual tickets need to be treated as child tickets and should be closed with a cross-reference to a single parent ticket. The parent ticket typically must be addressed by a specialty L3 organization followed by a root cause analysis of the issue and an update to the knowledge base with relevant resolution details. In addition, in order to reduce the calls coming into the service desk, these situations require a broadcast knowledge of the current situation. Alerts can be provided on plasma screens, dashboards, intranets (web sites), e-mails, and text messages based on the nature of the problem and the organization's approach in communicating such alerts. Also, if these issues are related to outages in the systems or the network, they require close looping with the support organization. There must be a cumulative accounting of outages and assurance that operational-level agreements are managed with supporting functions using these details. In many cases, the problems might not be outages. They can be degradations in system performance from increased usage, increased transactions, or other limitations with infrastructure horsepower or network bandwidth. Issues like these also require close looping with the supporting organizations to track root causes and assessment for ramping up of network bandwidth or infrastructure capacity.
In simple terms, service catalog management is a menu or catalog of services provided by the IT department. It essentially captures different services, categories, approval details, cost information (if applicable), and expected turnaround time for resolution or service. Turnaround time is one of the critical performance parameters for the service delivery organization. It is published to customers being serviced and tightly coupled with the service desk processes and OLAs with other delivery organizations. A typical list of services is illustrated in Table 21.1. A sample entry for e-mail service in the service catalog is illustrated in Table 21.2.
|
Table 21.1: Typical List of Services Open table as spreadsheet |
||
|
Service Type |
Provisioning Medium and Processes |
Measurement |
|
Communication |
Mail, messenger, and broadcast services |
Uptime, capacity, and performance |
|
Desktop management |
Configuration and upkeep of standard workstation image |
Patching, compliance and performance |
|
Productivity tools |
Document, spreadsheet, presentation, and process management tools |
Patching, integration, and performance |
|
Network access |
Access to organization's systems over local, metropolitan, and wide area networks |
Uptime and performance |
|
Remote access |
Remote access mechanism for troubleshooting, knowledge sharing, and presentation |
Authorization, authentication, and availability |
|
Internet/intranet |
Restricted and unrestricted access to authenticated and white-listed domains inside and outside of the organization |
Uptime and performance |
|
Identity and access management |
Managing users, their profiles, personalization, and ease of access to business systems through single-sign-on configuration |
Authorization, authentication, availability, and self-service |
|
Threat management |
Protecting business systems from vulnerabilities and attacks |
Infections, threats, vulnerabilities, patching, and compliance |
|
Backups and archiving |
Ensuring high availability of information from disasters and data losses |
Backup success, recoverability, and restoration |
|
Table 21.2: Sample Entry for E-mail Service in the Service Catalog Open table as spreadsheet |
|
|
Service Name |
|
|
Service Availability |
24 hours/7 days a week |
|
Eligibility |
Full-time employees and authorized contractors, standard desktop access, andactive employment status on corporate HR management system |
|
Service Creation |
Automatic creation on the basis of employment entry and inactivation upon termination of employment services as recorded in the HR management system |
|
Service Support |
Service desk through published contact mechanisms |
|
Cost |
Charge-back component of IT services |
|
Service Availability |
99.9% excluding scheduled outages every other Saturday from 12 midnight until 3 a.m. |
|
|
Account creation and updates within 48 hours of employment status changes |
|
|
Quota/capacity based on designation and specialized needs |
|
|
Restoration based on severity of outages |
Other services provided in the catalog can include extension to the basic IT services, such as application services (support processes for enterprise resource planning and customer relationship management systems) and specialized services for projects and technology architecture management.
Service desk knowledge is not the same as process expertise within L3 groups. Service desk knowledge is built, managed, and accessed using a knowledge database. This database can be a simple collection of files, a repository on the intranet, or a systematic solution that provides a database of known issues/problems along with the resolution steps describing underlying actions. These knowledge tools provide details on IT issues along with resolutions. Organizations seeking customer excellence and process optimization tend to implement high-end knowledge management solutions. Organizations that have cost as the primary driver build rudimentary knowledge bases that are hosted on their intranet.
Sophisticated knowledge management solutions allow creation of structured knowledge with an easy-to-use unstructured search mechanism for service desk staff or end users. In most cases, resolution process/documentation is a narrative presentation that allows easy-to-follow step-by-step instructions for resolution.
Whether a knowledge management solution is bought or a rudimentary knowledge base is built in-house, service desk performance will depend on how the knowledge is maintained in the system. Every time a new call type is logged and resolved, it is imperative that the new knowledge (resolution) is incrementally added to this repository. This discipline will positively impact long-term resolution rates (FCR) and will ease the analysis of root causes.
Many service requests result in allocation of assets to end users in the form of software or hardware. It is essential that when IT analysts serve these requests there is a close tie-in with the software and hardware inventory management. The inventory will certainly tie into the organization's security, data protection, software compliance, and audit policies. Also, it is relatively easy to track and manage inventory of hardware resources as they are physically allocated. If these are devices connected on the network, inventory and desktop management software solutions can easily account for these resources and help you update the inventory automatically. In the case of software installation on desktops, installed units can be maintained as part of the inventory, and new installations can be made using centralized desktop management software with a push mechanism. Desktop management solutions can actually record the number of available licensed software units, track the number of installed software units, and appropriately lock from deployment unauthorized or unlicensed installations. Automating these inventory details improves accuracy of information, reduces the effort required from HR, and protects the organization from licensing violations.
Asset inventory can be managed through a sophisticated asset management tool or a simplified list of assets in the inventory. A typical asset inventory would capture these details:
· Asset identification number (internal to organization)
· Asset name and description
· Asset type (software, desktop, server, etc.)
· Asset location and assigned to user
· Manufacturer's serial number
· Asset make
· Asset model (if applicable)
· License key required
· Asset purchase date
· Asset install date
· Warranty/maintenance period
