Saturday, March 6, 2010

Critical Principles In Establishing A Support Structure


Jack Dikian

ABSTRACT

Media Lab Pacific

June, 1984

Among the many services a typical Support Centre provides to its client base, perhaps the ability to maintain control over the many unresolved or pending tasks is .the most important. A typical Support Centre facilitating a medium sized computer supplier can handle hundreds of queries a day. The type and complexity of the queries can vary greatly. As platforms become more and more compatible, not only does the variety of tools and packages increase, but the source of those tools and packages become increasingly diverse. Good examples of this are apparent in the Unix and DOS environments. These days, both environments promote a great degree of compatibility; exhibit a large variety of readily available software solutions, as well as fostering the proliferation of independent software developers competing to sell the perfect accounting system, the fastest DBMS, and even the trickiest adventure game. All of this can of course be contrasted against a less open system such as the proprietary operating systems. Here, major tools and packages are often written in close collaboration with the original platform manufacture. Providing support in an open environment may in some cases require a Support Centre to be many things to many people. A well thought out support strategy aided by a comprehensive task tracking system can make the difference between an effective support unit and one that is pure hindrance to all parties concerned. This paper presents what I consider important when setting up a formal Support Centre in an open environment, as well providing some design ideas for a productive task tracking system.

1. Introduction

A Support Centre is usually that part of the overall EDP effort that attempts to answer queries and/or coordinates the resolution of problems that clients experience while using a particular system. The support effort, philosophy, and practice can span between two functionally varying extremes. At one end of this spectrum, the Support Centre and its personnel can be extremely specialised and thus attempt to provide the same sort of client support as that expected directly from back room technicians. On the other hand, the Support Centre may be setup such that it caters for a much broader, and hence more general client base. At Media-Lab Pacific a less technical support team is supported by a more rigorous system of call recording, problem escalation, task distribution, and follow up strategy. Factors which often determine the type of support that will be provided out of a formal Support Centre include the following considerations:

  • The variation products to be supported.
  • The stability of the target environment.
  • The standard of service expected from the support team.
  • The size of the EDP team from which support is provided.

2. The Degree of Product Variety

Open environments such as Unix cater for, and encourage the proliferation of standard non-proprietary technologies. The number and variety of available packages and utilities can be astronomical. My latest copy of Sun Microsystems’ Catalyst (catalogue of third party hardware/software SPARCware solutions) lists more than 2000 products in 22 very broad categories. Silicon Graphics boasts a heafty 700 page Applications Directory. At a different level, most Unix systems come to us with at least three file backup mechanisms, two editors, two command line interpreters, and a host of vendor added features. One particular manufacturer even provides two flavours of Unix running on the same machine at the same time.

Although much of this type of variety comes about from a genuine need for a particular feature, there is nevertheless sufficient overlap and a great deal of inherent flexibility to allow the client to use any utility based almost entirely on preference alone. Back at home, things are not too much easier either. The PC industry has never been in a stronger position, providing great performance for value; a host of industry standard plug ins, migration paths, and a world of software.

The wide range of products are often indicative of the large number of independent vendors, all committed to making their goods available on these platforms. Whilst a suite of products written for one proprietary environment may feature common menu structures, file layouts, control files, naming conventions, and even consistent documentation, a series of products supplied by different vendors in an open environment will often possess no underlying uniformity. Contrast for example DEC’s VMS operating system against Unix. VMS, like Unix parades a large number of layered products. However, unlike Unix, layered products under VMS all exhibit the same underlying design philosophy. Control keys always represent similar actions, help files always display similar layouts, and error messages always have the same consistent format.

Each product in an open environment will require the same high level of technical training before it can be properly supported. In such an environment, a generalised type Support Centre is most effective. Personnel in this centre may have an overall systems, analytical and communication skills, but may lack the specific specialised product knowledge. There are simply too many products for any one individual to know well. In such an environment, the Support Centre acts as an interface between the client and other more specialist EDP groups. How this interfaces is likely to work is closely linked with factors contributing to the overall style of Support Centre. For example, the overall size of the EDP group, the size of the client base, agreed turnaround commitments, and the sophistication of task tracking system will often determine the interface mechanism.

3. The Stability of the Target Environment

The stability of the typical environment that requires support is a very important factor in determining the type of support expected from a Support Centre. Site instability may be inherent within a certain client group or may transcend them. In an environment which has just gone through a major systems conversion, upgrade or simply taken on new responsibilities, it is typical that that site will experience a period of instability. On the other hand, a software house involved in developing systems around products that you are supporting will seem in a sense always unstable. In the later case, queries will often be raised reflecting the need for more detailed specifications, reporting faults which may or may not be associated with your product, and importantly, the reporting of legitimate, but low level anomalies which get picked up due to the nature of this sort of work.

