Arena Newsletter and Blog

We have been receiving a number of questions about building Arena simulation models from healthcare organizations that are struggling to cope with the COVID-19 crisis. While we will continue to provide support as quickly and thoroughly as we can to individual questions, we wanted to write a post to help with general suggestions for users building models focused on predicting healthcare capacity and bottlenecks. 

While simulation tools have improved over time, most of these improvements have been in regards to simplifying technical hurdles, like importing data or making the user interface easier to understand. The complexity of how to break down a complicated, real-world process into concrete steps that can be modeled in a simulation language continues to be the most difficult part of using any package.

Sometimes, a high speed packaging line must handle products that need to be stabilized during movement because of their size, shape, or spill potential. When this situation occurs, a common solution is to place the product into a puck, or carrier, during conveyance through the line operations. However, this can present a challenge to the modeler in exactly how to represent the introduction of empty pucks to the line, marrying the product with the puck, and de-pucking the product when complete. The following example discusses how to use pucks in a 1:1 relationship to product on a line.

The value of simulation is pretty well documented, however our clients who have been able to achieve the greatest value from simulation are those who recognized that it was important to apply simulation when a new project is just beginning to be formulated.  Simulation is the original digital twin of a system and it allows you to play with a system in the virtual world and gain insight into what a proposed change may mean to production, scheduling or even determine if perhaps the current system is adequate.   Generally speaking, any investment in simulation is typically money well spent, so long as it is a good simulation and not just pretty animation, because it helps determine the best use of capital. Even if the decision is made not to change something, it prevented someone from taking a risk and making a change for the sake of change that likely would have been less effective or even more costly.

The Direct Read feature has been Arena for a few years now but the capability has been expanded to more Arena elements, making it easier to import data directly into Arena for ease of use in analyzing data.   For those of you who haven’t used the Direct Read functionality within Arena, it is definitely a feature worth taking a look at.  Direct Read allows you to link elements in Arena with data sources so that Arena will read in the values for those elements from the data source.  This means that you can create an Excel file and have data defined for your model in a workbook that you will link via Named Ranges to Recordsets in Arena.  

In keeping with our continued effort to make modeling more intuitive, the new Gather and Disperse modules will make it far easier to seize and release groupings of resources.

AVAILABLE NOW!

Companies spend lots of time and effort defining vision and mission for their organizations.  These are important to ensure that teams are aligned with its direction and that everyone clearly understands where they are going as a company.  While vision and strategy are important, companies often ignore the most critical question:  “Why?”  Why do we do what we do?

Complex, expensive vehicles – such as airplanes or trucks – often contain a number of parts that will fail over the lifetime of the item. Approaching the modeling of this usage and failure tracking can be a tricky prospect. One solution is to use the entity’s attributes to model each part. Attributes can even be arrayed to contain additional information about the individual part, such as the installation date, number of trips made or miles logged, part number, and a unique identification code. But since every entity has a copy of every attribute, what happens when different vehicles have different part requirements? The number of attributes needed to manage this level of complexity can quickly become overwhelming and cumbersome.

Worldwide, the average human is 5’6” (167cm) tall. This is a true fact – I know because I found it on the internet. However, is it a useful fact? Assume for a moment that you are a manufacturer of blue jeans. Would you take this average height value and then size all of your equipment so that it can only make jeans for individuals who are exactly this height? Now imagine your business was more narrowly focused in terms of your potential customer pool, e.g. men living in the United States. If you’re aiming for a smaller group, would it make any more sense to buy equipment that only makes one length of jeans? Or should you take the range of potential heights into account when designing your factory?