Let's connect
Let's connect

How to simulate a supply chain model: From a simple recipe to a flow graph in the factory

Picture of Szymon Tracz, Senior Software Developer

Szymon Tracz

Senior Software Developer

12 minutes read

The supply chain modeling inside a factory seems like an overwhelming task. You deal with complex multi-stage specifications, internal logistics, and just-in-time product deliveries. More or less, you try to keep your production plan up-to-date and in order. This complex reality downsized into a computer program doesn’t make it any easier.

But there is a possibility to grasp everything and keep you in control. It opens up new concepts for you and your company. In this post, we’ll try to illustrate the solution by segmenting the whole picture and making graphs corresponding to customer orders. This enables us to create an elegant structure that is extensible and understandable for both developers and factory managers.

The goal of every manufacturing company is the production of products from commodities. So the first question arises: What commodities do we need to produce the end product? Let’s start with a basic tree diagram. During production, we have commodities that we buy or produce. Let’s call them ingredients, for better understanding. If we throw several ingredients together and pre-produce them to fit the production process, we’ll refer to it as a recipe. This way, we’ll answer more questions throughout the article, such as:

  • How do we fulfill the ingredients? 
  • Are they in stock? 
  • Do we produce them on-site or have them delivered?
  • At what stage in the process will we use the ingredients? 
  • Do we need to move them from the warehouse to the production line?
  • How will following the processes impact the duration of the whole production?

Later we’ll explore alternative views and extensions of our model. They will meet more specific needs and allow a detailed analysis.

We also know that a day in a factory holds various surprises. So, our graphs and answers to the above-mentioned questions change dynamically.

Supply chain modeling: Initial recipe

Let’s start with the following assumptions:

  • A customer orders a product, which might be a book.
  • For the production of said book, we use printed pages and a book cover.
  • The printed pages come from combining ink and pre-cut pages.
  • The pre-cut pages are produced from paper.

The above-mentioned ingredients formulate a recipe. It shows which commodities we need to start production. Let’s visualize it as a tree. The root is the ordered book and the stem with its branches portrays, as referred to in graph terminology, nodes and their children displaying the production process of said book. The leaves represent the commodities crucial for the production process.


The recipe can be dynamically adjusted. For instance, we may start printing the pages, before the book cover has arrived. Even if it doesn’t arrive, we have created a future buffer for a different order. This means, the factory workers decide what to do next. If we lack some commodities, we can simply abandon a subtree and replace it with a leaf or another subtree derived from another recipe.

Supply chain modeling: Way of fulfillment

At this stage, our model represents dependencies, but omits specifics. Strategies to satisfy the need for commodities may vary among companies and certain cases. Let’s take a closer look at the possible strategies:

  • Commodity buffer – In some cases, companies keep a buffer of commodities in stock to start the production of a product right away, in our case a book.
  • External supplier – Once a company uses various commodities, it buys most ingredients from external sources to avoid a buffer.
  • The Hybrid – Some companies choose to do both, produce a given ingredient or order it externally, based on the current workload.

A company could mix strategies depending on the business sector and specific variables such as commodities, time, and availability. Whatever method they choose, our diagram needs to represent the results in the right sequence within our structure.

For all preassembled items in the graph, we’ll assume that the company produces them locally. It doesn’t have to be true, since we can outsource some production and our model will also support it. So, a company keeps commodities either in stock or needs to order them from a supplier.

Let’s model our exemplary assumptions like this:

  • Book Cover is available in-house
  • Ink is available in-house
  • Paper can be ordered from a supplier

The fulfillment for various parts in the graph can rapidly change. In case of cancellation of an urgent order, we could reuse the already produced items to satisfy other orders. This means we use them as an available and suitable substitute. 

As for now, we can simply change the label on a given node and perhaps relink its children to another production, or increase the future buffer of a commodity.

Supply chain modeling: Represent processes

Let’s imagine a situation, where we have a single node for a single item. Either it’s created or detached from some larger graph. This could mean one of two things:

  • The node is a product of a no-input process that satisfies the needs of other processes
  • The node corresponds to a customer order and waits for proper expansion into a production tree

In other words, a node can be either a fulfillment that comes from a production process or a demand from a customer order. This means, we’ll split our nodes into:

  • demands, items required by the process, and
  • fulfilments, items provided by the process.

This approach satisfies single or large demands with multiple small fulfilments, or caters to multiple demands with single or large fulfilments. We’ll go deeper into this matter in the section “Other Models”, but for now, let’s leave it at that.


This definition of nodes also allows us to attach a single node to a single process. It gives us multiple advantages:

  • We can easily explore various perspectives of diverse company departments
  • We can assign any fulfillment to any process
  • We can order the demand by use and shape a pull system around our model

The distinction between demand and fulfillment lets us easily handle scenarios, such as cancellation or modification of the graph. Let’s say, a node becomes detached. It still contains precise information about operations that were planned before. This means we need to decide what to do with the connected fulfillment.

Supply chain modeling: Time as a dimension