Both of these scenarios need to be addressed. These support requirements will inevitably exist in both open and proprietary environments. However, in an open environment, not only are there many more independent groups developing systems, but often, these groups will know as much about your product as your Support Centre personnel. This is especially true if the Support Centre is of a generalised type. Clients experiencing significant downtime due to various reasons including conversion processes, come closest to justifying the need to contact back room staff directly. It is also this very desire that raises the many concerns for the quality of support. Clients more often than not, always prefer to discuss their problems with back room personnel directly. However, there are just as many important arguments for clients to continue to address their problems through a centralised Support Centre. Many of these arguments are to do with a supplier providing a consistent level of support, as opposed to a see-sawing effort depending on the availability of key personnel (See figure 1). Figure 1 illustrates how the quality of support (*) can vary between two great extremes when the Support Centre is basing their support effort on key back room personnel. When these people are available, the support effort is at its peak. However, when they are unavailable, support effort is reduced to a minimum. The use of a more generalised support team (-) allows the Support team to provide a much more consistent support effort. It is neither as good as the back room personnel, nor as bad when they are not available. In time, this quality will rise. Providing consistent support, with an agreed service level come about most effectively through the implementation of service level agreements between yourself and the client base. The section discussing the standard of service expectation will further detail the implementation of service level agreements.

Fig. 1

In the situation where a client is going through a major conversion process, or where a major upgrade is to be released, the generalised Support Centre should be supplemented by back room technicians rather than be abandoned. The client should be encouraged to schedule the conversion process, as well as assisted in associated areas such as risk analysis, resource allocation, and contingency planning. Both the client and the supplier will only then really appreciate each others requirements. This liaison process will allow the Support Centre to prepare more adequately for this situation. Without this sort of preparation, the support personnel are, at best, most likely to allocate the highest possible priority available to them before escalating the query to a pool of back room personnel. The problem with this approach is of course that there may well be any number of such high priority requests already outstanding. Some suppliers nominate certain individuals to be responsible for the support of one or more clients. Account managers are usually very effective in providing a personalised style of support. They can become acquainted with the specific needs of the client, as well as develop an understanding for the longer term directions of the organisation. These people also represent the supplier and its resources. The negative aspects of this approach however are significant in an open environment. The main problem is once again availability. The greater the dependence on the one account representative, the more exposed both parties become.

Account managers also tend to have strong consulting, negotiating, or managerial skills. These qualities are very important when dealing with sites that feel undersold. At the end of the day however, hands on representation will still be required. Problems need not only be understood, but fixed in a timely manner.

4. The Standard of Service Expected from the Support Team

Often, the effectiveness of a Support Centre is erroneously measured by the quality of on the spot advice the support personnel can provide. For example, there is always a perception that a particular organisation has a good support operation if clients constantly receive informative advice immediately. On the other hand, giving the client a reference number with the promise that an expert will attend to their call as soon as possible raises, in some peoples’ minds, a certain amount of cynicism. There is simply no formal framework by which to gauge the effectiveness of the support in non-subjective terms. Questions like "Why can’t we talk to this expert direct...?", "why do we need to explain this problem all over again?" and so on are asked, and asked of the wrong people. This concern is accentuated when the overhead costs of maintaining the support effort are passed on to the client base. Soon, some clients will attempt to contact back room personnel directly, avoiding the so called front line. Clients who judge a Support Centre ineffective, fairly or otherwise will always attempt to bypass formal support structures. In general, clients believe that back room personnel are the ones who really understand the problem; they know the system and have the facilities to fix it. Everyone else, including the Support Centre are nothing more than "go betweens." To some extent, there is a lot of truth in this belief. Support consultants, specially in a help desk centre do not have the luxury to see the problem for themselves. They can only react to what the client thinks is seeing.

Often, if the Support Centre can’t resolve a problem over the phone, they are forced to escalate the task to someone who can. Back room personnel may be so familiar with particular anomalies that they will save the client the bother of describing peripheral, and in retrospect, unnecessary detail. Also, where a support consultant may tackle a new query by first examining a wide range of possible causes, a back room technical person, faced with the same task may grasp the kernel of the problem much quicker. The other side of the coin holds a different picture. It is also true that most back room guys do not want to be interrupted by users. Back room personnel can handle direct contacts in various, and in some cases undesirable ways. Perhaps the three most common reactions I have seen are:

They may refer the problem back to the Support Centre and hang up in the clients ear. This, as it turns out is probably the best course of action in the long run.

