Quarter 1, 2002:  Volume 3, Issue 1

Reliability Edge Home

Implementing an Automated Reliability/Quality System: What You Can Expect

The benefits of automated analysis and reporting systems for reliability and quality data are abundant and well-understood within the product manufacturing community. The rewards to companies that invest in automated reliability analysis systems range from improved product design to increased customer satisfaction and are presented in more detail in the Benefits of Automated Reliability Systems article. When deciding to make the commitment to implementing such a system, the company must also carefully consider the investment of time and money as well as the risks of undertaking a project of this nature. 

The process requires the cooperation of the client (e.g. end users and their managers), who may have very little experience with the IT design and development process, and the software development team, who will need assistance to understand the business requirements for the system. If the client is unfamiliar with the system design, development and implementation process, there may be some trepidation about entering into this process. 

This article is intended to provide some insight into what can be expected when an organization undertakes the implementation of an automated analysis system for reliability and quality data. With some variation due to the nature of the project, development team and/or client, this general discussion is applicable to most projects of this nature.

Various Project Types to Meet Particular Needs
The nature of the project depends on the needs and resources of the client and there are many different ways that companies can improve and automate portions of their reliability/quality programs. Some types of projects that ReliaSoft has cooperated with clients to implement include:

• FRACAS++: A Web-based, closed-loop, incident (failure) reporting, analysis and corrective action system designed for the acquisition, management and analysis of product quality and reliability data from multiple locations within the organization (e.g. in-house testing, phone support, on-site service providers, etc.). 
  
• Reliability and Quality Dashboard: An interactive graphical reporting tool that presents automated reports and analyses via the Web. Dashboard can be configured to automatically analyze data captured via the FRACAS++ system or other data sources that support the desired analyses. Users can view “at-a-glance” summary reports or “drill down” to more detailed analyses by selecting the specific criteria for the analysis. Figure 1 displays an example of the Dashboard interface. 

Figure 1: Example of the Dashboard interface

• Automated Data Conversion and Import to Reliability Software: Automated utilities that obtain data from an existing data source, perform any actions that are necessary to convert the data to a format that can be analyzed and import the data into a reliability analysis software package, such as ReliaSoft’s Weibull++.
  
• Custom User Interfaces for Data Capture: Web-based or client-server utilities that support and streamline a process in which reliability/quality information is generated (e.g. phone support, repair, warranty returns) and capture/transmit the data for subsequent analysis and reporting. For example, hand-held automated repair “manuals” that support the decision-making process during repair and capture/transmit relevant data.

Design, Development and Implementation Process 
The design, development and implementation process varies depending on the type of project and on the particular needs/characteristics of the client. However, in general, the organization can expect some or all of the following activities to take place during the process. 

Project Assessment: The first step in undertaking a project of this nature is to define the project and make some preliminary assessments about the requirements, as well as the effort that will go into development. The project assessment stage usually begins with a series of phone calls, e-mails and face-to-face meetings. Often, the process begins with a wide area of interest and the consideration of multiple needs. In fact, by bringing together key players and acting as a catalyst to discussion and discovery, this process can often help an organization to gain a new understanding of its current processes and to identify untapped existing resources. Through this process, the scope gradually narrows to a manageable project level. 

This stage of the project provides an opportunity for the software development team to understand the needs of the client and for the client to understand the capabilities of the development team. Many times, the client will come into the process with a prepared list of requirements and the development team will provide demonstrations of the solutions offered. Typically, this stage culminates with a proposal for the project, which includes documentation of the client goals, requirements and processes that are relevant to the project, an overview of the proposed IT solution and a preliminary budget and schedule estimate for development. 

Prototype: In many cases, it can be very effective to start with a “proof of concept” or “prototype” project/phase before proceeding with the full development of the system. Depending on the project, the prototype may be a scaled down version or a particular component of the total system. Because of the limited scope, the prototype is easier to manage and more affordable than the total system and can be implemented in a relatively short period of time. The prototype can be used to demonstrate the effectiveness of the system to users and managers and obtain “buy in” for development of the full system. The effort that goes into the prototype contributes to the development of the full system in a number of ways. For example, the components developed for the prototype can often be incorporated directly into the development of the total system. In addition, the prototype phase provides useful experience that will inform and improve the subsequent design of the full system. 

Design and Specifications: The determination of the detailed functional specifications for the system is a crucial stage in the process. The functional specifications document identifies each piece of functionality that will be included in the system and presents the requirements in a way that both the client and the development team can understand. The process works best when the client and the development team work cooperatively to determine the functional specifications and when both sides have a clear understanding of the expectations for the system. In many cases, the development team will prepare preliminary screen designs (e.g. drawings, Visio diagrams, non-functional Web pages, etc.) to demonstrate the “look and feel” of the user interfaces. This process helps the client to get a more tangible sense of the finished product and often highlights requirements or other issues that had not yet been identified during meetings and functional specifications development. Once the development team and the client have a solid understanding of the functional specifications for the system, the development team must prepare the detailed technical specifications that they will use as a “roadmap” to develop the software. 

Development and Testing: Next, the development team follows internal development and testing procedures to create the system based on the technical specifications that have been determined. After a rigorous internal testing stage, which includes the validation of any calculations, the system is ready for “beta” installation and testing at the client location. 

Installation and Acceptance Testing: After the “beta” system has been installed at the client location, the client will have the ability to thoroughly test the system to make sure that it meets the functional requirements. Based on this testing, the development team makes any modifications that fit within the original scope of the project and there may be negotiations about the inclusion of additional functionality that was not communicated in the original specifications. In some cases, future phases of development are planned to expand and improve the system after the original successful implementation. 

User Training: During design and development, every effort is made to create intuitive user interfaces. In addition, the development team may also provide detailed user documentation and other training materials. In some cases, the development team will provide training for a small group of key users and system administrators on the use of the system and the client will usually have internal procedures in place for widespread user training. 

“Live” System: Finally, the system is ready to “go live” and begin to be used within the organization. After this goal has been reached, the development team may provide ongoing technical support for the system and, in many cases, works with the client to design and develop enhancements and modifications to the system in future phases. 

Conclusion 
Although it is a challenging process that requires careful planning and active involvement by the client as well as the development team, the implementation of an automated reliability/quality reporting and analysis system can provide tremendous benefits to organizations that are willing to make the commitment.