Collecting the Data

When gathering data, it is best to go from general to specific. In practice, data gathering continues through to the end of the simulation project as objectives change and information that was unavailable at the beginning of the project be- gins to materialize. Consistent with this progressive refinement approach, data should be gathered in the following sequence:

1. Define the overall entity flow.

2. Develop a description of operation.

3. Define incidental details and firm up data values.

This doesn’t necessarily mean that data will become available in this sequence.

It only means that the focus of attention should follow this order. For example, some assumptions may need to be made initially to come up with a complete definition of entity flow. Other incidental information obtained early on, such as downtimes, may need to be set aside until it is needed at a later stage of model building.

6.5.1 Defining the Entity Flow

The first area of focus in data collection should be in defining the basic entity flow through the system. This establishes a skeletal framework to which additional data can be attached. The entity flow is defined by following the entity movement through the system, taking the perspective of the entity itself.

The overall entity flow is best described using an entity flow diagram (see Figure 6.1) or perhaps by superimposing the entity flow on an actual layout of the system.

An entity flow diagram is slightly different from a process flowchart. A process flowchart shows the logical sequence of activities through which entities

FIGURE 6.1 Entity flow diagram.

Product A

Station 3B

FIGURE 6.2 Entity flow diagram for patient

processing at Dr.

Brown’s office.

Patient

Checkout counter

go and defines what happens to the entity, not where it happens. An entity flow diagram, on the other hand, is more of a routing chart that shows the physical movement of entities through the system from location to location. An entity flow diagram should depict any branching that may occur in the flow such as routings to alternative work centers or rework loops. The purpose of the entity flow dia- gram is to document the overall flow of entities in the system and to provide a visual aid for communicating the entity flow to others. A flow diagram is easy to understand and gets everyone thinking in the same way about the system. It can easily be expanded as additional information is gathered to show activity times, where resources are used, and so forth.

6.5.2 Developing a Description of Operation

Once an entity flow diagram has been created, a description of operation should be developed that explains how entities are processed through the system. A de- scription of operation may be written in a step-by-step, brief narrative form, or it may be represented in tabular form. For simple systems, the entity flow diagram itself can be annotated with operational information. Whatever the form, it should identify for each type of entity at each location in the system

• The time and resource requirements of the activity or operation.

• Where, when, and in what quantities entities get routed next.

• The time and resource requirements for moving to the next location.

Example: Patients enter Dr. Brown’s office and sign in at the check-in counter before taking a seat to wait for the nurse’s call. Patients are summoned to one of three exami- nation rooms when one becomes available. The nurse escorts patients to the examina- tion room, where they wait for Dr. Brown to see them. After treatment, patients return on their own to the checkout counter, where they make payment and possibly resched- ule another visit. This process is shown in the entity flow diagram in Figure 6.2.

Using the entity flow diagram and information provided, a summary descrip- tion of operation is created using a table format, as shown in Table 6.1.

Station 1 Station 2 Station 3A

Exam room Check-in (3)

counter Waiting

room

TABLE 6.1 Process Description for Dr. Brown’s Office Check-in counter N(1,.2) min. Secretary Waiting room None 0.2 min. None

Waiting room None None Exam room When room is 0.8 min.* Nurse

available

Exam room N(15,4) min. Doctor Checkout counter None 0.2 min. None

Checkout counter N(3,.5) min. Secretary Exit None None None

*Stops to get weighed on the way.

Notice that the description of operation really provides the details of the en-tity flow diagram. This detail is needed for defining the simulation model. The times associated with activities and movements can be just estimates at this stage. The important thing to accomplish at this point is simply to describe how entities are processed through the system.

The entity flow diagram, together with the description of operation, provides a good data document that can be expanded as the project progresses. At this point, it is a good idea to conduct a structured walk-through of the operation using the entity flow diagram as the focal point. Individuals should be involved in this review who are familiar with the operation to ensure that the description of oper- ation is accurate and complete.

Based on this description of operation, a first cut at building the model can begin. Using ProModel, a model for simulating Dr. Brown’s practice can be built in a matter of just a few minutes. Little translation is needed as both the diagram (Figure 6.2) and the data table (Table 6.1) can be entered pretty much in the same way they are shown. The only additional modeling information required to build a running model is the interarrival time of patients.

Getting a basic model up and running early in a simulation project helps hold the interest of stakeholders. It also helps identify missing information and moti- vates team members to try to fill in these information gaps. Additional questions about the operation of the system are usually raised once a basic model is running. Some of the questions that begin to be asked are Have all of the routings been accounted for? and Have any entities been overlooked? In essence, modeling the system actually helps define and validate system data.

6.5.3 Defining Incidental Details and Refining Data Values Once a basic model has been constructed and tested, additional details of the process such as downtimes, setups, and work priorities can be added. This infor-mation is not essential to getting a running model, but is necessary for a complete and accurate model. Sometimes the decision of whether to include a particular el- ement of the system such as a downtime is easier to make once the basic model is running. The potential impact of the element and the time available to implement it in the model are much clearer than at the start of the project.

At this point, any numerical values such as activity times, arrival rates, and others should also be firmed up. Having a running model enables estimates and other assumptions to be tested to see if it is necessary to spend additional time get- ting more accurate information. For existing systems, obtaining more accurate data is usually accomplished by conducting time studies of the activity or event under investigation. A sample is gathered to represent all conditions under which the activity or event occurs. Any biases that do not represent normal operating conditions are eliminated. The sample size should be large enough to provide an accurate picture yet not so large that it becomes costly without really adding additional information.