Divide your inventories by 2 while decreasing shortages. What a bold statement we claim! This article aims at explaining how it is possible to achieve such outcomes with numerical simulations and simple cases.

We will explain below with simulations the two main differentiators of Flowlity : dynamic safety stock and extended Supply Chain synchronization.


The impact of dynamic safety stock

Case Description

For the first part we will simulate the impact of dynamic safety stock.

For this part we consider the following seasonal demand pattern. The graph below shows the demand pattern for the period week 27 2018 to week 23 2020

demand pattern for the period week 27 2018 to week 23 2020

With this example, we want to see the impact of a seasonal peak on inventory levels depending on two different inventory policies.

Traditionally, companies define a static safety stock approach that would consist of setting a fixed min and max (reevaluated quarterly or yearly):

static safety stock approach by setting a fixed min and max

Flowlity, instead, dynamically adjusts safety stocks based on computed uncertainties. Here is a simple example of how Flowlity’s algorithm would react to the demand pattern above:

Flowlity's algorithm reaction

This inventory policy takes into account the different levels of risk through time and places the right inventory at the right time.

As you can see in the graph below, we first made a forecast of future consumption that is different from the actual one that materializes.

forecast of future consumption

Let’s now run a simulation to compare what are the results achieved by each of the previously defined inventory policies. (You can find the settings for the simulation in the appendix)


The results highlight the benefit of a dynamic inventory policy in this case. In the following graph we can see the actual inventory evolution when planning according to a traditional inventory policy and when planning with dynamic safety stocks:

actual inventory evolution when planning traditional inventory policy and dynamic safety stocks

Graphically we can notice that the blue line (inventory level when planning according to a dynamic inventory policy) is almost always below the brown one (inventory level when planning according to a traditional inventory policy). On top of that we can notice that the dynamic inventory policy here prevents a stock out by suggesting a higher inventory level during the peak of demand compared to the traditional inventory policy approach.

The results are summed up in the following table:

results traditional vs Flowlity

We can see that for this specific case, defining a variable inventory policy through time led to an average inventory reduction of around 33% with an improved service level given the avoided stockout.


To sum up, this simulation highlights the benefits of a dynamic definition of the inventory policy. Following the risk pattern in demand and supply to place inventories allows for average lower inventory levels and less stockouts.

This is a simple example and heuristic to illustrate the benefits of dynamic Safety Stocks. Flowlity’s AI algorithms are going way beyond those simple principles and are always dynamically adjusting safety stock for maximum performance.



Killing the beer game by being a synchronizing 3rd party

Case description

The beer game is probably the most famous serious game about supply chain management. As you know, it allows people to understand the bullwhip effect by experiencing it first hand in a simulation where 4 players of a beer production and distribution Network are involved. It typically highlights how sharing information among the various actors of the supply chain is beneficial for the entire value chain.

By being a trusted third party, Flowlity can help people achieve total visibility along the supply chain without the drawbacks of sharing information dictated by the competitive nature of the customer-supplier relationship. This feature allows Flowlity to actually enable end-to-end visibility and given the celebrity and purpose of the beer game, we applied the Flowlity approach to simulate the effects on it. (The settings for the simulation can be found in the appendix)


To evaluate Flowlity’s impact, we implemented 2 ordering policies:

1 – Base Stock Policy: This policy emulates a good strategy that a standalone player would apply. (The details can be found in the appendix)

2 – Customer Synchronization: This policy emulates what happens when a player is synchronized with their customer through Flowlity. In this setting a player follows Flowlity’s recommendations which are based on information available at the player and their customer. (The details of this policy can be found in the appendix)

We ran two simulations which are summed up in the table below:

prdering policy per player for each simulation

For the simulation we consider the following demand from the final customer

simulation consider the demand from the final customer

The results of the simulation on ordering patterns and costs can be found below.

Results Simulation 1 – Base Stock Policy

order patterns per player simulation 1 order patterns per player simulation 1


Results Simulation 2 – Customer Synchronization

order patterns per player simulation 2 order patterns per player simulation 2



