Conference kernel::csguk_systems

30.0. "ESCALATION PROCEDURE" by KERNEL::ADAMS (Venus on Remote Control) Thu Apr 20 1989 02:59

From:	NAME: WHITFIELD

Ladies and Gentlemen,
			DRIVE has had major impacts in the Field 
Service operation. The key area I am involved with is around the Duty 
Manager and Escalation Manager which you are all fully aware off.
But, were you aware that there has also been major changes within the 
escalation process to Engineering (CLD Process).
I recently attended a meeting in the States on this very subject and 
this memo is intended to put you all in the picture so that you 
understand why a customer problem is escalated in a certain way.

THE CSC EXCEPTION MANAGEMENT TEAM:
---------------------------------  This is a combination of the TSC 
and Country Support Escalation Management; SPR admin and 
REVCON/Manpower resourcing. The logic being that with 4 people  
it makes the operation much more flexible; apart from the obvious 
coverage angle.
The members are: Jeff Whitfield (CS Escalation Manager)
		 Chris Quintana (TSC Escalation Manager)
		 Mick Hockley   (Revcon/Resource Manager)
		 Angela Evans   (SPR Admin)

There is one "hunt" number: DTN: 7833 3600 
			    DDI: 0256 488600

PLEASE USE THIS NUMBER FOR ALL ESCALATION QUERIES.

THE CLD PROCESS:
---------------  
CLD stands for Central Log Desk (not very dynamic) and is a means of 
routing a customer problem to the right engineering group for "any" 
product (software and hardware).
It is the highest level of Escalation.
In the past, the front end group to Hardware Engineering was CSSE and 
the recipricol group for software was COG. COG are a SWAS function and 
as such were not goaled on remedial work; hence the commitment 
problems many of you have been unfortunate enough to come across.
CSSE are committed to remedial work and as such we very rarely see any 
ownership problems.

As of 4-July-88, CSSE took ownership of the Software Escalation. Thus 
they are now the sole interface into both Software and Hardware 
Engineering. The transition was a major task; imagine having to 
employee the very high levels of expertise to cover "every" software 
product. Manpower is still their biggest problem. 

At the same time, a new CLD logging system was introduced, which would 
allow engineers access so that they can keep a track of their own CLD.
Also, software is being written which will allow direct links to the 
various OUTAGE systems in different parts of the world (ECSO for 
Europe). Thus there will be just one Problem Management System. 
The CLD database is installed in the CSC and engineer/manager access is 
being currently being invoked. Each CLD is owned by these two people 
and it only becomes a exception when links break down between 
engineering and the field. From the database we can monitor/add to 
CLD's anywhere in the world; produce stats packages; monitor update 
time lapses; and generally clean up the entries (something we could do 
with on ECSO). Coming shortly will be a Product Sort package so that we 
can sort the world CLD's for any known problems being worked 
elsewhere. 
The default time for updating a CLD is daily (States Support Strategy 
Notebook) so immediately a action plan is drawn up between CSSE and the 
field, the update timeframe must be entered. This will be policed by 
the CSSE Program Group (Hank Watkins) and rules are in place as to the 
level of management brought into the loop. Locally, the Exception 
Management Team will do the checks and chasing so that we do not get 
into the reprimand arena.  
When a CLD is first raised, the Technical Manager/Engineer will 
receive a phone call from the relavent CSSE group within 4 hours
(allow extra for the time differences). What this means is that the 
Problem Manager/Technical Manager/Engineer should ensure that they 
are available; or ensure that standins are fully conversant with the 
problem. In the States Support Strategy Notebook it says; "Every 
member on a CLD must be contactable within 1 hour during working 
hours. The Problem/Technical/CLD Managers must be the same but 
24hr x 7 day a week". I don't know whether this works in the States; 
but it certainly does not happen in the UK. All I can say is that
"Every CSC Manager" does carry a bleeper; and every one does have a 
terminal logged into the CLD Database.
This emphasyses the importance placed on CLD's. We must uphold our end 
of this agreement and work towards more efficient involvement. Hence, 
every TSC/Country Support manager now has access to the CLD database;
as well as all the engineers involved in current CLD's. 

Since the changeover to CSSE from COG the responces have been very 
encouraging and I can only see a brighter future for problem 
resolution.

