# A Decision Support System for Better Qualitative Supply Chain Diagnoses

Anthony Fouque, Matthieu Lauras, Frederick Benaben, Hamideh Afsarmanesh

► To cite this version:

Anthony Fouque, Matthieu Lauras, Frederick Benaben, Hamideh Afsarmanesh. A Decision Support System for Better Qualitative Supply Chain Diagnoses. PRO-VE 2022 - 23rd IFIP WG 5.5 Working Conference on Virtual Enterprises, Sep 2022, Lisbonne, Portugal. 434-446 (chap. 35), 10.1007/978-3-031-14844-6_35. hal-03775866

HAL Id: hal-03775866

https://imt-mines-albi.hal.science/hal-03775866

Submitted on 27 Sep 2022

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
# A Decision Support System for Better Qualitative Supply Chain Diagnoses

Anthony Fouqué¹, Matthieu Lauras², Frederick Benaben² and Hamideh Afsarmanesh³,

¹ AGILEA, Rue Michel Larousse, 31100, Toulouse, France
[anthony.fouque@agilea-group.com](mailto:anthony.fouque@agilea-group.com)

² IMT Mines Albi, Industrial Engineering Center, Route de Teillet, 81013 Albi, France
[matthieu.lauras, frederick.benaben]@mines-albi.fr

¹ University of Amsterdam, 1012 WX Amsterdam, The Netherlands
[h. afsarmanesh@uva.nl](mailto:h. afsarmanesh@uva.nlx)

**Abstract.** In the current supply chain world where instability and variability are the norm, being able to efficiently identify/diagnose the root causes of non-performance is of prime importance. Although numerous methods exist to support quantitative diagnosis step, there are very few materials regarding the qualitative dimension of diagnosis. Additionally, the rare existing methods are very time-intensive, need scarce expertise and often produce poor results. In a such context, the problem is how to make supply chain qualitative diagnoses impactful and fast. Practically, this paper develops a business process and its associated knowledge-based system, inspired by the theory of constraints' thinking processes approach, to effectively support practitioners in their qualitative diagnosis step. A set of real industrial application cases is analyzed to discuss the implications of the contribution. It notably demonstrates that the proposal supports both increasing the impact of the diagnosis and reducing the time of the process by almost 80%.

## 1 Introduction

As [1] said, “a good doctor is not the one who first knows well all medications or who masters all healing techniques, but the one who is able to quickly make a proper diagnosis”. A right diagnosis will allow you to choose the right medication that is to say the right tool and so caring. Make a wrong diagnosis, can even cause amplification of the problem. The point is exactly the same for Supply Chain (SC) improvement step. SCs are under pressure due to the high level of uncertainty and variability they have to cope with and as a consequence, they have to be able to adapt themselves quickly if they do not want to die prematurely. To reach such a goal, SC practitioners need to develop several abilities and notably ones to detect rapidly and effectively potential weaknesses in their organization. This is generally supported by
a diagnosis step which tries to assess objectively the forces and the weaknesses of the existing SC.

But as demonstrated by [2], these methods are generally large, quantitative, expert-oriented and time-consuming. [2] also indicated that most of them do not allow producing a relevant analysis to support improvements of the SC. Let's now take time to analyze these issues and to fix the problem statement of this research work.

Basically, most of the quantitative diagnosis techniques such as Cause and Effect Diagram or Interference Diagram need long time to gather, classify and analyze data. This is nowadays particularly problematic as the data sources are numerous and as SC features change so quickly. As a consequence, these approaches often deliver obsolete conclusions. Finding a solution to speed up the diagnosis process appears now as mandatory. An approach to solve this issue might consist in supporting the step within a dedicated decision support system able to assist properly the SC practitioners.

Regarding the relevance of the SC diagnosis, authors like [3] showed that using qualitative approach might be powerful. However, despite their potentialities, [3] indicated that these qualitative approaches are very time-consuming. They also explained that only very well-trained experts are able to use this kind of approach effectively. These techniques are then poorly spread among SC practitioners. As a consequence, a solution able to make the use of qualitative diagnosis easier seems to be required by SC practitioners.

