Leaderboard

DISCRETE-EVENT SIMULATION (DES) Business processes are commonly modeled as computer-based, dynamic, stochastic, and discrete simulation models. The most popular way to represent these models within the computer is using Discrete-Event Simulation (DES). In simplistic terms, DES defines how a system with discrete flow units or jobs evolves. Technically, this implies that the computer tracks how and when state variables such as queue lengths and resource availabilities improve over time—the state-variables change due to an event (or discrete event) occurring in the system. A characteristic is that discrete-event models focus only on the time cases when these discrete events occur. This feature allows for vital time compression because it makes it possible to skip through all time segments within events when the system's state remains unchanged. Therefore, the computer can simulate many situations epistolizing to a long real-time span in a short period. To demonstrate the mechanics of a DES model, consider an information desk within an individual server. Suppose that the objective of the simulation is to evaluate the typical delay of a customer. This simulation then must have the following state variables. The status of the server (active or idle). The number of shoppers in the queue. Time of arrival of each shopper in the queue. While the simulation runs, two events can change these state variables' value: the arrival of a customer or service completion. A customer's approach either changes the server's status from idle to busy or increases the number of customers in the queue. On the other hand, the completion of service either changes the server's status from active to idle or minimizes the number of customers in the line. However, the state variables evolve when an event occurs. A discrete-event simulation model analyzes the system's dynamics from one event to the next. The simulation prompts the "simulation clock" from one event to the next and considers that the system does not improve in any way between two consecutive events. For example, suppose a single customer is waiting in line at a grocery store. The subsequent event is the completion of service of the consumer who is currently paying for his groceries. In that case, the discrete-event simulation does not keep track of how the consumer in the line spends the waiting time. Hence, the simulation keeps track of when each event occurs but assumes that nothing occurs during the elapsed time between two consecutive events. The below figure reviews the steps associated with a discrete-event simulation. The simulation begins with initializing the current state of the system and an event list. The primary state of the system, for example, might include some jobs in multiple queues as specified by the analyst. It also could determine the availability of some resources in the process. The most apparent initial state is to consider that no jobs are in the process and that all supplies are currently available. The event list shows the time when the next event will occur. For instance, the event list initially might incorporate the time of the first arrival to the process. Other events might be scheduled originally, as defined by the analyst. Once the initialization move is completed, the clock is advanced to the next phase in the event list. The next event is then performed. The execution of an event triggers three activities. First, the current state of the system is changed. For instance, the executed event might be a job landing in the process. If all the servers are occupied, then the state change consists of adding the arriving job to a queue. Other state changes might expect deleting a job from a queue or making a server occupied. FIGURE: Discrete-Event Simulation [Source: Business Process Modeling, Simulation, and Design by Manuel Laguna] The execution of an event might induce the cancellation of other events. For instance, if the completed event consists of a machine breakdown, this event forces removing the processing of jobs waiting for the machine. Ultimately, the execution of an event may prompt the scheduling of future events. For instance, if a job arrives and is added to a queue, a future event is also added to the event list, indicating that the job will commence processing. During an event is executed, the event is eliminated from the event list. Then the termination rule is checked. If the rule indicates that the end of the simulation has been reached, then raw data & summary statistics are available to the analyst. However, if the termination rule indicates that the simulation has not finished (for instance, because more events remain in the event list), the clock is moved ahead to the next event.