©1993-2006 ReliaSoft Corporation ReliaSoft Enterprise Systems Group

What is XFRACAS? • Complete system designed for managing, monitoring, controlling and understanding incidents and associated problems. • Completely Web-based for easy access, collaboration and deployment to/with multiple sites, suppliers and dealers. • Integrated to allow for the capture of all relevant data for subsequent analysis. • A comprehensive knowledge base and reliability data repository. • An infinitely flexible and scalable enterprise system able to grow with your needs.

XFRACAS is a Complete System • The many capabilities of XFRACAS include: • Safety Management System, Quality Tracking System, or FRACAS process management (Failure reporting, analysis and corrective action). • Part repair/replacement tracking and complete serialized system configuration management. • Customer support and failure (incident/issue) reporting. • Dashboard-style reporting with non-parametric progress tracking and reliability/quality reporting in an interactive graphical interface. • Integration with parametric reliability analysis engines including life data, system reliability and maintainability and reliability growth analyses. • "Knowledge Base" of product quality and reliability data that can be utilized by product safety and design, sales, management, procurement and other personnel.

About this Overview

The XFRACAS Overview • This overview has been designed to give you a general understanding of the XFRACAS system and allow you to assess how XFRACAS may improve your company process. • This overview is divided into the following sections: • Section 1: The XFRACAS Process • Introduces the system’s unique ability to individually address both incidents and problems and expands on the incident/problem relationship. This section also presents high-level flowcharts of the XFRACAS process and the problem resolution process.

XFRACAS Overview (continued) • Section 2: The End User's Perspective • Discusses standard navigation, search and reporting interfaces of the XFRACAS, as viewed by an average user. • Section 3: Managing Incidents • Discusses the incident creation process and the subsequent assignment of issues to problems. Incidents are the specific individual issues, while problems are the root causes for the incidents. • Section 4: Solving Problems • Discusses the process by which problems are addressed using a 4 to 8 step problem resolution process. This section provides an overview of these steps and shows sample user interfaces using an 8D process.

XFRACAS Overview (continued) • Section 5: Not Just FRACAS • Discusses ancillary interfaces included in XFRACAS designed to cover all facets of the incident and problem resolution process over the entire life cycle of your product, including failure (FA) analysis information on returned parts, complete customer/vendor contact information and incident histories, installation details, system configuration information and other functionality. • Section 6: Administrative Interfaces • Discusses the XFRACAS administrative interfaces. A system administrator can manage and reconfigure the system, user permissions and other aspects.

XFRACAS Overview (continued) • Section 7: System Architecture • Discusses the Web-based, n-tier, scalable and robust system architecture for XFRACAS. • Section 8: Advanced Reliability Analysis • Discusses the ability of XFRACAS to provide direct integration with the most advanced suite of Reliability Engineering analysis tools.

About this Demo/Overview • The screens provided in the overview and subsequent product demos will have fields, inputs, options or lists that may or may not be applicable to your organization. • Please keep in mind that XFRACAS is customizable and different deployed systems will have different interfaces. These different interfaces can support many different types of processes, from Safety Management Process, to Quality Tracking processes, to FRACAS-type processes.

1 Section 1:The XFRACAS Process A Conceptual Overview

Closing the Loop on Problem Resolution • XFRACAS is unique in its design and framework, as it can be used to address both individual incidents and the underlying problems. • In XFRACAS terminology, a single problem can have many incidents. • Incidents are dealt with as they occur, while problems (the underlying causes of the incidents) are analyzed and resolved through a formal Problem Resolution Report (PRR).

The Incident/Problem Relation • XFRACAS uses an incident/problem relation in its data tracking process. • Incidents are issues/failures reported by customers, found during testing, etc. Each of these incidents can be attributed to one or more underlying problems. These problems can be either Reliability, Quality, or Safety issues. • As an example, consider a product with a faulty component. • Multiple customers may experience/report a failure due to that faulty component. Each failure is an incident. • From an engineering perspective, all of these incidents are due to the faulty component; thus, the problem is the faulty component. The faulty component could have Reliability, Quality or Safety related issues. • In this scenario, customer support or repair technicians will attempt to resolve the incident (i.e. get the customer up and running). However, resolving individual incidents does not resolve the problem. The problem is resolved by dealing with the faulty component.