To sum up, there is a need for a SC qualitative diagnosis method that would bring relevant analysis in a very short time. The research question can then be formulated as: how to process and support a fast and relevant SC qualitative diagnosis?

To answer this question, the remainder of the paper is presented in four sections. First, an analysis of the literature will be developed to identify existing methodologies and to conclude about good practices and gaps. Second, the proposed decision support system will be developed by focusing on the business process and on the associated knowledge-based system. Third, the paper will describe and analyze a set of real industrial application cases to demonstrate the potential benefits of using such a system and to discuss about its limitations. Fourth, the paper will end up by summarizing the contributions and developing avenues for future research.

## 2 Background

Most of the SC diagnosis methodologies are generally linked to automatic control and systems theory on one hand, and continuous improvement methodologies such as Lean Manufacturing, 6 Sigma, Supply Chain Operations Reference (SCOR) or Balanced Scorecard on the other hand. In the following, we first discuss the features of them before diving in the details of the existing qualitative approaches.

### 2.1 Quantitative diagnosis methodologies

Quantitative methods were among the first to emerge in systems theory in the seventies. Nowadays, most of the quantitative diagnosis methods come from the field
of automatic control and the fault detection [4]. They are generally based on control and statistical decision theories. As shown by [5], these approaches are based on the following requirements: Early detection of small faults with short time behavior, diagnosis of faults, detection of faults in closed loops and supervision of processes in transient states. The goal is then to detect on-the-fly "potential failures to react quickly by making decisions such as reconfiguration, maintenance or repair" [5]. Obviously, these approaches are working on dedicated systems and often do not consider the interactions between them [4]. As a consequence, it is not possible to support any diagnosis step within such an approach in the context of complex systems such as SCs, or any industrial organization.

Another spectrum of quantitative diagnoses is proposed by continuous improvement approaches as the first stage of such a process is systematically a diagnosis stage. Among all the continuous improvement approaches, Lean Manufacturing is probably the most famous one. Lean Manufacturing is considered as the most effective methodology for productivity improvement in any kind of organization [6]. The main idea of Lean Manufacturing consists in managing flows in order to better satisfy the customer demand. Particularly, it focuses on the time spent by the different operations of the process in order to reduce it by eliminating wastes [7]. According to [7], Lean Manufacturing is mainly a philosophy which includes a specific toolbox able to evaluate and improve any kind of system.

Within a management control perspective, we also must consider the Balanced Scorecard approach which was created in the early 1990s by [8]. The Balanced Scorecard should be designed as "a day-to-day diagnosis tool to guide executive actions" as mentioned by [9]. On their side, [10] indicated that Balanced Scorecard can be considered as a diagnosis control system as it might be used to monitor the organizational outcomes to correct deviations from pre-set standards of performance. However, they highlighted some limits of such an approach and notably the fact that Balanced Scorecard needs frequent and regular attention from operating managers at all levels, huge amount of data regularly refreshed to be relevant, and a point of reference (to compare) must be set up a priori to any diagnosis consideration.

Additionally, Supply Chain Operations Reference (SCOR) has received a lot of attention from scholars and practitioners during the past decades for supporting continuous improvement approaches in the context of supply chain management. The SCOR model [11] provides a unified representation of SC activities with six general activities: Plan, Source, Make, Deliver, Return and Enable. Each activity can be refined into sub-activities, which are themselves decomposed into sub-sub activities, and so on. Several quantitative key performance indicators are associated to each activity in order to assess the performance of the SC and make a diagnosis. Although these performance indicators are attached to activities and well formulated, they remain very difficult to set up a proper diagnosis within an existing SC. If the decomposition process on a macroscopic level is quite generic and can be applied to a lot of industrial cases, the detailed levels might be difficult to use, due to the granularity and specificities of activity representation [12]. In addition, the SCOR model does not "try to close the loop", and there is no suggestion that the indicators should be used to manage the system. Thus, it could be rather difficult – even random in some cases – to define the necessary corrective actions on this basis alone [12].
As we reminded in this section, the main features of quantitative based diagnosis approaches and their limits, it is now time to extend our analysis in direction of qualitative diagnosis methodologies.