Once we’ve extracted every process into a separate group of nodes, we can try to represent the most crucial dimension – time. We want to save and access data about time as:

  • Occurrence time of a given node – is a point in time, or its estimation, at which a given item is demanded or fulfilled. We will derive this time from evaluating the elapsed time described below.
  • Time elapsed in a given state – is at the most granular level, we can distinguish between two kinds:
    • Active time – when we wait for the process to complete. It sums up the process duration.
    • Idle time – when we wait for a process to take place and start transforming it. The items lay during this time inactively in buffers.

This distinction fits nicely into our supply chain model. It draws borders between processes. If a given edge is crossing the “process’ border”, we call it idle time. This means another process demands an item later than the other process will fulfill it. 

If processes don’t cross borders, we call it active time. This means the demands of a process need to be fulfilled before another process commences.

Then again, if we assign durations between the edges, we get a key advantage. We can now evaluate paths in our tree according to their “duration” and compare every possible tree and subtree within this metric. 

Moreover, if we assign completion times to recipes, or processes, we are able to calculate the fulfillment time for the end product in a bottom-up manner.

Let’s visualize this data in our example.


In our example, the time of the whole process is dictated by the availability of leaves. If they are available, they can be processed right away and if supplied externally, their availability might be delayed. However major delays are caused by processes that take a long time or their initial position in the production queue.

Both durations of processes and waiting times can dynamically change according to the following factors:

  • Queue – processes are often part of a sequence, for example, a queue of production tasks for a given machine. After reordering it, their expected execution time may change.
  • Even if first in the queue, processes can have delays – we can’t expect the estimated time of a process to always match reality. The key responsibility of the system, when processes are in progress, should be to monitor waiting times and make sure they are always positive to restrict the delay of process execution by other dependants. 
  • Delay in one process causes delays for others – If some delay or speed-up of the process occurs anyway, we should transmit that change across the whole graph.

Supply chain modeling: Space as a dimension

Since we now have a representation of time, we turn to the availability of an item at a requested time. Yet, we add one crucial assumption: The fulfillment satisfies the demand right after completion. This assumption is problematic since different processes happen in different locations. Let’s call them places. This means we need to account for transportation as another kind of process for our calculation:


After adding transport processes between demands with different locations, we’d get the following representation:


This way, we have built a complete supply chain model that involves items and fulfills other demands. The processes are anchored in space and time, so we’re able to visualize a complete tree of fulfillment for an order in the company.

If you want to read more about advances in modeling and simulation in supply chain and industry, we recommend reading this article.

Other supply chain models

With such a complete supply chain model, we derive various other data models to see our company from multiple perspectives.

A multiple demand and fulfillment simulation

The supply chain model and simulation can be extended to a multiple order fulfillment. This means we address multiple demands with a single fulfillment, or execute a single request with multiple fulfilments.


Nodes as events

Nodes as events enable us to represent demands and fulfillment as a chart with historical stock levels along with a forecast with future stock level changes. Each demand represents a decrease, and a fulfillment represents an increase of a given stock level. This way, we get a great tool to detect high-priority stock orders or even inappropriate buffers.


Flow between places

Let’s consider the fact that we hold data about all transports in our supply chain model. We are then able to create another graph, and every node symbolizes a place. This allows us to see the transfer rate between places in a given timeframe. It can help us to optimize transportation. For example, we could increase commodity buffers in our warehouses or organize internal logistics to reduce transfers or make the majority of them as short as possible.



We haven’t mentioned any specific industry throughout the whole process, since we tried to make this model as generic as possible. If we extend processes within the bounds of our definitions, this model can be used to represent a material flow in a lot of industries, from manufacturing to logistic companies. If introduced in various sectors interacting with each other, we can even cover graphs from multiple companies.

Scalable lean manufacturing software

Manage production processes with software tailored to your business model that outperforms historically competitive systems. VirtusLab helps you to implement a modern custom production system that adheres to the Industry 4.0 concept.

I want to know more

Liked the article?

Share it with others!

explore more on

Take the first step to a sustained competitive edge for your business

Let's connect

VirtusLab's work has met the mark several times over, and their latest project is no exception. The team is efficient, hard-working, and trustworthy. Customers can expect a proactive team that drives results.

Stephen Rooke
Stephen RookeDirector of Software Development @ Extreme Reach

VirtusLab's engineers are truly Strapi extensions experts. Their knowledge and expertise in the area of Strapi plugins gave us the opportunity to lift our multi-brand CMS implementation to a different level.

facile logo
Leonardo PoddaEngineering Manager @ Facile.it

VirtusLab has been an incredible partner since the early development of Scala 3, essential to a mature and stable Scala 3 ecosystem.

Martin OderskyHead of Programming Research Group @ EPFL

The VirtusLab team's in-depth knowledge, understanding, and experience of technology have been invaluable to us in developing our product. The team is professional and delivers on time – we greatly appreciated this efficiency when working with them.

Michael GrantDirector of Development @ Cyber Sec Company