3.3 – Activities
Activities are the tasks performed on entities—e.g., assembly, document approval or customer checkout. An activity is defined in terms of the activity time as well as any resource requirements. User-defined action logic may also be specified for an activity. Activities have a processing capacity and may have input and output queues associated with them. Resources connected to an activity are captured before the activity takes place and freed after it has ended.
3.3.1 – General
Name The name of the activity (e.g. CheckIn).
Capacity The maximum number of entities (1 – 999,999) that can be processed concurrently (either individually or in batch). Scenario Parameters may be used in place of numeric values. INF may be used to represent the largest numeric value allowed (999,999).
Stats on This check box allows you to turn off statistics collection for individual activities in your model. By default, this option remains checked.
Time The time to perform the activity. Any expression including distributions, attributes, or variables may be entered as the time value. If a resource is connected to the activity, the resource is captured before the time is taken. Activity times may also be defined using TIME statements in the Action section of the dialog.
If an entity is spending more time than expected at an activity where you are using action logic, you likely have time on the General tab AND in a TIME statement in your action logic. If you use a TIME statement in action logic, you should typically set the time on the General tab to 0. Otherwise you will first execute the time in the action logic. Then the time on the General tab will be executed. Thus your two time settings add together.
Input Queue Cap. The capacity of the input queue. The input queue is like a waiting area. If the input queue has available capacity, entities may be routed into it to wait until the activity has available capacity to process the entity. If the queue has no available capacity, entities must wait at the previous activity (or in that activity’s output queue) until capacity becomes available in the input queue or the activity (0–999,999). Scenario Parameters may be used in place of numeric values.
Output Queue Cap. The capacity of the output queue. The output queue is like a waiting area where entities will wait for available capacity at the intended destination (0–999,999). Scenario Parameters may be used in place of numeric values.
Object Type Allows the type of the object to be changed to something other than an activity. For instance, you may want to change an activity object into a storage or resource.
3.3.2 – Batching
The batching tab allows you to hold entities in queue until a specified quantity is reached. For example, parts might be held in front of a heat treating oven until a specified quantity is reached. The group of part is moved into the oven and the entire batch is heat treated for a specific time. The batch is then moved out of the oven. This batching is performed to increase the efficiency of an expensive resource allowing it cycle only when it has a full load.
When the batch is created in the input queue, one entity is moved into the capacity for processing (the batch). The processing time will be for the batch. If the batch is created in the output queue, then the routing time will be for one entity (again the batch).
A basic explanation of how ProcessModel works may prove helpful. When the batch quantity is reached, all entities are then attached to a new entity (the batch). You may change graphics, set attributes, accumulate cost and assign resources to the new entity. Recognize you are making assignments to the new entity. If the batch is unbatched, the batch entity goes away and the attached entities are removed from the batch and continue on. VA Time accumulated as a batch will be divided among the unbatched entities. Cost added to the batch will also divide to the unbatched entities.
If a resource is assigned (Get) to an entity prior batching, the resource will be trapped in the batch. If you have less resources than the quantity of the batch, the models will be unable to process the request to get the next resource and entities will stop at the Get statement. If a resource is assigned to a batch and is unbatched before the resource is released (Free), the resource will be transferred to the first exiting entity from the batch.
When and unbatch occurs, entities will exit the batch in the same order as they entered the batch.
A batch can consist of other batches. When unbatching, only one level of batch is unbatched at a time.
It is possible to accomplish many other types of batching. For example you could
1. Batch at the end of a shift regardless of quantity – see the model object “short batches”
2. Batch all waiting entities – see the model object “all waiting entities at a specific time”
3. Produce separate batches for different entities — see the model object “group similar entity types”
4. Batch based on multiple criteria — see the model object “smaller quantity because the batch was open too long”
The batch will assume the name of the last entity entering the batch. For example, if you had Car and Truck entities being batched together, and Truck was the last entity to enter the batch, then the batch name would be Truck, regardless of how many of each entity type were contained within the batch. The batched entity name ‘Truck’ can not be change with the ‘New name’ property in the properties dialog.
Attaching is just creating a batch. So if a batch was -not- created after an attach operation, and you then unbatch, the attached child entities will be detached. However, unbatching should not be used as a detaching method because of the following; When forming a batch, a temporary entity is created and the batching entities grouped together with it. When you unbatch, that temporary entity is destroyed. Therefore, if you unbatch a group of “attached” entities, the parent entity will be destroyed and the child entities will detach and move downstream in the model.
• None No batching occurs before the activity. (No Batch Size field appears.)
• Batch The activity will batch or group incoming entities (whether or not the entities have already been batched) and process them as a batch. The number batched is defined by the Batch Size field.
An input queue with a capacity that meets or exceeds the maximum batch size is required.
An Attribute may be used in the Batch Size field to set the number to be batched. The specified batch quantity is evaluated each time an entity is batched. If the entity attribute is less than or equal to the number already waiting to be batched, the batch is formed (with possibly a new size) and released for processing. This allows the specified batch quantity to vary if desirable. It also allows for the creation of short batches.
• Unbatch The activity unbatches or ungroups the incoming entity (if the entity has not been batched, the unbatching is ignored) and processes each entity individually.
• Rebatch The activity will batch or group the same number of entities back together that were unbatched previously. This means you don’t have to know how many entities were previously unbatched in order to rebatch them—no batch size is required.
An input queue with a capacity that meets or exceeds the maximum batch size is required.
• None No batching occurs after the activity. (No Batch Size field appears.)
• Batch The activity will batch or group entities (whether or not the entities have already been batched) after the activity has completed processing. The number batched is defined by the Batch Size field.
An output queue with a capacity that meets or exceeds the maximum batch size is required.
• Unbatch The activity unbatches or ungroups entities after the activity has completed processing. If the entity has not been batched, the unbatching is ignored. No output queue capacity is required, but without sufficient capacity downstream, processing could be delayed while the unbatching occurs.
• Rebatch The activity will batch or group the same number of entities back together that were unbatched previously or arrived in quantities greater than one (in which case the quantity batched is the quantity of the arrival). This means you don’t have to know how many entities were previously unbatched in order to rebatch them—no batch size is required.
An output queue with a capacity that meets or exceeds the maximum batch size is required.
Batch Size Determines the number of entities to be included in each batch. (Used only when batching entities.) An Attribute may be used in the Batch Size field to set the number to be batched. The specified batch quantity is evaluated each time an entity is batched. If the entity attribute is less than or equal to the number already waiting to be batched, then batch is formed (with possibly a new size) and released for processing. This allows the specified batch quantity to vary if desirable. It also allows for the creation of “short batches,” or batches that formed early before the normal size is achieved.
Before using batching, consider that your batch may just as easily be modeled as a single entity (see Section 10.3.8, Job Shop Scheduling ). Also, remember that batching may require an input queue or output queue. Follow the directions on the properties dialog. If a queue is needed, make sure it has sufficient capacity to hold an equal or greater number of entities than the expected maximum batch size. Also note that all batches or groups are unbatched when the batched entity exits the model in order to complete statistics collection on each entity. However, if a batch or group has had an entity attached to it during the simulation, ProcessModel will not unbatch that particular batch (or any groups within that batch).
Variable Batch Size
Existing “in process” batch sizes change when variable batch sizes change.
First some definitions. A batch is a group of items that will be processed at one time. In ProcessModel when a number is entered into the Batch Size field, all processing at that activity will stop until the batch size is met. That means that a batch could wait for hour or even days for the batch to reach the specified size. Changing the batch sizes allows the modeler to have control over what to do if the batch size isn’t met and yet the batch still needs to close. For example: at Quest Diagnostics human samples are processed within predefined response times. The economic order size is to process 24 at one time , but when the end of the day arrives and the economic order quantity has not been reached, the order must still be closed even if there is only one specimen in the batch. These undersized batches are called Short Batches.
An entity needs to enter the batching location to trigger the review of the batch size. In other words you can’t cause the release of a batch by simply changing a variable, but the next entity to enter will cause the review of the batch size.
The entities waiting to be batched don’t know anything about the batch size value. They are always released into the batch when the number of waiting entities equals or is greater than the “current” batch size.
For example, suppose your initial batch size is 10 and you have 5 entities waiting to be batched. Then your batch size changes to 6 AND a new entity enters the batching activity. Those 5 waiting entities will be released into the batch as soon as one more entity arrives. They will not wait for a batch quantity of 10.
When Variable Batch Sizes Change
Sometimes a batch size is controlled by an attribute on the entity arriving at the batching location and other times by a variable. Use the method that best suites your needs. See the model object Batching \ Short Batches for an example of how to change the batch size.
3.3.3 – Action
Develop customized behavior for entities at an activity. In addition to the information set in the General tab of the activities properties dialog, logic can be developed to report statistics, control processing, collect information and a host of other items. Variables, entity attributes, systems information and if-then statements allow expansive capabilities to be accessed from the action tab.
Action logic is processed when the entity enters the Capacity of an activity, and then entities also process the time entered on the General tab. For this reason, when action logic is used, often a TIME statement is included in the action logic and the General tab time is set to 0.
Action logic does not occur in the Input Queue of an activity. If a situation requires action logic in the input queue, see the model object “Flow control – action logic in the input queue”
For additional information see Section 3.11, Action Logic.
3.3.4 – Cost
The cost tab provides a method of adding cost to each entity as it moves through the process. The cost tab also provides a means for classifying how time is accounted at the activity (VA, NVA, BVA). Other costs may be added by the usage of resources (see section 3.4.3 Resource Costs), routings (see section 3.6 Entity Routing Costs) and the initial costs of an entity (see section 3.2.2 Entity Costs).
The identification of cost is optional and has no effect on the behavior of the model.
Hourly cost Cost added to each entity per hour of time spent performing this activity. Cost values may range from negative 1,000,000 to 1,000,000. Idle time, while waiting for resources, is not counted. This cost is added to the pre-defined Cost attribute of the entity being processed.
Activity cost Cost added to each entity completing this activity. This cost is added to the pre-defined Cost attribute of the entity being processed.
If costs are entered as a negative number and final completed production is entered as a positive then a net revenue number can be obtained from the Summary Report. See “Output Summary Reports ” in Chapter 6.2.
Resource cost must be a number. Expressions, attributes, variables, or scenario parameters are not allowed.
To learn more about costs, see ProcessModel and Activity-based Costing .
VA Time How the time for each entity completing this activity is categorized. As an entity is processed its total time in the system will be divided into three categories Value Added, Non-Value Added and Book Value Added. This allows an accurate accounting of how much of the total process time adds value from
• VA — Value Added – Time for those work elements that transform the product or service in a way the customer is willing to pay for.
Value adding (VA Time) activities are those which must be done in order to meet the customer’s requirements. Without these activities, the customer wouldn’t get their desired output. To be a value added action the action must meet all three of the following criteria:
1. Necessary to meet customer requirements.
2. Required for or assists in the production of the product or service.
3. Represents an output that the customer is willing to pay for.
Value added time is calculated by summing the entity VA Time. If the VA type is set to BVA Time (Business Value Added) the time in the activity will be associated to another category. Otherwise all entity time is calculated as NVA Time (non value adding).
It’s not always easy to identify which of the three types an activity is. If you don’t understand customer requirements, spotting Real VA will be difficult. Book/Business Value Added is almost always the most contentious to identify. People will tell you “but we have to do that”, usually for reasons lost in time. Perhaps there was once an audit requirement to carry out a check at a step in the process, but does it apply now? Maybe there was a National Standard that stated an activity had to be done, but is it still required? The biggest challenges, in most public sector processes will be: “why are there so many checks, inspections and approvals required?” What value do they really add and can they be eliminated?
• NVA — Non-value Added – Adding Time for those work elements that are not used to transform the product or service in a way the customer is willing to pay for.
Non Value Added activities are waste! They don’t contribute to the customer’s requirements and don’t need to be performed. Non value added time is characterized by the following:
1. If eliminated, would not impact the product or service to the customer.
2. Creates waste, extra time, rework.
3. Is performed because of inefficiency elsewhere within the process.
4. Represents a equivalent effort to other activities or adds unneeded steps to the process.
Non value added time is applied to an entity when an entity is in the capacity of an activity AND the VA Type is set to NVA Time.
NVA time is also accumulated when an entity:
* Travels on a route
* Sits in storage
* Waits in an input queue
* Is held by a Wait Until statement
NVA Time is calculated by summing the time an entity spends in the above 5 identified areas. Activities are classified from the customer’s point of view meaning that the value of each action in the process is determined by whether it adds value from the customer perspective—value added—or does not add value from the customer perspective—non-value added. Steps that are required but irrelevant from the customer perspective represent a final classification—business-value added.
• BVA — Book-value Added – Time for those work elements that are required to stay in business. Often government required steps will be classified as BVA.
The time that an entity spends in the Input queue, Output queue or in route is Non-Value Added.
3.3.5 – Shift
Shift file The name of the shift file which defines the times when this activity can be performed. A default shift file for all activities may be defined in the Options dialog under the Simulation menu.
Browse Allows you to search through one or more directories to locate a shift file.
Interrupt current activity to go off shift or on break Check this option if the current activity is to be interrupted in order to go off shift or on break. If not checked, the shift will interrupt the activity only after it has completed processing the current entity.
Create shift file Opens the shift editor for defining a shift and saving it as an.SFT file. For more information, see Section 3.10.1, Shift Definition.
Shift with breaks; The breaks are not included in the s