## 2.2 Qualitative diagnosis methodologies

Within a qualitative perspective, we identified three main methodologies in the literature:

- Cause and Effect Diagram (CED),

- Quick Scan (QS),

- Current Reality Tree (CRT).

CED are usually represented through an Ishikawa Diagram. The main idea of this methodology is to collect facts which may explain the connection between a potential root cause of the current situation and the noticed symptom. Usually, CED is composed of the following steps:

- Recording consciously each defect occurring in the company.

- Identifying the potential root causes associated to the event.

- Classifying the root causes.

- Visualizing the root causes by putting them into an Ishikawa Diagram.

CED has several advantages. The implementation is quick (only few hours are needed), participative and quite easy to get [13]. However, there is one major drawback as CED is poorly consistent in terms of diagnosis results. [13] demonstrates that for a same problem, different teams never get the same results when using CED approach. This is why we could not consider CED has good enough to reach our goal of improving the efficiency of diagnosis.

QS can be defined as a robust diagnosis methodology developed to assess the current performance of an organization's SC [14]. The core of the methodology consists in conducting the QS itself through four sources of data: attitudinal and qualitative questionnaires, process maps, semi-structured interviews and archival information [14]. Typically, the QS methodology implies a mixed approach that consider both qualitative and quantitative insights and try to make the link between them. We must also highlight that QS is an iterative process which required approximately two weeks to be executed (for the whole process). Some authors such as [15] propose to enrich the QS methodology by adding a dynamic Bayesian network to elaborate on the causal relationships previously extracted. In addition, [15] highlight several drawbacks regarding QS implementations. They notably mentioned that QS is time consuming comparing to other diagnosis methods and needs a very important expertise and experience to be used efficiently. They also indicate that the methodology is very sensitive to the completeness and freshness of the data used. In a variable world as we know in modern SCs, this is definitively a critical limitation.

The CRT methodology is based on the Theory of Constraints (TOC) body of knowledge. The TOC has been developed by [16] through a novel book named "The Goal". As for Lean Manufacturing, the TOC is also a philosophy and a toolbox which can be applied for production, distribution, project and problem-solving issues. Regarding our problem statement, we focus on the last domain of application and more specifically on what is called the Thinking Processes which are a set of logic
tools able to support the problem-solving issue [16]. The Thinking Processes involve five basic logic tools. As explained by [17], these tools use logic to help managers understand why desirable or undesirable situations occur, to ascertain the impact of interventions designed to eliminate undesirable conditions and to offer guidance on how to manage the change required for improved performance. The five tools are current reality tree (CRT), evaporating or conflict cloud, future reality tree, prerequisite tree and transition tree. In the TOC philosophy, the Thinking Processes should not only focus on the improvement of the system but also consider the change management issues. Basically, this methodology implies three major components to support efficiently the change: agree on the problem, agree on the solution and agree on the way to implement it. The Thinking Processes put a huge emphasis on the diagnosis step which is necessary to agree on the problem. In practice, this step is supported by the CRT tool. As for QS and CED, CRT is a cause-and-effect approach, but it focused on "conflicts". A conflict is a combination of two opposite actions which theoretically contribute to the same goal but do not get the same results. For example, a purchasing team can be in the following conflict: buy large quantity to save money on fixed-costs or buy just the required quantity even if fixed-costs are important. The two actions are opposite. When you buy higher quantity to scale, you decrease the purchase price which may results in more money. But when you buy only what is required, you may have less inventory which increase the cash availability. These are two opposite actions which might help the company to make money and to be more or less profitable. CRT implementation is quite similar to QS and CED in terms of process. It consists in identifying symptoms (also called undesirable effects) which are limiting the performance of the system [17]. CRT logically linked the identified symptoms through a series of intermediate entities that specify prevailing relationships downward to a core problem [17]. According to [17], the first step of CRT process consists in examining the different symptoms for possible cause-effect relationships using "if-then" logic and make appropriate logical linkages between them. Then, it consists of enhancing the linkages by introducing additional insights to ensure that the resulting relationships are clear and sufficient. As for QS and CED, CRT has some drawbacks as it is time consuming and needs high level of expertise and experience to be performed. However, CRT has a huge advantage compared to others which is its robustness. As mentioned in [3], when different teams work on the same list of symptoms with this approach, they achieved systematically the same root causes. Moreover, [3] also demonstrated through a specific experience that consisted of submitting a same problem to three different teams using CED, QS and CRT to solve it. It appeared that only CRT approach allowed finding the real root causes of the undesirable effects.