The results show that when Flowlity is deploying end to end synchronization, everybody is reaping out the benefits. The bullwhip effect is almost completely annihilated and costs are much lower for each single player of the game. But that is a conclusion everyone in Supply Chain already knows. The purpose here is to emphasize the fact that with Flowlity it is a reachable goal. Indeed, what prevents companies to implement full visibility with their business partners is mistrust towards the use of that information in commercial negotiations. Flowlity being a trusted third party, each player only has visibility to their own data but gets recommendations based on information coming from all players leveraging thus full end to end synchronization.


Overall Conclusion

I want to conclude this article summing up what we have discussed and what I hoped to convey as a message here. Flowlity allows every company to reduce their inventory levels and increase service level in two ways:

  • Fully leveraging your own data to dynamically place the right inventory at the right place and at the right time
  • Making End To End Supply Chain synchronization a reality by leveraging everyone’s data to kill the bullwhip effect




Dynamic Inventory policy – Simulation Settings

This simulation is played with the following rules:

  • The forecast is fixed in the beginning and does not evolve through time
  • The inventory policies, both traditional and Flowlity, are fixed and do not change during the simulation
  • The actual demand is not known in advance
  • There is no difference between planned supply and actual supply (everything that is ordered is delivered on time and in full)
  • There is one week lead time meaning the planner cannot change the plan for the current week but only starting next
  • Each week the planner does the planning for the next 3 weeks
  • The ordered amount is calculated with the following logic: for every week within the next 3 weeks, if the projected inventory goes above the maximum or below the minimum levels of the inventory policy a plan is made/changed to aim for the minimum inventory level

When making this simulation we track the following things:

  • actual inventory level over the whole period
  • number of stockouts
  • average actual inventory level over the whole period

The Beer Game – Simulation Settings

We have played the game with the common settings:

  • 4 stage supply chain (customer, retailer, wholesaler, distributor, factory)
  • 2 periods lead time for orders (when an actor places an order, it is received 2 periods later by its supplier)
  • 2 periods lead time for shipments (when an actor ships an order, the goods are received 2 periods later by its customer)
  • Initial inventory is 12
  • Initial customer demand is 4, it doubles in period 8 and remains stable for the rest of the game
  • The simulation runs for 52 periods
  • Every period is composed of these 4 steps happening in the following order:
    1. Check deliveries: How many units of beer are being delivered to the player from the wholesaler.
    2. Check orders: How many units the customer has ordered.
    3. Deliver beer: Deliver as much beer as a player can to satisfy the demand (in this game the step is performed automatically).
    4. Make order decision: Decide how many units are needed to order to maintain stock.
  • The costs are calculated according to the standard settings (0,5 point per inventory unit per period, 1 point per backlog unit per period)

The Beer Game Simulation – Base Stock Policy

Each player places an order to reach the target inventory position which is defined as a safety stock (arbitrarily set to 4 pieces) and the expected demand over 4 period. The expected demand is calculated as the average demand of the last 4 periods. Then they calculate their current inventory position which is the inventory on hand after shipping the products, plus the outstanding orders (orders placed in the current period and the 3 previous ones), plus the known backlog of the supplier (the backlog of the previous 4th period) minus the current backlog of the player.


TIP = Target Inventory Position
CIP = Current Inventory Position
P   = Current Period
BL(P)  = Player Backlog in period P (after shipping of goods in period P)
SBL(P) = Supplier Backlog in period P (after shipping of goods in period P)
Order(P) = Order placed by player in the period P
AvgDem4 = Average Demand of periods P-1 to P-4
SS = Safety Stock = 4

TIP = SS + 4 * AvgDem4
CIP = SUM[Order(P:P-3)] + SBL(P-4) - BL(P)
we aim at TIP = CIP hence 
Order(P) = MAX{SS + 4*AvgDem4 + BL(P) - SBL(P-4) - SUM[Order(P-1:P-3)],0}


A player places an order to their supplier which is equal to the order placed by their customer in the same period. This policy can be applied for each player except the retailer as they receive orders directly from the end customer whose demand is still unknown


CO(P) = Customer Order in period P
Order(P) = player Order in period P

Order(P) = CO(P)