The Incident/Problem Relation Problem 1 i i i Problem 2 i i Problem 3 Problem 3 i i Incidents are assigned to problems Problems are managed, tracked and resolved through an 8D process Problem 1 Incidents occur and are reported i i i i i Problem 2 i i i i i i i

Addressing and Resolving Problems • Once incidents have been classified into problems, responsible engineering teams (REs) address and resolve the problems through a PRR process. This process can range from a four step process, to a five or six step process like Six Sigma DMAIC methodology, to an 8 step process like 8D. • The entire process is managed by XFRACAS, which in turn also becomes the data repository for subsequent analysis and lessons learned.

Dashboard Reports & Analyses -Reliability Metrics -Quality Metrics -Customer Support Efficiency Metrics -Engineering Change Efficiency Metrics -Warranty Projections -etc... 15 ©1993-2006 ReliaSoft Corporation ProcessFlow Diagram Reliable Products Problem Resolved Incident (Failure) Reporting Incidents are reported from a variety of channels. Reliability/Quality Knowledge Base Information resource for troubleshooting and reports/analyses . Test/Inspection Facilities Implement Changes -Product Design Changes -Manufacturing Changes -Distribution Changes -Documentation Changes -etc... Data Includes: Occurrence Date/Time Affected Part(s) Time to Failure Time to Repair Incident Description Fault Code(s) Part Repair/Replacements Incident Resolution etc... Distributors or Suppliers etc... Customer Support Technical/Customer Support Troubleshooting Manage Problem Resolution Incident Resolved Review Incidents and Identify Problems Assign incidents to problems that can be tracked and resolved. -New Problem -Existing (Known) Problem -Disregard Data Includes: Problem Description Associated Incidents Failure Mode Root Cause Problem Resolution Responsible Individuals etc...

16 ©1993-2006 ReliaSoft Corporation Problem Resolution Process No Service Call (lab) Incident Report (In Process) Incident Investigation Incident Report (Open) IR Dispositioned to ‘Closed’ PRR Incident Occurs Service Call (field) IR Disposition to ‘Owner’ IR Dispositioned to ‘old’ PRR IR Dispositioned to ‘new’ PRR Create new PRR D8 Reward Team A D1 Choose Team D2 Describe D3 Contain D4 Root Cause D5 Choose C.A. D6 Validate C.A. D7 Prevent Recurrence A Reject FRB Review of Proposed Containment FRB Review of Proposed Corrective Action FRB-or-Offline Review of PRR/8D Reject Reject Approve Approve Approve AND/OR AND/OR Close PRR/8D TSB SCAR (supplier) QCR (process) ECN-R (retrofit) QCR (process) ECN (design)

2 End User's Perspective Navigating XFRACAS...

My XFRACAS Portal • When you log into the XFRACAS system (and are authenticated), your personalized "My XFRACAS Portal" will load. In addition to allowing you to easily navigate the system through relevant links and menus, this customizable portal includes an at-a-glance view of all the issues you need to work on, including: • Actions assigned to you that need to be completed. • Incidents that you need to review. • Problems that you need to work on. • Solutions that you need to review and sign off on. • Along with customizing your portal, you can easily add global or local announcements and links. Global items can be seen by all users of the system, while local items are seen only by you. As with most XFRACAS features, the ability to view or add global items is permission-based. • Additionally, you can run saved custom searches and reports directly from this page, or have one automatically run when visiting this page.

XFRACAS My XFRACAS Portal (Sample Screen) Local, Global Announcements Local, Global Links My Actions PRRs I need to work on PRRs I need to review Incidents I need to review Projects I need to work on 19 ©1993-2006 ReliaSoft Corporation

Searching and My Search Page • You can easily access specific information through the system’s “My Search Page” functionality. • A powerful and highly flexible search interface allows you to find needed information through a set of pre-defined or user-defined ad-hoc queries with user defined output. • Your queries can also be saved to the system for easy future access. • These can be stored both globally and locally. ?