To sum up, the results of this approach can be described with the following chart:

<table><caption>**Table 1.** Qualitative diagnosis methodologies comparison.</caption><thead><tr><th></th><th>CED</th><th>Quick Scan</th><th>CRT</th></tr></thead><tbody><tr><td>Ability to make robust diagnosis</td><td>Low</td><td>Medium</td><td>High</td></tr><tr><td>Level of experience and expertise required</td><td>Low</td><td>High</td><td>High</td></tr><tr><td>Time to perform</td><td>Fast</td><td>Long</td><td>Medium</td></tr></tbody></table>
## 2.3 Problem formulation

According to the previous table, there is no methodology which provides full benefits in the qualitative diagnosis approach. The first consideration of any diagnosis is to make sure that the results are pointing to real root cause. Consequently, the CRT is probably the best tool to use when you want to focus on qualitative information. However, there are several drawbacks in the process to build a CRT efficiently: The high level of competencies, the time to perform it, the visibility of the results and the capacity to use it easily. The question we are trying to answer in this study is finally: how can we speed up the process of CRT’s diagnosis while improving usability of it? To reach such a goal, we propose to build an innovative decision support system (DSS) as described in the next section.

# 3 Decision Support System Proposal

This section develops the features of the Decision Support System we suggest to better benefit from the CRT methodology to support a SC diagnosis step. Practically, this section gives first an overview of the Decision Support System and explains how to use it concretely. Then it explains the functional architecture of the DSS and its key components: the key algorithms and the core knowledge base. Finally, some information about the technical architecture used to run the DSS is presented.

## 3.1 Overview of the DSS

As demonstrated in the previous section, one major issue with CRT methodology is the process is long to execute, particularly regarding the time needed to build the CRT itself. This is mainly explained by the fact that the combination of potential symptoms, facts or conflicts is huge and depending of numerous features and behaviors of the studied company. Consequently, our proposal suggests speeding up the process consists in questioning the user in order to focus only on symptoms, facts and conflicts which could occur regarding the gathered knowledge about the studied system. In essence, the DSS will start by asking some key features about the company to the user. This information is mainly about name of the company, scope of the improvement project and material-flow strategy (Make-To-Stock, Make-To-Order, Engineering-To-Order). Then, the DSS will ask questions to the user in order to help him/her identifying symptoms, facts and potential conflicts. A first set of questions will be generating based on the key features indicated during the first step. Then, questions will be adapted on-the-fly depending of the answers given by the user in order to avoid orienting user on useless directions. This is made to optimize the time needed to gather the necessary information to build the CRT. When, the DSS gets enough information to set up the CRT of the studied system, then it will automatically build it up and display it. The user will have the possibility to update the result by modifying directly the CRT (e.g., add / withdraw some elements) or by going back to the previous step in order to indicate additional symptoms, facts or conflicts. Finally,
based on the obtained CRT, the user will have the opportunity to formulate his/her qualitative diagnosis to support his/her SC improvement step. Figure 1 summarizes the DSS steps and the following sub-section will give more information about how technically this DSS runs to get such a result.

<figure><img src="image_1.png" /><figcaption>Fig. 1. Overview of the proposed DSS</figcaption></figure>

## 3.2 Functional architecture of the DSS

