Product Life Cycle Risk Management

Abstract

Every new product coming to the market usually brings with a certain amount of doubt concerning the likelihood of its success. In particular, hidden problems and risks which might appear later in the product’s service life could cause producers’ difficulties, costing them a lot of money. This might even result in product phaseout and a consequent loss of the company’s reputation. Hence, it is necessary to manage all product risks. Unfortunately, no comprehensive methodology, managing the entire product life cycle, has been developed so far. This paper presents a new risk management methodology that covers the entire product life cycle. The product life cycle and its management have become a present standard and an important element of the information structure of modern enterprises. A product life cycle comprises several phases; this helps make risk management easier because it is feasible to manage risk for each phase separately. Generally, this phase structure creates a closed and unceasing rotation of risk management tasks and is an important element in universal process improvement. The methodology is focused on prioritizing risks according to the customer’s needs and requirements. It can be applied to a large number of different products and industries.

1. Introduction

Nowadays, risk management is an integral part of every state-of-the-art enterprise. This is because engaging in an enterprise always involves various kinds of risk. Thus, it is necessary to develop methods for risk management system integration into enterprise processes. Risks shall be controlled on all levels of an organization and exist in terms of costs and environmental and occupational safety. As far as manufacturing enterprises are concerned, it is also required to possess a strategy of the risk management related to the finished products. Every product has its product life cycle, and it is necessary to consider the various spectra of issues which may occur during the product life cycle and manage the risks related to them. The product life cycle management (PLM) has become a standard: widely recognized element of the information structure of modern enterprises. In order to promote comprehensibility and definiteness, it is seen as consisting of several phases. The aim of this is to make the risk management more tractable because it is, in fact, feasible to manage risks for each phase separately. Unfortunately, no comprehensive methodology managing the entire product life cycle has so far been developed. Some methodologies attempt to combine a number of known methods, but they are unsatisfactory in most cases. There is a need for a comprehensive, sophisticated method which would cover all possible risks throughout the entire product life cycle. This chapter deals with the primary life cycle phases—of conceiving, designing, realizing, and servicing a product. The risk management, especially at the beginning of the product life cycle, is a very important management task since this measure may be beneficial for following phases and save a considerable cost, the company’s reputation, and even human health.

2. Product life cycle risk management

The product life cycle model is based on the idea of a biological cycle, i.e., the process from birth to death. The pattern holds good for a commercial product, and it can also be understood as a process embedded within all the other processes of an enterprise. In risk management, all participating subjects must understand the relationship between the project management processes and the other enterprise processes. The product life cycle is a natural framework for the investigation of relationships and processes in the product management. It can be described as a means to define the start and end of a product and all phases in between. The way that defines the life cycle varies from industry to industry, but it also varies within the same industry in relation to different organizations and businesses. In product life cycle management, the risk approach changes once different phases are reached. This change depends on how much information is available and project progress. A typical product life cycle description covering all phases is shown in Figure 1 .

Figure 1.

Product life cycle phases.

The product life cycle or product life cycle management (PLM) is a control process maintained from conception through design and production to service and disposal. PLM includes people, data, processes, and business systems and represents the main information flow within companies. At the same time, PLM systems help organizations to cope with increased complexity and new engineering tasks related to new product developments for global competitive markets [1]. Low-quality data generated in the product conception phase may mean considerably higher costs in the subsequent phases [2]. The number of components involved with most of today’s products, along with their complexity, increases. This trend can evidently be seen in all industries. It is not exceptional for the number of product components to be in the hundreds of thousands or even in six figures (automotive, aerospace, and marine industry) [3]. Thus, it is necessary to take extreme care, to prevent the risk of failures, from the very beginning of the life cycle of each product. The potential existence and detection of nonconformities throughout the product life cycle are shown in Figure 2 .

Figure 2.

Existence and detection of nonconformities during the product.

The risk management aim is to add the highest permanent value to all company’s processes. It contributes to a better understanding of all the possible advantages and disadvantages of all the factors affecting the project or organization. It increases the probability of success and decreases the probability of failure and of uncertainty as regards achieving general objectives. The final output of the risk management process should be a decision about whether and how to treat risks. If there is an unacceptable level of risk, it may be necessary to stop the current process(es) and accept certain countermeasures which will abate the risk level. Residual risks that cannot effectively be abated by such countermeasures may be processed using crisis plans [4]. Risk priority assessment shall be performed whether the risk is acceptable or not. Risk management should be a continuous and ever-improving process integrated into the strategy of the organization and the enforcement of this strategy.

