The derivation and visualization of supply network risk profiles from product architectures

The architectures of extended enterprises, including the supply networks that design, develop and support large, complex, engineered products, often reflect system‐level design decisions made very early in the product development process. Design tools used at this, preliminary design, stage focus on the physics and optimization of product system behaviors. Comparable tools for the consideration of extended enterprise perspectives at this stage are not available despite the costs of non‐quality often attributed to supply chain issues related to early design decisions. This paper introduces an interface to a discrete event simulation package that derives supply chain processes from product system architectures, so enabling the quantification and visualization of supply chain risk in early design decisions. The interface uses input data, in the form of a product architecture and associated make‐buy scenarios, which are available in the preliminary design process. Supplier data needed to drive the simulations is predefined and editable by users. Results from a proof‐of‐concept software prototype demonstrate the feasibility of generating enterprise architectures from product architectures and coupling these with a systems design vee model to create executable simulation models that can be used to identify, quantify and visualize engineering supply chain process operations and consequential risks.

where details of production and other lifecycle processes, and the organizations that will deliver them, are a key part of the technical data package that contains the evidence on which certification decisions are based. Two key milestones in the certification of a new product are the decision (made by the prime contractor) that a given design is a candidate for certification and the decision (made by the regulator) to issue a type certificate for the design. This type certificate covers not only the design of the product but also downstream processes such as production, maintenance, repair and overhaul, all of which are critical to maintaining the airworthiness of a given product through its working life. The focus of this paper lies in the part of the product development process that sits between these two milestones: where test products, such as aero engines, are manufactured and the testing required for airworthiness certification is carried out. Both the manufacturing processes used and the organizations who carry out these processes are considered in the final certification decision, and any changes after a product has been certified require regulatory approval.
At this stage in the product development process, schedule risk is a high priority because production of products for market cannot begin until the necessary certification has been gained.
The architectures of extended enterprises, including the supply networks that design, develop and support large, complex, engineered products, reflect [product] system-level design decisions made early in the product development process. For example, Huth et al., 3 highlight make-buy decisions, often made very early in the design and development process, as a key factor in overall project success. However, design tools used at this stage of product development focus on the physics and optimization of [product] system behaviors. Comparable tools for the consideration of supply chain perspectives are not available despite the costs of non-quality often attributed to supply chain issues. For example, the UK's Crossrail project lessons learnt include recommendations for the management of quality in supply chains. 4 The purpose of this paper is to introduce a proof-of-concept software prototype that demonstrates the feasibility of generating a supply chain structure from a product structure and an associated make-buy scenario. The resulting supply chain structure is coupled with a systems design vee model 5 to create an executable supply chain process simulation model. The model is imported into the simulation package to enable the identification, quantification and visualization of supply chain schedule risks in early design decisions. In addition to these technical requirements, there is an equally critical requirement to avoid increasing the resources (e.g., time and expertise) needed for preliminary design. To this end, the software prototype uses input data that is already available in preliminary design and generates output data that is suitable for use by designers with limited or no specialist knowledge of supply chain management or process simulation tools.
The approach introduced in this paper integrates research in three areas of work, extended enterprises, design and make supply chains, and make-buy decisions, into a product development context (see Section 2). In this way, we form key design requirements for the approach introduced in Section 4. These design requirements and the research methodology used to establish the approach are outlined in Section 3 and a case study used to evaluate the approach is provided in Section 5.
Finally, in Sections 6 and 7, we discuss the implications of this work for the development of future design tools and consider issues that would need to be addressed to realize such tools.

BACKGROUND
Significant lifecycle costs are committed very early in the design process when there is limited knowledge of the design. For example, Asiedu and Gu 6 report that over 70% of lifecycle costs are committed in this way. An early stage of a product's lifecycle is manufacturing, where the product begins its life, but these costs continue through the entire life of the product and are increasingly important for the complex networks of organizations who operate and support large, complex, engineered products through and at the end of their lives.
Extended enterprise system architectures, including the supply networks that design, develop and support such products, often reflect system-level design decisions made early in the product development process. 7 However, design tools used at this stage of the development process focus on the physics and optimization of [product] system behaviors. Comparable tools for the consideration of extended enterprise perspectives are not available despite the costs of non-quality often attributed to supply chain issues. Browning and Eppinger 8 report early work on product and process architectures and highlight the need to trade off delivery time (related primarily to process architecture) and quality (related primarily to product architecture) to deliver maximum value to customers. Sosa et al. 9 explore implications of mismatches between organizational and product architectures and how entrenched organizational relationships can have a detrimental impact on design innovation. Further, Gokpinar et al. 10 introduce the term "coordination deficit" as a means to quantify mismatches between product architectures and organizational structures and conclude that this affects product performance. Their work uses engineering change orders as a measure of product development performance, and takes a system of systems view of the product, meaning that relationships between parts are functional and physical interactions between parts.
In contrast, the research reported in this paper regards the product as a system of sub-systems and so the relationships in the product architecture are part-whole relationships. 11 DeRosa et al. 12  A number of authors provide approaches for the management of engineering supply chain risk that begin with the identification of risks but all relate to post-certification production processes where delivering orders in full and on time, and minimizing costs, are priorities.
To our knowledge, none relates to precertification processes where the priority is to gain regulatory approval for the design and its lifecycle processes (e.g., production, maintenance, repair and overhaul) as quickly as possible. Oliveira et al., 21 in a review of simulation methods for supply chain risk management, identify disconnects between risk management, simulation and optimization methods as an important knowledge gap in supply chain performance measurement systems.
The approach introduced in this paper could form a future tool for the identification of supply chain risk: the first stage of Oliveira et al' .s supply chain risk management framework. 21 . Fig. 9 The need for such approaches is highlighted in the tools and techniques listed by Oliveira et al., none of which reflect the product architecture which has such a significant impact on supply chain structure and so its operation and risk. Suffo

RESEARCH METHODOLOGY
The approach introduced in this paper is the result of research spanning almost 20 years that has involved the development of software prototypes evaluated using case study data with target users. In recognition of the observation that engineering supply chain and other organizational structures tend to mirror product architectures, 25 an initial extended enterprise design tool was proposed by McKay and de Pennington. 26 This enabled the analysis of extended enterprise configurations with respect to Fine's electronic proximity measure. However, a key limitation was the static nature of these network models. To produce dynamic models, for example, to enable process simulations, we needed a process model that reflected the activities being carried out by the organizations in the network and, for this process, a means of measuring process performance.
From work on design and make networks in the aerospace sector, 27 a need was identified for a design tool that, as early as possible in the design process, could be used to quantify and visualize supply chain implications of early design decisions when product architectures are being fixed. In addition to this primary functionality, key requirements were that such a tool was (i) usable by design engineers with limited time and supply chain knowledge, and (ii) used only data that was available early in the design process. A process simulation tool, version 22.0a of Lanner's WITNESS discrete event simulation system i , was i https://www.lanner.com/en-us/technology/witness-simulation-software.html F I G U R E 1 Example used to introduce the approach selected to support the quantification and visualization process. However, given that design engineers were unlikely to be process simulation specialists, it was decided to produce a simulation framework model in WITNESS that would read in automatically a product architecture and associated make-buy scenario and generate the required model logic

PROPOSED APPROACH
This section uses a schematic example to introduce the six key stages of the approach: (i) Define a product breakdown structure and make-buy scenario; (ii) Generate a supply chain structure from the break-down structure and make-buy scenario; (iii) Elaborate the supply chain structure into a supply chain process; (iv) Translate the supply chain process into a discrete event simulation model; (v) Quantify, visualize and experiment with alternative product architectures and make-buy scenarios, and so supply chain risk profiles; and (vi) Compare supply chain risk profiles with each other.
In Section 5, we demonstrate its applicability to a real-world case study.

Define a product breakdown structure and make-buy scenario
The example used to introduce the approach is a part, A, that has two breakdown structures shown in Figure 1

Generate a supply chain structure
The approach builds on the systems design vee model shown in RAEng systems engineering vee model 28 and establishes an explicit relationship between a given product's architecture and its development process. The vee model acts as a recursive process template (illustrated in Figure 2(B)) that is elaborated through the development process depending on design decisions related to the product being developed and its architecture. In the process template, systems that are decomposed into further [sub-]systems are referred to as "assemblies" and are treated differently to systems that are not further decomposed which are referred to as "components". As a result, the design process structure varies depending on design decisions made during the development process; this means that it is not possible to define, a priori, a simulation model for a given system design process.
The approach introduced in this paper addresses this issue by providing a mechanism that derives such a process from a given product architecture. We used the systems engineering vee but, in principle, there is no reason why the vee model could not be replaced with an alternative model, for example, to suit practises in specific sectors. Figure 3 shows the design processes that result for Scenarios A and C. In addition to the process structure, the key feature to note is the flows between Given a product development process and a make-buy scenario, it is possible to establish which of the process steps are carried out by which organization. This is shown for Scenarios A and C in Figure 4 for the design aspects of the make-buy scenarios, and in Figure 5 the resulting design supply chain structure for Scenario A is shown. Key points to note are: (i) if a part is designed in-house then the organization responsible for the design of the parent part is also responsible for the design of the part (e.g., see Parts D and E in Figure 4(B)); and (ii) if a part is designed externally then a new organization is needed to take responsibility for the design of the part (e.g., see Parts D and E in Figure 4(A)).
The structure of the manufacturing portion of the supply chain (shown in Figure 6) is derived through a comparable process. However,

Elaborate into a supply chain process
The process that each organization carries out at a given point in the supply network depends upon its location in the double vee model and the part that it is working on. Details of the processes at each stage of the double vee are shown in Table 1. It can be seen that the process steps reflect the activities in the systems design vee model and whether the item being processed is a component or an assembly. The results of applying this to the Scenario C supply chain structure are shown in Figure 8 where, for clarity, the organizations are shown in white text on black hexagons associated with each process step.
To form the basis of an executable simulation model, a process such as the one shown in Figure 8 needs more detailed characterizations of its process steps. Given the focus on schedule risk, for this research these attributes related to the time taken for each process step. However, if the approach was used to assess a different performance indicator then these attributes would need to be adjusted to reflect this. The timing data used in the current version of the interface is shown in Table 2. There were a number of challenges in establishing Manufacture a system (or assembly) with n parts 0.1 × n(n-1) Design a system (or assembly) with n parts 0.5 × n(n-1) Integrate designs to form a system (or assembly) with n parts 0.5 × n(n-1) Place an order 0 values for these attributes. The root causes of these challenges were: (a) the time taken to design a given product (i.e., designing either a fully defined component suitable for use by a manufacturer or a subsystem architecture and requirements for each sub-system suitable for a design supplier) is not typically known and (b) the time taken varies depending on the complexity of the design. However, given that our goal was to generate risk profiles that could be compared with each other rather than absolute times taken, we used relative timing data based on two rules of thumb. Firstly, the time needed to manufacture a component is one time unit provided the design is complete and correct and the time needed to create such a design is five times longer than the time to manufacture it, and so takes five time units. Secondly, for assemblies, all possible interfaces between parts, whether required or not, need to be considered so the relative time needed to process an assembly is related to the number of possible interfaces between parts, that is, n(n-1), where n is the number of parts. The same relative times for components were used for assemblies (i.e., design (x5) and manufacture (x1)) and, again a rule of thumb, the time needed for each interface was one tenth of the time needed for a component. The results of this are shown in Table 2. As already noted, these are estimates and, if the interface was used in real-world settings, they would need to be validated and adjusted accordingly. In the implementation of the interface, the component design and manufacture times for each part are captured in a spreadsheet so these are straight forward to modify after the supply chain structure has been generated and before the simu- Combining this data with the supply chain process in Figure 8 creates a deterministic model that will always take the same amount of time to run, that is, the time of the slowest path through the process. In practice, supply chain risk arises from randomness within the process. just that, models, and we are aware that data in this area is largely in the heads of experts (to date). However, the necessary accuracy of a given model depends on its purpose and more work is needed to assess the feasibility of accessing more accurate data at an early stage (e.g., by using databases of experience coupled with expert amendments for specific industry sectors).
Rework, on the other hand, cannot be modelled using data within individual process steps because it spans multiple steps. In practice rework can be triggered through the entire design and make process.
However, the approach reported here focused on rework triggered by requests for concessions after a design has been approved as a candidate for certification but before it has been approved for certification (i.e., in the Flow up of products regions in Figure 7). The rationale for this was that the majority of significant schedule delays in the development of aero engines were attributed by industry experts to concessions raised during manufacture, after a candidate design for certification had been approved, rather than across the different stages of the design process. For this research, rework has two key characteristics: a need for rework, which appears randomly in the manufacturing process through requests for concessions, and the degree of rework, which governs how far back in the design process a given rework task must return. Together these characteristics result in randomly used feedback loops across tiers in the supply network. Again, the models could be enhanced to include more detail on this in future. However, the granularity of the model that can be created is somewhat dependent on the data available (either from collected data or expert opinion) and affects both the accuracy and usefulness of the model. For this reason, and as with any model, for any chosen level of simplification a model needs to go through a validation process before use in real-world applications. Table 3 gives the parameters used to characterize rework in this study.
The values were used to generate the results presented in this paper TA B L E 3 Probabilities for whether rework will be raised and, if so, its extent (i.e., the number of stages back in the process that need to be redone)

F I G U R E 9
Schematic of the pre-built component design process simulation module F I G U R E 1 0 Schematic of the pre-built assembly/system design process simulation module. NOTES: (i) Specify architecture includes specification of sub-system requirements;(ii) The Design components step is expanded using the template in Figure 9 and the same limitations apply as those in the discussion of Table 2. Like the process time data in Table 2, in our implementation the values in Table 3 are stored in a spreadsheet so can be easily adjusted.
The data related to the degree of rework, again in the form of probabilities, are on the left-hand side of Table 3. As can be seen from the column headings, two factors are used to specify the degree of any given rework process. These are (1) the number of design process steps across which a given request creates rework, and (2) whether this rework is of the design requirements (which applies to components) or the design definition (i.e., the TDP, which applies to assemblies). To explain how these work, more detail is needed of the design process models used in the pre-built design process simulation modules (see   Table 3. As can be seen from Figure 11 The design process for each part is triggered when the design process is initiated and during manufacture when requests for concessions F I G U R E 1 1 Schematic of the simulation model for the design and verification of System A and Component B derived from the simulation modules in Figures 9 and 10 are raised. The data related to the need for rework, in the form of concessions, is in the two right-hand columns of Table 3. These are the probabilities that a concession request is raised and, once raised, whether it is rejected or not. For example, the data on the first row says that there is a 20% chance of a concession request being raised for an assembly that was designed in-house, and, as with all requests, there is a 10% chance that the request will be rejected. For the 90% of requests that are not rejected, rework activity is triggered in the design process starting at the prime contractor in the flow up of designs stage of the development process (e.g., PC, "Integrate sub-systems B&C & Verify System A" in Figure 8).
Together, the rework loops within the design process and the rework resulting from requests for concessions create the schedule risk reflected in the risk profiles generated. Given a need for rework to be carried out by an organization, the third factor that affects the speed with which rework can be completed, and so schedule risk, is each organization's design capability. For this research, organizational capability is the combination of competency and capacity. In the aerospace sector, all candidate suppliers have completed a supplier selection process that confirms their competency. For this reason, organizational competency was not treated as a schedule risk factor but the capacity of each organization in the network was. In this paper, capacity is a measure of the resources available within an organization to deliver one or more processes. We quantify capacity as the number of simultaneous processes an organization can carry out, using a value of one for low capacity and a value of five for high capacity. Like the process times in Table 2, this is held in the Excel spreadsheet so straight forward to change before the simulation model is created.

Translate into a simulation model
As is evident from the process model in Figure 8, which corresponds to an unusually simple product architecture, the time needed to create a simulation model, even for an expert user, would be significant.

Quantify, visualize and experiment with supply chain risk profiles in the simulation package
Once created the simulation model can be run multiple times to create a risk profile for a given scenario. The histograms shown in Figure 12 are based on 1000 runs. Figure 12(A) shows the risk profile for Scenario C with a capacity of one for all organizations, and (b) the risk profile for Scenario C with a capacity of five for all organizations. Results of an initial analysis of the data used to produce the results given in Figure 12 are shown in Figure 13. From Figure 12, it can be seen that capacity impacts design and make time, and so supply chain risk. Further, from Figure 13, in general, simulation runs with fewer concessions take less time although this is not always the case. However, it should be noted that there were few instances of runs with five or six concessions (see Table 4) which would explain why those are misaligned.

F I G U R E 1 2
Risk profiles for Scenario C with low (A) and high (B) organizational capacities (NOTE: In both charts, the X-axis is the time taken (in simulation system time units) for the supply chain process to run and the Y-axis is the probability that the supply chain process will take each amount of time.)

Visualize and cross-compare supply chain risk profiles in Excel
Each of the histograms in Figure 12 provides a quantification and visualization of risk for a single make-buy scenario. However, they are difficult to compare with each other because the x-axes have different scales, related to the range of times taken in the given simulation.
To enable comparison of alternative profiles, the results of different simulation scenarios are exported to Excel where results for multiple make-buy scenarios can be visualized. The results of this for the example used in this section are shown in Figure 14 where the x-axis is the ranges of times taken and the y-axis is the probability that the time will fall into a given range based on 1000 runs of the simulation model. For the example used in this section, this results in a simple visualization but, as will be seen in the next section, such profiles provide more value in real-world cases.

CASE STUDY APPLICATION
In this section we introduce a product case study that was used to evaluate the approach using available design data. The selected product, illustrated in Figure 15, was a ground support trolley that is used in the lifecycle support processes of an aero engine. The design data provided were the engineering drawings that define the product; these were used to create a CAD model from which the illustration and parts list in Figure 15 were derived.
Two product architectures (see Figure 16), each with four makebuy scenarios (see Table 5), were developed from the parts list which, in the assembly drawings, was the flat structure shown in Figure 16(B).
Design and make supply chain structures were generated for each of the make-buy scenarios. This resulted in four supply chain structures, corresponding to whether the product structure was flat or indented,

DISCUSSION
This paper has introduced an interface to a discrete event simulation package that derives supply chain processes from product architectures, so enabling the quantification and visualization of schedule risks in engineering supply chains used to produce test products as part of design certification processes. An important feature of the interface is its use of input data (a system architecture and associated make-buy scenario) which are available early in the design process. In this way, we have demonstrated the feasibility of bringing supply chain thinking into early design processes without the need for engineering designers to become supply chain or simulation specialists, or spend time creating data sets for supply chain applications. However, further work is needed for such tools to become an integral part of day-to-day design processes. In this section we discuss three key areas: model validation, embedded domain specific assumptions such as those related to specific industry sectors, and the need for supplier and supply chain data.
The interface generates discrete event simulation models that are well-suited to supply chain processes where key events are the delivery of information and goods from one organization to another. The models and resulting risk profiles have been face validated with industry specialists but further work is needed to validate the simulation models, and so risk profiles that are produced, more objectively. This is challenging because, at the design stage, the networks being simulated do not exist in the real world. In addition, the necessary degree of accuracy is unclear and may well vary across application domains.
However, in validating the models, it will be important to remember that the risk profiles are relative to each other and intended for use in design trade-off decisions. If more accurate predictions of the time needed to design and make a given product configuration were needed then it would be better to calculate them using purpose-built simulation models. However, building such models would only feasible later in the product development cycle when, for example, suppliers have been selected and so supplier data is available. By this stage of the product development process, many supply chain costs will have been designed into the product indicating a need for different kinds of supply chain simulation model with different degrees of validation and verification at different stages in the product development process.
The overall approach introduced in this paper is applicable to any situation where design decisions related to product architecture impact on supply chain structure. However, the interface itself has embedded within it several assumptions related to the industry sector (civil aerospace) for which it was developed. Some of these, such as the prebuilt modules that represent processes within individual organizations and the process timing data, are straightforward to adjust because data values can be modified and alternative pre-built modules used. However, other assumptions are less straight forward to adjust because they permeate the entire interface. For example, the process structures used (such as the systems design vee model in Figure 2, the development process phases in Table 1, the double vee model introduced in Section 4.2, and the processes for the management of change requests reflected in Table 3 In addition to an appropriately structured and validated model, the quality of the results from any simulation depends on the quality of the data that drives it. For example, any supply chain simulation model needs data related to suppliers and their performance. In this paper the data used to drive the simulations was based on rules of thumb (see Tables 2 and 3) that were applied to all suppliers in the same way.
Early in the design process, it is unlikely that specific suppliers will have been identified so the characterisations of suppliers we used were limited to capacity which, in itself, is represented crudely as the number of parallel processes a supplier can carry out. In the software prototype developed as a part of this research, the supplier for each part is specified in a spreadsheet that is generated from the make-buy scenario and can be edited before the simulation model is generated. However, only supplier names, capacities and design and make times for components can be edited. Whether more sophisticated definitions of suppliers are necessary could be a part of future model validation efforts that could include sensitivity analyses. For example, Gosavi et al. 29 provide an approach for understanding risks in the negotiation of contracts with suppliers based on previous experiences of the contracting organization. Similar data could be incorporated into the models reported here and, in the future, approaches such as that reported by Gosavi et al.
could be used to generate data for use in our models. An early observation related to the data presented in this paper is that capacity is not always a determining factor. For example, from Figures 18 and 19, it can be seen that the risk profiles for the indented, external makebuy scenarios are not affected by the capacity of the prime contractor.
Another factor that affects the performance of the supply chain is the competence of suppliers. In highly regulated sectors such as aerospace, the competence of suppliers is established in supplier selection and development processes. As a result, it is reasonable to assume that all suppliers are fully competent. In other sectors this may not be the case and mechanisms to characterize supplier competence may be needed.
Although intended for designers with limited simulation modelling skills, the simulation models are available to users and could therefore Instead, the value that the simulation models provide is additional information for decision makers to enable the early identification of design and make supply chain risks related to the design of product architectures, and so decisions surrounding how these risks are to be managed or whether these risks need to be removed or reduced through changes to the design.
To be used in real world preliminary design processes, however, further work is needed to ensure that (a) the simulation models are adequately validated for their specific contexts of use, and (b) the cost of use (e.g., additional user training and effort) is proportionate to the added value created. With respect to model validation, in this paper, the choice of process (the development of test products for certification) and performance indicator (time taken in design and make supply networks), made it feasible to access necessary data. Early work exploring the applicability of the approach to the construction sector 30 has also highlighted the importance of incorporating factors from the business operating environment that influence process operations, especially when the processes are operated by multiple organizations in more volatile supply chain contexts. The approach could also be adapted to support simulations of other lifecycle processes. However, new process metrics and further data would be needed, and so further work to integrate these into the process simulations. For example, in principle, the approach could be used to compare design alternatives in terms of their carbon footprints but this would need details of the lifecycle process being considered, and data on carbon footprints that may not be available and could be affected by wider factors such as the behaviors of users. With respect to cost of use, the interface (including data input and presentation of results) uses Excel which is widely used in the engineering design community. The input data is in the form of an indented parts list annotated with make-buy data. Indented parts lists are a widely used format but the annotation with make-buy data is additional information that needs to be added. In the case study used in this paper this data was added manually. In a full implementation this could be partially automated. For example, it would be straightforward for a competent programmer to write Macros that annotated the BoM using rules of thumb such as that given in Table 5. In summary, given adequately validated simulation models, the cost of use has the potential to be low in the light of the added value from the use of such tools in enabling the early identification of supply network risks and so trade-offs that may need to be considered in later stages of the product development process. As outlined in the Introduction to this paper, the approach presented in this paper is intended for use early in the prod-

DATA AVAILABILITY STATEMENT
Data sharing not applicable to this article as no datasets were generated or analyzed during the current study.