As mentioned on Figure 2, the functional architecture is composed of 3 types of components: interface, services and database.

- The interface component is about the necessary User Interface functionalities as for any kind of DSS. There is no specific innovation on this part.

- The services' components include some important contributions through specific algorithms allowing to gather and exploit the useful knowledge for an automatic generation of the CRT. This is one of the main contributions of the proposal.

- The database components are in the core of the device as it includes some usual database for the storage of the collected information, but also because it includes a specific database called “Generic Reality Tree”. This is another major contribution of the proposal.

Let's start by presenting the Generic Reality Tree database. This database is a knowledge base which represents all the possible connections which can exist in a Make-To-Stock environment between symptoms, facts and conflicts. This knowledge base has been established conceptually by the “web of conflicts” proposed by [18] and recently enriched by [19] based on a review of both practices and literature. In this paper we did not try to challenge the content of this knowledge base but only tried to instantiate it practically through our DSS. However, we must give some insights regarding the content of this database to well understand how the DSS runs. Basically, the Generic Reality Tree database makes the link between the current major conflicts which can exist in a production environment (e.g., buy in volume vs buy only what's needed; run larger batches vs run smaller batches; authorize overtime vs
do not authorize overtime, etc.) and the undesirable effects, called symptoms (e.g., too much inventory, bad quality of service, machines / tools which are not used by shopfloor, etc.). In [19], the authors suggest to represent this knowledge base through a logic graph. Practically, the Generic Reality Tree database is the pivot of the DSS as it will be used to select the questions that the system must ask to confirm or infirm the existence of this or that symptom. Basically, the DSS will travel across the graph to automatically ask additional questions in order to close potential options or at the opposite, confirm some other ones. The final CRT that the DSS will build up will be composed of all validated symptoms, facts and conflicts for the studied system as well as all the validated connections. The diagnosis will be based on this mapping of the current situation.

<figure><img src="image_2.png" /><figcaption>Fig. 2. Functional architecture of the DSS</figcaption></figure>

Obviously, the knowledge base is not enough to get such a result. Some value-added services are needed to exploit properly the knowledge of the Generic Reality Tree on one hand, and the knowledge given by the user about the studied system on the other hand. In our proposal, four main algorithms have been developed and implemented as shown on Figure 2. Practically, these algorithms manage the following issues:

- Algorithm 1 is about generating the first set of potential symptoms and conflicts that the studied system should occur based on the key features of the system indicated by the user and of course, the Generic Reality Tree database.

- Algorithm 2 is about travelling across the knowledge base function of the answers given by the user to both confirm / reject potentialities and ask for new questions able to open on new set of potentialities according to previous ones.

- Algorithm 3 is about sorting and extracting the valid set of symptoms and conflicts as well as all associated connections in order to build the CRT up.

- Algorithm 4 is about building the CRT itself and displaying it in order to allow the user analyzing it on one hand, and potentially editing it to help interpretation along on the other hand.
In addition to the algorithms previously described, we also considered the
possibility for the user to fill information directly into the system without following
automatic recommendations. To support this additional way to gather relevant
information, some syntactic algorithms have been developed to recognize proximity
between the terms that a user can choose to express a given symptom. For instance,
the DSS should have been able to identify that "high inventory" and "high stock" are
two different wordings for a same symptom.

3.3 Technical architecture of the DSS

The DSS has been designed as a Software as a Service developed using Java
languages. Basically, there are 5 technical components which are:

- User Interface based on ReactJS.

- Rest API for managing the security of the application based on Spring web and Spring security

- Core services for supporting the main functionalities based on Java coding.

- Relational database for managing standard database through object-relational mapping and data access object (MyBatis).

- Graph database for managing logic graphs that CRT methodology requires through object-relational mapping and graph data access object (OrientDB).

4 Application case

The developed DSS has already been experimented on more than 50 real industrial
cases during the last few months. Among them, we decided to present the case of a
SME (55 persons) from the industrial sector which manufactures springs for
aeronautics, railways and nuclear, oil & gas. The production is divided into two
segments: short springs and long springs. The industrial process can be summarized
as described in the following Figure.

