Minimum Viable Model (MVM) Methodology for Integration of Agile Methods into Operational Simulation of Logistics

Abstract

Background: Logistics problems involve a large number of complexities, which makes the development of models challenging. While computer simulation models are developed for addressing complexities, it is essential to ensure that the necessary operational behaviours are captured, and that the architecture of the model is suitable to represent them. The early stage of simulation modelling, known as conceptual modelling (CM), is thus dependent on successfully extracting tacit operational knowledge and avoiding misunderstanding between the client (customer of the model) and simulation analyst. Objective: This paper developed a methodology for managing the knowledge-acquisition process needed to create a sufficient simulation model at the early or the CM stage to ensure the correctness of operation representation. Methods: A minimum viable model (MVM) methodology was proposed with five principles relevant to CM: iterative development, embedded communication, soliciting tacit knowledge, interactive face validity, and a sufficient model. The method was validated by a case study of freight operations, and the results were encouraging. Conclusions: The MVM method improved the architecture of the simulation model through eliciting tacit knowledge and clearing up communication misunderstandings. It also helped shape the architecture of the model towards the features most appreciated by the client, and features not needed in the model. Originality: The novel contribution of this work is the presentation of a method for eliciting tacit information from industrial clients, and building a minimally sufficient simulation model at the early modelling stage. The framework is demonstrated for logistics operations, though the principles may benefit simulation practitioners more generally.

1. Introduction

Logistics problems involve a large number of complexities. These are introduced by the variety in vehicle fleet composition [1], vehicle allocation and routing [2], shipment consolidation and dispatching [3], diverse types of infrastructure, network design [4], day-to-day variability of customer consignments, difficulty of obtaining accurate parameter data [5], and complex operational systems [6]. Computer simulation methods including agent-based simulation (ABS), system dynamics (SD) and discrete-event simulation (DES) have been used to deal with randomness. They can represent the behaviour of logistics transportation systems with randomness: the process workflow; logical structure and decision modules; parameters of different types; stochastic uncertainty; interactions between agents; availability of resources; long-haul and short-haul, etc. Long-haul refers to intercity transport between depots/warehouses, and short-haul is pickup and delivery between customer locations and the depot/warehouse. However, a model must be created before it can be interrogated for results, and the complexity of logistics problems makes this a difficult undertaking.

Conceptual modelling (CM) is the most crucial and challenging part of simulation modelling because it determines the structure and accuracy of the future model [7,8]. It provides the initial layout of the model, and increases the validity of the final model [9,10]. There are three main issues in the early modelling stage or the conceptual modelling stage. The first is to design the architecture of the model [11], include the necessary factors, solicit the tacit knowledge, and ensure the model is extendable and refinable. The second is to obtain data on the various parameters and apply them to the simulation. The last is to validate the model, especially from the operational perspective [12]. Inadequacies in any of these stages may lead to technical debt in the future phases.

The data approach involves the industry client providing the simulation analyst with the data. Disadvantages of the conventional approach are the sometimes-unreasonable information burden placed on the client and the introduction of errors into the model due to undetected deficiencies in problem definition and data. Consequently, there is a risk of technical debt occurring, whereby the deficiencies are structurally incorporated into the architecture of the model, which then may have to be substantially reworked at a future time. Structural changes to models are effortful to change later because the validation partly depends on the structure of the model. This is because any validation process involves an element of tuning of parameters, and those parameters are determined by the structure of the model. Hence, reformulating the model at a future date involves changes to the tuneable parameters, and therefore a need for revalidation. Communication and collaboration with the client are necessary for model definition and validation. Client participation and facilitation improve the quality of the model, but can lead to other issues such as problems in gathering sufficient data [13], paradigm incommensurability, and cognitive difficulty [14].

Current methods for conceptual modelling have several weaknesses. First, there is a scarcity of simulation models with a systematic and explicit method for involving communication and collaboration with the client. Previous models including participative modelling and facilitated modelling have been proposed to alleviate these issues [13,15]. These methods mainly focus on client involvement rather than the model itself. Second, issues such as knowledge boundaries and tacit knowledge elicitation are seldom explicitly included, at least not in the simulation literature. Third, client engagement is complex in terms of model definition, data acquisition, and data validation. There is a need for better methods to solve multiple information issues. Fourth, the process for transforming the conceptual model into a detailed model is not always clear.

This paper proposes a method for acquiring information to create the architecture of conceptual simulation models, and support credible and feasible models. More specifically, the method addresses the problem of how to elicit contextual information, or tacit knowledge. The solution involves an adaptation of agile methods from software development, combined with several principles adapted from the minimum viable product (MVP) concept of agile software development. The resulting framework is called the minimum viable model (MVM) method. Minimum in this context means that the model is sufficient to represent the main features that are of interest to the client; i.e., the validation process occurs via client assent. Minimum does not refer to the smallest model, or an optimal model, or to validation beyond face validation.

The structure of the paper comprises a literature review (Section 2), MVM development (Section 3), the proposed underlying principles (Section 4.1), elaboration of the framework (Section 4.2), and application of the method to a logistics industrial case study for freight operations (Section 5).

2. Literature Review

2.1. Methods for Solving Logistics Problems

Logistics transportation problems can be categorised into long-haul (intercity transport between depots/warehouses) and short-haul (pickup and delivery between client location and depot/warehouse). Typical problems, which apply to both long- and short-haul differently, include vehicle allocation problems, vehicle routing problems, shipment consolidation and dispatching problems, and network design problems [3].

2.1.1. Analytical Methods

Operations problems of simple to medium complexity may be solved by analytical methods such as linear programming and regression analysis. Mixed-integer linear programming is a prevalent mathematical optimisation method that includes objective functions and constraints. This method is frequently applied to transportation problems; e.g., in multimodal transport [16,17], scheduling [18,19], rail transport systems [20], and transport energy analysis [21]. Although analytical models can be quickly developed, there are several limitations of these models. One limitation is the difficulty in describing dynamic and transient effects. Additionally, analytical models are limited to simulating randomness of the system due to the complexity of the calculations [6], so these models normally simplify real problems. For example, for routing models, analytical techniques lack considerations of path constraints and practical scheduling of vehicles [22]. Moreover, clients may struggle to interact with these models due to the mathematical formulations.

2.1.2. Computer Simulation Methods

Typical simulation approaches here include ABS, SD, and DES. ABS focuses on individual entities who make their own decisions; whereas DES concentrates on system analysis, and the process relies on model architecture. Therefore, from the perspective of consultation and collaboration between simulation analysts and industrial clients, DES is more straightforward, and has been widely implemented [23]. Table 1 summarises recent applications of simulations in logistics.

Typical DES software includes Arena, SIEMENS Plant Simulation, and SIMUL8. These use program diagrams with logic to mimic real operational procedures [24]. Compared with traditional mathematical models, simulation models are able to analyse stochastic events by including logic functions (decision modules) and probability distributions (using Monte Carlo methods), so uncertainties such as delay time, arrival time, and arrival rate can be reflected in the system. Once the model is validated, simulations can quickly analyse different scenarios.

Table 1. Applications of ABS and DES on logistics.

Logistics Areas	Problems	Methods
Truck platoon planning	Investigate truck platoon possibilities and evaluate waiting times [1]	ABS
Freight operations	Evaluate freight-unloading operations [25] Freight pickup and delivery [26]	DES DES
Multimodal and intermodal transport	Analyse multimodal freight-routing system [27]	DES
Railway network design	Avoid collisions [28]	ABS
	Analyse queuing systems of rail network [4]	DES
Rail yard design	Design rail transhipment yard [29]	ABS
	Evaluate processing capabilities of rail yard [30]	DES
	Integrate high-speed rail lines with conventional railways [31]	DES
Port operations	Simulate container logistics [32]	DES
Supply chain management	Estimate last-mile distance [33]	DES
	Conduct inventory analysis [34]	DES

Table 1. Applications of ABS and DES on logistics.

Logistics Areas	Problems	Methods
Truck platoon planning	Investigate truck platoon possibilities and evaluate waiting times [1]	ABS
Freight operations	Evaluate freight-unloading operations [25] Freight pickup and delivery [26]	DES DES
Multimodal and intermodal transport	Analyse multimodal freight-routing system [27]	DES
Railway network design	Avoid collisions [28]	ABS
	Analyse queuing systems of rail network [4]	DES
Rail yard design	Design rail transhipment yard [29]	ABS
	Evaluate processing capabilities of rail yard [30]	DES
	Integrate high-speed rail lines with conventional railways [31]	DES
Port operations	Simulate container logistics [32]	DES
Supply chain management	Estimate last-mile distance [33]	DES
	Conduct inventory analysis [34]	DES

2.2. Conceptual Modelling Approaches

Simulations are used to solve real-world operations problems, and this requires collaboration between the industry client and the analyst. Figure 1 shows the conventional simulation modelling process per Robinson [6]. The most critical steps of simulation modelling are conceptual modelling, detailed model creation, and experiment conduction [35]. The simulation modelling process is generally undertaken by the analyst with partial industry client participation.

Specifically, simulation model development at the early stage is important to a project. Scope and model definition, data collection, and collaboration with industry are the main challenges [11]. Proposed modelling methods include parallel and iterative methodology [36], applications of discrete-event simulation [37,38], and methods to support project objective definition [39]. CM has been widely used to create abstractive simulation models at the early modelling stage [9]. Knowledge elicitation and abstraction, validity, credibility, utility, and feasibility of CM are key aspects [40,41]. CM delivers crucial information to the future models [7]. The process may help identify relevant information [6,42] and increase the validity of the model [10].

The conventional CM approach tends to adopt a linear method of problem solving, and this is seen most strongly in the project management, waterfall, and stage-gate methods, which require each phase to be reviewed before approval is given to proceed to the next [43]. These methods all require complete scope definition at the outset, or sequential decisions against predetermined objectives [44]. In well-defined projects where the tasks are familiar to participants, these methods may work well. However, when complexity is high; e.g., for unfamiliar work streams and uncertain requirements, these methods struggle. The issues have been identified as ‘paradigm incommensurability’ and ‘cognitive difficulty of switching paradigms for stakeholders’ [14].

2.3. Client Participation and Stakeholder-Facilitated Modelling

Conventional CM lacks stakeholder engagement. Involving stakeholders in simulation modelling can improve the credibility of the model. Stakeholder engagement is emphasised in methods such as hybrid modelling [15] and facilitated/participative modelling [13,40,45].

Hybrid modelling introduces a second loop to involve stakeholders [15]. It illuminates that visualisation of simulation models supports analysts to clarify modelling ideas. Stakeholders were involved through the iterative development process. The validation conducted by this method was face validation. Participative modelling was applied to create a simulation conceptual model. An obesity system was created by DES through participative and facilitative conceptual modelling [40]. The model was evaluated using knowledge elicitation and abstraction, validity, credibility, utility, and feasibility.

Facilitated modelling was proposed to engage the client through interventions [13]. In this mode, the simulation analyst is also a facilitator to build relationships with the client. Compared with the conventional expert mode, the facilitated mode relies on the analyst to develop inventions with the client. This means the analyst needs facilitation skills including ‘active listening’, ‘chart-writing’, ‘managing group dynamics and power shifts’, and ‘reaching closure’. A DES model for a hospital was developed, and a facilitated mode was included. The discussion with stakeholders included model understanding, face validation, problem scoping, and improvement. The client involvement was evaluated at each modelling phrase. The invention was achieved in this research, but the full facilitated mode was still challenging [45].

In the above literature, these stakeholder engagement models increased stakeholder involvement during the initial modelling stage. Simplified models were developed in order to reduce the time. However, the detailed complexity of the DES model was difficult to obtain [45]. Boundary-spanning activities were presentations and group discussions. The validation of the facilitated model was mainly the face validation. The facilitator/analyst did not conduct enough operational observations to elicit tacit knowledge, which could not be noticed by stakeholders. Moreover, the communication hierarchy was unclear.

2.4. Agile Method

The agile method originated in software development. Agile is primarily directed at maximising collaboration between project stakeholders and directing work effort towards progressive development of the product [46,47]. Agile development typically uses a MVP approach. This refers to a product that embodies the primary functionalities with the least detail. The MVP perspective is complementary to the scrum process, which is a method for managing agile team interactions towards MVP outcomes [48,49]. The method has a strong emphasis on getting the architecture of the system correct at the early stages, which it does via a structured communication process. Hence, a degree of validation of the model occurs much earlier in the process than in conventional simulation processes.

Some recent examples of the MVP software process are a hospital management system to improve communication [50], e-commerce systems [51], the Internet of Things [52], and enterprise management [53]. The method has been adapted to other disciplines such as project management and development [46,54] and entrepreneurship (business start-ups) [55,56]. The key advantages of MVP are the improvement in communication within the development team and with the client. MVP has the potential to reduce the technical deficit (or debt) [57,58]. This is the future cost of reworking the solution due to defects in the architecture of the initial solution. Offsetting that advantage is the disadvantage that the product might never move beyond the minimal state. However, MVP also requires resources, as recognised in the specific case of software start-up businesses [59].

2.5. Gaps in Existing Approaches to Developing Simulation Models

According to the aforementioned literature, there are still some challenges existing in the CM process, including knowledge acquisition and identification, validation, and detailed model development. The key challenges for simulation are elaborated below.

Knowledge acquisition and identification: Communication and the collaboration between stakeholders are often neglected [60]. In addition, the CM processes can sometimes be ad hoc [8], and replicability is not guaranteed. Tacit knowledge is difficult to capture. Disadvantages of the conventional approach are the sometimes-unreasonable information burden placed on the client and the introduction of errors into the model due to undetected deficiencies in problem definition and data. Consequently, there is a risk of technical debt occurring, whereby the deficiencies are structurally incorporated into the model, which then has to be substantially reworked at a future time. Existing data may be unhelpful in the simulation modelling. For example, the data could be obsolete [61].

Model building: The transition and insights from the conceptual model to the detailed model are unclear. Structural changes to models are effortful to change later because the validation partly depends on the structure of the model. This is because any validation process involves an element of tuning of parameters, and those parameters are determined by the structure of the model. Hence, reformulating the model at a future date involves changes to the tuneable parameters, and therefore a need for r-validation.

Validation: It is often challenging to validate the model sufficiently [62]. The validation of the conceptual models is mainly the face validation.

Detailed model development: The simulation model should be extendable and refinable [62], but this may be difficult to achieve. Typically there is a need to examine the trade-off between detailed factors, but this can be difficult to conduct [42].

Of these, the question of how to define the client’s needs is the subject of this paper.

3. Methodology

3.1. Objective

The objective was to develop a model-building process that better deals with the ambiguity at the start of a project, and better ensures that the business need and operational context are correctly represented in the structural (or architectural) design of the simulation model. The situation under examination was freight logistics.

3.2. Approach

The approach comprised two stages. The first was an inductive reasoning process whereby observations from other domains, primarily software development and knowledge management, were used to derive a set of general principles for how to extract knowledge through the analyst–client interaction. The area under examination was the development of logistics simulations. The second stage tested these principles through application to an industrial case study.

3.2.1. Stage 1: Conceptual Development of a Methodology for Minimum Viable Modelling

The proposed MVM method mainly focused on issues in the conceptual modelling stage. The problem-definition stage was involved, since it is prior to the conceptual modelling stage. In order to solve issues such as tacit knowledge and boundary of knowledge between the client and simulation analyst, which could be encountered, principles from several different disciplines were adapted to and complemented the modelling framework:

• The systems-engineering methodology was used to provide the emphasis on requirement analysis, validation, and verification.
• The knowledge-management literature provided the concepts of tacit and explicit knowledge, as well as the need to find ways to deliberately extract the former.
• We adapted agile principles and the proposed MVP method using agile software development and applied them in a simulation. The key feature of agile is to reduce the misunderstanding between stakeholders and quickly develop partial solutions that can be evaluated and used to direct the next efforts. There is no reported literature on the application of MVP thinking to simulation modelling.
• The communications literature provided the concept of boundary spanning activities within the team communication process.

The resulting methodology was expressed as a framework, in the form of (a) a set of principles, and (b) a sequence of proposed activities. We refer to this as the minimum viable model simulation methodology.

3.2.2. Stage 2: Application to Industrial Logistics Case Study

We applied the new MVM method to a real industrial case to evaluate how practical it was to implement. The situation under examination was a freight company, for which the first author was the primary investigator. The MVM method was applied by developing basic models, obtaining feedback, and continuous improvement as per the framework. The industry client was represented by a coordinator within the organisation. Comments from the coordinator were reported by way of illustration of the method. Personal approval was obtained from the manager, and ethics approval from the University of Canterbury (HEC 2020/65/LR-PS).

The model shown here was a minimum viable one to explore whether the problem had been properly captured by the architecture of the model. The focus was on establishing a robust architectural model, rather than on the numerical accuracy of the results. As such, the paper shows how the proposed principles may be applied, and how an Arena^® model may be constructed. Some preliminary output results are presented for freight transport for demonstration purposes. Data were provided by the industrial client. These are representative rather than exact, for reasons of commercial sensitivity. The model represents pickup and delivery (PUD) operations.

4. Results: Reconceptualising the Simulation Modelling Process as a Minimum Viable Model

4.1. Principles of Minimum Viable Model (MVM) Development

We defined the minimum viable model method as follows:

A minimum viable model (MVM) is a simulation model with sufficient outputs that the end-user/client can use to evaluate the validity of the conceptual model in a continuous improvement cycle.

Note that the MVM involves exploration of conceptual models, but is not limited to that. It extends to the exploration of multiple different conceptual models, and produces a simulation model. It is also important to note is that the MVM validates the conceptual model, not the simulation model itself. The outputs of the simulation model will still need to be validated by other means. The final model developed by MVM should include enough tacit knowledge that is needed to create a sufficient model.

In continuous improvement, the cycle is meant to be the continuous and evolutionary development of the model using rapid iterations of client feedback and new model developments in response. Implicit therein is the identification of features that are important from the client’s perspective for inclusion in the model, and exclusion of unnecessary features. This ensures that the analyst avoids unnecessary work, and the client is spared lengthy discussions about features that are not meaningful. Like MVP software programming, the method seeks to maximise the opportunity for the analyst to efficiently learn about the client’s needs. Underlying the MVM method is the assumption that the client may be unable to articulate all their needs initially; i.e., complete problem definition a priori is not always possible, and that the iterative process is valuable in helping the client understand and express their needs.

The MVM is not necessarily the simplest model possible. Rather, it is merely an adequate representation of the client’s operations. As with any complex simulation, there are many ways to represent the relationships. Different model architectures emphasise different perspectives, and in the case of MVM, the process results in a model that emphasises the client’s operational realities. The product method can usefully be adapted to create a method for approaching the simulation task, and the agile method was applied throughout these principles.

Existing approaches to model building emphasise a linear development of the model, with communication occurring as a series of separate transactional episodes. As this is at odds with the MVP approach, it is apparent that the communication process is one of the key features to redesign. Hence, at a high level of abstraction, we propose that the minimum viable model involves iterative development loops between the client and the simulation analyst (see Figure 2). The knowledge boundary of the client and simulation analyst is supposed to be mitigated by the MVM approach.

Within this high-level model, we propose a number of principles, as follows.

4.1.1. §1 Iterative Development with Boundary-Spanning Activities

Conceptual models should be comprehendible by stakeholders [63]. However, the engagement of stakeholders is difficult in practice, especially in the presentation and validation of results [15]. Iterative participative and facilitated modelling is well known in the literature [9,12,64].

However, the navigation of the boundary of knowledge between the client and simulation analyst has not been considered. Instead, the conventional approach for constructing a simulation model assumes a simple communication model based on a transactional exchange of factual information. The problem this creates is that the architecture of the simulation model needs to represent, with sufficient accuracy, the problem the client is trying to address. If this is not achieved, then the architecture of the solution may be inappropriate, and technical debt arises. However, since the industrial context is invariably implicit, the analyst may have difficulty identifying the information they need.

Likewise, since the client is unfamiliar with the structure of simulation, they may not know what information is important to provide. This communication between the analyst and client is known to be a cognitively challenging process. Other issues include inconsistency of information [65,66], timing mismatches, and passive behaviour [67]. Problems are known in various fields, such as software engineering [66,68], manufacturing [69], requirements engineering [70], biomedical engineering [71], and business management [66].

In contrast to the simple model of transactional communication, we propose that the industrial context includes tacit knowledge that is better elucidated by deliberately including activities that transcend the boundaries of knowledge between stakeholders. These are called boundary-spanning activities [72]. They provide opportunities for stakeholders to communicate and interact with the project team. This concept of interaction and knowledge sharing is evident in the literature; e.g., [8,73], though not specifically linked therein to the concept of boundary objects.

An iterative process involving boundary spanning is shown in Figure 3. Through iterative boundary-spanning activities with MVM development, the client can understand the simulation model gradually. Likewise, the analyst is able to understand the industry organisation. This action supports the collaboration and helps define the future model specification.

4.1.2. §2 Embedded Communication

Even within an organisation, there are internal communication boundaries [72]. When knowledge is transmitted across different groups, misunderstandings may result. In the case of simulation models, the analyst is often external to the organisation, and must rely on documents and meetings to understand the industrial context, which increases the risk of misunderstandings. Typical misinterpretations are vague objectives, scant data, and conflicting acceptance of results [74].

Historically, the problem of misunderstanding was attributed to loss of information during communication. Several models have been proposed to improve communication actions, such as the push–pull model [66], effectuation integration model [55], and sender–receiver model [75]. These are now considered somewhat deficient because misunderstandings involve team roles and political interactions between members [76]. Nonetheless, the sender–receiver paradigm is still evident in many frameworks. For example, the communication process itself has been modelled using discrete-event simulation and value-stream mapping as a sender–receiver process of loss of information [75]. Although the analyst can build a well-developed communication with the industry coordinator in §1, issues such as data interpretation and operations explanation still arise when the company client communicates with internal staff.

Embedded communication is proposed to reduce interorganisation boundary activities and provide more types of knowledge-transmission activities. Figure 4 illustrates the embedded communication activity. The emphasis here is on the analyst being embedded in the organisation; i.e., having an identifiable membership with the organisation. The analyst may be placed in different operational groups, and then has an opportunity for discussion with specific individuals with their different perspectives of the work being modelled. The analyst can watch and participate in real operations, which allows them to comprehend tacit elements of the system behaviour. This also allows the benefit of internal staff being able to understand the project and then provide more effective information.

4.1.3. §3 Soliciting Tacit Knowledge

Tacit knowledge refers to information that is difficult for people to articulate. The knowledge provided by the client’s experts is critical for model identification [41], but is often of the tacit kind [69]. For example, in freight logistics, tacit knowledge includes operational rules for load consolidation, as well as priorities such as driver route decisions. The distinction between tacit and explicit knowledge, per Nonaka [77], requires a deliberate effort at knowledge management via elicitation of the tacit component. A large knowledge-management literature exists, but was not reviewed here. Knowledge engineering is used in the CM process to elicit the knowledge created and mastered by humans [63]. The development of a simulation model needs to be systematic about extracting tacit information.

We propose that analysts should focus on identifying tacit knowledge when they communicate with the client. Tacit information can be extracted by means of iterative model development and embedded communication such as observations and conversations with staff. This implies the need for appropriate language, both textual and visual [8]. Facilitation has also been proposed for this [78], and may include stakeholder-oriented workshops. Although tacit knowledge has been mentioned in previous studies, elicitation of it is unclear.

4.1.4. §4 Interactive Face Validation

From the systems-engineering perspective, verification refers to the process of confirming that the system (often a physical system) has been designed and constructed according to the criteria determined at the outset, whereas validation is the later process of assuring that the system does meet the needs of the client. In the context of simulation, validation refers to the process of confirming that the behaviour of the model is a sufficiently accurate representation of the real operations system [12]. Validation should ideally be involved in each life cycle of model development [63,79] because it decides the authenticity of the simulation model compared with the practical system [35]. However, model validation is a challenge for many simulation projects, as there may be limited opportunities to apply it. Unsurprisingly, many modelling methods lack a description of the validation part [35].

There are multiple ways to validate a simulation model:

Contrast with reality: Comparison of results to a real system is ideal, but not always available. This may include frequency of events, using half the historical data for model tuning and the other half for validation, or comparing predictions of the model against later behaviour of the real system [12].

Multiple model comparison: Results may be compared to those of another validated model such as an analytical model [80]. However, analytical models have many limitations, as described above.

Internal consistency tests: This approach uses internal validity tests, degeneracy tests, and sensitivity analyses, which involve running the model with multiple different input configurations and examining the consistency of the outputs. An example of this method can be found in [80].

Face validity: Face validity, or audit, involves a superficial examination of the model reviewed by the analyst and the client [12]. Face validity involves watching simulations, running simulations with different conditions, and demonstrating models to other people [6]. The simulation analyst has a responsibility to understand the client’s feedback [8]. Textual and visual language is used to help the client comprehend the simulation model [8]. Structured walkthrough and trace methods are also applicable [80]. Face validity has not been used much in previous conceptual modelling [8].

Other methods: In addition, some novel approaches such as the model-based generic approach [81] and Turing test [82] can aid the validation process.

Given the challenges of validating simulation models, we propose that more use could be made of face validation earlier and more often in the process. This is because one of the risks in the conceptual modelling phase is that the tacit nature of the knowledge may lead the analyst to misunderstand some aspect of the client’s operations, and develop a wrong mental model thereof that is carried through into the structure of the simulation. Face validity, with its discussion element, has the potential to remedy these problems. Hence, we propose that the logic and content of the simulation model are interpreted to the client in iterative feedback loops until mutual satisfaction is achieved. The animation features (if any) of the software can be utilised to aid comprehension. The advantage of having an early MVM simulation model is that the architecture is exposed sooner. Note that we also propose that this face validity be an interactive process that is undertaken throughout the model-building phase, as opposed to an event at the end. Face validity may be directed to explore the extent to which the model is a sufficient representation as regards credibility, utility, and feasibility [40,41].

4.1.5. §5 Sufficient Model

A key principle is that a model need only be sufficient for the purposes. This means that it does not need all features that are conceivable. Simplification and abstraction of the simulation model are necessary, but difficult [7,42]. This is consistent with the concept of sufficiency from Ackoff [83], and ‘semantic quality’ [8]. A top-down process has been proposed [63].

The conceptual model should be valid, credible, useful, and feasible [41]. The focus of the model creation should be on developing an adequate representation of the architecture of the problem, not the development of fine detail features that might not be needed at all. The corollary to this is that fine features are only developed once (a) the architecture has been established, and (b) the client needs those features. To create fine features in advance of their need is acting in anticipation of a future need that might or might not materialise, and hence the value of such work is ambiguous. Furthermore, the presence of many fine features in a model potentially obscures the underlying architecture and makes changes more difficult.

4.2. Process for MVM Development

Application of the above principles results in a process for the development of minimum viable models. A key feature of the method is the interaction between the industry client and the simulation analyst. Agile interactions occur at the intersection of these two groups of people.

There are typically three main stages to the process: (1) problem definition, which progresses from identification of the industry need through to determination of the MVM scope; (2) the MVM conceptual modelling process, which involves the progressive development of the model architecture and feedback interactions with the client, leading to a sufficient model that has face validity; and (3) detailed model building and application, in which the model is refined and detailed, and the scenarios explored (this part was not included in this paper). This process is shown in Figure 5, including where the above principles §1–5 apply.

5. Application to Case Study

The purpose of this case study was to illustrate the proposed principles used in the agile interactions, and to show how the architecture of the model may be developed for simulation modelling.

5.1. Problem Definition

For the case under examination, the operations were pickup and delivery (PUD) in Christchurch and Auckland, and line haul between these two cities. The first author was embedded in the organisation in a 0.5 FTE research role (§2).

Initial discussion with the client identified that the PUD activities were more logistically complex than the line haul, and hence were the area of focus. The complexity arises in the uncertain freight volume and variable customer addresses. In the models that follow, some details have been replaced with representative data to protect commercial confidentiality.

The analyst split the model into three submodels, which were two city PUD models and a line-haul model, each operated by different truck fleets (see Figure 6).

This study did not make a sharp distinction between conceptual, detailed, and simulation models, as exists in other theoretical frameworks. The minimum viable method seeks to work on creating the simulation model—or at least a simplified version thereof—at the early stage (§5). This is necessary to support the iterative process of critique by the client. This is a point of difference in what follows.

5.2. Establishing the Operational Principles to Include in the Model

5.2.1. Operational Complexity and Tacit Knowledge

The freight operations were complex due to the variability in daily consignments. This requires aggregation of loads (consolidation), practical scheduling of vehicles, and route planning on a daily basis. Industries tend to use their own specialised technical and operational terminology and abbreviations. This contributes to the tacit nature of their knowledge (§3). In turn, this creates barriers for the analyst in the formulation of the simulation model. For example, in the area under examination, the specifics included pickup and delivery (PUD), less-than-container load (LCL), and line haul. In order to solicit tacit knowledge, analysts should not be ashamed to ask for clarification, as any feelings of awkwardness are more than compensated by a better simulation model. The problem of esoteric terminology was applied both ways. For example, when the standard Arena results were presented to the client, it was evident that simulation terminology (such as ‘half width’) was unfamiliar to the client.

The analyst found the logic of truck routing was important to the model, though the rules of this were tacit. The actual daily route was varied rather than being a fixed run, due to the nature of the general freight environment. Truck routing depends on many factors, including daily variability in the quantity and addresses of consignments. For those regions served by multiple trucks, there is the additional need to balance the workload between drivers, taking into account the capacity of the trucks (which may be different). This was handled by the dispatcher, but the underpinning assumptions were tacit and difficult to comprehend on a superficial examination. The precise daily route, which was highly variable, was determined by the driver. Again, this involved tacit knowledge.

Hence, it was necessary to solicit tacit operational knowledge. This was supported by embedment (§2) and boundary-spanning activities (§1).

5.2.2. Benefit of Embedment

The problem itself originated in the industry, rather than from the analyst side. In this way, the project was aligned with the client’s needs from the outset. Consequently, the client was receptive to the subsequent communication process. The tacit knowledge was solicited by embedding the first author in the client organisation (see Figure 7) to allow multiple discussions with staff and observation of operations (§2). Multiple iterations of communication, model building, and feedback were undertaken, especially with the dispatcher and truck drivers.

5.2.3. Tacit-Knowledge Extraction

Tacit knowledge was especially evident in the operations of freight consolidation, truck allocation, and route planning. It was evident that operators were making systematic decisions, but the decision making was not obvious in casual observation, and the operators struggled to articulate their thinking. Hence, it was necessary to take a deliberate approach to extraction of tacit knowledge (§3). This was successfully achieved using two main methods: (a) work shadowing of dispatchers and drivers; and (b) repeated critique of assumptions.

5.2.4. Work Shadowing of Dispatchers and Drivers

During the embedded communication, the analyst contacted the specific staff directly. With a smaller number of hierarchical levels, communication cycles became much shorter, and misunderstandings were reduced. The analyst had conversations with them and conducted observations such as watching workflow and following PUD trucks.

For example, to facilitate communication and understand the delivery-routing decisions, the analyst provided the driver with a map of the delivery address for one past round. Then the driver drew the tour on the map (see Figure 8). This type of information proved to be valuable when subsequently evaluating the accuracy of other route-determination algorithms such as the travelling salesman algorithm in geographical information system (GIS) software (results not shown here).

These means of communication helped the analyst acquire both explicit and tacit knowledge. For example, the analyst was able to comprehend the truck routing and PUD activities by sitting in the truck. In addition, the truck driver could explain terminology during the process. A secondary benefit was that staff of the client organisation became more engaged and interested in the simulation project, hence they provided more information. Nevertheless, this could be challenging for the analyst due to the need to adapt to the industry environment and interact with people at many different levels with various personalities and attitudes.

5.2.5. Repeated Critique of Assumptions

This process involved the analyst explicitly stating their assumptions during creation of the early simulation model, and putting those forward for critique by the client coordinator (§1, §5). An example is summarised in

Table 2. Example of tacit knowledge extraction.

Tacit Knowledge Solicited	Question from the Analyst	Client Comment or Reply	Further Questions from the Analyst	Further Answers from the Client	Response to the Model
Truck fleet and service areas	‘Both trucks and vans are using. I may add vans to the model, so I need the configuration of vans if you have.’	‘Vans are a relatively insignificant method of transport for us, they don’t actually fit our desired profile of freight which is B2B. I wouldn’t worry too much about vans but I can provide some detail if desired.’	‘I thought you use vans to transport residual freights or small volumes to some remote destinations. Do you have the information about the truck volume limit and pallets? Through my observation, you put most freights on pallets and there is a limit of the pallet. I think I cannot just add volume up and I should consider the arrangement for pallets.’	‘No, freight is managed by area. Vans are seldom used for overflow (mostly for unusual freight or very urgent deliveries) instead where excess freight can’t justify another truck load (perhaps one or 2 pallets) then it would wait until the next day. 6 wheeler (standard PUD truck) would be 12 pallet spaces and 12 tonne Truck and trailer (intercity, direct deliveries or larger delivery areas) would be 24 pallet spaces and 24 tonnes Note some pallets can be double stacked meaning pallet spaces aren’t so much a limitation but some dimensions also mean that practically speaking it’s not always possible to reach max tonne capacity. Most freight is on pallets, smaller items like cartons for multiple orders would be consolidated on a pallet as far as loading is concerned.’	The fleet of trucks was considered as the client described. The capacity of the truck was included in the consolidation process.

, which shows extracts of the communication (per email) between the analyst and the client coordinator (see Appendix A 

Table A1. Tacit-knowledge extraction.

Tacit Knowledge Solicited	Question from the Analyst	Client Comment or Reply	Further Questions from the Analyst	Further Answers from the Client	Response to the Model
Operations of PUD and line-haul	‘For PUD, I know you run trucks in different regions. Do these trucks just run in a specific region individually or they sometimes can run in different regions for one trip?’	‘Mostly by region/area and as far as the model is concerned this might be the easiest basis to work from. There are some variations including full truckloads and directs.’	‘OK, I will make assumptions about this and you can check these in my next report. Also, are delivery and pickup conducted in one trip or the trucks come back to the site once they finish the delivery and go to pickup as needed?’	‘Good question, mostly separate that is to say the truck is either doing pickups or doing deliveries. Typically the truck does deliveries in the morning (this is freight received in from all over the country) and does pickups in the afternoon to give the customer time to pick, pack and stage. This then goes on intercity linehaul overnight for delivery in other cities (within the same island) the next day.’	Submodels of PUD and line-haul operations were created separately, and pickup and delivery were models as two individual processes
Truck fleet and service areas	‘Both trucks and vans are using. I may add vans to the model, so I need the configuration of vans if you have.’	‘Vans are a relatively insignificant method of transport for us, they don’t actually fit our desired profile of freight which is B2B. I wouldn’t worry too much about vans but I can provide some detail if desired.’	‘I thought you use vans to transport residual freights or small volumes to some remote destinations. Do you have the information about truck volume limit and pallets? Through my observation, you put most freights on pallets and there is a limit of pallet. I think I cannot just add volume up and I should consider the arrangement for pallets.’	‘No, freight is managed by area. Vans are seldom used for overflow (mostly for unusual freight or very urgent deliveries) instead where excess freight can’t justify another truck load (perhaps one or 2 pallets) then it would wait until the next day. 6 wheeler (standard PUD truck) would be 12 pallet spaces and 12 tonne Truck and trailer (intercity, direct deliveries or larger delivery areas) would be 24 pallet spaces and 24 tonnes Note some pallets can be double stacked meaning pallet spaces isn’t so much a limitation but some dimensions also mean that practically speaking its not always possible to reach max tonne capacity. Most freight is on pallets, smaller items like cartons for multiple orders would be consolidated on a pallet as far as loading is concerned.’	The fleet of trucks was considered as the client described. The capacity of the trucks was included in the consolidation process.
Truck allocation and area partition	‘We found some suburbs have low numbers of requests so we want to integrate suburbs and make the network clear. Based on the previous spreadsheet, Rangiora, Christchurch central, Hornby, Papanui, Riccarton, Sockburn, Sydenham and Wigram seem to have a high frequency. I wonder if you have your own partition of suburbs.’	‘Yes suburbs are divided into ‘dispatch groups’, the table above shows the key dispatch groups for Mainfreight Christchurch Note, these can change for instance if we get a large new customer in a specific area or our transport team want to re-optimise While you are welcome to use the provided dispatch groups, this might also be an area where your research could suggest a better design’	‘When dispatchers operate trucks, it is a real-time operation, are there any rules except considering weight and volume? Such as distance, time, specific routes and traffic conditions. Our idea is giving priority to each suburb based on distance. Maybe Rangiora–Christchurch Central–Sydenham–Papanui–Riccarton–Sockburn–Wigram–Hornby (from high to low).’	‘Priority makes sense to apply to both high volume and nearby locations in terms of best asset utilisation (nearby because more freight can be collected or delivered in less time) There are some other rules that we could look at but perhaps we hold off until we can discuss further and then apply to the next iteration of the model.’	Areas were modelled based on customer suburbs, and the priority was included in truck routing of the model

for more examples).

This can be a personally challenging situation for the analyst, because there is a natural tendency for people in such roles to want to be seen as competent and knowledgeable. Therefore, it takes some humbleness for an analyst to commit to such a process, but the rewards are great from the perspective of early strengthening of foundational assumptions. There were several instances when the analyst misunderstood the client coordinator’s intent, and the MVM approach was successful at detecting and correcting these issues.

5.2.6. Iterative Processes

The focus at the early stage was establishing a correct understanding of the fundamentals of the operations, because these determine the architecture of the subsequent simulation model. Sometimes gross simplifications were made by the analyst (§5).

The results were presented to the client, and the network was clarified. The simulation analyst came to understand the operations of the company and what needed to be represented (or not) in the simulation model. In parallel, the client coordinator acquired an appreciation of DES and a comprehension of the capabilities and limitations of the simulation model.

The further development of the simulation model required more detail about routes (travel network), freight volume, allocation of drivers, distances, and speeds. Further correspondence between the analyst and the client helped unravel additional tacit knowledge. The types of boundary-spanning activities (§1) conducted in the case study included technical reports, emails, meetings, model presentations, operations observations, and enquiry with staff.

In simulation modelling, it is convenient to have a pool of resources; e.g., trucks, which can be called to service the queue of work. However, the previous round of the MVM process identified that a more complex situation existed. The actual current freight process had the truck collection schedules (‘runs’) defined before they left the depot. Hence, the analyst identified that processes regarding consignment allocation needed to be elucidated from the client, so further communication occurred regarding this specific feature.

5.3. Testing the Model for Face Validity

Further refinements were made to the model. At the end of this stage, a minimum viable model existed (see below). The sufficiency of the model was then subjected to an overall test of face validity (§4, §5) (see

Table 3. Example of interactive face validation.

Analyst’s Questions	Client’s Comment or Reply	Further Actions
‘Does this model adequate represent the core operational processes for your organisation?’	‘Perhaps, but would like to discuss further some of the underlying assumptions.’	The analyst modified the model and discussed it with the client.
‘What features in this model do you view positively?’	‘Good first attempt at defining modelling logic for an operation that is complex and dynamic. Batching is a practical equivalent to our dispatching process. Outputs as time, distance, waiting time, occupied trucks and consumption are all practical measures that can point towards optimisation initiatives.’	Consolidation was considered to add to the future detailed model but not to this MVM due to the sufficient model consideration.
‘What features in this model are weak?’	‘An area-based/hub and spoke model is probably more suited than shared routes. To do this we may need to define which areas can and can’t be done by given trucks.’	The suburbs for trucks were specified in the model. Some suburbs that had fewer consignments were ignored.
‘What additional features should be included for a minimal viable model?’	‘Weight and cubic volume are fairly fundamental, more so than the number of items which may entail a 1 kg carton or a 1000 kg pallet. Otherwise, I think feature wise we may be close it is just working around documenting process and assumptions and formatting report/findings they can make the model more clear.’	Weight and volume limits were involved in the future detailed model but not in this MVM due to the sufficient model consideration. They will be included in the detailed model.
‘Is the operational pattern reasonably realistic? Are there other operational patterns the organisation sometimes uses?’	‘There are numerous operational patterns but the vast majority are covered by 2 key activities PUD and LH. While these have numerous variations in and of themselves a generalised base view of these two will account for 90% of volumes moved.’	Except for PUD and LH transports, other transport patterns were excluded, such as metro freight and B2B.

). Questions about model scope and structure were discussed.

This feedback resulted in further refinements to the model and further communications loops. The final model was able to simulate the pickup-and-delivery process based on the suburb network to a level that satisfied the client. The project subsequently went on to (a) replicate the model to other suburbs and cities, with further refinement in the process; and (b) develop other minimum viable models for consolidation, line haul, etc., to cover the entirety of the client’s operations.

As this paper reports on a conceptual advancement, validation was limited to face validation. If the MVM methodology proves useful, then practitioners may wish to consider other forms of validation such as comparison with real data and benchmarking against other models [6].

5.4. Simulation Model

A summary of the main changes that arose in the development of the model (§5) after several agile loops are provided in

Table 4. Initial and refined models showing assumptions and structure.

Freight Operations	Initial Model—Basic Model as Initially Discussed with Client	Refined MVM
Consignments	Only pickup	Pickup and delivery separately
Truck speed	New Zealand Transport Agency data	Real GPS data
Truck allocation	No specific routes	Based on customer clusters
Routing areas	Based on the anticlockwise direction	Based on the hierarchy of suburbs
Freight consolidation	Consolidated all consignments	Consolidated consignments based on destinations
Freight loading and unloading time	Not considered	Considered

. The presentation of results is limited to the initial and refined models, rather than the intermediate iterations.

In the MVM process, more operations were incorporated into the model, and some operations were further clarified. In addition, more data were obtained from the client (§1).

The analyst assumed four suburbs (for simplicity) and mimicked freight operations. Each suburb model only included pickup. Figure 9 and Figure 10 show the initial schematic representation of the transportation network and operations formulated using Arena (version 16.00) based on the analyst’s assumptions and initial discussion with the client. The first simulation was implemented in Arena including animations.

The refined MVM of this freight network presented general freight consolidation, the PUD process, truck allocation, transport routes, and real suburbs with connecting routes, etc. (see Figure 11 and Figure 12). Most parts were validated by the client as sufficient to represent their network (§5). The suburb models in Arena were much the same as before, but this time they included both pickup and delivery. The depot model had become more complex due to the need to include consolidation of the deliveries.

A description of the main functionality is given in

Table 5. Complexity of main Arena blocks for the detailed model.

Blocks	Description	Complexity Identified by MVM
	Create block for creating consignments	Discrete distribution for the number of consignments (pickup and delivery) per day for each suburb; first creation time
	Process block for freight loading and unloading	Number of forklifts, capacity of forklifts, and process time
	Assign block for freight attributes	Weight and volume of each consignment and number of pallets—this was highly variable
	Decide block for determining consignment destination	Identification of destinations based on consignment types
	Batch block for pickup or delivery freight based on destinations	Weight and volume limits of trucks—in general, a freight company will have a fleet with mixed capabilities
	Request block for assigning trucks	Priority of pickup and delivery, FIFO, truck fleets, and driver break times
	Transport block for truck movement	Truck routes and truck speed according to GPS data
	Station block for representing suburbs	Identification of customer clusters
	Process block for truck dispatching	Number of dispatchers and truck dispatching time
	Assign block for intrasuburb distance	Intrasuburb travel distance could be obtained from the travelling salesman algorithm in a geographical information system (GIS)

. The table also indicates the complexity that was elucidated in the progression from the basic to the refined model, and which would need to be included in a future more detailed model.

6. Discussion

6.1. Evaluation of the Outcomes

The case study confirmed that the five principles provided useful mechanics for discovery of tacit knowledge, expansion of the boundaries of knowledge of the analyst and the client, and model development. Moreover, the future work was explicit in terms of data requirements, additional operations, and simulation inputs for the detailed model.

In evaluating the modelling method, our assessment was that the principles supported each other. The iterative process (§1) helped in the production of feasible models. Without iteration, a model would still have been produced, but in our experience, it would not have been a robust one. If an attempt had been made to take the initial model forward to a more detailed simulation, it probably would have been infeasible due to the incorrect architecture. The embedded process (§2) contributed to authenticity of the communication. This better exposed the heuristics underpinning the tacit knowledge (§3), hence increasing the credibility of the simulation model and its validity (§4). Sufficiency of the model (§5) meant that it had utility for both the client and analyst.

The key starting points appeared to be clarification of information, which is a boundary-spanning activity related to principle (§1), and management of tacit knowledge related to (§3). The embedded communication (§2) supported multiple other principles. The sufficient model (§5) arose from the successful solicitation of tacit knowledge and the interactive face validation (§4).

6.2. Contributions and Contextualisation with the Literature

It was the agile communication interactions that were key to the successful development of the MVM. There were several aspects to the communication that became apparent from the case study, and these related to how the tacit knowledge was extracted.

Industrial firms have complex internal reporting structures. The case study showed that no one person within the firm had all the knowledge needed for the simulation, and even then, much of the knowledge was tacit. While any analyst is likely to have access to the main contact person within the organisation (the ‘client coordinator’), it is also necessary that the analyst has access to staff deeper in the organisation; e.g., the truck drivers, dispatchers, etc. Operational details are not necessarily known in full by managers in the industry—it may be necessary to get these from lower-level managers or operators themselves. A typical way to receive this communication is for it to be relayed through the hierarchy, but this raises the significant risk of misunderstandings. The analyst should recognise tacit knowledge and find ways to elicit it. We found that it was helpful for the analyst to be familiar with the environment and habits of the staff. This was because we found that soliciting tacit knowledge from operators was best done through casual meetings (rather than formal), and this required opportunities for spontaneous interactions.

The concept that industry participants need to be included in the model-building process is well known in the literature. The idea takes several forms, such as Nonaka’s tacit knowledge, as well as facilitated modelling [9,12,64]. However, it is rare to see participatory methods combined with simulation models. The present work contributes to the field by establishing a set of principles and an MVM framework that was demonstrably able to lead to a simulation model (see Figure 5 for the framework). Hence, this work also contributes to the broader field of participative or facilitated modelling, and is one of only a few studies reported that used these methods as applied in logistics.

There is existing, though not extensive, literature on participative methods applied to simulation generally, but this is sparse when applied more specifically to logistics. One of the participative methods defines a ‘participation scheme’ [84]. The key idea is to involve stakeholders during the entire simulation modelling process and identify the level of stakeholder participation. This method provides a formal way of defining participation, whereas the present paper took a more organic approach whereby the analyst explored deeper into the organisation on a relationship basis via the embedding process. It is possible that our approach might take a longer time to establish and require more effort on the part of the analyst than the participative method, but on the other hand, it appears that the participative method might be critically dependent on establishing the identity of key stakeholders at the outset. Other than the cited reference, there appears to be no other literature on the topic of extracting implicit knowledge for logistics simulation.

The current work broadly overlaps with the Industry 4.0 concept of digital twins; i.e., virtual representation of a (typically) mechanical or manufacturing system, for which a large body of literature exists. In some ways, a logistics simulation is a type of digital twin. While this is an uncommon idea, or at least the application of this term to freight logistics is rare, there have been a few applications, such as that presented in [85]. Those authors offered a process for designing a digital twin in production logistics. However, their concept of logistics did not extend to freight, but was primarily focused on aspects of in-house material handling or material resource planning (MRP). Their framework was silent on the possibility of tacit knowledge or participative modelling. In addition, their validation was to a simple single station robot in an academic lab environment, in contrast to the more complex real-world logistics case in the present paper. Another paper in the area of digital twins applied to logistics-modelled parking management of inner-city freight vehicles [86]. As before, there was no inclusion of tacit knowledge. Comparison of different line-haul modes of transport (‘synchromodal’) has also been considered a type of digital twin [87]. All these approaches made the assumption that extraction of the parameters of logistics was a straightforward and objective process of explicit data collection, and there was no tacit knowledge in the system. They were also applied to relatively simple problems.

In contrast, our experience in a real-world situation of generalized urban PUD is that the logistics operations had a high degree of tacit knowledge. Hence, the present principle-based MVM framework is both novel and has the potential to provide new ways of approaching the question of how tacit knowledge may be extracted from complex operational environments.

6.3. Implications for Practitioners

As regards the temporal sequence of implementation of the principles and the relationships between them, our experience is summarised in Figure 13. Green blocks indicate MVM activities conducted in compliance with proposed principles, while orange blocks present knowledge extracted and clarified with the model development.

6.4. Critique

There were several limitations of this study. First, the validation was limited to face validation. This may have been sufficient for the minimum viable simulation model as intended here. As this is developed into a detailed model, it will need to be further validated. Second, the paper mainly drew attention to the analyst’s perspective. The client raised no issues, but this was not the same as actively evaluating whether there were issues. Ideally, the client’s perspective and satisfaction would also be examined. Last, this simulation model only presented the main operations. For a detailed model, it would need to include other operations such as the real consolidation process, dispatching process, paperwork process, and forklift operator and driver break times. For example, the actual freight consolidation was more complex because it was based on suburbs, and trucks may visit more than one suburb. In addition, there were also limits included in the real consolidation, such as the weight limit and the volume limit of PUD trucks. A comprehensive freight model would ideally address all these in an integrative way.

7. Conclusions

The objective was to create a methodology to handle the knowledge acquisition needed to build a sufficient simulation model at the initial modelling stage. The difficulty of simulation modelling is that it produces outcomes quantitatively, but if the architecture of the model is incorrect from the outset, then that precision may be spurious. It may be difficult to identify these architectural problems afterwards by inspection of the results. The paper offered a solution by presenting an agile method for extracting information for optional simulation that is called MVM. The MVM method proposes five principles: iterative development, embedded communication, soliciting tacit knowledge, a sufficient model, and interactive face validity. These may be used in combination to elicit tacit knowledge and manage the boundary of knowledge. Although client engagement is described elsewhere [13,14], the present work emphasised the communication methods at the boundary of knowledge and tacit knowledge, and this was novel. At its heart, this paper proposed that the development of a simulation model is an iterative process of extracting tacit requirements from the stakeholders. In itself, this is not new, as the concepts of requirements analysis, tacit knowledge, and minimum viable software products are well known in their respective bodies of literature. However, the combination of the concepts has not previously been shown in the literature for a logistics simulation. The methodology was tested on a case study of freight operations, and the results were encouraging. The approach successfully identified and overcame communication and information errors.

The novel contribution of this work was the presentation of a new methodology that may be used to elicit tacit information from industrial clients for building a minimally sufficient simulation model at the early modelling stages. The benefits of this proposed MVM method over other methods in the existing literature are a more explicit solicitation of tacit knowledge, provision of methods to include boundary-spanning activities in the model development process, and a practical application of face validation with the client.