Initiating and Managing Incidents in QTMS: The process begins with an incident. What one defines as an incident is relative. An incident is basically an issue that needs to be addressed. An incident could be a customer reported failure or an issue discovered during in-house testing, a customer's, engineer's or manager's suggestion, etc. The following graphic highlights the incident process, as discussed in this section. Grayed out portions are discussed in other sections of the tour. 

Process Flow [Click to Enlarge]

In describing the QTMS incident process, we'll assume that one is dealing with a fielded serialized unit and that a customer has called in with an incident. (One of the great strengths of QTMS is its complete support of serialized systems, along with  complete configuration management --  down to the serial numbers of every component in a fielded unit if so desired.) 

For each incident, one would begin by identifying the responsible system (or subsystem, assembly, part, etc.). This would be done using the "Create a New Incident Report" interface. During this step, one captures relevant incident data (including system and part responsible, and their serial numbers if so desired), incident disposition actions and other relevant data for subsequent analysis. This interface includes multiple lookups and searches to assist in identifying the appropriate system. (Note that these screens are customized to meet specific customer requirements. In this example, an imaginary company is utilized.)

Initiating an Incident [Click to Enlarge]

Initiating an Incident [Click to Enlarge]

Dealing with Incidents in QTMS: An incident may be dealt with during the incident creation process or at a later stage (see also Incidents and Problems). Once the incident has been created, the incident is automatically assigned to the “Responsible Engineer” (RE). One or more responsible engineers are assigned to specific parts (REs are assigned by the system administrator when creating a system and they can be defined for any indenture level, such as system, subsystem ,assembly, component etc.). Each time an incident is created, the RE is automatically notified of the incident creation through an automatic e-mail notification that contains a direct link to the current incident page. A link to the incident is also added to the RE's portal. 

Complete Picture of the Incident and the Responsible System: The incident page includes complete information regarding the incident and is available to both the RE and the incident creator (which may be the field repair person, support person, another engineer, etc.). When working with serialized systems, the complete history of the specific system is also available, including its current configuration and full repair/issue history.  

Process Flow [Click to Enlarge]

The subsequent steps allow for both incident resolution and the assignment of the incident to a PRR for problem resolution. It is important to note that even though the incident may have been assigned to a PRR for resolution, the incident itself may have to be dealt with independently by the person reporting it (e.g. replace/repair parts to get the customer up and running).  

Complete Support for Repairs: For each incident, the complete repair history of the system is available and the current repair can be appended to the system's history, including serial numbers of failed/removed parts as well as serial numbers of new or used parts added to the system. In effect, this maintains the complete system configuration history and assures comprehensive time-to-failure/replacement data for each component. This information can be used for ancillary analyses using any of ReliaSoft's reliability analysis software products.

Process Flow [Click to Enlarge]

PRRs - Resolving the Problem: The RE is responsible for finding, understanding, resolving and preventing the problem that caused the incident. In accomplishing that, he/she is responsible for assigning the problem to a Problem Resolution Report (PRR) that will enable the problem resolution process. The RE will assign incidents to either a new or an existing (open or closed) PRR, or may reassign the incident to another RE altogether. The next pages discuss the PRR process. Next...

[1]  [2]  [3]  [4]  [5]  [6]  [7]

[Home]   [Softwares]   [Treinamentos]   [Consultorias]   [Painel de Confiabilidade]   [A Empresa]   [Clientes]   [weibull.com]

Copyright ©1998-2005 ReliaSoft Brasil, Todos os Direitos Reservados
Última Alteração: 24-02-05
 

LEGAL [Termos de Uso] [Links]
[Privacidade das Informações]
Contate Webmaster
Tel: +55 11 5584-5456