<figure><img src="image_3.png" /><figcaption>Fig. 3. Functional architecture of the DSS</figcaption></figure>

Practically, the diagnosis operating process based on the proposed DSS is defined
through the five steps described on Figure 4. The setting-up has been conducted via 5
interviews covering production, supply, planning and quality functions.

<figure><img src="image_4.png" /><figcaption>Fig. 4. Operating process</figcaption></figure>
In the context of these exchanges, we were able to note the following symptoms:

- Suppliers are often late;

- The production system is obliged to incur additional expenses to deliver on time (overtime, temporary workers, subcontracting);

- The sales order book is decreasing;

- The company buys quantities of raw materials in excess of its needs;

- The stock (raw material, in-progress, finished product) is increasing;

- Team productivity is decreasing;

- Priorities in the workshop change regularly.

<figure><img src="image_5.png" /><figcaption>**Fig. 5.** Sample of questions automatically generated for the company by the DSS (left) and extract from the automatically deduced tree (right).</figcaption></figure>

The list of symptoms was integrated into the proposed DSS as outlined in previous sections. At this stage, the DSS has been able to generate a set of questions to refine and consolidate the initial diagnosis. Basically, the tool automatically generated 57 questions as shown in the Figure 5. To answer these questions, we brought together the 5 people initially interviewed to collectively answer each of the proposed questions. Once all the questions had been dealt with, and therefore all the symptoms had been validated, we were able to display the complete tree. Given the richness of this tree (difficult to read in the format of this document), we only propose a quick snapshot of it on Figure 5 and discuss several specific extracts without displaying it in full. Basically, the tool highlighted automatically three major conflicts:

- The conflict between making to order or making to stock. If this conflict exists, then the system will seek to protect itself through stock or time. These protections will generate more stock of raw materials and work in progress. This stock will slow down the flow and therefore increase manufacturing cycles when, at the same time, it generates a greater risk of obsolescence;

- The conflict between buying the necessary quantities or buying more than needed. The point is the quantity bought is large then it will generate stock. And this stock generation will lead to an increase in cycles and thus impact the entry of cash flow significantly;

- The conflict between producing large or small batch sizes. Through this conflict, the tree suggests that the increase in batch sizes generates an increase in the stock of raw materials and therefore purchases in higher quantities.
These purchases in higher quantities increase variable costs and invariably impact the company's income statement.

These 3 conflicts have been validated by the practitioners and used for developing a concrete improvement plan for the company that is currently ongoing. In terms of implementation, it took half a day to conduct the interviews and visit the company. Entering the information into the tool took 23 minutes (answers to suggested questions). Reading, interpreting and sharing the diagnosis (the resulting tree) took 1 hour. To compare with the days and weeks usually need with the existing methods.

# 5 Conclusion and perspectives

In the work carried out in this paper, we found that most of the existing SC diagnostic methods were based on quantitative data which unfortunately now tend to be valid only for very short periods. Other approaches advocate conducting the SC diagnoses mainly through qualitative approaches. Unfortunately, the findings are not much more satisfactory than for quantitative methods. Indeed, the existing methods also require a significant amount of time to implement. In addition, they often require technical expertise and very significant business experience. Finally, they have the disadvantage of having a very low level of quality, and are highly dependent on the people who carry out the diagnoses. To solve this issue, we designed, structured and developed a decision support system (DSS) to carry out organizational diagnoses of SCs based on qualitative data. This DSS, directly inspired by the Thinking Processes, includes a functional dimension, an implementation process and a complete technical architecture, instantiated in the framework of a software prototype. The relevance and the usability of the proposal have been tested on more than 50 real industrial cases among which one of a number of springs production companies was used as an illustration in this paper. We noticed that the conversion rate to the improvement stage for these cases were 70% on average whereas it was only 37% for all other diagnoses (about 100) made during the same experiment without our DSS. We also noticed that the consultants who used our DSS needed 32 minutes for making a diagnosis while days were needed for the others.