Secondly, they may promise the client prompt resolution knowing full well that they will neither have the time nor the inclination to carry it through.

Finally, they may well resolve the problem in a timely manner, but fail to inform the client, or their peers of the solution.

Back room personnel are never hired based on their diplomacy, communication, or even business skills, most of these people will call a spade a spade. This is regardless of who the caller may be and the sort of effort the sales team expended to secure them.

Back room personnel, the development team, systems managers, operators, DBA’s etc are highly paid professionals who, without stating the obvious, have a job to do. It’s simply not as if they are waiting around idle for someone to ring them with a problem. Often they are working against tight schedules, with priorities not including impromptu client requests. Often, what starts off as a very brief interruption may eventually result in a great deal of wasted time and resources. In the event that a problem has been accepted directly in such an environment, there is no real guarantee for effective follow up, no framework for providing a realistic turnaround time, or even a rudimentary concept of ownership.

So what is a fair expectation of a Support Centre, and what can a supplier do in terms of its support policy? The best way to avoid unreasonable client expectation is to tell them exactly what you will, and will not do. If the Support Centre is manned between the hours of 8:30am and 6:00pm, then the client should be made very aware that support is not available outside these hours. If the Support Centre is promising a maximum turnaround time of 3 hours for critical problems, then clients should be sold the support service based on this condition. With the same token, published support hours are required to be adhered to by the support personnel.

A support facility between 8:30am and 6:00pm means just that, and does not mean 8:45am to 6:15pm. Also, a promise of a 3 hour turnaround means that if an answer is not found within that time flame, then the client is informed, and a suitable alternative arrangement is made. The creation and regular maintenance of a standard service level agreement is not only a very effective method of making your position clear in terms of the support delivery, but it is also a vehicle by which the client can use to request certain specific functions. The implications of the service level agreement will drive the practice and policy of the support personnel. Once the Support Centre is comfortable with this agreement, every new client likely to use your support facility should understand and accept the terms and conditions of the agreement. In the event that a particular client has specific requirements outside the scope of the standard service level agreement, then a new agreement should be forged before formal support commences.

The new service level should be such that both parties feel comfortable with. It is no use for example the client requesting call back on reported faults within an hour when the Support Centre averages 2 day turnaround time. Ultimately, an attitude where the user pays should be employed. If a client has a need for 24 hour support, and your Support Centre only provides an 18 hour window, then the idea that the client pay for facilitating the expansion (should you agree) of the support window should not be discarded lightly. It is also important that the service level agreement is structured such that it complements the original maintenance or service warranty contract. The sort of elements in a typical service level agreement should include:

  • Support Centre hours.
  • Method of priority allocation.
  • The meaning of priorities and corresponding actions.
  • Escalation mechanism, and responsibility lines.
  • Forms of expected documentation.
  • Emergency arrangements.
  • Turnaround times for various types of situations.
  • Contact name nomination guidelines.
  • Support Centre responsibilities.
  • Problem status reporting procedures.

The presence of such a document takes away any misconceptions of the Support Centre’s role. It clearly identifies what the Support Centre will do, and how it will do it. Importantly, clients can compare how the Support Centre is performing against how they have formally committed to perform. Anomalies can be raised and resolution sought at the appropriate business level. This type of structure enforces accountability at all levels. What this understanding also does is throw back some responsibility on to the user of the Support Centre. In the same way that the client can highlight difficulties with the Support Centre, the Support Centre itself can rightly object to providing a support facility if the client is not upholding their end of the bargain.

For example, if the client has been asked to document a particular problem in accordance with the service level procedures, and have failed to do so, then the Support Centre can legitimately hold that query pending until the relevant documentation is supplied. The Size of the EDP Team from which Support is Provided In a very small EDP team comprising say of 15 members or less, it can be argued that there isn’t a large enough infrastructure to support a dedicated support group. However, as the EDP group grows, and the overall EDP effort divides into specific speciality areas such as R&D, business consulting, operations, and systems delivery, it becomes more and more apparent that a support type team is necessary. In some cases, this support team is a misnomer, and what the group really needs is an office administrator/telephonist/goofier. However, as the client base grows and their requirements become more sophisticated, a single contact point within the EDP group becomes unavoidable. This is the support team. Not only does the support team provide fault diagnostics and rectification, but also a host of many other functions.