2.1. Baseball field diagram

This method of risk analysis has been developed uniquely for the assessment of risks identified by utilizing a combination of different tools within the product life cycle. The use of this unique assessment method guarantees a unified system for the entire product life cycle. There is a priority attached to each identified risk, according to its risk value. Risk priority may change during the life cycle.

For priority risk assessment, the basic principle of the method from Dr. Hsia [5], as customized for this particular situation, was used. The diagram is applied once all risks associated with a given product life cycle phase have been identified. Risk value R is divided into five priority areas, from A to E. Risk value R combines the probability index RP and the impact index RI. With one index as the horizontal axis and the other as the vertical axis, a diagram (which is reminiscent of a sector of a baseball field) can be drawn. The bottom left corner represents the lowest coordinates (0,0), and the upper right corner represents the largest coordinates (1,1), as shown in Figure 3 .

Figure 3.

Baseball field diagram.

There are five priority areas outlined in the diagram. Priority area A represents risks of the highest priority for which it is necessary to carry out immediate countermeasures. The area designated as B represents risks of the next highest priority. Thus, the risks have the next highest priority to call on resources for management, and so on, down to the E priority area where risks may be neglected.

2.1.1. Probability and impact level

The probability value is categorized into five levels: very likely, likely, possible, unlikely, and very unlikely. The relative descriptions of these probabilities are shown in Table 1 . Furthermore, the impact event level is also categorized into five levels: very serious, serious, moderate, minor, and negligible. The exact criterion description depends on the particular product, as seen in Table 2 . The higher level of either, the more serious the issue.

Level	Description	Probability (%)
5	Very likely	1–0.1
4	Likely	0.1–0.01
3	Possible	0.01–0.001
2	Unlikely	0.001–0.0001
1	Very unlikely	Less than 0.0001

Table 1.

Probability level.

Level	Description	Criterion
5	Very serious
4	Serious
3	Moderate	Depends on the event
2	Minor
1	Negligible

Table 2.

Impact level.

When assessing or calculating a probability level, these three approaches may be used, individually or in a combination.

2.1.1.1. Historical data

The use of appropriate historical data, for example, data from previous, similar, projects (the Lessons Learned database), provides the ability to extrapolate an approximate probability of occurrence of certain effects or failures. The historical data must be in regard to the same system, equipment, or operational concept. If there is only a low frequency of occurrence (of a particular situation), then any estimate based on historical data is very uncertain.

2.1.1.2. Predictive techniques

For probability prediction, a number of “predictive techniques” can be used, for example, fault tree analysis, event tree analysis, or Markov chains. When historical data are unavailable or unsuitable, it is then necessary to determine probabilities from the system or equipment operation analysis in terms of fault or failure conditions. Numerical data for equipment, people, and systems come from experience or from other data sources, and it is used in order to estimate the probability of the top event. Simulation techniques that generate probabilities of component, equipment, and system failures caused by degradation or aging may also be used here.

2.1.1.3. Expert estimate

In systematic and structured processes, it is possible to use expert estimates in order to assess probabilities. There are many formal methods designed to obtain relevant expert estimates; these help in forming proper, pertinent questions. Available methods are Delphi, What If?, category classification, and absolute probability estimates.

When determining or calculating the impact level of a risk, the criteria (character and type) must be stated. The impact of risk factors can be determined from previous, similar, projects, or they can be estimated by an expert. The analytic hierarchy process (AHP) method facilitates determination of the priority of risk factors when multiple criteria in relation to specific impacts are available. AHP has attracted the attention of many researchers because of its logical and mathematical approach and because the input data for the method are easily attainable. The method is a decision-making tool that can be used for the solution of complex problems. More details can be found in Thomas L. Saaty’s work [6].

2.1.2. Risk value

After the identification of all the possible risk events, it is necessary to determine the probability and impact index of each given event and its consequent risk value R, as provided by Eq. (1). The calculation of the probability and impact indexes are shown in Eqs. (2) and (3):

$R=\sqrt{R_I^2+R_P^2}$ E1

where

$R_P=\frac{{\mu }_P-\text{min}}{R_{FP}}$ E2

$R_I=\frac{{\mu }_I-\text{min}}{R_{FI}}$ E3