Many research avenues arise from this research work. Indeed, the use of the DSS is quite significant and regular with users. Thus, the knowledge base of the DSS is developing. One line of research could be to study the recurrences of symptoms and conflicts according to the typologies of companies diagnosed. These analyses could lead to the consolidation of the knowledge base and perhaps to its development as well. Another one is related to the resulted trees deduced by the DSS which can be likened to neural networks. We could imagine utilizing this information network in order to influence the questioning even more with users. In addition, we could imagine the DSS being linked to market trend information that would help identify potential symptoms. This would give users the opportunity to anticipate the actions to be implemented.
References

1. Ben Fredj-Ben Alaya, L. (2016). VSM a powerful diagnostic and planning tool for a successful Lean implementation: a Tunisian case study of an auto parts manufacturing firm. Production Planning & Control, 27(7-8), 563-578.

2. Foggin, James H., John T. Mentzer, et Carol L. Monroe. « A supply chain diagnostic tool ». International Journal of Physical Distribution & Logistics Management 34, no 10 (2004): 827 55.

3. Doggett, A. Mark. « Root Cause Analysis: A Framework for Tool Selection ». Quality Management Journal 12, no 4 (2005): 34-45.

4. Ribeiro, L., & Barata, J. (2011). Re-thinking diagnosis for future automation systems: An analysis of current diagnostic practices and their applicability in emerging IT based production paradigms. Computers in Industry, 62(7), 639-659.

5. Isermann, R. (1997). Supervision, fault-detection and fault-diagnosis methods—an introduction. Control engineering practice, 5(5), 639-652.

6. Urban, W. (2015). The lean management maturity self-assessment tool based on organizational culture diagnosis. Procedia-Social and Behavioral Sciences, 213, 728-733.

7. Womack, J. P., Jones, D. T., & Roos, D. (2007). The machine that changed the world: The story of lean production--Toyota's secret weapon in the global car wars that is now revolutionizing world industry. Simon and Schuster.

8. Kaplan, R. S., & Norton, D. P. (1996). Using the balanced scorecard as a strategic management system.

9. Williams, K. (2004). What constitutes a successful balanced scorecard?. Strategic Finance, 86(5), 19.

10. van Veen-Dirks, P., & Wijn, M. (2002). Strategic control: meshing critical success factors with the balanced scorecard. Long range planning, 35(4), 407-427.

11. Huan, S. H., Sheoran, S. K., & Wang, G. (2004). A review and analysis of supply chain operations reference (SCOR) model. Supply chain management: An international Journal.

12. Lauras, M., Lamothe, J., & Pingaud, H. (2011). A business process oriented method to design supply chain performance measurement systems. International Journal of Business Performance Management, 12(4), 354-376.

13. Park, J., Nam, G., & Choi, J. (2011). Parameters in cause and effect diagram for uncertainty evaluation. Accreditation and quality assurance, 16(6), 325-326.

14. Naim, M. M., Childerhouse, P., Disney, S. M., & Towill, D. R. (2002). A supply chain diagnostic methodology: determining the vector of change. Computers & industrial engineering, 43(1-2), 135-157.

15. Childerhouse, P., & Towill, D. R. (2011). Effective supply chain research via the quick scan audit methodology. Supply Chain Management: An International Journal.

16. Goldratt, E. M., & Cox, J. (2016). The goal: a process of ongoing improvement. Routledge.

17. Kim, S., Mabin, V. J., & Davies, J. (2008). The theory of constraints thinking processes: retrospect and prospect. International Journal of Operations & Production Management.

18. Smith, D. (1999). The measurement nightmare: How the theory of constraints can resolve conflicting strategies, policies, and measures. CRC press.

19. Fouque, A., Lauras, M., Afsarmanesh, H., & Benaben, F. (2018). Toward automated qualitative supply chain diagnoses. In ILS 2018-7th International Conference on Information Systems, Logistics and Supply Chain (pp. p-296).