For example, the support team can coordinate and follow up the resolution of queries within the EDP group. The Support Centre can act as an interface between the client and the supplier, as well as interface between the many sub groups within the EDP group (See Figure 2). Problem prioritisation, logging, and reporting is also something typically handled without a Support Centre. These functions help glue the overall EDP effort as well as streamline the many client requests. Importantly they free the other groups from continual client interruptions, and channel the filtered requests to the most appropriate people. The client on the other hand sees a single consistent face who is prepared to accept ownership of the problem until it is resolved.

In order for the Support Centre to maintain control over the many unresolved tasks, and also provide efficient call reporting and statistics facilities, a sophisticated task tracking or logging system is indispensable. The task tracking system should not be confused with a general task scheduling, or even an accounting system. Although both a scheduling and account charging system can be implemented underneath the task tracking system, in general, these modules should exist independently. The task tracking system should however possess the following features:

A multiuser system with the ability to differentiate between user groups in order to provide in context displays and data update restrictions.

An inter/intra office E-mail and fax interface system.

The ability to accept task priority allocations, and prompt the user with the appropriate action based on a setup database.

The ability to accept and or automatically allocate expected completion times for tasks based on a number of criteria such as priority, client expectation, task type and client status.

The ability to accept historical notes and provide online query reporting based on client, task type, task status or chronological order.

The overall system should be fast enough to service a real interactive session. Typically, queries and actions should be generated at speeds that match the telephone conversation.

The system should be sitting on top of a user maintained database that provides such things as valid contact names, site information, product information, release compatibility, release schedules, inventory control, technical notes and online manuals. An escalation system should exist that is based on task urgency, potential client exposure, allocated priority, and completion time blow outs. The escalation mechanism should be such that it automatically raises the priority allocation, warns the support team, and delivers the appropriate messaging to the support supervisor. The system should allow the creation of ad hoc query and reporting facilities by the user. This is opposed to reports that are run periodically. Periodic report should provide both the user and the client base with various statistical, and managerial information. This should include outstanding open queries, queries of a certain type, queries logged within a period of time, query history and other charge information. Tasks should be allocated to individuals and or groups, with the guarantee that all unresolved tasks have a single owner. The owner may change during the resolution cycle, but it must always have an owner. When tasks are reallocated, the person receiving the task should be made aware via a formal and agreed mechanism.

A facility should exist to reopen closed calls, or alternatively, clone previous calls for subsequent alteration. This allows the support consultant to quickly log calls based on previous facts.

The system should allocate unique task reference numbers that can be used by both the client and within the EDP group.

A number of task status codes should be catered for to reflect the position any one task is at. For example, a task may be pending, closed, completed or current.

Action codes should also be employed along with a more descriptive comment to indicate the sort of work that has, or will take place for any particular query. For example, the support team may indicate that the query has been transferred to development, the development team may indicate that they are testing etc.

A system of query categorising should be catered for such that each query can be placed in a particular class of problem. For example, the query may pertain to network errors, inoperative terminals, application errors, systems errors etc. This will assist in reconciling the problem areas and thus put in place longer term solutions rather than simply fixing the problem at hand. It should also be said that even the most sophisticated task tracking systems become ineffectual when either the system is not accepted by the users, or when there isn’t enough motivation to use them. The system has to be used by all parties concerned, or none. Once a commitment is made to use such a system, management should ensure that all members comply. Equally, nagging difficulties identified by the users should not be discarded. The biggest problem with getting such systems accepted by users is the obvious fact that it might take a few minutes to resolve a problem, but an equal amount of time to register it. It should be noted that much of the benefits of these systems are long term ones and therefore may not always be appreciated in the short term.

The system should also be used in an on-line manner and queries logged into the system as they are raised.

An off-line system will result in catch up games played at the end of the day in order to register the days queries. This has two main disadvantages. The first is that retrospective entries will be rushed and can be erroneous. The second is the very real possibility that certain requests do not get processed until the task is recorded. This particular problem is especially ominous when the service level agreement promises a few hour turnaround time for very high priority tasks.

6. Conclusion

The two most overwhelming factors which go hand in hand when an organization is looking at providing an effective support effort is the introduction of a well thought out service level agreement, and the implementation of a task tracking system. The scope of the service level agreement, and the functionality of the tracking system can evolve over a period of time, however, it is extremely important that a certain amount of initial planning takes place. It is important for example that prospective clients understand, and accept the manner in which support will be delivered. New services and conditions can be amended in time, however, the basic principles of working within an agreed frame work, and providing a measurable standard of service should be a major initial goal. The task tracking system can also start small. The first version may be nothing more than a hand full of shell scripts that allow call recording, searching, and reporting. Once again, the system should be designed such that it can grow with the users needs. It should be a system that the user needs and drives unlike many large systems available these days which force the user to change there working methods.


No comments:

Post a Comment