This evening I attended the DC IIBA Meetup on the subject of process mapping, which is obviously an area in which I have some experience. Since I’ve reached a natural break in writing about pure business analysis subjects I’m going to revisit the discrete-event simulation framework, with my first goal being to add a few demos that illustrate some variations that are possible. To that end I’ve been reviewing the existing code and the to-do list and see that I need to add the following sub-item to the list of abstract processes to support:
- Include ability to represent entities that remain in the system and only change state during the simulation run, rather than entities that merely pass through the system from an entry to an exit. These should be referred to as resident entities. The items might change color or include one or more text labels reflecting their current state (since multiple characteristics may drive several state characteristics in parallel, with multiple state variables making up synthetic state variables of other kinds), or move among locations (components) to represent state (assuming resident items).
- Include the ability to easily replicate groups of components representing the state of items that remain within the simulation, if that method is adopted. Alternatively, make the resident entities move through a common set of state-representation components.
These capabilities support modeling of items like aircraft in operation and maintenance simulations. They remain within the system at all times while parts may enter and leave the system.
The item defining pools of resources was originally meant to represent staff that performed certain functions, though they could also represent specialized equipment. An example of how this works is to imagine pools of mechanics that are available to service aircraft. This can get quite complex, but lets work from a simple example to something more complex. Aircraft require a continuing series of scheduled and unscheduled maintenance activities over time, and each one requires a certain number of mechanics for a certain duration. If a group of aircraft simultaneously require service actions that require more mechanics than are available, then the service requests will have to be queued and answered in some kind of order. That is, mechanics will complete a service on one aircraft, return to the pool, and when enough mechanics are back in the pool to fulfill the next service request, they are dispatched to do so.
The next complication is to consider the queue of service events and identify opportunities to service the requests out of order to take advantage of opportunities to complete services requiring fewer resources (e.g., mechanics and time) while waiting for resources to become available to service a larger request. Imagine a group of four aircraft and six mechanics. One aircraft requires a service involving four mechanics for three hours. Another aircraft then requires a service that requires a service involving eight mechanics for two hours. The second service cannot begin until the first one is completed and the mechanics return to the pool. Now imagine a third service request involving two mechanics for thirty minutes. We might check to see if this one can be completed while the first service is still underway, so the mechanics can be used closer to their full capacity. (I would call this an opportunity service after the idea of an opportunity move the Level 1 engineers worked out for transfer of slabs in two-line tunnel furnaces at Bricmont.) The calculations involved can get quite complicated but you can see where this is going.
Another complication beyond that is that there are several groups of mechanics to service different parts of the aircraft, each subject to the same limitations. By itself this isn’t a problem but there are cases where more resources are required to complete an action than there are resources of the needed type available. That is, there might be a service that requires seven airframe mechanics in a situation where only five are assigned. In these cases the system pulls mechanics from other specialty pools to provide the necessary help. Sometimes the main work is performed and supervised by the relevant specialists while other workers just stand around and hold things and move things and run tools under direction. In that case there has to be logic that determines which supplementary pools to pull from.
Another concept to add is the idea of consuming supplies or parts. This requires the ability of logically merging entities. In an assembly process we might have a main assembly moving along an assembly line and having parts added to them from pools of parts from other processes and locations. Chaining pools of parts together can model a supply chain, and various sizes of those pools can be investigated to determine their optimum size and configuration. Pools of part can be treated like queues that might be reloaded in bulk rather than one entity at a time. Additionally, we might consider adding parts to larger assemblies based on custom configurations. This is true of automobiles being made with different options and military aircraft being fitted with different equipment in order to perform different missions. In other cases we might want to split elements off from a moving entity, as we do in the bag object, which can be thought of as a parking lot where vehicles park and their occupants get out and go through their own process. These ideas suggest two more items to add to the to do list.
- Include ability to merge entities together. (This is somewhat similar to an AND gateway, a diamond with a plus symbol, in BPMN.)
- Include a flow-through pool component that acts like a queue component but which can potentially be loaded in bulk. The object may also send a request for replenishment when the supply declines to a specified level. There should be signals and warnings based on definable quantity thresholds.
I’ve added the new items to the project page.