From Eq. (2), μ _p refers to the level of probability. From Eq. (3), μ _I refers to the impact level and min refers, in both cases, to the minimum of the k – level table, set to 1. R _FP and R _FI refer to the full distance of k – level table minus 1; both values are 4 (R _FP = R _FI = 4). All calculated indexes and values are recorded in the table. An example is seen in Table 3 .

Item	Event	Probability level	Impact level	Probability index	Impact index	Risk value
1.	Risk	1–5	1–5	0–1	0–1	0–1.41

Table 3.

Example of a table with assessed risks.

3. Method of risk management for the entire product life cycle

The first phase of the product life cycle, called conception, has a number of risk factors and influences associated with it. These risks must be treated immediately once identified, if possible. However, this is not always feasible, and so it becomes necessary to transfer the risk to the next product life cycle phase (again, where this is possible). All risks which are identified must be recorded in order not to be forgotten in the later product phases. Some risks may not be possible to eliminate but can only be mitigated to a certain level. These cases must also be transferred to the next product phase. Risks present at the conception phase which were not totally mitigated there, so that there is still a residual risk or a risk which was not possible to treat at that phase, are then inputs to the design phase. At the design phase, identified design risks are added to these inputs. Together, these risks make up the risk input to the design phase. All risks discovered at or before the design phase which have not been totally mitigated, so there is still a residual risk or risks which were not possible to treat in that phase, become inputs to the third phase: the phase of realization. The procedure is then the same as for previous phases. Risks originating at the realization phase are added to these input risks and treated together here. Risks relating to the service phase consist of risks identified in previous product phases, but not completely mitigated, plus risks particular to the service phase. It should be noted that most of these identified risks, associated with these phases, are predicted risks only. Thus, it is not possible to determine their precise probability; it is only possible to make a qualified estimate.

All risks identified in the fourth phase become the feedback for the life cycle of the new generation product—if it is impossible to treat them. The same applies to all risks which weren’t predicted but which were subsequently identified when investigating an incident—but also could not be treated. Generally, it may be said that the method leads to a closed, unceasing cycle of the risk management tasks and forms the continuous process of improvement. The entire process is displayed in Figure 4 . The detailed description of the risk management method, as it pertains to each individual phase, follows.

Figure 4.

Entire process of risk management for the entire product life cycle.

3.1. Risk at the conception phase

At the beginning of each product’s life cycle, there is always a customer who expresses his needs; these needs must be heard. There is no universal voice of the customer (VOC), each is unique, and they are very diverse. Customers have many different requirements. Even within a single purchasing unit, various different requirements may appear [7]. All these voices must be considered and balanced in order to develop a successful product. For a better understanding of the customer’s needs, a discussion with them should be held; it is important at this point to identify the basic customer’s needs. First, it is needed to define requirements, answer the questions raised by developers, and then advise and criticize the process of the actual product development or the evaluation of the prototype design. General requirements should be split into more specific detailed requirements—the customer should be urged in order to clarify and express thoroughly his demands until they make perfect sense from the supplier’s perspective.

Voice of customer is usually the input for critical to customer (CTC). Critical to customer (CTC) are measurable standards of product performance which has been determined essential to its customers. CTC is generally defined in the process of the voice of customer assessment by methods ranging from survey or interview to focus groups. CTC provides a straightforward method for the prioritization and selection of appropriate input requirements for the whole process. CTC items are internally reflected in critical-to-quality (CTQ) criteria as shown in Figure 5 .

Figure 5.

Example of critical to quality criteria.

Further, CTC and CTQ are used as inputs for risk analysis techniques like the Delphi method. Another input for the preliminary risk analysis of the entire product life cycle is the Lessons Learned database, as it is termed: recommendations based on experience, from which others can learn in order to improve their performance. This may be supplied in the form of knowledge from data product management (DPM), enterprise resource planning (ERP), customer relationship management (CRM), and supply chain management (SCM). It is necessary to consider whether a similar product has already been developed in the past and what risks occurred and how they were treated. Hence, the same countermeasures may be applied to the current product (possibly with adjustments or improvements). As was mentioned above, the inputs to the very first risk analyses should be CTC, CTQ, and the Lessons Learned database, as shown in Figure 6 .

Figure 6.

Risk process management at the conceptual stage.

