[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

7.0. "Support and Problem reporting" by --UnknownUser-- () Tue Oct 06 1992 11:13

T.RTitleUserPersonal
Name
DateLines
7.1Updated reporting informationTOOK::MINTZErik MintzFri Sep 10 1993 08:5850
Latest update on problem reporting procedures:

From:	TOOK::FRIES        "Joe Fries, NSM-QA, 227-3175, now at TAY2-2/B5"  9-SEP-1993 14:46:03.49
To:	TOOK::MINTZ


--------------------------------------------------------------------------------
There seems to be some confusion about problem reporting procedures.

QAR system: Use to report only problems in field test code.
    We are *not* accepting or tracking any other problems here.

Notes File: Use for general and specific discussions of DECmcc related
    issues and topics of interest including problems.  *Noters* may
    help with problems reported here.  
    The DECmcc engineers are *not* tracking any problems here.


For problems in released code, including DECmcc v1.3, contact a local 
    support organization: 

    - For critical problems, file a CLD 
    - For routine problems,  file an SPR

    The corporate definition of the levels of severity as described in 
    "Multivendor Customer Services & Engineering Problem Management Process
    Revision 1.1" are:
    
	Level 1 - CLD 
                      A catastrophic outage. The customer cannot produce
	              and no procedural workaround exists.

        Level 2 - CLD 
                      A high impact problem. The customer's operation is
		      distrupted, but there is some capacity to produce.

 	Level 3 - SPR 
                      A problem that involves partial noncritical
                      loss.  Some operations are impaired but customer
		      continues to function.   

        Level 4 - SPR 
                      A very minor issue with very limited loss or no loss
		      of functionality or impact to the customer's operation.

        Level 5 - SPR 
                      A Suggestion.



7.2Remedial Support Escalation Process SummaryAZUR::LANGENSTEINHubert Langensteiner, @VBEMon Jan 09 1995 09:55114
From:	MSE1::VANROEKENS "Peter van Roekens DTN 227-3398 Multivendor Systems Engineering  06-Jan-1995 1609"  6-JAN-1995 16:18:55.46
To:	@MCSLT @MCSDLT @SENIOR_ENG_MGRS 
CC:	@MSE_TEAM @MSE_DIS:MSE @SSMF @SSMF_INTEREST @QLT
Subj:	A: Remedial Support Escalation Process Summary 

 ***************************************************************************
 *  PLEASE DISTRIBUTE WIDELY TO ALL ENGINEERING, MCS, AND SALES MANAGERS   *
 ***************************************************************************

Remedial support issues have become increasingly critical to our customers. In
order to ensure that our customers are receiving the best support possible, it
is very important to know and follow the proper remedial support escalation
process.  While there are many documents such as the Escalation/Exception and 
Crisis Management Worldwide Model and Process Guide or the Baseline Process
Flows that provide great detail, what follows is a summary of the escalation
process. Adhering to this escalation process will significantly improve the
potential for customer satisfaction and reduce unnecessary effort on
everyone's part. 


                         Escalation Process Summary

  1.  The customer reports a problem to Digital through the formal Call
      Handling Process.  This is Zone dependent and well documented 
      in the Field.  For example, it may be handled through an Operations
      Control Center in Europe or a 1-800 number in the US. 

  2.  At this point a Territory problem manager will be assigned. The 
      Territory problem manager is responsible for continuous  customer 
      management and communication. This is a critical role throughout the 
      life of the escalation and should avoid the necessity of customer 
      escalations to senior management. 

  3.  Territory resources are used first to identify, manage, and resolve 
      the problem to satisfy the customer if an escalation to Engineering 
      is not required.

  4.  If these resources are unable to resolve a remedial problem, the problem 
      should then be escalated to Engineering via a Call Handling System to 
      IPMT. The Territories must insure the problem has been isolated to the 
      best of their abilities, is well defined, and documented with all 
      supporting data included in accordance with the Remedial Support 
      Agreement (RSA). This will allow Engineering to effectively work the 
      problem when it is received. Using the same Call Handling System, the 
      Territories can escalate problems to Multivendor Systems Engineering 
      (MSE) when the problem involves multivendor interoperability issues or 
      if the nature of the problem is so complex that it cannot be isolated 
      by Zone/Territory resources. MSE will drive the resolution of these 
      issues with the support of the Zone/Territory and Engineering resources. 
      All of these remedial problems will be handled in accordance with the 
      Remedial Support Agreement (RSA).

  5.  The level of severity is assigned by the Territory problem manager 
      according to the Remedial Support Agreement (RSA). There are three 
      levels of severity plus a category for suggestions.  Level 1 is 
      defined as catastrophic, and Level 2 represents a high impact for 
      the current supported version of a product. Level 3 is defined as a 
      noncritical problem with the expectation that it will be reviewed for 
      possible resolution in a future release. The last category represents 
      suggestions or a wish list for a future version of the product without 
      any strong expectations that they will be acted upon. During the course 
      of the resolution process the severity level may be downgraded or 
      upgraded with the agreement of Engineering and the Territories  in 
      accordance with the process specified in the RSA.




     
  6.  The Territory problem manager is responsible for monitoring all Territory 
      escalations and pressing resolution with Engineering. If there is a 
      conflict between the Territory and Engineering, either side may utilize 
      Multivendor Systems Engineering (MSE) to arbitrate. 

  7.  Upon receipt of an IPMT case, the receiving Engineering group  either
      accepts  or  reassigns  the  problem  by  contacting  the Engineering 
      Manager of the appropriate group.  If a reassignment agreement cannot  
      be reached, Engineering should contact MSE Problem Management.

  8.  The Territory and Engineering develop and execute a joint action plan  
      to solve the customer's problem and keep the customer informed. IPMT    
      is utilized to communicate action plan status and progress towards 
      problem resolution.  Status is updated according to the  RSA, e.g. 
      Level  2  problems  are  updated according to the Action Plan. This 
      update generally occurs at least once per week.

  9.  A resolution to the problem is proposed by Engineering and is  either
      accepted or rejected by the Territory/Customer.  If an agreement
      cannot be reached between the Territory  and  Engineering,  then  the
      Territory  problem  manager  and  the  Engineering  Manager  should
      contact MSE Problem Management for assistance.

 10.  When the accepted solution is agreed to by the customer, the case  is
      closed.   



                        Direct to Engineering Escalations

      If  the  customer calls  Engineering directly, Engineering should pass  
      the information to the  formal  Call Handling Process in the Zone. For
      details of the Zone/Territory remedial escalation process, please 
      contact the  Technical  Expertise and  Capability  Function  in  the  
      Zones.   The current contacts are Harry Dugas (DTN:483-4104) for the 
      Americas, Manfred Stein (DTN:865-2075) for Europe, and Faye Fitzpatrick 
      (DTN:730-5572) for AP.            

                                Non-Remedial Issues

      Other escalation requests will be  handled  via  separate  processes.
      For example, major enhancement requests are handled via the Engineering 
      Commitment Process (ECP); non-technical problems/political issues are 
      handled by MCS  Customer Relations;  Pre-sales  Support  through  the  
      Sales  channels, etc.