Copyright Gerd Wagner (CC BY-NC), created on 6/1/2016 with the Object Event Simulation (OES) framework OESjs, last modified on 4/28/2022 | OESjs Credits
Classification tags: business operations management, DES, next-event time progression
A shop is selling one product type only (e.g., one model of TVs), such that its in-house inventory only consists of items of that type. On each business day, customers come to the shop and place their orders. If the ordered product quantity is in stock, the customer pays for the order and the ordered items are provided. Otherwise, the shop has missed a business opportunity and the difference between order quantity and the inventory level counts as a lost sale. The order may still be partially fulfilled, if there are still some items in stock, else the customer has to leave the shop without any item. The percentage of lost sales is an important performance indicator.
Whenever the stock level falls below a certain threshold (called reorder point), the shop places a replenishment order with a quantity computed as the difference between an upper threshold (called target inventory) and the current stock level.
The model defines an inventory management system for a single product shop with a continuous review replenishment policy. For simplicity, customer orders are treated in an abstract way by aggregating all customer orders during a business day into a daily demand event, such that the random variation of the daily order quantity is modeled by a random variable.
Likewise, the random variation of the delivery lead time, which is the time in-between a replenishment order and the corresponding delivery, is modeled by a random variable.
The potentially relevant object types are:
Potentially relevant types of events are:
These object and event types, with their participation associations, can be visually described in a UML class diagram, as shown below.
If a demand is greater than the current stock level, the difference counts as a lost sale. Whenever the stock level falls below a certain threshold (called reorder point)), the shop places a replenishment order with a quantity computed as the difference between an upper threshold (called target inventory) and the current stock level.
ON (event type) | DO (event routine) | Conceptual Event Rule Diagram |
---|---|---|
customer order | if there is sufficient inventory, then product handover, else customer departure | |
product handover | customer payment | |
customer payment | customer departure |
The random variation of the lead time between a replenishment order and the corresponding delivery
is modeled by a random variable with a uniform probability distribution between 1 and 3 days.
The inventory is modelled as an object with three attributes: productQuantityInStock
,
reorderPoint
and targetInventory
. For simplicity, the model does not create
replenishment order events, but instead it only schedules corresponding delivery events.
Consequently, we model just one object type: SingleProductShop
, with three attributes
quantityInStock
(NonNegativeInteger), reorderPoint
(NonNegativeInteger),
and targetInventory
(PositiveInteger). In addition, we model two event types:
DailyDemand
as an exogeneous event type with one attribute: quantity
(PositiveInteger),
and with the random variable function sampleQuantity
and, as an exogeneous event type,
with a recurrence
function.Delivery
as a caused event type with one attribute: quantity
(PositiveInteger),
and with the random variable function sampleLeadTime
.When the design model is implemented with an object-oriented programming language or framework,
the participation associations between DailyDemand
and SingleProductShop
, as well as
between Delivery
and SingleProductShop
, are represented with the corresponding
reference properties shop
and receiver
. This is also the case when using the Object Event
Simulation (OES) framework OESjs available from Sim4edu,
where all object types are derived from the pre-defined OES category oBJECT
and all event types are derived from the pre-defined OES category eVENT
,
as shown in the following diagram:
ON (event type) | DO (event routine) |
DailyDemand( demQuant) @ t |
IF demQuant <= shop.quantityInStock THEN IF shop.quantityInStock − demQuant < shop.reorderPoint AND shop.quantityInStock > shop.reorderPoint THEN SET ordQuant TO shop.targetInventory − shop.quantityInStock - demQuant SCHEDULE Delivery( ordQuant) @ t + sampleLeadTime() DECREMENT shop.quantityInStock BY demQuant ELSE (if demQuant > shop.quantityInStock) INCREMENT shop.lostSales BY demQuant − shop.quantityInStock SET shop.quantityInStock TO 0 |
Delivery( delQuant) @ t |
INCREMENT receiver.quantityInStock BY delQuant IF receiver.quantityInStock <= receiver.reorderPoint THEN SET ordQuant TO receiver.targetInventory − receiver.quantityInStock SCHEDULE Delivery( ordQuant) @ t + sampleLeadTime() |