Click on our Sponsors to help Support SunWorld
Realworld

Cut workplace frustration -- take these steps to build an efficient help desk

We show you how to implement an effective support center through the lessons learned at one company

SunWorld
April  1997
[Next story]
[Table of Contents]
[Search]
Subscribe to SunWorld, it's free!
Abstract
The support center (a.k.a. the help desk) is rapidly evolving to meet the challenges of client/server computing. In many organizations, the support center is being integrated with network managers, systems administrators, and application architects. Here's how one company evolved its workflow to meet the challenges of distributed computing. (1,700 words)


Mail this
article to
a friend

With the exception of air traffic controllers, the greatest workplace stress involves the brave individuals who handle support centers at large corporations. Because upper management has failed to understand the support requirements of client/server computing, help desks often have the following task:

"Hello, may I help you?"

"I hope so. I can't log onto the Teradata server and can't access the market data I need for a meeting in two minutes."

Meanwhile, the help desk operator is looking at a 3270 InfoMan screen that does not know the end-user workstation type or the software configuration, and does not have a diagram of the network between the end user and the Teradata database server. Even with a great crystal ball, the chances of isolating the problem are almost nil.

Getting your requirements in order
Trouble tracking systems should be at the heart of the support paradigm for any operational model. Whether the systems are mainframe centric, LAN centric, or based on distributing systems, the health and well being of the systems and interconnecting networks need to be linked to a common operational support structure. The days of isolated trouble tracking systems targeted at particular enclaves of technology are over. Mainframes are now linked to LANs that are linked to distributed client/server systems and ultimately tied to end-user workstations. To support this collective continuum of systems and networks, the support center trouble tracking system needs to be linked to enterprise management systems and designed in a tiered fashion to allow for expeditious problem resolution.

One of our clients, "Enterprise A," decided to integrate network and systems management tools with a help desk package. It also wanted to develop better online and Web reporting to ensure that users could track Service Level Agreements (SLAs).

Our company began by working with the help desk administrator to review the SLA and determine the toolsets and staffing required to meet the agreement. The company had installed Hewlett-Packard OpenView, Cisco Works, HP NetMetrix, and Tivoli's Tivoli Management Environment (TME).

The customer had been using InfoMan for seven years. While InfoMan had a productive life, it required a great deal of customization and had very limited reporting options. In addition, Enterprise A had moved to a distributed computing environment and wanted to move mainframe tools to client/server platforms when possible.

Enterprise A had these additional requirements:

Advertisements

It's the process, process, process
We have, on occasion, been accused of concentrating too much on technical issues. However, we have built many support systems and analyzed hundreds of systems. We have seen poor management toolsets successful with good people and excellent processes, but we have never seen great management platforms compensate for poor processes. In Machiavellian terms, technology is but a means to an end.

It is crucial to take the time to develop a thorough operational workflow. When developing a new operational workflow, focus on business structures like service-level objectives and operational support organizations first. Don't be afraid to make changes to existing operational structures to fit the new workflow model.

When building a support center system the operational support structure must be viewed from a top down model. An assessment of existing operational personnel, support processes, organizations, and tools must be surveyed. With a starting point well defined, business functional objectives behind the operational support model must then be identified and prioritized. Tying the business needs to the help desk process is a good way to both ensure that end business goals are being served and that justification for system expenditures are well founded.

Armed with agreed upon business objects, the systems designers will need to perform an operational workflow analysis, evaluate and select a trouble tracking package, identify automated networked systems management interface points, and articulate a tiered support model.

By processes, we are talking about the discipline of problem determination. How are support personnel distributed among first tier, second tier, and third tier support? What skillset mix (Microsoft office, custom applications, networking, etc.) do the different levels need? When are problems escalated? Who is responsible for setting SLAs and providing reports to confirm compliance with service-level objectives?

The problem resolution processes should be tied to established service-level objectives in order to ensure that "blackholing" does not occur. "Blackholing" means diving into the minutia before classifying the problem type from a high-level perspective. This type of operational problem resolution technique typically consumes large amounts of time and resources and delivers poor results.

Tracking trouble
In setting up a tiered trouble tacking system, you should establish these requirements:

High-level health and service assessment:

Second-tier problem resolution:

Third-tier detailed troubleshooting:

Service levels should be based on end-user criteria (Sybase servers must be available 157-plus hours per month from 8:30 a.m. to 4:30 p.m.) They must be specific, and they must be granular (not all IS resources are mission critical). Usually, availability is defined as mean time between failure (MTBF) and the mean time to repair (MTTR) of a device. The equation for availability is:
A% = (MTBF)/MTBF + MTTR x 100.

Choosing the right support center tools
Through the Tivoli event adapters, HP OpenView and NetMetrix events were being forwarded to Tivoli's Tivoli Enterprise Console (TEC). The network and systems administrators of Enterprise A and our firm defined which events would trigger the creation of trouble tickets within the help desk system. Tivoli provides a bi-directional interface to Remedy's Action Request System which allows tickets to be automatically created and modified from the TEC console and allows Remedy help desk administrators to view the Tivoli console to forward information to relevant network and systems support personnel.

OpenView had a crude e-mail interface with the Remedy 2.x product, so we consequently decided to integrate OpenView with Tivoli (via an event adapter) and to utilize the more functional Tivoli/Remedy interface. The Remedy 3.0 product replaces e-mail with a forwarding mechanism based on the trapd daemon as a series of event forwarding processes.

Trouble ticketing selection
Based on the requirements of Enterprise A and the critical importance of a solid workflow, we chose Remedy Action Request System (ARS). Remedy supplies sample workflow schemas for simplified notification and escalation, but the requirements of the customer (a PC does not operate properly, and therefore the systems should contact the individual (or individuals) most familiar with PC hardware and contact their beeper) made custom development a requirement.

The custom development necessitated design of the schemas (such as help desk, assignee, etc.) and even writing to some of the APIs. One of Remedy's weaknesses (partially addressed by its new 3.x release) is the lack of integration of the schemas with backend databases (such as Sybase or Oracle) to provide multiple joins across schemas and ensure data integrity. To avoid corrupted data, careful coding and quality and assurance are required.

As mentioned, the bi-directional linkages of Tivoli and Remedy allowed the help desk operators and systems staff to share information and quickly escalate or reassign problems to the appropriate personnel.

The Remedy ARS system was deployed on a single Unix server which provides support for approximately 2,000 users and a support staff of sixty individuals located at six separate locations. Remedy has added a distributed server option which allows the system to run on an independent process from the report generation module. Enterprise A required client support for Macintosh and Windows for its support staff. Remedy's Web interface was deployed to provide platform-independent access to relevant service-level metrics.

Because of Remedy's robust marketshare, there are many interesting third-party applications that can be integrated into the Remedy schemas. For instance, since Microsoft is the dominant desktop, there are knowledge packages, such as KnowledgeBroker or ServiceWare, that can address common problems in Microsoft Office, Novell NetWare, and other packages.

The outstanding requirement for problem determination is event correlation. Help desks and management platforms receive scores of data and events which may be problems or are merely passing phenomena on the network. Seagate's NerveCenter and especially Systems Management ARTS (SMARTS) InCharge have the ability to correlate data from multiple sources and deliver information which can provide proactive analysis of systems faults. Without event correlation, life itself would be impossible. We will look at this topic in an upcoming column.

There are many other trouble ticketing applications on the market. Computer Associates acquired the Legent Paradigm product, and it has detailed problem determination logic that may or may not be appropriate to your support process design. Prolin's Pro/Helpdesk features a powerful Oracle backend and offers a great deal of scalability, but it does not readily facilitate schema changes. Clarify and Vantive have excellent client/server environments and are in the process of developing interfaces to the leading network and systems management platforms.


Click on our Sponsors to help Support SunWorld

Resources

About the author
Frank Henderson is chief technology officer at The Netplex Group. His expertise is in designing and installing networks and reengineering help desks, and in ORB, distributed databases, and network management. Dave Koehler is director of network strategies at The Netplex Group. He has 13 years experience in distributed network design. Koehler has written for several journals, and has delivered papers at ComNet, IEEE, and SunWorld Expo. Reach Frank Henderson at frank.henderson@sunworld.com and Dave Koehler at dave.koehler@sunworld.com.

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
 -Too long
-Just right
-Too short
 -Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Subscribe to SunWorld, it's free! 		[Search]
Feedback 		[Next story]
Sun's Site

[(c) Copyright Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-04-1997/swol-04-realworld.html
Last modified: