1 of 502

Chapter 1

Computer Simulation:

General Methodologies

1

2 of 502

Learning objectives

Classify the type of system (§ §1.2–1.3)
Delineate the components of a computer simulation (§ 1.3)
Appreciate the landscape of business process simulation software suites and vendors (§ 1.4)
Understand the input data analysis (§1.5), including input parameter optimization (§ 1.9)
Understand the basic principle of (pseudo–) random number generation (§ 1.6)
Define simulation verification and validation (§ 1.7)
Recall the statistical analyses that go into output data analysis (§ 1.8)

2

3 of 502

1.2 Preliminary concepts

The basic concept of a computer simulation:

Physical simulation – require significant efforts, costly and time–consuming;
Simulation by analogy – manual efforts to conduct the experiments, tabulate the results;
Simulation by computer – an accurate estimate of the expected payoff through many trials.

3

4 of 502

1.2 Preliminary concepts

Disadvantages of computer simulation:

Results are based on random numbers;
Large number of trials;
Each simulation requires its own design;
AnyLogic PLE is time–consuming;
Potentially prone to error.

4

Advantages of computer simulation:

Analysis of large, complex problems;
Experiment with different policies and scenarios;
Saves time;
Require a little or no complex mathematics.

5 of 502

1.3 The computer simulation methodology

Classifying the system:

A discrete–event system – the state of the system changes only at certain points in time.
A continuous system – the state of the system changes continuously overtime.
An agent–based system – independent agents interact, useful if the interactions are complex.
System dynamics – feedback systems theory is used to explain complex system behaviors, is more popular in strategic decision–making.

5

6 of 502

1.3 The computer simulation methodology

Examples of the system:

A discrete–event system: The state of the system changes when an order arrives, completes processing, advances to machine’s queue, or departs the system.
A continuous system: Simulating a moon rocket launch, the state of the system changes by the rocket’s position, speed, acceleration, and so on.
An agent–based system: An adaptive supply chain network in which each firm behaves differently during disruptions.
System dynamics: The bullwhip effect and the dynamic behavior of inventory.

6

7 of 502

1.3 The computer simulation methodology

Classifying simulation methodology (Grigoryev, 2022):

7

8 of 502

1.3 The computer simulation methodology

Discrete–event systems:

A terminating system – precise known starting and ending points.
A nonterminating system – ongoing without precise known starting and ending points. The conditions at the end of one day are the starting conditions of the next day.

8

Length of the simulation — the amount of time over which to conduct the simulation for purposes of analysis.

9 of 502

1.3 The computer simulation methodology

The basic steps of computer simulation (adapted from Banks et al., 2004):

9

10 of 502

1.3 The computer simulation methodology

Model inputs:

Initial conditions – initial values that express the state of the system.
Deterministic data – known input values that are needed to perform the calculations.
Probabilistic data – quantities whose values are uncertain but needed to obtain the outputs.

10

11 of 502

1.4 Why AnyLogic?

A software, specializing in business process simulation. Automates the drawing process flow diagrams;
Automates random number generation, discrete–event execution, and simulation experiment bookkeeping;
The coding knowledge required is basic Javascript;
A free PLE version;
A multi–method software, allowance to build simulation models with integrated models.

11

12 of 502

1.5 Input data analysis

Preparing the inputs to a simulation:

Data collection:

Known deterministic data are identified and recorded.
Uncertain data parameters (e.g., demand arrival patterns, processing times, supplier lead times, and so forth) must be collected, probability distributions can be estimated.

12

13 of 502

1.5 Input data analysis

Preparing the inputs to a simulation:

Specifying distributions:

Collected probabilistic data may be represented by empirical distributions (by frequency histograms)
For continuous distributions can be further hypothesized, and then use maximum likelihood estimation to find the parameters.

13

14 of 502

1.5 Input data analysis

Issues arises during data collection:

No system–collected data is available.
The system–collected data is the wrong data.
The data is difficult to collect.

14

Triangular distribution:

What is the shortest time this event has ever required?
How long does this event usually take?
What is the longest time that this event has ever required?

15 of 502

1.6 Random number generation

15

16 of 502

1.6 Random number generation

Computer languages have a capability for generating a sequence of random numbers between 0 and 1:

The approach is based on numerical methods.
Each time that same seed is used, the same sequence of random numbers is generated.
The generated numbers are uniformly distributed between 0 and 1, and successive numbers are statistically independent of each other.

16

17 of 502

1.6 Random number generation

17

18 of 502

1.6 Random number generation

18

19 of 502

1.6 Random number generation

19

Inverse transform method – generating random numbers from a random variable’s cumulative distribution function and uniform 0–1 random numbers.

20 of 502

1.6 Random number generation

20

21 of 502

1.7 Model verification and validation

Verification determines whether a model actually behaves as an experimenter assumes it does.

Before and during modeling. Make flowcharts, describe conceptual models with pseudo–code.
Post–modeling verification. Debug modules and connections. Animation and graphical outputs are useful.
Advanced techniques. Sensitivity analysis using a variation experiment — useful for rerunning model with varying inputs. Robustness tests.

21

22 of 502

1.7 Model verification and validation

Validation tests whether a simulation model reasonably approximates a real system.

Micro–validation – ensures that the logic rules of the simulation model’s sub–processes and sub–systems are captured correctly.
Macro–validation – ensures that the logic rules correctly define all sub–processes interaction.
Face validation – a qualitative approach where a modeler seek consensus from subject–matter experts.
Empirical validation – an quantitative approach, comparing the output from simulation replications against theoretical.

22

23 of 502

1.8 Output data analysis

23

24 of 502

1.8 Output data analysis

24

25 of 502

1.8 Output data analysis

Overview of computer simulation in supply chain and operation management:

25

26 of 502

1.9 Simulation optimization

Default global optimization algorithm, implemented in AnyLogic:

The user interface identifies the “best” input parameter based on a measure of central tendency;
Neither method performs the identification if the reported “best” parameter offer better performance than others;
The algorithm cannot guarantee the identification the global optimal input parameter.

26

27 of 502

1.9 Simulation optimization

Shortcomings of the default global optimization algorithm, implemented in AnyLogic:

The KPI dashboard is not inherited by an optimization experiment;
OptQuest optimization engine does not iterate the decision variables over their defined ranges in sequential order from low to high (discrete) values.

27

28 of 502

Chapter 2

Business Process Simulation �Modeling and Analysis

28

29 of 502

Learning objectives

Become familiar with AnyLogic process models (§ § 2.1–2.2)
Develop technical skills by building process models (§ § 2.3-2.4)
Learn how to reproduced and replicate (instances) of simulation experiments to collect relevant simulation statistics. (§ § 2.5.1-2.5.3)
Validate a simulation model (§ 2.5.4)
How simulation modeling accelerated the "what-if?" Business design (§ § 2.4)
Learn how simulation optimization guides parameter selection, decision-making, and understanding of system variability. (§ 2.6)
Build analytical and management skills through hands-on scenarios that use simulation to identify “pain points” and improvement areas (§ § 2.7)

29

30 of 502

Chapter summary

Case study of a simple operation
Case study description (§2.1)
Step–by–step instructions to create a first AnyLogic process model (§2.2)

30

31 of 502

2.1

A Simple Process Model:

A Bank Office

31

32 of 502

2.1 A simple process model: A Bank Office

Problem statement

The simplest queuing model simulating how customers are serviced at the ATM.

Arrival rate is relatively steady throughout the peak banking hours
Customers arrive predetermined to use the ATM or to seek the assistance of a person

A step–by–step tutorial is freely available on the AnyLogic help system by selecting Help → AnyLogic Help → Tutorials → Bank Office (Queueing system) → Phase 1. Creating a simple model. Alternatively, navigate here: https://anylogic.help/tutorials/index.html.

32

33 of 502

2.1 A simple process model: A Bank Office

33

Customers	18
Average inter–arrival time	313 min
Average arrival rate	0,3 cust per min
Tellers	4
ATM	1
% of customers served by tellers	50%
% of customers used ATM	50%
Average time ATM	1,5 min
Shorterst time ATM	0,8 min
Longest time ATM	3,5 min
Average time teller	6 min
Shortest time teller	2,5 min
Longest time teller	11 min
Max. customers in line	20 min

34 of 502

2.1.2 Process model

34

Download the AnyLogic Personal Learning Edition (PLE) at https://www.anylogic.com/downloads.
Model the ATM process first. A step–by–step tutorial is freely available on the AnyLogic help system by selecting Help → AnyLogic Help → Tutorials → Bank Office (Queueing system) → Phase 1. Creating a simple model. Alternatively, navigate here: https://anylogic.help/tutorials/index.html.1
Add animation to the ATM process simulation. Instructions are available by navigating the above tutorial to Phase 2. Creating a model animation.
Add the teller process to the simulation, along with its animation. See Phase 3. Adding tellers.
Collect basic performance metrics for the simulation. See Phase 4. Collecting utilization statistics.

35 of 502

2.1 A simple process model: A Bank Office

35

Download the AnyLogic Personal Learning Edition (PLE) at https://www.anylogic.com/downloads.
Model the ATM process first. A step–by–step tutorial is freely available on the AnyLogic help system by selecting Help → AnyLogic Help → Tutorials → Bank Office (Queueing system) → Phase 1. Creating a simple model. Alternatively, navigate here: https://anylogic.help/tutorials/index.html.1
Add animation to the ATM process simulation. Instructions are available by navigating the above tutorial to Phase 2. Creating a model animation.

Process model

36 of 502

2.1 A simple process model: A Bank Office

36

Add the teller process to the simulation, along with its animation. See Phase 3. Adding tellers.
Collect basic performance metrics for the simulation. See Phase 4. Collecting utilization statistics.

Process model

37 of 502

2.1 A simple process model: A Bank Office

37

In “Phase 2,” consider temporarily setting the arrival rate to 0.5 customers per minute (30 per hour) to observe some queueing in the simulation.
In “Phase 3” and “Phase 4,” temporarily use arrival rate 1 per minute (60 per hour) to observe queueing.

Process model

38 of 502

2.1 A simple process model: A Bank Office

The triangular service time distribution implies that a teller’s expected service time is (2.5+6+11)/3 = 6.5 minutes; the teller resource pool capacity is 4 × 60/6.5 = 36.9 customers per hour, on average. The expected service time of the ATM is 1.93 minutes; the ATM’s average capacity is 60/1.93 = 31.1 customers per hour. And so an average system arrival rate of up to 36.9/50% + 31.1/50% = 136 customers per hour would not exceed the average process capacity.

38

Process model

39 of 502

2.1 A simple process model: A Bank Office

Long–run performance is rather difficult to analyze with stochastic models — and simple with simulation. Process performance is subject to four distinct types of uncertainty: variable arrival times, variable “customer types” (ATM vs. teller demand), variable ATM service times, and variable durations of teller service encounters.

39

Process model

40 of 502

2.2

More Complex Process Models:

A Manufacturing Line

40

41 of 502

2.2 A manufacturing line

A linear manufacturing process that contains four machines

41

A batch of orders is uniformly and discretely distributed between 3 and 7 units arrives at the start of every day (that’s mean 5 orders/day with standard deviation √2 orders/day)

Process Description

42 of 502

2.2 A manufacturing line

42

Each order is processed sequentially by each of the four machines (i.e., a flow shop) with processing times that vary according to the following triangular distribution.

Process Description

43 of 502

2.2 A manufacturing line

43

A linear manufacturing process:

Process Description

44 of 502

2.2 A manufacturing line

44

Backlog – the total units of work–in–process inventory that has arrived and exists anywhere in the system.

Backlog WIP – the total unit of work–in–process inventory that has commenced production; does not include backlogged orders waiting to begin the process.

Financial Performance Metrics

45 of 502

2.2 A manufacturing line

45

Financial Performance Metrics

46 of 502

2.3

Model Building

46

47 of 502

2.3 Model building

Creating a Flow Diagram and Defining Process Properties

Select File → New → Mode

47

Indicate the Model name and Location

Model time units are seconds

Press Finish

48 of 502

2.3 Model building

Creating a Flow Diagram and Defining Process Properties

Create process model

48

Drop simulation building blocks from the Process Modeling Library Palette onto the “canvas”

49 of 502

2.3 Model building

Creating a flow diagram and defining Process Properties

Create process model

49

A Source node where the customer orders arrive.
A Time Measure Start block which time–stamps the arrival of every order.
A Queue block where orders wait their turn to start the process at machine 1.
A Time Measure Start block which records the time at which an order is dispatched into the manufacturing line.

1

2

3

4

5

6

7

8

50 of 502

2.3 Model building

Creating a flow diagram and defining Process Properties

Create process model

50

A Delay block which models the random processing times of orders at machine 1
Three more pairs of Queue and Delay blocks to model machines 2, 3, 4 and their queues.
Two Time Measure End blocks (“End1” and “End2”) which time–stamp the moment a job completes processing. End1 and End2 record an identical departure time for each order.

1

2

3

4

5

6

7

8

51 of 502

2.3 Model building

Creating a flow diagram and defining Process Properties

Create process model

51

A Sink node where orders depart the system.

1

2

3

4

5

6

7

8

52 of 502

2.3 Model building

52

Lead time – the total time a customer order is in the process, from the moment of arrival to the moment of departure.

Flow time – the duration of time a customer order requires to complete the process, from the moment it commences work in the first station, until it departs the process; the flow time plus the initial wait equals the lead time.

Arrival process – the way in which customers from the population arrive for service.

Creating a flow diagram and defining Process Properties

53 of 502

2.3 Model building

Features of process model:

We refer to the duration End1−Start1 as the process lead time and End2−Start2 as the process flow time.
We accept default naming of blocks of the same type (e.g., “queue,” “queue1,” “queue2,” and “queue3”). This results in model where “queue1” is the name given to the second queue.

53

Creating a flow diagram and defining Process Properties

54 of 502

2.3 Model building

Define order arrival process

Go to View → Properties and then click on the source node.

54

The arrivals of batches: rates, inter–arrival times, or schedules.

A batch of agents arrives at deterministic inter–arrival intervals of 1 second..

We set First arrival occurs at model start.

Creating a flow diagram and defining Process Properties

55 of 502

2.3 Model building

Define order arrival process

Go to View → Properties and then click on the source node.

55

Limited number of arrivals is selected.

Maximum number of arrivals = 100.

Creating a flow diagram and defining Process Properties

56 of 502

2.3 Model building

Define order arrival process

Go to View → Properties and then click on the source node.

56

One can further restrict the arrival process 50 arrival batches by enabling Limited number of arrivals and then setting Maximum number of arrivals to 50.

Creating a flow diagram and defining Process Properties

57 of 502

2.3 Model building

Define a pull policy in source properties

57

Forced pushing checkbox allows us to specify a push vs. pull policy.

If Forced pushing is enabled, the source does not allow the orders to wait until they can be “consumed” by the next object.

Creating a flow diagram and defining Process Properties

58 of 502

2.3 Model building

Define a pull policy in source properties

58

Deselecting Forced pushing and choosing the behavior (destroy or wait in the queue) from Agents that can’t exit models a pull system that depends on available capacity, corresponding to one–piece flow and CONWIP control techniques.

Creating a flow diagram and defining Process Properties

59 of 502

2.3 Model building

The inter–arrival intervals of batches may be deterministic or stochastic, and the number of agents within a batch may be deterministic or stochastic.

Define queue rules:

Queueing process – the way in which customers wait for service.

Queueing discipline – the way customers are selected for service.

59

CONWIP control – CONstant Work in Process where the start of manufacturing each product in an assembly line is triggered by the completion of one at the end of the line; a kind of single–stage kanban system.

Creating a flow diagram and defining Process Properties

60 of 502

2.3 Model building

Creating a flow diagram and defining properties: Define queue rules

Open properties of a Queue block.

60

A queue’s capacity can be finite (e.g., Capacity = 50) or unlimited (checking the Maximum capacity checkbox).

Its dispatching rule can be FIFO, priority–based (i.e., orders from the most important customers dispatched first), preemptive (the Enable preemption option), agent comparison (i.e., preferences for certain orders), or LIFO.

The Enable exit on timeout option allows orders to abandon the queue.

61 of 502

2.3 Model building

Creating a flow diagram and defining properties: Define processing rules

Open a Delay block’s properties for the first block (“M1”).

61

Delay time can be modeled with the Delay time: triangular(1, 2, 3) function.

We employ symmetric triangular distributions using the two–parameter Delay time: triangularAV(2, 0.5) function.

Service process – the way and rate at which customers are served.

62 of 502

2.3 Model building

62

Creating a flow diagram and defining Process Properties

63 of 502

2.3 Model building

Define processing rules

63

The Capacity setting in a Delay block is the batch size of orders that can be processed at the machine simultaneously.

In the advanced models, the processing stage may require multiple resources (e.g., a machine and a worker and a forklift). Such requirements can be implemented using Resource, Seize, Release, and Service process modeling blocks.

Creating a flow diagram and defining Process Properties

64 of 502

2.3 Model building

Define processing rules

Repeating for the Delay times at machines M2, M3, and M4, our model uses the following processing times.

64

Creating a flow diagram and defining Process Properties

65 of 502

2.3 Model building

Create basic animation

65

Double–click the Rectangular Node.

Draw nine Rectangular Nodes (the source node, four waiting areas, and four machines).

Connect Rectangular Nodes with Paths.

Adding Animation

66 of 502

2.3 Model building

Create basic animation

66

Open the Properties for each rectangular node and give each a name.

Adding Animation

67 of 502

2.3 Model building

Adding Animation: Create basic animation

67

In the Properties of each process diagram element (i.e., Source, Queue, and Delay blocks), assign the drawn Rectangular Nodes.

Assign the Supplier node to the Source block by setting the Location of arrival to Network/GIS node and the Node to Supplier.

Repeat this in properties for each Queue and Delay block, chose the name of the corresponding Rectangular Node in Agent location.

68 of 502

2.3 Model building

Adding Animation: Set simulation experiment parameters

Select the Projects tab and view Properties for the Simulation: Main.

68

Set Stop to Stop at specified time.

Set Stop time to 100 time units. The experiment will simulate 100 days continuous operation using 100 seconds of model time.

69 of 502

2.3 Model building

Set simulation experiment parameters

69

To enable a reproducible simulation, set a Fixed seed (reproducible simulation runs) in Randomness.

Henceforth, if Fixed seed (reproducible simulation runs) is enabled, the Seed value is 1.

Adding Animation

70 of 502

2.3 Model building

Set simulation experiment parameters

Select the menu item Model → Run → MyFirst–Model.

70

Adding Animation

71 of 502

2.3 Model building

In this step, diagrams to analyze the following financial and operational KPIs will be created:

Revenue, costs, profit;
Capacity utilization;
Lead time and flow time;
Backlog.

71

KPI dashboard – a graphical representation of financial, operational, and customer service metrics, arranged for intuitive data visualization.

Collect Statistics

72 of 502

2.3 Model building

Revenue, costs, profit

From the Agent palette, drag and drop three Variable blocks onto the canvas, and give them names C, R, and Z.

72

Parameters mfgCost, Revenue, and Backlog define the monetary estimations of manufacturing costs, revenue, and backlog delay costs.

Collect Statistics

73 of 502

2.3 Model building

Revenue, costs, profit

73

From the Agent palette drag and drop three Parameter blocks onto the canvas.

In properties, rename them mfgCost, Revenue, and Backlog.

In the Default value assign them values $10, $15, and $4.

Collect Statistics

74 of 502

2.3 Model building

Revenue, costs, profit

From the Analysis palette we drag and drop a Bar Chart which will display the cumulative variables C (cost), R (revenue) and Z (backlog).

74

Collect Statistics

75 of 502

2.3 Model building

Revenue, costs, profit

75

Setting the Recurrence Time to 1 second updates the chart every second of the model run time (i.e., after every simulated day).

Collect Statistics

76 of 502

2.3 Model building

Revenue, costs, profit

Update the variables R, C, and Z by defining time points in the process flow diagram.

76

Collect Statistics

77 of 502

2.3 Model building

Revenue, costs, profit

One may obtain a list of all model parameters and their default values by clicking on the Project area, and then selecting Simulation: Main properties.

77

Collect Statistics

78 of 502

2.3 Model building

78

Capacity utilization – the proportion of time during a scheduling horizon that resources in a process are busy working on the flow units of that process.

Collect Statistics

79 of 502

2.3 Model building

Capacity utilization

From the Analysis palette we drag and drop a Bar Chart to analyze capacity utilization.

79

Collect Statistics

80 of 502

2.3 Model building

Capacity utilization

To analyze a time series of capacity utilization throughout the simulation, insert a Time Plot from the Analysis palette.

80

Collect Statistics

81 of 502

2.3 Model building

Capacity utilization

Analyze mean capacity utilization’s dependence on the length of the first queue over time.

81

Collect Statistics

82 of 502

2.3 Model building

Lead time and flow time

To represent the End1 and End2 datasets in diagrams, create from the Analysis palette a Time Plot of how the times evolve during the simulation.

82

Collect Statistics

83 of 502

2.3 Model building

Lead time and flow time

To represent the End1 and End2 datasets in diagrams, create from the Analysis palette a Histograms of the distribution of times.

83

Collect Statistics

84 of 502

2.3 Model building

Backlog and queue analysis

Create a Bar Chart.

84

Collect Statistics

85 of 502

2.3 Model building

Backlog and queue analysis

Create a Time Plot.

85

Collect Statistics

86 of 502

2.3 Model building

Backlog and queue analysis

Create a Bar Chart.

86

Collect Statistics

87 of 502

2.4

Experiments &

Managerial Insights

87

88 of 502

Learning objectives

Strengthen analytical and management skills in inventory management (§5.1-5.4)
Build simulation models of key inventory control policies and customize KPI dashboards for performance tracking. (§5.2)
Learn to model complex inventory dynamics like stochastic demand, variable lead times, and planned shortages. (§5.2)
Evaluate inventory policies under dynamic conditions like demand shocks and lead time disruptions.(§5.3.1-5.3.3)
Gain insight into the trade-offs between efficiency and service responsiveness through simulation. (§5.3.4)
Practice running and interpreting simulation experiments to support inventory management decisions. (§5.4)

88

89 of 502

Learning objectives

Practice setting up the parameters for an experiment (§5.1)
Run a simulation experiment and interpret the KPI dashboard to glean managerial insights (§5.2)
Learn how simulation modeling accelerates the “what if?” business design and improvement process (§§5.3–5.4)

89

90 of 502

2.4 Experiments and managerial insights

To collect statistics in the experiment view one should check that the Force statistics collection option is checked in every block in the process flow diagram.

90

Experimental view – an AnyLogic window that appears when AnyLogic is running a process simulation; includes simulation controls and a depiction of the process model and KPI dashboard with metrics that update dynamically as the simulation runs.

Experimental settings

91 of 502

2.4 Experiments and managerial insights

The following settings are used in every experiment:

Inter–arrival times of batches are deterministic, with the first arrival occurring at the model start;
Each experiment runs 100 seconds, representing 100 days;
The FIFO discipline is employed in every queue;
Queue capacities are maximum (in each queue’s properties, select the Maximum capacity checkbox).

91

Experimental settings

92 of 502

2.4 Experiments and managerial insights

Settings of Experiment 1.

92

A model file for the experiment can be downloaded from the AnyLogic Cloud as MyFirstModel–exp1.alp.

Experiment 1

93 of 502

2.4 Experiments and managerial insights

To run the experiment, select Model → Run → MyFirstModel/Simulation.

93

Statistics collected by the parameters.

Flow statistics at every stage.

Simple process animation.

KPI dashboard.

Experiment 1

94 of 502

2.4 Experiments and managerial insights

Results:

507 orders arrived
Of the 507 arrivals, 51 were dispatched to the first machine (M1); 456 remain waiting to be dispatched.
Of the 51 orders dispatched to M1, 50 completed processing at M1.
Of the 50 orders that advanced to M2, 49 departed M2.
Of the 49 orders that arrived at M3, 32 completed processing, 1 was still in process, and 16 remained in M3’s queue.

94

Experiment 1

95 of 502

2.4 Experiments and managerial insights

95

Experiment 1

96 of 502

2.4 Experiments and managerial insights

Results:

Capacity utilization depends on the number of waiting orders. The same holds true for the flow and lead times:

96

Experiment 1

97 of 502

2.4 Experiments and managerial insights

Queueing theory:

97

Service level (of a flow line) – the proportion of jobs that arrive to a manufacturing process during a planning period that have been completed; not the same as service level in an inventory system.

Experiment 1

98 of 502

2.4 Experiments and managerial insights

Based on the analysis, suppose the manufacturing manager proposes the following improvements:

The worker at machine M3 is reassigned to M1 so M1 can process two orders at once. (In M1’s Delay block properties, set Capacity to 2.)
At M3, a more experienced worker is hired to replace the reassigned worker.
The average processing times at M3 are expected to reduce from 3 to 1.5 seconds, ranging between 1 and 2 seconds. (In M3’s Delay block properties, change Delay time to triangularAV(1.5, 0.3).)
Such actions increase the per–order manufacturing costs from $10 to $11. (In the mfgCost parameter’s properties, change the Default value to 11.)

98

Experiment 1

99 of 502

2.4 Experiments and managerial insights

Settings of Experiment 2.

99

A model file for the experiment can be downloaded from the AnyLogic Cloud as MyFirstModel–exp2.alp.

Experiment 2

100 of 502

2.4 Experiments and managerial insights

Run the experiment.

100

Statistics collected by the parameters.

Flow statistics at every stage.

Simple process animation.

KPI dashboard.

Experiment 2

101 of 502

2.4 Experiments and managerial insights

101

The lead time statistics comparison that are revealed when clicking on the End1 block in experiments 1 and 2.

Flow Similar flow time statistics are available by clicking on the End2 block.

Experiment 2

102 of 502

2.4 Experiments and managerial insights

The two experiments’ KPIs for financial and operational performance.

102

Experiment 2

103 of 502

2.4 Experiments and managerial insights

Results:

Revenue increased $510 (106%).
Total costs decreased $1482 (–67%).
Profit increase of $1992 from –$1740 to $252 — flipping from loss to gain.
The backlog was essentially eliminated (–99.0%).
The service level increased from 6.3% to 95.7% .
The average WIP of orders queued at M2, M3, and M4 will shrink from 7.8 to 1.0 orders, on average.
The average system capacity utilization increased +6.5%

103

Experiment 2

104 of 502

2.4 Experiments and managerial insights

Additional improvements:

Change from push to pull by using a one–piece flow, CONWIP, and Heijunka dispatching principles.
Standardize the manufacturing technology to align the cycle times and reduce the processing time variability at each machine. Consequently, every machine has processing time in seconds that fluctuates following the triangular(0.5, 1.0, 1.5) distribution.

104

Heijunka – the Japanese term for production leveling so that steps in a production process are smoothed out to flow at the same rate.

Experiment 2

105 of 502

2.4 Experiments and managerial insights

Additional improvements:

Coordinate order management at the sales site to reduce the variability of incoming orders. Specifically, they will control orders such that the inter–arrival time of batches slows from 2 to 2.5 seconds and the number of orders per batch shifts from “1 or 2” to “2 or 3” (average arrival rate increases from 0.75 to 1 per second).
Eliminate the second worker at M1.

105

Experiment 2

106 of 502

2.4 Experiments and managerial insights

Settings of Experiment 3.

106

A model file for the experiment can be downloaded from the AnyLogic Cloud as MyFirstModel–exp3.alp.

Experiment 3

107 of 502

2.4 Experiments and managerial insights

Run the experiment.

107

Statistics collected by the parameters.

Flow statistics at every stage.

Simple process animation.

KPI dashboard.

Experiment 3

108 of 502

2.4 Experiments and managerial insights

The two experiments’ KPIs for financial and operational performance.

108

Experiment 3

109 of 502

2.4 Experiments and managerial insights

Results:

A 40% improvement in total profits.
The number of orders and completed orders were each up 39%
Mean capacity utilization increased by 18% with all machines balanced between 92% and 97% average utilization.

109

Experiment 3

110 of 502

2.5

Replication & Validation

110

111 of 502

Learning objectives

Employ the scientific principle of reproducible experiments, controlled by the “seed” value (§§6.1–6.2).
Understand how the seed can be changed (and the simulation rerun) many times, replicating a simulation experiment to create a distribution of observations that allows us to better understand the uncertainty inherent in each KPI (§6.3).
Automate the replications in the free PLE version of AnyLogic and collect a distribution of sampled values for key KPIs (§6.3).
Validate a simulation model (§6.4).

111

112 of 502

2.5 Replication and validation

112

Creating a new simulation replication by changing the seed value:

Instance – the drawing of random numbers for a single run of a simulation experiment..

Reproducible simulation – when an instance of a simulation experiment’s output is replicated identically.

Change Seed value to 2.

Runs, replication, and reproducibility

113 of 502

2.5 Replication and validation

113

A replication of Experiment 3 with the seed value of 2.

Runs, replication, and reproducibility

114 of 502

2.5 Replication and validation

114

Summary of 10 replications of Experiment 3.

Runs, replication, and reproducibility

115 of 502

2.5 Replication and validation

115

Runs, replication, and reproducibility

116 of 502

2.5 Replication and validation

116

Runs, replication, and reproducibility

117 of 502

2.5 Replication and validation

117

The revenue result as follows:

“We expect that the revenue from this redesigned process will be $1370, and we are 95% certain that the actual revenue will fall within the range of $1353 to $1387 (that’s $1370 ± 1.2%) if the system after the process change behaves exactly the same as the simulation model.”

Runs, replication, and reproducibility

118 of 502

2.5 Replication and validation

118

If any replication gave particularly interesting results, it can be conveniently reproduced for further analysis by resetting the seed value.

Table indicates that replications 1, 7, and 8 recorded unit profits exceeding $3.75 per order. The manager could reset the seed value to 1, 7, and 8 to explore what in particular happened in those runs to achieve such high profits.

Reproducibility for deeper analysis

119 of 502

2.5 Replication and validation

119

One can use AnyLogic PLE to replicate an experiment thousands of times to truly understand the uncertainty in all KPI output measures.

Random seeds

Toggle on Random seed (unique simulation runs).

Automated replications

120 of 502

2.5 Replication and validation

120

Random seeds

A replication of Experiment 3 with a random seed.

Automated replications

121 of 502

2.5 Replication and validation

121

A workload in PLE

We want to measure Revenue, Profit, Customer orders, and Output for 1000 replications.

Right–click on the Main model in the Projects view, then select New → Experiment → Parameter Variation.

Name the experiment Replicate_1000_times.

Automated replications

122 of 502

2.5 Replication and validation

122

A workload in PLE

Add four Histogram Data.

Add four Histogram charts.

Automated replications

123 of 502

2.5 Replication and validation

123

A workload in PLE

Properties of the four Histogram Data and Histogram objects are added.

Automated replications

124 of 502

2.5 Replication and validation

124

A workload in PLE

In the Projects view, select the Replicate_1000_times Parameter Variation experiment.

Automated replications

125 of 502

2.5 Replication and validation

125

Automated replications

126 of 502

2.5 Replication and validation

126

A workload in PLE

In the AnyLogic menu, select Model → Run → Replicate_1000_times.

It is not possible to reproduce Figure exactly as these replications employ Random seed (unique simulation runs).

Automated replications

127 of 502

2.5 Replication and validation

127

A workload in PLE

Click on any Histogram Data object to obtain detailed statistics.

Automated replications

128 of 502

2.5 Replication and validation

128

A workload in PLE

Comparing 10 vs. 1000 replications of Experiment 3.

Automated replications

129 of 502

2.5 Replication and validation

129

Considering the 50000–agent limit in AnyLogic PLE, adopt a 9900–day planning horizon for validation.

The following changes are made to the Experiment–1 and to the parameter variation experiment:

In the main experiment, change the Source properties to allow the maximum number of arrivals to be 9900.
In the parameter variation experiment properties, we:

Set the Stop time to 9900 seconds.
Select Random seed.
Set Replications per iteration to 1000.

Validation

130 of 502

2.5 Replication and validation

130

Queueing theoretic description

In Experiment 1 the mean demand rate is 5 orders per day; the machine processing time distributions are summarized in Table:

Validation

131 of 502

2.5 Replication and validation

131

Validation

132 of 502

2.5 Replication and validation

132

Validation

133 of 502

2.5 Replication and validation

133

Little’s Law – a fundamental result in Operations Research due to John D.C. Little that relates three key process an system (or a subsystem) of a business process: (average system inventory) = (average system flow rate) × (average lead time).

Validation

134 of 502

2.5 Replication and validation

134

Validation

135 of 502

2.5 Replication and validation

135

Validation

136 of 502

2.5 Replication and validation

136

Validation

137 of 502

2.5 Replication and validation

137

Validation

138 of 502

2.5 Replication and validation

138

Validation

139 of 502

2.5 Replication and validation

139

Queueing theoretic description

Expected results for the system:

The theoretical process lead time is approximated 4624.26 days.

Validation

140 of 502

2.5 Replication and validation

140

Comparing analytical and simulation results

Two changes in Experiment 1, required for validation purposes:

The simulation experiment is run for 9900 seconds.
The simulation experiment is replicated 1000 times using random seeds and methods described in §6.3.
In the main experiment, the Source properties are changed to allow an unlimited number of arrivals (uncheck Limited number of arrivals).

Validation

141 of 502

2.5 Replication and validation

141

Comparing analytical and simulation results

The resulting simulation �summary statistics should be �compared with the theoretical �values:

Validation

142 of 502

2.5 Replication and validation

142

Comparing analytical and simulation results

We employ the one–sample t–test. Specifically, we conduct 14 hypothesis tests to ascertain if the simulation results are “equivalent” to the theoretical values, where:

Null hypothesis: “the simulation sample mean is equal to the theoretical expected value”;
Alternate hypothesis: “the simulation sample mean is not equal to the theoretical expected value.”

Validation

143 of 502

2.5 Replication and validation

143

Comparing analytical and simulation results

At the α = 0.05 level, we see that there is insufficient evidence to reject the null hypothesis for 12 of the 14 metrics.

We conclude that the validation of the model is complete, and that the model is indeed generating results that are in line with queueing theory.

Validation

144 of 502

2.5 Replication and validation

144

Comparing analytical and simulation results

Instead of hypothesis testing, one may use the 95% confidence interval of the mean. The Backlog order M1 statistic displays a sample mean of 44 551.926, with a mean confidence of 8.664.

Validation

145 of 502

2.5 Replication and validation

145

Comparing analytical and simulation results

This implies that a 95% confidence interval on the population mean is [44 551.926 − 8.664, 44551.926 + 8.664], namely, that a plausible range for the population mean is roughly [44 543.3, 44 560.6].

Validation

146 of 502

2.6

Advanced Experiment Control

& Modeling

146

147 of 502

Learning objectives

Model customer impatience (§7.2), including the changes needed to allow the dynamics of customer abandonment from queues as well as the mechanics to record the metrics of abandonment.
Control simulation experiments dynamically, in real–time as the simulation is executing (§7.3). To facilitate this, several new AnyLogic building blocks are introduced. Another advanced technique will be introduced: “views” that allow the user to separate the process model view from the KPI dashboard view (§7.3.1).
Model resource pools in AnyLogic (§7.4).

147

148 of 502

Taking control

All changes in are applied to the simulation model in Chapter 4, starting with Experiment 1 (summarized in §5.2).

Strip away the KPI dashboard (but retain the animation).
A model file with change is available for download from the AnyLogic Cloud at Process_capacity_and_workload_balancing_v3.2.alp.

148

2.6 Advanced experiment control modeling

149 of 502

Modeling customer impatience

Open Queue block’s properties.

149

Enable the option Enable exit on timeout

Define a constant or random amount of time in the Timeout field

2.6 Advanced experiment control modeling

150 of 502

Modeling customer impatience

Open Queue block’s properties.

150

In the process model, the queue block’s outTimeout port (upper–right green dot) is connected to a new Sink node.

2.6 Advanced experiment control modeling

151 of 502

Real–time experiment control

Before simulation model parameters were entered in respective model blocks. For better simulation model control, create interfaces. We introduce new methods for gathering statistics, more accurate costs analysis, and KPI computation.

Views

151

Views – a method of partitioning the AnyLogic experiment view into different areas; useful for navigating thought different parts of complex models as well as separating process logic, animation, and KPI output during an experiment.

2.6 Advanced experiment control modeling

152 of 502

Views

152

Drag the View Area pointer in the desired working area.

2.6 Advanced experiment control modeling

Real–time experiment control

153 of 502

2.6 Advanced experiment control modeling

Views

153

Define the Name as ProcessLogic (and repeat for the AnimationAndOutput view area).

Real–time experiment control

154 of 502

2.6 Advanced experiment control modeling

Views

154

To hyperlink to the process logic, in the Presentation palette, drag a Text object onto the workspace.

Real–time experiment control

155 of 502

2.6 Advanced experiment control modeling

Views

155

Change the Text to Process Logic.

Real–time experiment control

156 of 502

2.6 Advanced experiment control modeling

Views

156

In the Advanced → On click field, type: ProcessLogic.navigateTo();

Real–time experiment control

157 of 502

2.6 Advanced experiment control modeling

Views

157

In the other view, change the Text to Animation & Output and in the Advanced → On click field type: AnimationAndOutput.navigateTo();

Real–time experiment control

158 of 502

2.6 Advanced experiment control modeling

Parameters

Previously parameters mfgCost, Revenue, and Backlog were defined as static values (e.g., Revenue had default value $15 per order). It is possible to expand this by enabling real–time parameter changes during the simulation experiment.

158

Parameters – a way of defining inputs to AnyLogic simulation models that (usually) take on fixed values during a simulation experiment; parameters are changed only when one wants to change model behavior.

Real–time experiment control

159 of 502

2.6 Advanced experiment control modeling

Parameters

159

Add additional Parameters and Variables.

Real–time experiment control

160 of 502

2.6 Advanced experiment control modeling

Parameters

Additional parameters:

mfgCost, Revenue, Backlog: Previously defined in §4.3.
InventoryCost: WIP inventory holding cost per order per day queued at M2, M3, or M4.
OpportunityCost: The opportunity cost for each order that abandons the first queue.
MinArrivalQuantity, MaxArrivalQuantity: Minimum and maximum number of orders arriving in a batch, which is uniformly and discretely distributed on this interval.
ArrivalTime: The inter–arrival time between batches.

160

Real–time experiment control

161 of 502

2.6 Advanced experiment control modeling

Parameters

Additional parameters:

TimeOut: “Exit on timeout” duration until an order is withdrawn from the first queue.
CapM1, ..., CapM4: Capacities of machines M1, . . . , M4, respectively. This is the number of machines in a machine’s resource pool.
MeanProcessTimeM1, ..., MeanProcessTimeM4: Expected processing times at machines M1, . . . , M4, respectively.
VariabilityM1, ..., VariabilityM4: Variability of processing times at machines M1, . . . , M4, respectively; specifically, the second parameter of the following AnyLogic function (see §4.1.4): triangularAV(MeanProcessTime,Variability).

161

Real–time experiment control

162 of 502

2.6 Advanced experiment control modeling

Variables

Additional variables:

C: Manufacturing costs
R: Revenue
Z: Backlog costs
I: Inventory costs �

162

Variable – a way of storing numerical data that changes or is collected during a simulation; whereas parameters are usually static, variables are dynamic.

Real–time experiment control

163 of 502

2.6 Advanced experiment control modeling

Variables

Additional variables:

O: Opportunity costs
LO: Lost orders that abandon the first queue
Q: Output quantity of completed orders
INPUT: Number of incoming orders
Cap: Average capacity utilization across machines M2, M3, and M4
WIP: WIP inventory level in the three queues following M1

�

163

Real–time experiment control

164 of 502

2.6 Advanced experiment control modeling

Variables

Update the properties of process model blocks to assign the logic that updates variables:

Defining variable updating in the sink node.

�

164

Real–time experiment control

165 of 502

2.6 Advanced experiment control modeling

165

Real–time experiment control

166 of 502

2.6 Advanced experiment control modeling

Functions

Drag the Function element from the Agent palette onto the canvas. �

166

Function – a method of automating an algorithm or calculation that needs to be carried out during an AnyLogic experiment; returns the value of an expression when called from a model.

Define properties of functions totalUnitCost.

Real–time experiment control

167 of 502

2.6 Advanced experiment control modeling

Functions

Drag the Function element from the Agent palette onto the canvas. �

167

Define properties of functions totalUnitProfit.

Real–time experiment control

168 of 502

2.6 Advanced experiment control modeling

Functions

Drag the Function element from the Agent palette onto the canvas.

168

Define properties of functions ServiceLevel.

Real–time experiment control

169 of 502

2.6 Advanced experiment control modeling

Events

From the Agent palette drag an Event (named arrival_event) and a Variable (named rolling_arrivals) to the lower left canvas; from the Analysis palette drag a Data Set (named order_dataset) for statistics collection. �

169

Event – a way of scheduling some action to take place during the running of a model

Real–time experiment control

170 of 502

2.6 Advanced experiment control modeling

Events

Define properties of arrival_event.�

170

Set a Mode to Cyclic to repeat it every day.

Set a Recurrence time to 1 second.

Real–time experiment control

171 of 502

2.6 Advanced experiment control modeling

Events

Define properties of arrival_event.�

171

Real–time experiment control

172 of 502

2.6 Advanced experiment control modeling

Events

From the KPI dashboard replace the bar chart (for orders, completed orders, and backlog) with a new Time Plot (from the Analysis palette) to track incoming orders.
�

172

Define properties of a time plot of the Input Orders data set.

Real–time experiment control

173 of 502

2.6 Advanced experiment control modeling

Events

�

173

Define properties of a time plot of the lost orders variable LO.

Real–time experiment control

174 of 502

2.6 Advanced experiment control modeling

Events

�

174

Create an event to calculate inventory costs.

Real–time experiment control

175 of 502

2.6 Advanced experiment control modeling

Events

�

175

Include inventory costs in the cost bar chart.

Real–time experiment control

176 of 502

2.6 Advanced experiment control modeling

Sliders

Sliders allow manual parameter changes while an experiment is running.

�

176

From the Controls palette, drag one Slider to the work space for each of the 21 parameters.

Real–time experiment control

177 of 502

2.6 Advanced experiment control modeling

Sliders

�

177

In slider properties, give it a Name, check Link to and specify the name of the appropriate parameter.

Real–time experiment control

178 of 502

2.6 Advanced experiment control modeling

Sliders

Specify the Minimum value, Maximum value, and Step to define the sliders limits:�

178

Real–time experiment control

179 of 502

2.6 Advanced experiment control modeling

Sliders

�

179

Press Add labels. . . to mark “min value max”.

Real–time experiment control

180 of 502

2.6 Advanced experiment control modeling

Real–time experiment control

Update source parameters to enable slider control of parameters ArrivalTime, MinArrivalQuantity, MaxArrivalQuantity, �and source.

�

180

181 of 502

2.6 Advanced experiment control modeling

Real–time experiment control

Update Process block properties to enable slider control of parameters:

�

181

182 of 502

2.6 Advanced experiment control modeling

Real–time experiment control

In the “Animation & Output” view, create a KPI dashboard that is separate from the process model view.

�

182

In the Presentation palette, drag Text for each of the text labels that are needed in the KPI dashboard.

183 of 502

2.6 Advanced experiment control modeling

Real–time experiment control

�

183

Enter the Formula.

184 of 502

2.6 Advanced experiment control modeling

Real–time experiment control

Syntax for defining the 21 KPIs’ dynamic values as text in the KPI dashboard:

�

184

185 of 502

2.6 Advanced experiment control modeling

Real–time experiment control

�

185

Add a Rounded Rectangle from the Presentation palette. In properties, set the Fill color to white.

186 of 502

2.6 Advanced experiment control modeling

We assumed every worker is dedicated to a single activity in a process, and so we modeled every stage using a Queue block followed by a Delay block, where the Delay block’s “capacity” denotes the number of workers/machines available.

What if a resource serves multiple process steps? For such scenario, one employs Resource Pools.

If a resource must perform N sequential tasks, then rather than employing Delay blocks, we can model this using the following blocks:

�

186

Resources and resource pools

187 of 502

2.6 Advanced experiment control modeling

In the special case N = 1, the foregoing can be simplified with a Service block which includes an embedded queue, a seize, a delay, and a release. Seize, Service, and Assembler blocks can seize one or multiple resource units at once.
A Resource Pool defines a set of resource units that can be seized and released by agents using Seize, Release, Assembler, and Service blocks. A resource unit is either idle or busy and so a Resource Pool collects utilization statistics.

�

187

Resources and resource pools

188 of 502

2.7

Simulation Game &

Optimization

188

189 of 502

Learning objectives

Integrate and practice the knowledge acquired in Chapters 3 through 7 in a series of simulation game rounds (§§8.1–8.3).
Explore the benefits of simulation optimization to find better compromises among conflicting objectives.
Learn simulation optimization (and interpretation of optimization outputs) in AnyLogic (§8.4) as well as how optimization can lead to multiobjective simulation experiments (§8.5).
Apply the learning and gain additional managerial insights in further game rounds (§8.6).

189

190 of 502

2.7 Simulation game and optimization

Players:

A division head who strives to maximize total profit of the division and unit profits for the orders.
A sales manager who wishes to maximize revenue, to accept as many customer orders as possible, and to complete the orders as quickly as possible subject to the lead–time.
A manufacturing manager who seeks the lowest unit costs, high capacity utilization, and low flow time.
A workload balancer who wishes to maintain a high service level.

190

Game rules and roles

191 of 502

2.7 Simulation game and optimization

Rules:

Teams will compete on total profitability.
The managers within team also compete on best individual KPIs.
Ten rounds.
In each round, the group with the highest total profit wins.
In each round a winner is declared for individual categories: best manufacturing manager (KPI: lowest unit cost and lowest flow time), best workload balancer (KPI: highest service level), best sales manager (KPI: highest output and lowest lead time), and best division head (KPI: highest total profit).

191

Game rules and roles

192 of 502

2.7 Simulation game and optimization

Setup:

Each experiment will run for 100 seconds to simulate a 100–day planning period.
Each queue is set at its maximum capacity employing the FIFO queuing discipline.
At most one additional machine may be purchased in each station. Each machine added increases mfgCosts by $1. For example, if 2 machines are added to the original 4 machines, then mfgCosts increase from $10 to $12 per order.
If more than two total machines are desired, then any additional requires out– sourcing at an additional cost of $2 per outsourced machine. For instance, if an extra machine is needed at M1 but 2 extra machines are needed at M3, then mfgCosts are $14 per order.

192

Game rules and roles

193 of 502

2.7 Simulation game and optimization

Input data:

Arrivals defined by interarrival time: 2 seconds (deterministic)
Agents per arrival: uniform discr(2, 5)
Force pushing @ source: False
Force pushing @ all machines : True
Maximum number of arrivals: 50 (set in source properties)
Timeout: 14 seconds�

193

Playing round #1

194 of 502

2.7 Simulation game and optimization

Input data:

Delay time and capacities�

194

Revenue and costs�

Playing round #1

195 of 502

2.7 Simulation game and optimization

In the projects area right–click on the project’s name, select New → Experiment → Simulation.
�

195

Name it Round 1.

Playing round #1

196 of 502

2.7 Simulation game and optimization

�

196

Enter parameters for Round #1.

Playing round #1

197 of 502

2.7 Simulation game and optimization

The model file can be downloaded from AnyLogic Cloud at Process_capacity_and_workload_balancing_v3.3.alp (see the experiment named Round1).
�

197

Results of Round #1 (seed value: 1).

Playing round #1

198 of 502

2.7 Simulation game and optimization

The team agrees to test the process changes:

From time 30 to 55 seconds, exactly 2 orders every day will be accepted (the MaxArrivalQuantity parameter will be reduced from 5 to 2 orders from the 30th to the 55th second).
From time 35 to 60 seconds, a second machine will be installed at M3, implying manufacturing costs of mfgCosts = $11 per order for this period (and revert at time 60 to 1 machine with mfgCosts = $10 thereafter). �

198

Playing round #2a

199 of 502

2.7 Simulation game and optimization

Apply changes in a real–time simulation environment:

Step 0: Select Model → Run → Round 1 to launch the experimental view.

�

199

Playing round #2a

200 of 502

2.7 Simulation game and optimization

Apply changes in a real–time simulation environment:

Repeat these steps to pause at second 35 before clicking the play button in step 5.
At second 35, adjust the capacityM3 slider from 1 to 2, the mfgCost slider from $10 to $11, and set the simulation to pause at second 55. Click the play button.
At second 55, move the maxQtyPerArrival slider back to 5, and set it to pause at second 60.
At second 60, readjust the capacityM3 and mfgCost to original values, and run the simulation until it ends.

200

Playing round #2a

201 of 502

2.7 Simulation game and optimization

Apply changes in a real–time simulation environment: �

201

Results after modifications in Round #2a (seed value: 1).

Playing round #2a

202 of 502

2.7 Simulation game and optimization

Apply changes in a real–time simulation environment:

Add a time plot to track the lost orders variable LO. �

202

Playing round #2a

203 of 502

2.7 Simulation game and optimization

KPI comparison, Rounds #1 vs. #2a.:�

203

Playing round #2a

204 of 502

2.7 Simulation game and optimization

�

204

Optimization Experiment – a module in AnyLogic that allows a simulation experiment to be repeatedly rerun while varying one or more input parameters to identify values of those parameters that “optimize” a performance criterion; requires caution as it “optimizes” only the sample mean of replications of the performance criterion, ignoring measures of central

tendency and ignoring statistical significance.

Decision variable – the input parameter in a simulation experiment that the AnyLogic Optimization Experiment will repeatedly change in search of optimizing some performance criterion; multiple simultaneous decision variables are possible.

Playing round #2b

205 of 502

2.7 Simulation game and optimization

In the projects area, right–click on the project’s name, then select New → Experiment → Optimization.

�

205

Give the experiment name Optimization.

Playing round #2b

206 of 502

2.7 Simulation game and optimization

�

206

Set top–level agent to Main.

Playing round #2b

207 of 502

2.7 Simulation game and optimization

207

Playing round #2b

208 of 502

2.7 Simulation game and optimization

Update Parameters:

mfgCost: Set to $11
CapM3: Set to 2 machines
MaxArrivalQuantity: In the Type column, click on the word fixed and change it to discrete. Set Min = 2, Max = 15, and Step = 1.
Model time: Check that it is set to Stop time 100 seconds.
Randomness: Select Random seed, which is needed for replications. �

208

Playing round #2b

209 of 502

2.7 Simulation game and optimization

Update Parameters:

Replications: Select Use replications → Fixed number of replications → Replications per iteration: 1000.
Advanced: Deselect Allow parallel evaluations. �

209

Playing round #2b

210 of 502

2.7 Simulation game and optimization

Return to the top of properties and click Create default UI, and AnyLogic populates the canvas with a user interface (UI) and inserts Java code.�

210

Playing round #2b

211 of 502

2.7 Simulation game and optimization

Drag a Data Set object from the Analysis palette and drop it on the Optimization canvas.

�

211

Playing round #2b

212 of 502

2.7 Simulation game and optimization

Running the optimization experiment

Select Model → Run → Optimization

212

User interface upon experiment completion.

Playing round #2b

213 of 502

2.7 Simulation game and optimization

Initial results in default interface

213

The UI confirms that the simulation completed 14 iterations and 1000 replications of each iteration, for a total of 14 000 samples.

Playing round #2b

214 of 502

2.7 Simulation game and optimization

Initial results in default interface

214

The “best” expected profit found was $1714 using MaxArrivalQuantity = 2 (this is the sample mean profit across the 1000 replications of MaxArrivalQuantity = 2).

Playing round #2b

215 of 502

2.7 Simulation game and optimization

Initial results in default interface

215

The blue line in the chart indicates that the second iteration (specifically, iteration ”1” where the 14 iterations are indexed 0, ..., 13 on the horizontal axis) yielded the “best” profit of $1714, and subsequent iterations yielded inferior profits.

Playing round #2b

216 of 502

2.7 Simulation game and optimization

Initial results in default interface

216

This is unconstrained optimization, thus there are no infeasible solutions shown (no red line in the chart).

Playing round #2b

217 of 502

2.7 Simulation game and optimization

Analysis of sample statistics collection

Open the opt_experiment_stats.xlsx workbook in MS–Excel.
Add column headers and then insert a pivot table.

217

Playing round #2b

218 of 502

2.7 Simulation game and optimization

Analysis of sample statistics collection

Figure indicates that with 1000 replications per parameter, the sample means of 100– day profits descrease monotonically in MaxArrivalQuantity, and that MaxArrivalQuantity = 2 achieves the global maximum expected 100–day profit.
The “best” profit (at MaxArrivalQuantity = 2 orders) is statistically significantly better than the profits sampled at 3 or more orders. (Cells D2:H3)
With this process capacity, the maximum expected profit is somewhat sensitive to the MaxArrivalQuantity decision. For example, increasing MaxArrivalQuantity by only 1 order (to 3) theoretically reduces expected 100–day profits by 8%. (Cells E2:E3)

218

Playing round #2b

219 of 502

2.7 Simulation game and optimization

Another optimization experiment

We wish to know what new demand management policy optimizes a process with double the original capacity, that is the optimal level of MaxArrivalQuantity that maximizes 100–day profits with the revised parameters:

2 machines at M1, M2, M4
4 machines at M3
mfgCosts of $10+(4×$1)+(2×$2)=$18 per order �

219

Playing round #2b

220 of 502

2.7 Simulation game and optimization

Another optimization experiment

Update parameters for another optimization experiment:�

220

Playing round #2b

221 of 502

2.7 Simulation game and optimization

Another optimization experiment

Rerun the optimization experiment.
Create pivot table:�

221

Playing round #2b

222 of 502

2.7 Simulation game and optimization

Another optimization experiment

Compare simulated performance: �

222

Playing round #2b

223 of 502

2.7 Simulation game and optimization

Another optimization experiment

Decision–makers can conclude:

Doubling the process capacity — along with increasing the MaxArrivalQuantity to 6 orders (per 2 days) — increases the theoretical 100–day profit from $1714 to $2079 (21% improvement).
The mean profit of $2079 sampled at MaxArrivalQuantity = 6 is statistically significantly different than MaxArrivalQuantity = 5 or 7 (see Figure 8.14); thus we have shown that MaxArrivalQuantity = 6 is indeed the “best” for this capacity (we have confirmed the result given by the UI). �

223

Playing round #2b

224 of 502

2.7 Simulation game and optimization

Another optimization experiment

Decision–makers can conclude:

Sensitivity analysis: With double the process capacity, there is leeway to set MaxArrivalQuantity from 4 to 10 orders and not do worse than the best expected profits of the original system analyzed in §8.4.4.
Sensitivity analysis (again): With double the process capacity, there is leeway to set MaxArrivalQuantity from 5 to 8 orders and not attenuate profits by more than 8%.
Doubling process capacity requires outsourcing 2 of the 4 machines at M3. Management should double–check that all coordination and scheduling costs are properly accounted in the mfgCosts = $18 parameter.

224

Playing round #2b

225 of 502

2.7 Simulation game and optimization

Similarities with parameter variation experiments

A parameter variation experiment is similar to the foregoing optimization experiment described through–out §8.4, with three key the exceptions: there is no objective function, the Create default UI button (in experiment properties) does not generate the the Java actions to find optimal values, and variable parameters are incremented sequentially (when Allow parallel evaluations is deselected in advanced properties).

225

Playing round #2b

226 of 502

2.7 Simulation game and optimization

Multiobjective optimization–based simulation experiments

Run a single replication of the parameters using seed value 1 for a 100–second runtime.

�

226

Playing round #2c

227 of 502

2.7 Simulation game and optimization

Multiobjective optimization–based simulation experiments

Simulation results after employing optimization results, Round #2c

�

227

Playing round #2c

228 of 502

2.7 Simulation game and optimization

Multiobjective optimization–based simulation experiments

Managers’ KPI after various simulation optimization experiments:

�

228

Playing round #2c

229 of 502

2.7 Simulation game and optimization

Sample parameters for rounds #3 to #10.�

229

Playing round #3 to # 10

230 of 502

2.7 Simulation game and optimization

After receiving the input data from the instructor, students are given 5–10 minutes to make decisions about controllable parameters. During that time they may also use optimization experiments but not the simulation.
Having setup the parameters, all teams start the simulation experiment; they may pause the experiment as often as they want but total time for all groups needs to be limited, say for 5–10 minutes for one round. �

230

Playing round #3 to # 10

231 of 502

2.7 Simulation game and optimization

Evaluation:

One possible evaluation method is to evaluate each round independently and assign in each round some scores to each team, e.g., team or respective manager with the best result gets 10 points, and the team with the worst gets 1 point.
Another evaluation method is to combine the results from all the rounds and then compute average values for each KPI to determine the winner. �

231

Playing round #3 to # 10

232 of 502

2.8

Further Extensions

232

233 of 502

Learning objectives

The purpose of this brief chapter is for the reader to consider viable extensions to the AnyLogic simulation models developed thus far. We also propose some questions to faciliate the discussion. The range of business process simulation models is endless!

233

234 of 502

2.8 Further extensions

The business case study that was introduced in Chapter 3 can be extended from its original linear system to networked supply chains, assembly lines, multiple parallel machines, and so forth.

Possible extensions:

Two products competing for process capacity with different priorities
Queues of limited (finite) capacities.
Due dates for orders (or lead time limits)
Parallel machines and multiple resources for each machine

234

235 of 502

2.8 Further extensions

Possible extensions:

Flexible workers who move about a process to deliver surge capacity dynamically as needed
Worker schedules with a calendar
Seasonal demand arrival patterns and schedules
Intermediate storage via internal or external warehouses
Incoming flow linked with demand forecasts (as a result of a multi–agent simulation)
Monetary penalties for excessive lead–time and/or waiting
Inventory of raw and final products

235

236 of 502

2.8 Further extensions

Possible extensions:

Different outsourcing options
Monte–Carlo simulation, comparing runs, and sensitivity experiments (available with Professional License only)
Material availability–check prior to customer order confirmation
Order batching
A networked supply chain with flow synchronisation among different companies (e.g., a JIT system)
Bottlenecks (and additional constraints) by incorporating supply and distribution parts in an integrated supply chain

236

237 of 502

2.8 Further extensions

Discussion question:

What roles play the blocks “Wait,” “Delay,” “Resource,” “Seize,” “Release,” and “Service” in Process Modeling Library? How other blocks in the Process Modeling Library can be used? Think of other possible applications of these blocks in manufacturing or logistics planning and control setting!
Explain basic trade–offs between capacity utilization, lead–time, and the number of waiting orders!
Explain basic trade–offs in coordinated decision making to balance the objectives of the division head, the sales manager, and the manufacturing manager in order to achieve maximal possible profit under given constraints.

237

238 of 502

2.8 Further extensions

Discussion question:

What KPIs are important for a control dashboard of a workload balancer?
Discuss on the difference between push and pull dispatching principles!
What are the process bottlenecks?
What is the objective of workload balancing?
What KPI are typically used for financial, customer and operational performance measurement? How to compute them in AnyLogic?
How we can proliferate the generic model to a larger scale model for practical problem solving? (i.e., limitation of PLE, scale up approach?)

238

239 of 502

Chapter 3

Advanced Process Modeling

and Optimization

239

240 of 502

Learning objectives

Develop analytical and management skills in capacity demand planning (§ § 3.1–3.2)
Develop soft skills in coordinating team-based decision-making(§ § 3.3)
Extend one’s technical skills in discrete-event process simulation (§ § 3.2)
additional practice with AnyLogic’s Optimization Experiment and Parameters (§ § 3.3)
Build more sophisticated KPI dashboards and using Anylogic multimethod simulation software for analysing performance (§ § 3.2.3)

240

241 of 502

Learning objectives

Describe a brief case study of a manufacturing flow line that will be the basis for the simulation model development throughout the remainder of Part I of this book (§3.1)
Define the arrival process, service process, and overall job routing flow
Define key process performance indicators used to evaluate the process (§3.2)

241

242 of 502

3.1

Problem Statement: Capacity Flexibility

242

243 of 502

Learning objectives

Understand a case study about a manufacturing capacity planning decision where a flexible workforce of skilled laborers can work on complex and simple jobs, each with different capacity and financial consequences
Learn the basis for all advanced modeling developed, including such features as multiple types of flow units (“custom agents”), resource pools, and priority queues

243

244 of 502

3.1 Problem statement: capacity flexibility

An operational challenge at an electronic device manufacturing company specializing in both rapid prototyping (engineer–to–order, or ETO) and serial manufacturing (make–to–order, or MTO)
The focus is on tactical–level capacity management, namely, determining a cost–efficient in–house workforce production capacity.
A simulation model is used to reveal the impact of workforce and capacity flexibility on operational performance

244

245 of 502

3.1 Problem statement: capacity flexibility

A single–stage manufacturing system:

245

246 of 502

3.1 Problem statement: capacity flexibility

The main difference between serial manufacturing and rapid prototyping (RPT) is that the workers at the RPT work station have a higher level of qualification (and higher labor costs) that allows them to produce both prototypes and serial products.

If there is no RPT demand, the workers at the RPT station can produce serial products which have significantly lower processing times and process–time variability.

246

247 of 502

3.1 Problem statement: capacity flexibility

If the lead time of an RPT order does not exceed 2 weeks, then the full revenue is earned; otherwise revenue is 20% less.
Hourly wages for RPT workers exceed the hourly wages paid to serial manufacturing workers.
RPT orders arrive at uncertain times. The processing times for RPT orders are also uncertain, following a triangular distribution (details below).
The time for an RPT worker to process a serial order is 5 hours with essentially no time variability from worker to worker and from order to order.
If an incoming order is delayed because of insufficient assembly capacity, and if the waiting time exceeds 3 weeks, the customer withdraws the order.

247

248 of 502

3.1 Problem statement: capacity flexibility

The duration of a planning period is 13 weeks (i.e., one quarter).
A standard work week has 40 hours, the planning horizon is hence 520 hours.
The simulation model time unit is seconds, and each second of simulation model time represents an hour of real time. the simulation time is 520 seconds.

248

249 of 502

3.2

Model Building

249

250 of 502

Learning objectives

Modeling service with service blocks and resource pools (§11.1)
Modeling multiple flow units using “custom agents” (§11.2).
Modeling a priority queueing discipline for multiple flow units (§11.2).
Advanced KPI dashboard design techniques, including dynamic queue status bars (§11.3).
Coding techniques for more advanced model data collection (§11.3).

250

251 of 502

Learning objectives

Steps of Model building:

Creating the process flow
Creating a custom agent
Updating the properties of process flow
Collecting data for performance measurement

251

252 of 502

Learning objectives

A note on complexity reduction. In the problem statement we assumed that “demand for serial products is sufficiently steady that any unused rapid prototype capacity can process serial orders.” And so to simplify our analysis for clarity in this manuscript, we shall decouple to joint RPT worker and serial worker capacity decisions, focusing only on RPT workers. A more complete model may consider both simultaneously.

252

253 of 502

3.2 Model building

Process model

253

254 of 502

3.2 Model building

254

RPT workstation is modeled using two sub–processes: one for RPT orders and another for serial orders, connected by a resource pool (rptWorkers) which serves them.

Process model

255 of 502

3.2 Model building

255

The RPT sub–process includes a source node (RPT demand) to generate RPT orders, a service block (RPT service) denoting the part of the RPT workstation processing RPT orders, and two sink nodes for completed orders (sink) and for lost RPT orders (sink1).

Process model

256 of 502

3.2 Model building

256

The serial sub–process includes another source node (serial demand), a service block for the other part of the RPT workstation processing serial orders (serial service), and two additional sink nodes for completed serial orders (sink2) and for lost orders (sink3).

Process model

257 of 502

3.2 Model building

Define parameters used in the model of capacity flexibility problem:

257

Process model

258 of 502

3.2 Model building

Define parameters used in the model of capacity flexibility problem:

258

Process model

259 of 502

3.2 Model building

Define parameters used in the model of capacity flexibility problem:

259

Process model

260 of 502

3.2 Model building

Custom agents have several modeling benefits:

They allow us to give more descriptive names to the flow units in simulation models.
They make it possible to model multiple distinct type of flow units (each with distinct properties such as demand arrival patterns, processing times, routing routing, resource needs, cost, revenue, and so on).
They facilitate advanced modeling techniques using assembler or combine blocks.
They offer an alternative to measuring throughput times with timeMeasureStart and timeMeasureEnd blocks.

260

Customer agent – a method of method of modeling a unique flow unit with a customizable name; allows multiple types of flow units in AnyLogic models.

Custom agents and process settings

261 of 502

3.2 Model building

Create a custom agent:

261

Name this agent RPT_order.

Custom agents and process settings

262 of 502

3.2 Model building

262

Define a variable timestampt1 to measure the start of a lead time.

Custom agents and process settings

263 of 502

3.2 Model building

263

Define a variable timestampt2 to measure the start of a flow time.

Custom agents and process settings

264 of 502

3.2 Model building

Adjust RPT demand source properties for the arrival of RPT orders with a time stamp:

264

Set New agent to RPT_order.

In Actions → On exit, enter the code agent.timestampt1 = time(); to record the arrival

time of each RPT order.

Custom agents and process settings

265 of 502

3.2 Model building

Define properties of serial_demand:

265

Set Agents per arrival as nAgents.

Custom agents and process settings

266 of 502

3.2 Model building

Define properties of services:

266

Define the Resource pool.

Define the Delay time.

Define the Timeout exit time (120 seconds).

Custom agents and process settings

267 of 502

3.2 Model building

Define properties of services:

267

To prioritize RPT orders over serial orders, one may open the properties of the service blocks and set the priority in Priorities/preemption → Task priority.

Custom agents and process settings

268 of 502

3.2 Model building

Define properties of services:

268

In this model, Task priority for RPT service and serial service are 1 and 0 respectively.

Custom agents and process settings

269 of 502

3.2 Model building

Define the RPTworkers resource pool:

269

The resource capacity (i.e., the number of RPT workers) is defined in the properties of resource pool RPTworkers using parameter nAgents.

Custom agents and process settings

270 of 502

3.2 Model building

In this part, diagrams to analyze the following KPIs will be created:

Revenue, costs, profit
Percentage of time that RPT workers spend on RPT orders
Percentage of time that RPT workers spend on serial orders
Lead and flow times
Number of RPT orders delivered on–time, delayed, or lost

270

Statistics collection and KPI dashboard design

271 of 502

3.2 Model building

KPI dashboard:

271

Statistics collection and KPI dashboard design

272 of 502

3.2 Model building

Lead time and flow time

Collect lead time statistics in the sink node:

272

Lead time is a duration from the moment an RPT_Order exits the RPT_demand source until it departs the RPT_service block.

Statistics collection and KPI dashboard design

273 of 502

3.2 Model building

Lead time and flow time

Collect lead time statistics in the sink node:

273

An RPT order’s end timestamp is collected at the sink (“sink”) with the following code:

//measure lead time double LeadTime = time() – agent.timestampt1;

//add the new observation to the lead time histogram dataset LeadTime_hist.add(LeadTime);

Statistics collection and KPI dashboard design

274 of 502

3.2 Model building

Lead time and flow time

We measure flow time in the RPT_service block’s Actions property via the following code:

On enter delay:

agent.timestampt2 = time();

On exit:

//measure flow time

double FlowTime = time() – agent.timestampt2;

//add the new observation to the flow time histogram dataset

FlowTime_hist.add(FlowTime);

274

Statistics collection and KPI dashboard design

275 of 502

3.2 Model building

Revenue, cost, profit

Define the rules for revenue statistics collection in the sink’s properties with the following code:

//calculate number of on–time– and late– RPT orders and revenue

if (LeadTime <= 80) {

nOnTime ++;

R += RPT Revenue;}

else {

nLate ++;�R += 0.8*RPT Revenue;}

275

Statistics collection and KPI dashboard design

276 of 502

3.2 Model building

Revenue, cost, profit

Capture the serial product revenue by incrementing the revenue R upon an agent entering sink2:

R += serial Revenue;

276

Statistics collection and KPI dashboard design

277 of 502

3.2 Model building

Revenue, cost, profit

Set properties of the Track_order_and_cost� event:

277

Statistics collection and KPI dashboard design

278 of 502

3.2 Model building

Revenue, cost, profit

The resource utilization and record the time series of RPT demand and completed RPT orders in the Track_order_and_cost event are measured using the following syntax:

//calculate manufacturing cost using RPT worker

mfgCosts += nAgents*RPT_HourlyRate;

//calculate the average util. of RPT workers for RPT

RPTworkerUtil = zidz(RPT_service.utilization(), nAgents);

//calculate the average util. of RPT workers for serial

SerialworkerUtil = RPTworkers.utilization() – RPTworkerUtil;

278

Statistics collection and KPI dashboard design

279 of 502

3.2 Model building

Revenue, cost, profit

The resource utilization and record the time series of RPT demand and completed RPT orders in the Track_order_and_cost event are measured using the following syntax:

//track number of incoming RPT orders

dt_RPT_demand.add(RPT_demand.count() – cumRPTdemand_t_minus_1);

cumRPTdemand_t_minus_1 = RPT_demand.count();

//track number of incoming RPT orders

dt_RPT_completed.add(sink.count() – cumRPTcompleted_t_minus_1); cumRPTcompleted_t_minus_1 = sink.count();

279

Statistics collection and KPI dashboard design

280 of 502

3.2 Model building

Revenue, cost, profit

Lost sales are calculated by the following code at sink1:

LostOrder++;

O += RPT OpportunityCost;

280

Statistics collection and KPI dashboard design

281 of 502

3.2 Model building

KPI dashboard

Creating a queue status bar using conditional formatting:

281

The conditional formatting syntax that makes the dark–blue rectangle visible whenever the queue has 10 or more.

Statistics collection and KPI dashboard design

282 of 502

3.2 Model building

KPI dashboard

Define a time plot for RPT demand.

282

Statistics collection and KPI dashboard design

283 of 502

3.2 Model building

KPI dashboard

Define a time plot for station and worker utilization.

283

Statistics collection and KPI dashboard design

284 of 502

3.2 Model building

KPI dashboard

Define a time plot to monitor timeliness of RPT orders.

284

Statistics collection and KPI dashboard design

285 of 502

3.2 Model building

KPI dashboard

Define a stack chart to track RPT order status.

285

Statistics collection and KPI dashboard design

286 of 502

3.2 Model building

KPI dashboard

Update the flow time histogram.

286

Statistics collection and KPI dashboard design

287 of 502

3.2 Model building

KPI dashboard

In the KPI dashboard, update the variables as follows:

Profit per Worker uses the dynamic text "$" + roundToInt(Profit()/nAgents)
Mean Worker Util. (RPT) uses the text roundToInt(RPTworkerUtil * 100) + "%"
Mean Worker Util. (Serial) uses the text roundToInt(serialworkerUtil * 100) + "%"

287

Statistics collection and KPI dashboard design

288 of 502

3.3

Simulation Game

288

289 of 502

Learning objectives

Play up to 10 game rounds to learn how input parameters affect conflicting objectives—and to struggle with finding the best input parameters for all stakeholders (§§12.1–12.3, 12.6);
Get additional practice using optimization experiments to find “best” input parameters in the face of complexity and risk (§§12.4–12.5);
Learn how to use parameter variation experiments to optimize input parameters repeatedly over multiple scenarios and thus start generalizing simulation experimental results (§12.7);
Revisit the classic “efficiency vs. flexibility” trade–off, and visualize through simulation results (§12.7).

289

290 of 502

3.3 Simulation game

Setup:

Each experiment runs 520 seconds to simulate 520 real working hours (roughly a quarter of the year, or 13 weeks of 40 work–hours).
The queueing discipline is FIFO.
All queue capacities are set at “maximum.”
The push production principle is used.

290

Game rules and roles

291 of 502

3.3 Simulation game

Roles for the game:

A division head who strives to maximize total division profit and unit profits for the RPT and serial orders.
A sales manager who wishes to maximize revenue by accepting as many customer orders as possible and by completing orders as quickly as possible.
A manufacturing manager who seeks low unit costs and high RPT capacity utilization.
A workload balancer who wishes to maintain a high service level for RPT orders.

291

Game rules and roles

292 of 502

3.3 Simulation game

Metrics used to establish the best–player role, each game round:

292

Game rules and roles

293 of 502

3.3 Simulation game

Input data round #1:

293

Playing round #1

294 of 502

3.3 Simulation game

Sample results #1 (seed value: 1):

294

Playing round #1

295 of 502

3.3 Simulation game

KPI results #1 (seed value: 1):

295

Playing round #1

296 of 502

3.3 Simulation game

The round #1 simulation results suggest to the division head that the number of incoming orders should be increased.
New minimum and maximum arrival quantities are set at 5 and 7 orders, respectively, yielding simulation round #2a.

296

Rounds #2a and #2b

297 of 502

3.3 Simulation game

Sample results from Round #2a (seed value: 1):

297

Rounds #2a and #2b

298 of 502

3.3 Simulation game

Upon reflection of round #2a, the sales manager indicates that the demand for RPT orders is even higher, in the range [7–10] orders per week.
Setting these new parameter for round #2b.

298

Rounds #2a and #2b

299 of 502

3.3 Simulation game

Sample results from Round #2b (seed value: 1):

299

Rounds #2a and #2b

300 of 502

3.3 Simulation game

Managers now seek the optimal number of RPT workers to staff in the workstation to face the demand levels modeled in round #2b.

In File → New → Experiment, select Optimization and create a new optimization experiment using the round #2b data.

300

An optimization experiment

301 of 502

3.3 Simulation game

Set properties of the optimization experiment using Round #2b data:

301

An optimization experiment

302 of 502

3.3 Simulation game

302

The user interface of the optimization experiment.

An optimization experiment

303 of 502

3.3 Simulation game

Set properties of the newly added chart:

303

An optimization experiment

304 of 502

3.3 Simulation game

Inspect Java code in the properties of the optimization experiment.

304

An optimization experiment

305 of 502

3.3 Simulation game

Update the property Randomness from Fixed seed to Random seed and enable Use replications.
Results of an optimization experiment: 5 RPT workers may yield the greatest profit, an expected value of $667 520.

305

An optimization experiment

306 of 502

3.3 Simulation game

Perform the simulation experiment on the basis of a new capacity of 5 RPT workers.
Sample results from Round #2c (seed value: 1):

306

Round #2c

307 of 502

3.3 Simulation game

KPI comparison across 7 simulation rounds:

307

Round #2c

308 of 502

3.3 Simulation game

The teams compete on total profitability.
The managers compete based on individual KPIs.
Each round, the instructor provides the input data and students have 5–10 minutes to set up the parameters. They may also use optimization experiments but not the simulation.
Having setup the parameters, the teams start each round’s simulation experiment.
Total time is limited, 10–15 minutes.
One way is to evaluate each round independently, assigning scores to the team with the best KPIs. Another evaluation method is to combine results from all rounds and then compute average KPI values to determine the winner.

308

Rounds #3 to #10, evaluation

309 of 502

3.3 Simulation game

Input data to facilitate the game:

309

Rounds #3 to #10, evaluation

310 of 502

3.3 Simulation game

In this section, three parameter variation experiments corresponding to the three demand scenarios with weekly RPT demand in the ranges [3,5], [5,7], and [7,10] will be built.
There are two steps to enable the experiment: set up the interface to visualize KPIs, and configure the properties with Java code.

310

Generalizing managerial insights

311 of 502

3.3 Simulation game

Configure the canvas for a parameter variation experiment with RPT demand [3,5]:

311

Generalizing managerial insights

312 of 502

3.3 Simulation game

To collect unit profits after every simulation replication, insert the ht_RPTunitProfit histogram data object:

312

In the experiment properties add the Java code to force data collection After simulation run: ht_RPTunitProfit.add(root.UnitProfit());

Generalizing managerial insights

313 of 502

3.3 Simulation game

To compute the average unit profit for all replications of one iteration, insert the dt_nAgent_RPTunitProfit data set:

313

In the experiment properties include the Java code to be executed After iteration:

dt_nAgent_RPTunitProfit.add(nAgents, ht_RPTunitProfit.mean());

ht_RPTunitProfit.reset();

Generalizing managerial insights

314 of 502

3.3 Simulation game

The RPT unit profit plot therefore refers to the dt_nAgent_RPTunitProfit data set:

314

Generalizing managerial insights

315 of 502

3.3 Simulation game

Each iteration in this experiment corresponds to the number of RPT workers; configure this in Parameters. Enable the Random seed (in Randomness) and Use replications with 100 replications per iteration (in Replications).

315

Generalizing managerial insights

316 of 502

3.3 Simulation game

Inspect Java code in the properties of the parameter variation experiment:

316

Generalizing managerial insights

317 of 502

3.3 Simulation game

Run the parameter variation experiment for the weekly RPT demand scenario [3,5]:

317

Generalizing managerial insights

318 of 502

3.3 Simulation game

Reproduce this experiment for the demand range [5,7] either by replicating the previous set–up, or by simply changing the demand parameters in the properties of the experiment:

318

Generalizing managerial insights

319 of 502

3.3 Simulation game

Reproduce this experiment for the demand range [7,10]:

319

Generalizing managerial insights

320 of 502

3.3 Simulation game

Maximum profits are achieved with 3 workers for low demand, 4 workers for medium demand, and 5 workers for high demand.
The trade–offs in flexibility and efficiency due to the number of RPT workers can be observed.

320

Generalizing managerial insights

321 of 502

3.3 Simulation game

Maximum profits are achieved with 3 workers for low demand, 4 workers for medium demand, and 5 workers for high demand.
The trade–offs in flexibility and efficiency due to the number of RPT workers can be observed.

321

Generalizing managerial insights

322 of 502

Chapter 4

Supply Chain Coordination

322

323 of 502

Learning objectives

Build simulation models of multi-echelon supply chain(§ 4.2)
Understand impact of operational levers on customer responsiveness, costs, and SC volatility (§ 4.1.3)
Explore root causes and prevention of the bullwhip effect (§ 4.3.5)
Build technical skills in modeling supply chain networks and analyzing performance with AnyLogic simulation software. (§ 4.3)
Apply advanced techniques like scheduling, batch processing, inventory control, demand forecasting, and multi-unit assembly. (§ 4.3.1- 4.3.4)
Run optimization experiments to explore trade-offs in supply chain coordination objectives. (§ 4.3.3)
Develop analytical and management skills in supply chain coordination (§ 4.3)

323

324 of 502

Learning objectives

Convert the description of the flow line into a AnyLogic process model (§4.1)
Employ AnyLogic’s intuitive way of creating a simulation models, starting by laying process modeling “blocks” on a “canvas” to sketch a process flow diagram
Update the properties of each block on the diagram to define the arrival process, service process, queueing discipline, and departure process (§4.1)
Create basic process computer animation (§4.2)
Set experiment parameters and build a KPI dashboard for simulation statistics analysis (§4.3)

324

325 of 502

4.1

Problem Statement: 2–Supplier Coordination

325

326 of 502

Learning objectives

Learn about an automobile manufacturing supply chain which serves as the basis for supply chain coordination simulation modeling.

326

327 of 502

4.1 Problem statement: 2–supplier coord.

The bullwhip effect (BWE) is a well–known phenomenon where uncertainty propagates with increasing fluctuations up the supply chain.

There are four underlying causes of the BWE:

Demand signal processing
Order batching
Price fluctuations
Rationing/shortage gaming

327

Introduction

328 of 502

4.1 Problem statement: 2–supplier coord.

Supply chain network:

An assembly plant
Two suppliers
The transportation of finished goods to customers (retail automobile dealerships)

328

Supply chain description

329 of 502

4.1 Problem statement: 2–supplier coord.

Linear manufacturing process using two work stations:

The assembly line processes cars in batches of 10.
Machine 1 (“M1”) attaches a component (“material 1”) to each car with mean processing time 1 day per batch and process time variability 30%.
Machine 2 (“M2”) attaches a component (“material 2”) to a car with mean processing time 1 day per batch and process time variability 30%.
Supplier 1 delivers material 1, Supplier 2 delivers material 2.
M1 and M2 can each process up to 5 batches simultaneously in parallel.
After M2, the cars go to a finished–goods inventory—a parking station—to prepare for shipment.

329

Supply chain description

330 of 502

4.1 Problem statement: 2–supplier coord.

An automobile assembly supply chain:

330

Supply chain description

331 of 502

4.1 Problem statement: 2–supplier coord.

Customer orders:

Arrive with some degree of uncertainty.
On average, orders for 25 new cars arrive daily, with standard deviation 10 cars per day.
All cars are identical.
Excess demand or material shortages cause lead–time delays.
If a customer order waits more than 14 days, then the customer withdraws it at a lost–order cost of $400/car to the manufacturer.

331

Supply chain description

332 of 502

4.1 Problem statement: 2–supplier coord.

The supply chain manager control the frequency of material inventory review (i.e., the planning cycle) considering the workload of the supply chain planner and other KPIs.

332

Order–up–to policy – an inventory management policy whereby the inventory level is periodically reviewed so that it may be replenished up to a preset amount called an “order–up–to level”; the order quantity is usually the difference between the order–up–to level and the present inventory position.

In any planning cycle (e.g., daily, weekly, ...), the supply chain planner must manage order quantities to suppliers.

Levers of SC coordination

333 of 502

4.1 Problem statement: 2–supplier coord.

Suppliers 1 and 2 have delivery lead times of 3 and 5 days respectively.
The material inventory holding cost is $10 per unit of material per day, and the ordering cost is $9000 per order.
One finished car requires 1 piece of material 1 and 1 piece of material 2.
To replenish material, the manufacturer employs the order–up–to policy based on simple exponential smoothing forecasts.

333

Levers of SC coordination

334 of 502

4.1 Problem statement: 2–supplier coord.

Causal loop diagram for the order–up–to policy based on simple exponential smoothing forecasts (Dejonckheere et al., 2003):

334

Levers of SC coordination

335 of 502

4.1 Problem statement: 2–supplier coord.

335

Levers of SC coordination

336 of 502

4.1 Problem statement: 2–supplier coord.

Their material management process can be broken down into four steps conducted each periodic review cycle:

Calculate the net inventory position factoring any backlog and any quantity in transit.
Calculate the order quantities and place orders to suppliers. If the inventory position is less than up–to–level S, the supply chain planner will place the order.

336

Levers of SC coordination

337 of 502

4.1 Problem statement: 2–supplier coord.

The management objective is to match capacity with demand so as to balance incoming customer orders, deliveries from suppliers, and shipments to customers at minimal cost while maintaining a reasonable 95% fill rate.

The total duration of management’s planning period is 365 days in real life, simulated in 365 seconds of model time.

337

Fill rate – the proportion of unit demand that can be satisfied immediately from on–hand inventory; a metric of inventory management performance.

Levers of SC coordination

338 of 502

4.2

Model Building

338

339 of 502

Learning objectives

To understand how to model supply chain coordination using simulation software (§§14.1–14.3).
To learn how to mitigate the bullwhip effect in supply chains through tighter coordination informed by simulating modeling (§§14.2–14.3).
To develop advanced AnyLogic simulation modeling skills (§14.1).
To use advanced AnyLogic functions and events to automate supply chain processes, such as forecast updating and inventory replenishment (§14.2).

339

340 of 502

4.2 Model building

An automobile assembly supply chain process model:

340

Creating the process model

341 of 502

4.2 Model building

Batch and unbatch blocks are introduced to model the batch production process.
Hold block is used to align production with material from suppliers.
Three source blocks are used to generate distinct flow units: the main car body, material 1 from supplier 1, and material 2 from suppler 2.

341

Creating the process model

342 of 502

4.2 Model building

Properties of source source block:

342

Creating the process model

343 of 502

4.2 Model building

Properties of M1_supplier source block:

343

Creating the process model

344 of 502

4.2 Model building

Properties of M2_supplier source block:

344

Creating the process model

345 of 502

4.2 Model building

A Hold block “can block the agent flow along a particular connection.”

The first Hold block (hold for M1) checks the net stock of material 1 before processing a batch of the main agent, “Car.” When sufficient inventory of material 1 is on hand, canMove is true, and the agent (a batch of cars) is released to delay block M1.

345

Creating the process model

Hold blocks

346 of 502

4.2 Model building

Properties of hold_for_M1 hold block:

346

Creating the process model

Hold blocks

347 of 502

4.2 Model building

Properties of canMove variable block:

347

Creating the process model

Hold blocks

348 of 502

4.2 Model building

Define properties of queue block:

348

Creating the process model

Hold blocks

349 of 502

4.2 Model building

Repeat with similar properties to hold the main agent at M2 for material 2 (the second hold block hold_for_M2, variable canMove2, and queue block queue2).
Material must be consumed when the main agent arrives at machines, it can be done with the delay block settings for M1 and M2.

349

Creating the process model

Hold blocks

350 of 502

4.2 Model building

Material must be consumed when the main agent arrives at machines, it can be done with the delay block settings for M1 and M2.

350

Creating the process model

Hold blocks

351 of 502

4.2 Model building

Material must be consumed when the main agent arrives at machines, it can be done with the delay block settings for M1 and M2.

351

Creating the process model

Hold blocks

352 of 502

4.2 Model building

A Batch block is used to accumulate a number of units before forwarding them to the next process block. Before shipping to customers one have to unbatch the production lot.

Define properties of Batch block:

352

Creating the process model

Batch and unbatch blocks

353 of 502

4.2 Model building

Define properties of Unbatch block:

353

Creating the process model

Batch and unbatch blocks

354 of 502

4.2 Model building

Define properties of Sink node:

354

Creating the process model

Batch and unbatch blocks

355 of 502

4.2 Model building

Outstanding orders must be received before subsequent orders may be placed.

This is modeled through three blocks: a M1_supplier source node, a M1_Order_in_Transit delay block, and a sink called sink2.
When there is new order, the function inject() will “inject” the order quantity at the source node, generating the arrival of a custom agent called Material1.
Once the Material1 agent moves to sink2, it increases the net stock of material available to production.

355

Creating the process model

Material flow

356 of 502

4.2 Model building

Define properties for supply lead time:

356

Creating the process model

Material flow

357 of 502

4.2 Model building

Define properties for material arrivals:

357

The material flow from supplier 2 is modeled the same way.

Creating the process model

Material flow

358 of 502

4.2 Model building

An AnyLogic function is a good way to describe a repeated task. Functions are employed to calculate KPI, model a forecasting demand and calculate the order–up–to level S.

Define properties of demand forecast:

358

Modeling the work flow

359 of 502

4.2 Model building

Define properties of order–up–to level, S:

359

Modeling the work flow

360 of 502

4.2 Model building

Define properties of ordering cost:

360

Modeling the work flow

361 of 502

4.2 Model building

Define properties of unit cost:

361

Modeling the work flow

362 of 502

4.2 Model building

The supply chain planner’s work flow is modeled with an event work flow. The event occurs at the beginning of day 1 and recurs daily.

362

Modeling the work flow

363 of 502

4.2 Model building

To generalize the code to accommodate different review frequencies, use parameter t_period with default value 7.
Event work_flow employs the following code in its properties:

// step 0: demand generation

Demand = roundToInt(max(normal(stddevDemand, meanDemand),0));

source.inject(Demand);

D_t_period += Demand; //total demand in t_period

363

Modeling the work flow

364 of 502

4.2 Model building

Event work_flow employs the following code in its properties:

// trigger actions at every t period

if ((time % t_period) == 0) {

// step 1.1: forecast FG demand by simple exponential smoothing

FG_D_t_plus_1_hat = demand_forecast(D_t_period, FG_D_t_hat);

FG_D_t_hat = FG_D_t_plus_1_hat; // overwrite D_t_hat

D_t_period = 0; //reset D_t_period

364

Modeling the work flow

365 of 502

4.2 Model building

Event work_flow employs the following code in its properties:

// step 1.2: calculate forecasted demand of material in t+1

M1_D_plus_1_hat = FG_D_t_plus_1_hat * M1_consumptionRate;

M2_D_plus_1_hat = FG_D_t_plus_1_hat * M2_consumptionRate;

// step 2: calculate up–to–level S

M1_S = OUT_S(M1_D_plus_1_hat, M1_Tp);

M2_S = OUT_S(M2_D_plus_1_hat, M2_Tp);

365

Modeling the work flow

366 of 502

4.2 Model building

Event work_flow employs the following code in its properties:

// step 3: calculate Inventory Position (including Backlog)

M1_Inventory_position = M1_Netstock + M1_Order_in_Transit.size();

M2_Inventory_position = M2_Netstock + M2_Order_in_Transit.size();

366

Modeling the work flow

367 of 502

4.2 Model building

Event work_flow employs the following code in its properties:

// step 4: calculate order quantity and release orders to suppliers

// step 4.1: material 1�M1_Order_Quant = roundToInt(max(M1_S – M1_Inventory_position, 0));

M1_supplier.inject(M1_Order_Quant);

// step 4.2: material 2

M2_Order_Quant = roundToInt(max(M2_S – M2_Inventory_position,0));

M2_supplier.inject(M2_Order_Quant);

367

Modeling the work flow

368 of 502

4.2 Model building

Event work_flow employs the following code in its properties:

// step 5: measure bullwhip effect and other KPIs

if (time() > warm up duration) {

// step 5.1: measure bullwhip ratio

M1_stat_Order.add(M1_Order_Quant);

M2_stat_Order.add(M2_Order_Quant);

M1_BWR = M1_stat Order.variance()/stat_Demand.variance();

M2_BWR = M2_stat_Order.variance()/stat_Demand.variance();

Stat_Demand.add(Demand);

368

Modeling the work flow

369 of 502

4.2 Model building

Event work_flow employs the following code in its properties:

// step 5.2: measure ordering cost

ordering_cost(M1_Order_Quant);

ordering_cost(M2_Order_Quant);

}}

// step 5.3: measure holding cost

if (time() > warm up duration) {

HoldingCosts += (max(M1_Netstock, 0) + max(M2_Netstock,0)) * HoldingCost;}

369

Modeling the work flow

370 of 502

4.2 Model building

Event work_flow employs the following code in its properties:

// step 5.4: measure fill rate

FillRate = zidz(sink.count(), source.count());

// measure time

time ++

370

Modeling the work flow

371 of 502

4.2 Model building

The logic of the code:

Step 0 generates the daily demand for cars (Demand) and injects this demand into the source node. It also tracks cumulative demand (D_t_period) during the periodic review interval of duration t_period.
Steps 1.1 to 5.3 are invoked only if a periodic review is triggered at the end of t_period days. Step 1.1 generates a forecast of the total finished–goods demand during the demand for the next t_period days.
Step 1.2 translates the finished–goods forecast to a materials forecast.

371

Modeling the work flow

372 of 502

4.2 Model building

The logic of the code:

Step 2 computes the order–up–to level S for materials 1 and 2, based on demand forecasts.
Step 3 computes the total inventory of materials 1 and 2, factoring backlogs and inventory in transit.
Step 4 computes order quantities based on the difference between S and total inventory.

372

Modeling the work flow

373 of 502

4.2 Model building

The logic of the code:

Steps 5.1 and 5.2 are only invoked after the simulation clock time exceeds the warm up period. They record the metrics of that order: order quantities, bullwhip ratios, ordering costs, and stock levels.
Steps 5.3 and 5.4 track daily material holding costs and fill rates.

373

Modeling the work flow

374 of 502

4.2 Model building

KPI dashboard:

374

Designing the KPI dashboard

375 of 502

4.2 Model building

It is needed to calculate the variance of demand and the variance of orders to compute the BWR statistic; variance requires at least three observations. Therefore, several KPI time plots set the First update time to warm_up_period + t_period*3.

375

Designing the KPI dashboard

376 of 502

4.2 Model building

For collecting statistics, a method using the Update data automatically option is introduced. Instead of using the Java .add() function (e.g., M1_stat_NetStock.add(max(M1 Netstock),0)), one may configure the data and set the update frequency.

376

Designing the KPI dashboard

377 of 502

4.3

Experiments &

Managerial Insights

377

378 of 502

Learning objectives

To explore the advantages and disadvantages of a daily replenishment strategy through a simulation of supply chain dynamics (§15.2).
To conduct optimization experiments to understand optimal review frequencies (§§15.3).
To analyze the relationship between batch sizes and supply chain volatility (§).
To explore the conflicting effects of cost, fill rate, and supply chain volatility through optimization experiments on batch size (§).
To conduct further optimization experiments on replenishment policy batch sizes to investigate the implications to such supply chain metrics as volatility, cost, and fill rates (§).

378

379 of 502

4.3 Experiments & managerial insights

The following settings hold true for all experiments:

Each experiment runs 365 seconds representing 365 days of real life
The queuing rule is FIFO
Queue capacities are set at maximum
The push production principle is used

379

Experimental settings

380 of 502

4.3 Experiments & managerial insights

What is the right frequency to review inventory from suppliers?

Run the experiment with daily review to verify if the significant effort would pay off. Input data for Experiment 1:

380

Experiment 1: Daily review policy

381 of 502

4.3 Experiments & managerial insights

Sample results from Experiment 1 (seed value: 1):

381

Experiment 1: Daily review policy

382 of 502

4.3 Experiments & managerial insights

An optimization experiment: to minimize the total costs including holding costs, stock–out costs, and ordering costs.

382

Change t_period from fixed to discrete over the range from 1 to 15 using a step of 1, enable Random seed and Use replications. 30 instances per 365–day iteration are replicated.

Experiment 2: An optimization experiment

383 of 502

4.3 Experiments & managerial insights

Add Total cost graphics for an optimization experiment:

383

Experiment 2: An optimization experiment

384 of 502

4.3 Experiments & managerial insights

Add Fill rate graphics for an optimization experiment:

384

Experiment 2: An optimization experiment

385 of 502

4.3 Experiments & managerial insights

Add Fill rate graphics for an optimization experiment:

385

Experiment 2: An optimization experiment

386 of 502

4.3 Experiments & managerial insights

Total cost and fill rate as a function of the review period (means of 30 replication):

386

Experiment 2: An optimization experiment

387 of 502

4.3 Experiments & managerial insights

Rerun experiment, substituting 7 for the t_period parameter.
Sample results from Experiment 3 (seed value: 1):

387

Experiment 3: Weekly review policy

388 of 502

4.3 Experiments & managerial insights

Parameter variation experiment to explore the relationship between batch sizes and supply chain volatility.

Define properties of an parameter variation experiment:

388

Relationship between batch size and the BWE

389 of 502

4.3 Experiments & managerial insights

Input parameters:

389

Change t_period to 7 days.

Relationship between batch size and the BWE

390 of 502

4.3 Experiments & managerial insights

Input parameters:

390

Control batch_size changing it from Fixed to Range on the interval of [1,20] with the step of 1.

Relationship between batch size and the BWE

391 of 502

4.3 Experiments & managerial insights

Use following code in Java actions:

After simulation runs:

// collect data of each simulation

ht_M1_BWR.add(root.M1_BWR);

ht_M2_BWR.add(root.M2_BWR);

ht_costs.add(root.HoldingCosts + root.StockoutCosts + root.OrderingCosts);

ht_FillRate.add(root.FillRate);

391

Relationship between batch size and the BWE

392 of 502

4.3 Experiments & managerial insights

Use following code in Java actions:

After iteration:

//record summarised data of each iteration

dt_batchsize_M1_BWR.add(batch_size, ht_M1_BWR.mean());

dt_batchsize_M2_BWR.add(batch_size, ht_M2_BWR.mean());

dt_batchsize_costs.add(batch_size, ht_costs.mean());

dt_batchsize_FillRate.add(batch_size, ht_FillRate.mean());

392

Relationship between batch size and the BWE

393 of 502

4.3 Experiments & managerial insights

Use following code in Java actions:

//clean histogram datasets

ht_M_ BWR.reset();

ht_M2_BWR.reset();

ht_costs.reset();

ht_FillRate.reset();

393

Relationship between batch size and the BWE

394 of 502

4.3 Experiments & managerial insights

Relationship between batch size and the BWE (means of 30 replications):

394

Relationship between batch size and the BWE

395 of 502

Chapter 5

Inventory Control

395

396 of 502

Learning objectives

Strengthen analytical and management skills in inventory management (§ § 5.2-5.3)
Learn to simulate periodic- and continuous-review inventory control policies and extend flexible KPI dashboards (§ § 5.2.1-5.2.4)
Learn to build more complex models that consider stochastic demand, replenishment lead times, dynamic reorder points and planned shortages (§ § 5.2.5- 5.2.8)
Analyze the performance inventory policies in a dynamic context (§ 5.3)
Gain managerial insights into the trade-off between inventory policy efficiency and responsiveness (§ 5.3.4)
Acquire additional experience running and interpreting simulation experiments for managerial decision-making (§ 5.4)

396

397 of 502

5.1

Problem Statement:

Periodic– and Continuous–

Review Policies

397

398 of 502

5.1 Problem statement

398

Continuous review – an inventory management system in which computer tracking enables constant monitoring of inventory positions in real time.

Periodic review – an inventory management policy where the inventory positions are counted at fixed intervals (e.g., daily, weekly, monthly, and so forth) and inventory replenishment decisions are made.

Fixed order quantity system – an inventory management policy whereby inventory replenishment orders are a constant size; the size is usually optimized due to appropriate performance criteria.

399 of 502

5.1 Problem statement

Automotive parts retailer

Demand and inventory requirements of five products:

399

400 of 502

5.1 Problem statement

Automotive parts retailer

Four inventory control policies:

400

401 of 502

5.1 Problem statement

Automotive parts retailer

Inventory control policies used in Part IV (Ivanov et al., 2021):

401

402 of 502

5.2

Model Building

402

403 of 502

Learning objectives

To build an AnyLogic simulation model of the Basic EOQ model (§17.1).
To extend the simulation mode of the Basic EOQ to include stochastic demand (§17.2), the flexibility of continuous or periodic review (§17.2), and planned shortages (§17.6).
To apply inventory management theory to extend models to incorporate deterministic lead times (§17.3), stochastic lead times (§17.5), and dynamic target inventory levels (§17.8).
To build out a flexible KPI dashboard that will track operational and financial performance indicators unique to inventory management, including holding costs, ordering costs, and stockout costs (§17.4).
To employ advanced modeling techniques including action charts to combine multiple inventory control policies on the same canvas (§§17.7–17.8).

403

404 of 502

5.2 Model building

A simple model with one event

404

Deterministic EOQ model – a classical mathematical model that prescribes the optimal reorder quantity in inventory systems where inventory levels are continuously reviewed, and demand and replenishment lead times are constant; the model trades off the cost of ordering inventory vs. cost of holding inventory.

Order quantity – the number of inventory units that are requested for delivery from a supplier, usually after a delay called the replenishment lead time.

Replenishment lead time – the time delay from the moment that an order is placed to a material supplier until the moment that the shipment is received.

Deterministic EOQ model with zero lead times

405 of 502

5.2 Model building

A simple model with one event

Start by dragging the event Ordering onto a blank AnyLogic canvas.
Add to the canvas a parameter OrderQuantity, two variables called Demand and InventoryLevel, and a time plot of inventory levels.

405

Deterministic EOQ model with zero lead times

406 of 502

5.2 Model building

A simple model with one event

Time plot’s properties:

406

Deterministic EOQ model with zero lead times

407 of 502

5.2 Model building

A simple model with one event

Describe properties of event Ordering with EOQ model logic:

407

Where “- =” is the Java operator equivalent to InventoryLevel = InventoryLevel – Demand.

Deterministic EOQ model with zero lead times

408 of 502

5.2 Model building

A simple model with one event

Describe properties of event Ordering with EOQ model logic:

408

The reorder point is s = 0 with instantaneous replenishment, so describe this replenishment rule using the Java script:

if (InventoryLevel == 0){

InventoryLevel += OrderQuantity;

}

Deterministic EOQ model with zero lead times

409 of 502

5.2 Model building

A simple model with one event

Set Demand = 80 units per day and OrderQuantity = 400 units per order, run the experiment for 30 seconds (30 days) and observe the inventory dynamics:

409

Deterministic EOQ model with zero lead times

410 of 502

5.2 Model building

More accurate charting with two events

To make inventory charts more precise, one can divide the functionality of the Ordering event into two separate events:

Inventory reduction to reduce inventory levels at the arrival of customer demand.
Ordering to restock the inventory.

410

Deterministic EOQ model with zero lead times

411 of 502

5.2 Model building

More accurate charting with two events

Describe properties of event Inventory_reduction:

411

Deterministic EOQ model with zero lead times

412 of 502

5.2 Model building

More accurate charting with two events

Describe properties of event Ordering_new:

412

Deterministic EOQ model with zero lead times

413 of 502

5.2 Model building

More accurate charting with two events

Run the simulation:

413

Deterministic EOQ model with zero lead times

414 of 502

5.2 Model building

Daily demand and replenishment lead times are uncertain, each following normal distributions. To account for this uncertainty, define new parameters:

414

Adding stochastic demand and periodic review

415 of 502

5.2 Model building

Daily demand and replenishment lead times are uncertain, each following normal distributions.

415

To account for this uncertainty, define new parameters.

Adding stochastic demand and periodic review

416 of 502

5.2 Model building

In the event Inventory reduction properties:

416

Add the following actions:

Demand = round( max (normal(DevDemand,MeanDemand),0));

LeadTime = round( max (normal(DevLT,MeanLT),0));

Adding stochastic demand and periodic review

417 of 502

5.2 Model building

Simulate 30 seconds with MeanDemand = 80 and DevDemand = 18 units per day:

417

Adding stochastic demand and periodic review

418 of 502

5.2 Model building

Periodic review policy

Define Ordering event for periodic–review policy (t,q):

418

Adding stochastic demand and periodic review

419 of 502

5.2 Model building

Periodic review policy

Define Consumption_dynamics event for periodic–review policy (t,q):

419

Adding stochastic demand and periodic review

420 of 502

5.2 Model building

Continuous review policy

420

Reorder point – the inventory level, that when reached in a continuously–reviewed inventory management system, automatically triggers a replenishment order of the item from the supplier; controls when orders are placed, but does not control order quantity.

For a continuous review system, the replenishment rule can be defined using a reorder point (ROP) in the Ordering event by modifying its action:

// Define replenishment rule

if (InventoryLevel == 0){

InventoryLevel += OrderQuantity;

}

Adding stochastic demand and periodic review

421 of 502

5.2 Model building

Continuous review policy

With new logic that employs a new parameter, ROP:

// Define replenishment rule

if (InventoryLevel <= ROP){

InventoryLevel += OrderQuantity;

}

421

Adding stochastic demand and periodic review

422 of 502

5.2 Model building

Continuous review policy

Simulate this policy 30 seconds with Random seed = 1 using ROP = 120 units, MeanDemand = 80 units, and DevDemand = 18 units:

422

Adding stochastic demand and periodic review

423 of 502

5.2 Model building

Continuous review policy

Simulate this policy 30 seconds with Random seed = 1 using ROP = 120 units, MeanDemand = 80 units, and DevDemand = 18 units:

423

Adding stochastic demand and periodic review

424 of 502

5.2 Model building

Only one order may be outstanding at any time.

Introduce a variable OrderInTransit of type Boolean with initial value false.
Define Ordering event for a continuous–review policy (s,q) with deterministic lead times:

424

Including deterministic lead times

425 of 502

5.2 Model building

Define NewOrder event for a continuous–review policy (s,q) with deterministic lead times:

425

Including deterministic lead times

426 of 502

5.2 Model building

Determenistic lead times are achieved with parameters MeanLT = 3 days and DevLT = 0.
Simulating the demand parameters MeanDemand = 80, DevDemand = 18 with reorder point ROP = 240 units for 30 days using Random seed = 1:

426

Including deterministic lead times

427 of 502

5.2 Model building

To evaluate the efficiency of different ordering policies, there is a need to estimate holding, ordering and stockout costs of inventory.

Define new parameters: HoldingCost, OrderingCost, and StockoutCost.
Define new variables: HoldingCosts, OrderingCosts, StockoutCosts, FillRate, TotalSales, RetailShortage.

427

Recording holding, ordering, and stockout costs

428 of 502

5.2 Model building

Variables TotalSales and RetailShortage are collected in the event Ordering using the following condition:

// Put this condition before consumption dynamics

// Compute sales and retail shortage

if (InventoryLevel >= Demand)

{TotalSales += Demand;}

428

Recording holding, ordering, and stockout costs

429 of 502

5.2 Model building

Variables TotalSales and RetailShortage are collected in the event Ordering using the following condition:

else

if (InventoryLevel >= 0)

{TotalSales += InventoryLevel;

RetailShortage += Demand – InventoryLevel;}

else

{RetailShortage += Demand;}

429

Recording holding, ordering, and stockout costs

430 of 502

5.2 Model building

Define an event to update holding costs, shortage costs, and fill rates:

430

Recording holding, ordering, and stockout costs

431 of 502

5.2 Model building

Create time plots for the variables FillRate and RetailShortage and stack charts for the variables HoldingCosts, OrderingCosts, and StockoutCosts.

431

Recording holding, ordering, and stockout costs

432 of 502

5.2 Model building

Run simulation experiment for 30 seconds and random seed 1:

432

Recording holding, ordering, and stockout costs

433 of 502

5.2 Model building

433

Service level – the long–run proportion of inventory replenishment cycles in which a stockout occurs.

Safety stock – extra inventory that is carried to provide protection against the risk of stocking out.

Modeling stochastic lead times; The Reorder Point

434 of 502

5.2 Model building

434

Modeling stochastic lead times; The Reorder Point

435 of 502

5.2 Model building

Normal distribution table to find the z–value for 3 service levels:

435

Modeling stochastic lead times; The Reorder Point

436 of 502

5.2 Model building

436

Modeling stochastic lead times; The Reorder Point

437 of 502

5.2 Model building

437

Modeling stochastic lead times; The Reorder Point

438 of 502

5.2 Model building

Update the parameters ROP = 292 units and OrderQuantity = 379 units, and rerun the experiment:

438

Modeling stochastic lead times; The Reorder Point

439 of 502

5.2 Model building

439

Modeling stochastic lead times; The Reorder Point

440 of 502

5.2 Model building

440

Allowing for planned shortages

441 of 502

5.2 Model building

441

Allowing for planned shortages

442 of 502

5.2 Model building

442

Allowing for planned shortages

443 of 502

5.2 Model building

443

Allowing for planned shortages

444 of 502

5.2 Model building

Let’s develop a more flexible model that integrates all four inventory control policies in one model.

Divide the event Ordering into two events:

Consumption_dynamics to describe the daily demand uncertainty and inventory consumption

s_OrderingPolicy to describe the continuous review policies and a dynamic reorder point.

444

Action charts

445 of 502

5.2 Model building

Drag Action Chart from the Actionchart palette onto the canvas:

445

Action charts

446 of 502

5.2 Model building

In the first action chart InvControl_s_q, define a condition for activating it, and logic for true or false conditions. In this case, define a condition Order placed? as:

InventoryLevel <= ROP && !OrderInTransit

and if true, then Update Inventory subsequently executes the following:

NewOrder.restart( LeadTime );

OrderInTransit = true;�

446

Action charts

447 of 502

5.2 Model building

Define a condition Order placed? as:

InventoryLevel1 <= ROP1 && !OrderInTransit1

The code for “Update Inventory” follows:

NewOrder1.restart( LeadTime );

OrderInTransit1 = true;

447

Action charts

448 of 502

5.2 Model building

The event NewOrder will be leveraged from the (s, q) policy and a new event NewOrder1 will be leveraged from (s, S) policy. The event NewOrder1 uses the following logic:

InventoryLevel1 = s_TargetInventory;

OrderingCosts1 = OrderingCosts1 + OrderingCost;

OrderInTransit1 = false;

448

Action charts

449 of 502

5.2 Model building

Action charts for continuous review policies (s, q) and (s, S):

449

Action charts

450 of 502

5.2 Model building

Create an event t_OrderingPolicy:

450

Dynamic target inventory

451 of 502

5.2 Model building

Put the following code into Actions:

// Count time

t2++;

t3++;

// Periodic Review – Fixed Quantity Model

if (t2 == t Period)

{InventoryLevel2 += OrderQuantity;

OrderingCosts2 = OrderingCosts2 + OrderingCost;

t2 = 0;}

451

Dynamic target inventory

452 of 502

5.2 Model building

Put the following code into Actions:

// Periodic Review – Target Inventory Model

// Calculate t_Target Inventory

t_TargetInventory = MeanDemand*(t_Period + MeanLT) + z*DevDemand*sqrt(t_Period + MeanLT);

452

Dynamic target inventory

453 of 502

5.2 Model building

Put the following code into Actions:

// Simple logic with deterministic leadtime

if (t3 == t_Period – LeadTime)

{Order quantity3 = (t_TargetInventory – InventoryLevel3);}

if (t3 == t Period)

{InventoryLevel3 += Order quantity3;

OrderingCosts3 = OrderingCosts3 + OrderingCost;

t3 = 0;}

453

Dynamic target inventory

454 of 502

5.2 Model building

To capture the different inventory dynamics of (s, q) and (s, S) policies, parameter ROP1 is introduced for the (s, S) policy, ROP will be used for the (s, q) policy.
In the action chart InvControl_s_S, update the code for UpdateInventory as follows:

s_TargetInventory = (ROP1–InventoryLevel1)+(a*(MeanDemand+DevDemand)*LeadTime);

NewOrder1.restart( LeadTime );

OrderInTransit1 = true;

454

Dynamic target inventory

455 of 502

5.2 Model building

For future reference, isolate the s_TargetInventory definition as the following equation:

s_TargetInventory = (ROP1 – InventoryLevel1) + (a*(MeanDemand + DevDemand)*LeadTime);

455

Dynamic target inventory

456 of 502

5.2 Model building

Update an event Consumption_dynamics for continuous–review polices:

456

Dynamic target inventory

457 of 502

5.2 Model building

Update an event s_OrderingPolicy for continuous–review polices :

457

Dynamic target inventory

458 of 502

5.2 Model building

458

Dynamic target inventory

459 of 502

5.3

Experiments &

Managerial Insights

459

460 of 502

Learning objectives

Test the performance of 4 inventory control policies on 3 inventory items..
Gain insights into control policy resiliency to demand shocks (§18.2) and lead time disruptions (§18.3).
Understand the trade–offs between being responsive to customer and being cost–efficient in an inventory risk management strategy (§18.4).
Acquire additional experience running and interpreting simulation experiments for managerial decision–making (§§18.2–18.5).

460

461 of 502

5.3 Experiments & managerial insights

The performance of the four inventory control policies introduced in Chapter 16 for the first three products A, B, and C with additional details about demand and inventory levels is compared:

461

Experimental design

462 of 502

5.3 Experiments & managerial insights

In all experiments, demand is variable and lead times are assumed to be constant. When (s,q) or (s,S) policies are employed, a 95% service level is desired (using z–value 1.65). Holding costs are $0.10 per unit per day, ordering costs are $90 per order, and stockout costs are $0.20 per unit per day backlogged.

462

Experimental design

463 of 502

5.3 Experiments & managerial insights

Logic view:

463

Experimental design

464 of 502

5.3 Experiments & managerial insights

Analysis view:

464

Experimental design

465 of 502

5.3 Experiments & managerial insights

The engine oil inventory management experiment with the input data:

465

Experiment 1

466 of 502

5.3 Experiments & managerial insights

In the table, parameter s_TargetInventory is dynamic, following the rule:

s_TargetInventory = (ROP1 – InventoryLevel1) + (a*(MeanDemand + DevDemand)*LeadTime);

Dynamic parameters ROP and ROP1 are defined in the s_OrderingPolicy event.

466

Inventory policy efficiency – the degree to which an inventory management methodology simultaneously minimizes the conflicting costs of inventory maintenance and poor service, including the costs of ordering, holding, and stocking out of inventory units; also called cost efficiency.

Experiment 1

467 of 502

5.3 Experiments & managerial insights

Experiment 1a: Analysis view:

467

Experiment 1

468 of 502

5.3 Experiments & managerial insights

Experiment 1a: Logic view:

468

Experiment 1

469 of 502

5.3 Experiments & managerial insights

Configure properties of parameter variation experiment using Experiment 1a data:

469

Experiment 1

470 of 502

5.3 Experiments & managerial insights

Configure properties of parameter variation experiment using Experiment 1a data:

470

Experiment 1

471 of 502

5.3 Experiments & managerial insights

Results of replicating Experiment 1a 1000 times:

471

Experiment 1

472 of 502

5.3 Experiments & managerial insights

Experiment 1: Modeling a demand shock

An unpredictable demand surge occurs: after 10 days the mean daily demand (MeanDemand) jumps from 200 to 250 units due to a competitor shutting down unexpectedly.

New variable, events, and parameter:

variable t tracks the simulation time clock (with initial value 0 seconds),
event time_tracking increments variable t every second using the logic t++,
parameter enable_update_D is a “switch” that triggers the simulated demand shock (if true), and
event update_Demand is prompted by the condition enable_update_D && t == 10 which triggers the action MeanDemand = 250 at time 10

472

473 of 502

5.3 Experiments & managerial insights

Experiment 1: Modeling a demand shock

Define properties of time_tracking event that model a demand shock:

473

474 of 502

5.3 Experiments & managerial insights

Experiment 1: Modeling a demand shock

Define properties of update_Demand event that model a demand shock:

474

475 of 502

5.3 Experiments & managerial insights

Experiment 1: Modeling a demand shock

To enable the demand shock Experiment 1b, update the value of enable_update_D to true in the experiment properties:

475

476 of 502

5.3 Experiments & managerial insights

Experiment 1: Modeling a demand shock

Experiment 1b with demand shock (seed value: 1):

476

477 of 502

5.3 Experiments & managerial insights

Experiment 1: Modeling a demand shock

Replicate Experiment 1b 1000 times:

477

478 of 502

5.3 Experiments & managerial insights

Experiment 1: Modeling a demand shock

Comparing results of Experiments 1a vs. 1b:

478

479 of 502

5.3 Experiments & managerial insights

Inventory management with lead time disruptions: product B, nuts and bolts.

Input data for Experiment 2:

479

Experiment 2

480 of 502

5.3 Experiments & managerial insights

Experiment 2a simulation results (seed value: 1):

480

Experiment 2

481 of 502

5.3 Experiments & managerial insights

Replicate Experiment 2a 1000 times:

481

Experiment 2

482 of 502

5.3 Experiments & managerial insights

Modeling a change in lead times. After 10 days the lead time increases from three to six days (due to a natural disaster interrupting the transportation route) while daily demand remains stationary.

Setting of event update_LT:

482

Experiment 2

483 of 502

5.3 Experiments & managerial insights

Modeling a change in lead times.

Update value of parameter enable_update_LT:

483

Experiment 2

484 of 502

5.3 Experiments & managerial insights

Modeling a change in lead times.

Experiment 2b simulation results with a day–10 change in lead time (seed value: 1):

484

Experiment 2

485 of 502

5.3 Experiments & managerial insights

Modeling a change in lead times.

Replicate Experiment 2b 1000 times:

485

Experiment 2

486 of 502

5.3 Experiments & managerial insights

Modeling a change in lead times.

Compare results of Experiments 2a vs. 2b:

486

Experiment 2

487 of 502

5.3 Experiments & managerial insights

Explore trade–offs between inventory cost efficiency and customer responsiveness: product C, spark plugs.

Input data for Experiment 3:

487

Experiment 3

488 of 502

5.3 Experiments & managerial insights

Experiment 3a simulation results (seed value: 1):

488

Experiment 3

489 of 502

5.3 Experiments & managerial insights

Replicate Experiment 3a 1000 times:

489

Experiment 3

490 of 502

5.3 Experiments & managerial insights

Observations from Experiment 3a simulation results:

490

Experiment 3

491 of 502

5.3 Experiments & managerial insights

Experiment 3b simulation results with proposed improvements (seed value: 1):

491

Experiment 3

492 of 502

5.3 Experiments & managerial insights

Replicating Experiment 3b 1000 times:

492

Experiment 3

493 of 502

5.3 Experiments & managerial insights

Trade–offs due to parameter change

Comparing results of Experiments 3a vs. 3b:

493

Experiment 3

494 of 502

5.3 Experiments & managerial insights

Trade–offs due to parameter change

The trade–offs between efficiency (total cost) and responsiveness (fill rate).

494

Experiment 3

495 of 502

5.3 Experiments & managerial insights

Trade–offs due to parameter change

The implications of the 2 proposed parameter changes may be gleaned:

Change 1: Reducing the order quantity for the (t, q) policy dramatically improved cost efficiency (32% reduction in expected total cost), but at a slight deterioration of fill rate. On the other hand, reducing the order quantity gave the (s, q) policy gave a milder cost efficiency improvement (9% total cost reduction), but again, at a 1% reduction in fill rates.
Change 2: Increasing the target inventory increased fill rates of (s, S) policy by 1.5%, but with a very slight reduction in cost efficiency. There are no significant improvement in (T, S) policy.

495

Experiment 3

496 of 502

5.4

Further Extentions

496

497 of 502

Learning objectives

In this chapter we briefly describe other ways one may extend inventory and supply chain models, leveraging AnyLogic’s system dynamics and agent–based simulation modeling methods.

497

498 of 502

5.4 Further extentions

Inventory management in supply chains with production and transportation considerations

498

System dynamics – a methodology employing computer–aided design for decision–making in complex systems; uses simulation modeling grounded in feedback systems theory, enabling the analysis of system behavior over time and the understanding of complex causal relationships and the prediction of system responses to changes.

In supply chains, interdependent behaviors of stakeholders (producers, distributors, retailers, suppliers, and customers) imply that production, inventory, and transportation planning should be integrated.
The well–known “Beer Game” (Production–Distribution Game) is an example of system dynamics.

System dynamics

499 of 502

5.4 Further extentions

Agent–based models for market demand

499

Agent–based simulation – a computational modeling technique that simulates systems of autonomous, interacting agents to replicate and study complex system behavior; useful for analyzing emergent phenomena and understanding the interplay between individual behaviors and overall system dynamics.

One can model the consumer market using SD and the supply chain using the AB approach.

500 of 502

5.4 Further extentions

To learn more about the AnyLogic’s functionality with agent–based simulation, system dynamics, and advanced inventory control policies, consider the following example models available with the AnyLogic PLE software:

“AB Market and SD Supply Chain,”
“Adaptive Supply Chain,”
“Supply Chain,”
“Two Stocks Problem,”
“Stock Management.”

500

Agent–based models

501 of 502

5.4 Further extentions

The models “Activity Based Costing Analysis,” “Call Center,” and “Job Shop” may be studied to become better acquainted with building basic types of process flow models, with animation, and with statistical analysis.
The models “AB Market and SD Supply Chain,” “Adaptive Supply Chain,” “Supply Chain,” “Distribution Center,” and “Wholesale Warehouse” for more practice with agent–based simulation, system dynamics simulation, and logistics processes.

501

Agent–based models

502 of 502

Thank you!

502

We gratefully acknowledge the support of Ms. Laides Kreuzpointner and Ms. Anna Putintseva for preparing the slides.