It is always difficult to assess risks, especially in the initial product life cycle phases, when no or only very minimal data is provided. Despite this, the risk analysis is important and an integral part of any new product development. Every risk analyst starts with risk identification. The means by which proper risk identification can be accomplished may differ. Delphi, What If?, preliminary hazard analysis, and just a simple brainstorming are all recommended tools. Risk estimation and measurement for the early phases of a product’s life cycle are complicated. Since no real-time data are available, methods like the analytic hierarchical process, for impact, and Markov chains, for probability estimation, should be utilized. Also, specific countermeasures or treatments from the Lessons Learned database can be accessed. Subsequently, risk values are calculated in order to determine the priorities of the various risks. If a priority dictates that a risk be treated, the risk must, in most cases, be reduced, avoided, or transferred. In exceptional cases, the risk is accepted. After this treatment, all countermeasures must be verified, and all risks must be measured again in order to discover whether there is any residual risk. Subsequent risk monitoring is essential. Sometimes, it is not possible to treat certain risks or residual risks in this phase. Consequently, these risks are transferred to the next product life cycle phase along with all the accepted risks identified due to proper risk monitoring. The whole process is shown in Figure 7 . This process is identical for the conception, design, and realization phases.

Figure 7.

Process of risk treating at early product life cycle phases.

In the (conception) phase, it is relatively easy to make changes. In the subsequent product phases, the ease, and indeed possibility, of any change decreases, and the costs of changes rapidly grow over the time since the product is committed to a certain technology, configuration, and performance. Therefore, it is highly desirable to identify all risks during the first two phases—while it is still feasible to make changes and take countermeasures with certain ease. Unidentified risks in the realization and service phases may endanger the overall financial viability of the product.

3.2. Risk at the design phase

This product life cycle phase is also very likely to produce a large number of nonconformities which may cause trouble in subsequent phases. A design risk assessment is the act of determining the potential risks in the design process, either in the detailed design, in subsequent analysis or simulation, or in validation or possible tool design [8]. It provides a broader evaluation of the design—beyond just CTQs—and enables the elimination of possible failures and reduces the impact of potential failures. Thus, it is possible to categorize these risk factors into groups and manage risks for each group separately according to their severity (see Table 4 ).

	Identification		Analysis								Decision
No.	Risk	Description	Category	Treating in this phase?	Probability level	Impact level	Probability index	Impact index	Risk value	Priority	Accepted
1.				Yes/no	1–5	1–5	0–1	0–1	0–1.41	A–E	Yes/no

Table 4.

Table for the risk analysis.

The process of risk management for the design phase is shown in Figure 8 . Accepted risks and residual risks with accepted risk values from the conception phase are transferred and evaluated again at the design phase, in order to determine possible increases in risk.

Figure 8.

The process of risk management for the design phase.

The identification of new risks in the design phase usually starts with the bill of materials and its list of components. These can assist in constructing a block reliability diagram, whereby weaknesses and risks can be identified. Building of a prototype and simulations can also help considerably in the identification of new product risk areas. Then, a simulation relating to the treatment of the product and its placement into the working environment are important. For the better understanding of customer’s requirements, it is appropriate to set an appointment with the customer, introduce the prototype, and afterward possibly customize it according to the customer’s stated considerations. It is likely that other possible risks will be observed from the way the customer deals with the prototype. A simple brainstorming session with customers is often essential. Further, it is still necessary to follow CTQ, CTC, and VOC as inputs for the Delphi method. At this phase, knowledge management is easier to apply, and the knowledge from DPM, ERP, CRM or SCM, and the Lessons Learned database should be used to deliberate about risks from previous similar projects or from the past generally. It is necessary to start planning the preventative maintenance of a product.

There are specific parts and systems determined in a bill of materials at the design phase: the systems, subsystems, and components which form the final product are defined here. This also forms an input to the reliability analysis: from analyses of single components to the reliability analysis of the entire system. For the correct understanding of the entire system reliability, it is necessary to make a detailed reliability diagram of the product. This may help to uncover product weaknesses. The reliability block diagram is a diagrammatic method to scheme how the reliability or otherwise of individual components contributes to the failure of the complete, complex system. This method is also known as the dependency diagram.

The reliability block diagram is usually produced as a group of blocks connected in a parallel and serial configuration. The example is shown in Figure 9 . Each block represents a system component with a certain failure rate. There are often parallel paths, meaning that all of them must fail for system breakdown to happen. They are in contrast to the serial paths where a failure of any component leads to the system breakdown.

Figure 9.

The reliability block diagram.

3.2.1. Reliability

At the design phase, it is necessary to plan the maintenance focused on reliability. Identified risks from this phase will serve as inputs for the maintenance plan. The successful application of the reliability program demands good product understanding as well as a good knowledge of operational conditions, context, associated systems all together with possible failures, and their consequences. Maintenance is a common way of treating less severe risks. The initial maintenance program should be formed in cooperation between supplier and user. A possible reliability program application is shown in Figure 10 .

Figure 10.

Reliability program application example.

3.2.2. Disposal

During product development and production, it is essential to think of product disposal and related risks. Some of the customer’s requirements might be concerned with various regulations regarding the usage of restricted and hazardous substances. Directives dealing with the use and handling of hazardous substances, waste, and its collection are as follows:

Waste electrical and electronic equipment (WEEE)—concerning the collection, recovery, and processing of electrical waste

Restriction of the use of certain hazardous substances (RoHS)—concerning the restriction of the use of hazardous substance in products

3.3. Risk at the realization phase

CTC and CTQ requirements are the basis of the risk management at the phase of realization. Accepted risks and residual risks with accepted risk values from the design phase are transferred and evaluated at the phase of realization again in order to verify their possible increase. Prior the production start, there is a need for a thorough simulation, tests, and planning. The process of the risk management at the phase of realization is shown in Figure 11 . Once all the tests and simulations [computer-aided production engineering (CAPE), computer-aided production planning (CAPP)] are done, risks are identified and the design is validated; it should be made sure that already specified CTQs define strict quality standards in the production. These can contain tolerances, procedures, performance, and safety tests which should be done prior the product delivery to customers. All these instructions should be stated in so-called control plans and refer to prior quality planning and tests. All production processes shall be tracked and monitored in a process map.

Figure 11.

The process of the risk management at the phase of realization.

It is also recommended to use quality management tools for risk identification at the phase of realization. Most of the seven quality basic tools are quantitative methods that contribute to better process control, process monitoring, process understanding, including diagnostics, troubleshooting, and generally better process operation [9].

The entire production process must be mapped in order to identify weak and risky spots. The example of a process map at the realization phase is shown in Figure 12 .

Figure 12.

Example of a process map.

3.3.1. SIPOC

For identification of factors and elements entering the process, the SIPOC method is highly recommended. The general SIPOC process map is a chronological representation of the most significant steps (up to 6), events, or operations in a process. It provides the basis for identification of the process inputs and outputs, and hence it shows possible risks affecting the process. It also gives a simplified view of the entire process. Inputs, outputs, and also suppliers and customers (internal or external) are identified in this diagram. The SIPOC example is shown in Figure 13 .

Figure 13.

The SIPOC diagram example.

Figure 14 shows a production process. It is possible to see a certain pattern in the graph. Based on observation, it is possible to find out root causes or define a certain period when an event occurred. The run chart shows a production process during a specific part of the year. Here, a steep value which increases in the month of July can be observed and a subsequent sharp fall in the month of August. A period of interest is defined by this observation: it is necessary to find out what happened or what changed at that time. There are a few possibilities of the usage, and the method application is mostly user-friendly.

Figure 14.

Example of a production process.

3.4. Risk at the service phase

By this phase, there should already be a minimal amount of risks, and all significant risks should have been identified at prior phases as no design changes are possible at this phase. CTC and CTQ are also very important for the final phase of the product life cycle and need to be considered. Accepted risks and residual risks with accepted risk values from the realization phase are transferred to the service phase and evaluated again in order to determine whether they might increase. The entire process is shown in Figure 15 .

Figure 15.

Process of risk treating at the final product life cycle phase.

Most of these risks can only be treated by preventive maintenance, customer support, or product manual. Risks involved at this phase are usually related to stocking, transportation, or disposal. Detailed feedbacks from customers, service experience, claims, and reports are recorded in the Lessons Learned database and used for the development of the next-generation product. The process of the risk management at the service phase is shown in Figure 16 .

Figure 16.

The process of the risk management at the phase of realization.

There are various methods of interpretation in relation to life test data or operational data. Many of these interpretation methods use theoretical statistical distributions which model the lifetime of monitored components (time before failure). Hence, quantification of reliability uses methods involving mathematical statistics, and the theory of probability for which the proper theoretical distribution usage is essential.