Reports and My Reports Page • XFRACAS includes extensive reporting capabilities. • With the system’s “My Reports Page” functionality, you have access to simple and complex pre-defined ad-hoc reports. • Additionally, you can easily create your own custom ad-hoc reports and add them to the system both globally and locally.

XFRACAS My Reports Page (Sample Screen) Ad-hoc Data Extracts 24 ©1993-2006 ReliaSoft Corporation • Use the reporting interface to extract data for further analyses. • Life Data Analysis • System Analysis • Reliability Growth Analysis

Graphs and My Dashboard Page • XFRACAS includes extensive graphing and trending capabilities. • With the system’s “My Dashboard Page” functionality, you have access to simple and complex pre-defined graphs. • Additionally, you can easily create your own custom ad-hoc graphs and add them to the system both globally and locally.

3 Managing Incidents Initiating and Managing Incidents in XFRACAS

Initiating and Managing Incidents in XFRACAS • In general, most problems begin with incidents. • 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.

Managing Incidents

Initiating an Incident • For each incident, you 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, the system 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.) In describing the XFRACAS incident process, we'll assume that we are dealing with a fielded serialized unit and that a customer has called in with an incident. (One of the great strengths of XFRACAS 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.)

Dealing with Incidents • An incident may be dealt with during the incident creation process or at a later stage. • 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 page is also added to the RE's portal.

The Incident Page • The incident page includes complete information regarding the incident and is available to both the RE and the incident creator (who 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.

Resolving the Incident • 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 several of ReliaSoft's reliability analysis software products directly from XFRACAS.

Address the Problem • The RE is responsible for finding, understanding, resolving and preventing future occurrences of 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 section discusses the PRR process.

4 Solving Problems The 8D Problem Resolution Process

Solving Problems • The XFRACAS problem resolution uses a step-by-step approach ranging from a four step process, to a five or six step process like Six Sigma DMAIC methodology, to an 8 step process like 8D to enable engineering teams to identify, understand, resolve and prevent the problem (that is associated with single or multiple incidents). • For any step from the second step on, you may be able to assign a failure review board (FRB) to verify and sign off on the effectiveness of the actions defined for the step. XFRACAS automatically tracks this sign-off process (the XFRACAS portal contains items that individuals need to review and sign off on). • The process is managed by a “Problem Resolution Report” or PRR. The following slides demonstrate a PRR using the 8D process.

Solving Problems

Step 1: D1 - Establish the Team • Establish the team with a team leader who has the knowledge, time, authority and skill to solve the problem and implement corrective actions. • XFRACAS can display all steps for a PRR at once or lead you step-by-step through the process by displaying the steps one at a time after each step is completed and saved, forcing you to finish each step before moving on. • The slides that follow display all steps.

Step 2: D2 - Describe the Problem • Describe the problem in measurable and specific terms. • During this step (and during most subsequent steps), action items can be assigned to team members and their progress can be monitored and tracked. • Additionally, incidents and/or projects can be associated with the PRR, along with references to other documents.

XFRACAS Step 2: D2 (Sample Screens) 46 ©1993-2006 ReliaSoft Corporation • Action items are emailed to team • members. • They are also added to their portal. • Past due notices and reminders can • also be utilized (including escalation). Action items can be assigned (and tracked) to different team members.

Step 3: D3 - Contain the Problem • Contain the problem by defining (and implementing) intermediate containment actions. • These actions should temporarily resolve customer issues (other incidents that may arise) until permanent corrective action can be implemented. • The following graphic shows D3, highlighting the sign-off process.

XFRACAS Step 3: D3 (Sample Screens) 48 ©1993-2006 ReliaSoft Corporation The current step in the process is highlighted in red. Other action items. Set FRB members for containment approval. Based on login credentials sign-off.

Step 4: D4 - Root Cause • Identify/define, describe and verify the root cause of the problem. • Action items can again be assigned and tracked until a root cause can be identified and verified. • Action item records can include other attached documents.

XFRACAS Step 4: D4 (Sample Screens ) 50 ©1993-2006 ReliaSoft Corporation • Root Cause • Determine • Describe • Verify Assign single or multiple failure modes. Add/monitor action items. Verify Root Cause Add/monitor action items.

©1993-2006 ReliaSoft Corporation ReliaSoft Enterprise Systems Group