OTHER INTERESTING FACTS:
-----------------------
Software Revision Matrix: 
			Which software works with what. A hardware 
matrix has been in place for years. CSSE are developing one for 
software.

VMS Engineering Sustaining Engineers: 
					 VMS Engineering's goal is to 
produce new versions of VMS. Hence the past frustrations when it was 
necessary to get them to make changes to an existing product. Well 
now they are to employ 12 engineers to work within engineering and fix 
bugs in them.

CSSE contacts list:
		  A list of all CSSE engineers and their product 
responsibilities will be kept updated by Ron Miller (CSSE) and 
distributed to the CSC's. Any engineer working in a CSC will have 
automatic access to these people; Field Support engineers will need to 
come through the CSC Exception Group who will set up the initial 
links. 

Query Support:
	      This the old HOTLINE telephone/mail system. For the 
first quarter this will continue to exist and any remedial calls 
forwarded to the relavent CSSE group instead of COG. The plan is to 
access each group individually; they in turn will have the same 
logging/call handling system for consistancy. This is already in place 
in some of the groups.

Post Partem Reviews:
		   At a local level we very often hold a meeting after 
a problem resolution to establish where we went wrong and put 
processes in place to ensure they do not happen again. CSSE are to do 
this from a Corporate Level; a problem manager is currently being 
hired to assist Ron Miller.

SPR/TIME:
         This is a complete mess. VMS Version 5 meant that very few 
SPR's were ever looked at and consequently there is a huge backlog of 
many thousands. CSSE is committed to sorting this out.
TIME is the SPR logging system.
The TIME system was badly managed; badly implemented, and poorly 
supported. Hence its failure as a live tool in the countries.
This is being cleaned up and made useable. However, the new CLD 
Database will probably take over this role (possibly Jan 89) in line 
with the "One Problem Management System".

Source Listings:
		CSSE have a program in place to distribute the Top 20 
Product Source Listings to the CSC's. This will be a tremendous boost 
to our problem resolution capabilities. It will also help us to get 
much closer to the route of a problem before escalating to the 
Engineering Group; thus not taking up their resources.

STARS:
      CLD/PRISM/SPR solutions will be automatically entered. CSSE are 
setting up the process.

CLD Closure Codes:
		 When a CLD is closed, CSSE will assign a "closure 
code number" to it. Basically a 1 or 2 means it was a valid CLD.
Any other means the problem should not have been a CLD. This can be 
disputed and taken up through the Exceptions Group in the CSC.

CSSE and CLD Goals:
                  CSSE are goaled on CLD closure. Thus if the problem 
changes they will want to close the CLD and then log a new one. This 
is time wasting; therefore a process is being looked into whereby the 
CLD number can have a extension for each incident;ie. UVO0038.1 for 
the first problem; then UVO0038.2  for the next). More importantly, 
this system maintains the focus on the number of problems a customer 
is having.

Product Problems:
                 Where the customer has a workaround, hardware product 
problems should be logged on PRISM. For software, the system to use it 
TIME (SPR). However, both these will probably go away and we will stay 
with the one CLD Database System.

SPR's for Problem Logging:
			 Currently, software engineering groups insist 
on a SPR to log a problem (it is all they know) but due to the very bad 
resonce SPR's have had in the past, the CSC's (wordwide) are reluctant 
to do this. CSSE are aware of this and are looking for a solution.


CONCLUSION: 
          It is imperative that the UK CSC is represented at future 
CSSE meetings if we are to have any say in how we think CSSE should 
work; especially at this crucial transission time. At the meeting I 
attended, it was the first time all the Field Service Geographies were 
represented (Europe,GIA,UK,States) and we all have our different 
requirements.
Any info I receive/aquire I  will share with you so that you all 
understand why a certain problem is handled a certain way.
The good news on the software front is that things have definitely 
improved in the first two weeks of CSSE taking over.
The escalation path is simplified; just one engineering front end 
contact. Likewise, they have one focal contact in the Exception
Management Team if they are having problems getting back to a District 
in the UK. This same contact is available in every CSC in the world.
The mind boggles at the thought of 24 hour cover through the various 
CSC's without having to pay overtime (there is always one open 
somewhere). I will leave you with this thought!!

		regards  

			Jeff