When analyzing the reliability of electronic and other components, Weibull distribution is often used. Weibull analysis is applied when addressing the following kinds of questions: How many failures should be expected in certain conditions? How reliable is the current construction or technology in comparison with the innovated technology? How to quantify the product reliability? The advantage of Weibull distribution is its ability to approximate other distributions (e.g., exponential, normal, or log-normal). On the basis of a small sample of data, it is also capable of determining the distribution shape suitable for modeling the time to failure [10].

When analyzing reliability, complications may arise from the occurrence of censored data (i.e., if failure does not occur in all monitored components in the monitored time interval) and also when performing rapid tests. The analytical procedures of modern software tools allow to perform reliability analyses with respect to these complications and thus the prediction of failures on the qualitatively higher level [11].

3.5. Risk monitoring and root cause investigation

When monitoring risks, failed countermeasures or even new risks may be identified. When this happens, it is necessary to take action against the newly uncovered risk immediately. First, it is essential to find out whether this problem has already been observed in the past and, if so, what kind of countermeasure was used there. In this case, the countermeasure clearly must be reviewed and then improved or replaced. If the situation appears to be entirely new, however, the process of incident investigation must be initiated. Finally, not all risks can be predicted. The investigation process is based on the PDCA (Plan-Do-Check-Act—Deming cycle) cycle as shown in Figure 17 .

Figure 17.

The investigation process.

A list of the best incident investigation methods is set out in Table 5 . In addition, this table indicates whether the method is qualitative, quantitative, or combined. It also indicates the phase of the life cycle for which each method is useful and its character. Subsequently, it describes whether it is a combination of methods and option of applicability only by one analyst.

Analysis	Quantitative	Qualitative	Design	Realize	Service	Method’s character	Combination of several methods?	Can it be applied by a single analyst?
Fault tree analysis	X	X	X	X	X	Supporting		X
Event tree analysis	X	X	X	X	X	Supporting		X
Causes and consequences analysis	X	X	X	X	X	Supporting	X	X
Current reality tree		X		X	X	Supporting	X
Multiple event sequencing		X		X	X	Supporting
Sequentially timed events plotting procedure		X		X	X	Supporting	x
Schematic report analysis diagram		X		X	X	Supporting		X
Tripod beta analysis		X		X	X	Investigating
Root cause analysis		X	X	X	X	Supporting	X	X
Root cause failure analysis		X		X	X	Supporting	X	X
Events and causal factor charting		X		X	x	Supporting	X	X
Savannah river plant root cause analysis		X		X	X	Supporting	X	X
Tap root		X		X	X	Investigating	X	X
Event root cause analysis procedure	X	X		X	X	Investigating	X	X
HSYS	X	X		X	X	Supporting	X
Assessment of safety significant teams		X	X	X	X	Supporting	X	X
Safety through organizational learning		X	X	X	X	Supporting
Causal tree method	X	X		X	X	Investigating	X
Systematic accident cause analysis	X	X	X	X	X	Supporting	X	X
Systematic cause analysis technique		X	X	X	X	Supporting	X	X
Six sigma	X	X	X	X	X	Investigating	X
Management oversight and risk tree	X	X		X	X	Investigating	X
Technique of operation		X		X	X	Investigating	X
Change analysis		X	X	X	X	Supporting		X

Table 5.

The list of best incident investigation methods.

4. Conclusion

The methodology comprises the risk analysis that combines with methods for the incident investigation where the results serve as the input risks for the new-generation products. Further, the methodology suggests to exploit the knowledge database which comes to light when managing incidents or already exists, and it is used for the purpose of the risk prevention. By recording of information of the origination, progress, and the way of previous incident solutions, the solution of a new or similar incident can be accelerated. The purpose of the knowledge base creation is also the objectification of probabilities and impacts of recorded risks. These records must be, in most cases, estimated, especially for completely new products, but thanks to the knowledge base, it is possible to refine the estimates. The methodology brings a new methodological approach that endeavors not only to prevent failures but also to remove the root cause as fast as possible and minimize its consequences. The use of the methodology can be customized for all kinds of industry.

Acknowledgments

This research has been supported by the Ministry of Education, Youth and Sports of the Czech Republic under the RICE—New Technologies and Concepts for Smart Industrial Systems, project No. LO1607, by the European Commission under Marie Curie action FP7, project Risk Management Software System for SMEs in the Construction Industry (RiMaCon), project No. FP7-2012-IAPP-324387 and by the Student Grant Agency of the University of West Bohemia in Pilsen, Grant No. SGS-2015-020 “Technology and Materials Systems in Electrical Engineering.