7 Steps to a Successful Discrete Event Simulation Project
By Jon Santavy, International Partner Manager
Published: November 13, 2015
A proven roadmap for successful completion of a simulation project is to follow an established methodology. This simple guide provides a basic framework that we recommend for ensuring success with simulation projects.
Step 1: Develop the Functional Specification Document
The key to any successful simulation project is to start with a clearly defined statement of the problem, the objective of the simulation model and how the model will go about addressing this problem. We call this a Functional Specification. The basic items to be addressed in the Functional Specification are as follows:
- Background of the problem
- Objectives – Why are you doing this study?
- Detailed process flow description and diagrams
- “What-if?” scenarios to be evaluated
- Key Performance Indicators (KPI) – driven by project objectives
- Boundaries of the system to be studied
- Input and Output data requirements
- Animation requirements
- Define system assumptions
- Define deliverables pertinent to the objective
- Project timeline
Step 2: Identify and Collect Data
Once you have clearly outlined the problem and model with the Functional Specification, you are now in a position to identify and collect the data that will be necessary to ensure that your model matches the reality you are trying to simulate. If done correctly, your Functional Specification document should make this straightforward.
You will need to identify what data is necessary. These data requirements are commonly driven by the process map, process objectives and model inputs/outputs.
Once you identify what data is necessary, then you need to determine where the data will come from. Common sources of data include system databases like ERP, MES, POS, Historians and other business systems. Some data may need to be collected manually via time studies, work sampling, etc...
Step 3: Build the Model
Because Arena is so easy to use, there is a real tendency to want to jump right into dragging and dropping blocks onto the screen. However, we find that a better practice is to first define the fixed aspects of your model before building out the logic. These fixed aspects include Resources, Variables, Attributes and other elements. If they are defined upfront, then accessing them in the model logic is made easy via Arena's drop down menus.
Once the fixed aspects have been defined, you can now build out the simulation model logic. Arena's flowchart modeling methodology makes this very easy and intuitive. The Functional Specification should be used as the roadmap for the model to ensure that it is developed correctly to address the problem.
After the model has been developed, you need to give some thought to the User Interface. Some important things to consider are:
- Who will need to run this model?
- What input information will they want to change?
- What output information needs to be evaluated?
We have found that Microsoft Excel can be utilized to build very effective User Interfaces for Arena. Virtually everyone in your organization is probably familiar with Excel and how to use it. Arena includes the ability to easily interface with Microsoft Excel so that users don't need to have a full in-depth knowledge of the simulation model in order to run the desired scenarios, review the results and make informed decisions.
Some Important Model Building Notes:
- Maintain easy to understand naming conventions, such as beginning all variable names with “v_”)
- Build the model in a modular format and utilize the module “Name” field to document your logic as you build it
- Collect data and build the model simultaneously
- Consistently review the model to ensure that the logic design mimics the real system or reflects a proposed system as closely as possible
- Utilize a simple method of version control in order to document model progress as well as to provide a backup version
- Maintain backups of the model versions on multiple machines and/or servers
Step 4: Document the Model
As much as everyone hates doing it, documenting your model is essential. Let's face it, if your simulation project is a success and you have saved your organization millions of dollars, you are going to be promoted quickly! So, you need to ensure that those following in your footsteps can benefit from the exceptional work that you have done.
Our standard practice on our consulting projects is to provide lots of documentation about the model within the simulation file. We recommend at least four types of documentation for each project:
- Functional Specification
- Model logic documentation
- Model run documentation
- Project analysis report
Step 5: Verification and Validation
Verification is defined as ensuring that the model behavior makes sense; entities are moving in the direction they should and process steps are taking place as expected. If you have developed a Functional Specification and followed it during the Model Building phase, then this step should be relatively easy.
Validation means that Stakeholders agree that the simulation model outputs are close enough to the real system outputs to be useful for solving the problem at hand. The validation process varies depending upon the type of model that is built. Models of existing systems are generally validated against historical data. In these situations the model input may use actual data or distributions based on that data and then the output from the simulation runs are compared against the actual historical results. For simulations of greenfield projects or proposed nonexistent systems, subject matter experts will be needed to participate in both the verification and validation steps and they will use data from similar systems or their knowledge of such systems to approve the simulation for use in analysis. In all cases, when the existing system is changed or becomes a reality the simulation is amended to reflect those changes and the Verification and Validation cycle is repeated to keep the model valid for continued analysis or for use in operational decision making.
Step 6: Analysis
Once the simulation model is validated, the various scenarios under consideration can be evaluated. This may involve:
- Varying the input data to represent proposed changes and analyzing the results.
- Modifying the base line model to remove or include new processes under consideration and running it with existing data.
- Utilizing OptQuest to find optimal combination of inputs to maximize profit.
It is important to document how each scenario is defined and use this information to justify the recommendations you make to meet the objectives of the project.
Step 7: Project Deliverables
Now that you have completed your analysis and formulated recommended solutions to the problem, it is time to think about the Project Deliverables. The following is a list of recommended deliverables that should be provided as part of a simulation project:
- Fully documented model with user interface and (optional) 2D or 3D animation and data dashboards.
- “What-if?” scenario/experimentation
- Analysis and recommendations
- Anticipated financial benefits including:
- Cost savings
- Cost avoidance
- Efficiency projections
Following these 7 Simple Project Guidelines will help ensure the success of your simulation project.
Rockwell Automation is committed to your success using Arena and provides expert Arena training and project Jumpstart Consulting services. To find information on these essential services, visit our Consulting Services page.
Sign up for the Newsletter
Arena User Group
Arena has a very active user community on LinkedIn. Ask questions, learn about best practices and connect with other simulation professionals.