Arena Newsletter and Blog

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?

Launcher’s Lurgy causes space launch vehicles to be delayed relative to their planned launch date. The disorder is similar in nature to Loser’s Lurgy, a condition causing Quidditch players to perform poorly, first described by Luna Lovegood in J.K. Rowling’s enormously successful Harry Potter series. Pretty much all rockets have Launcher’s Lurgy with launch delays being all too annoyingly common. For example, a quick search on the word “delayed” on Spaceflight Now’s launch history log web page[1] results in more than 100 matches (the search engine’s limit). There is no known cure for Launcher’s Lurgy but simulation modeling can be used to develop predictions for how many launches can be achieved over a particular time period and when any particular launch of interest is likely to launch by.

An Old Danish proverb says,

It is difficult to make predictions, especially about the future. 

Yet, businesses rely upon predictions and forecasts to make decisions each and every day; for better or for worse.

Data driven models are quick to develop, yet powerful for complex processes. SimWell, our Premier Partner in Canada, has put together this four part series which will explain what Data Driven Models are, why they are important, and how to begin making your own in Arena.

Data-Driven Supply Chain Model Built with Arena

Using Arena, it is easy to build a supply chain simulation model where trucks deliver material from 5 supplier sites to 100 different customer locations. Data-driven models are a very powerful type of simulation models, which rely on data to drive the actions taking place. This model only requires 17 modules of flowchart logic and creating animation is not mandatory. Andre at SimWell, our Premier Partner in Canada, has created a video to further explain how to build such a model, using the following data driven tools:

Time is our most precious commodity, and wasting even the smallest amount can be detrimental to your business.

In a previous role, I worked in logistics, specifically with manufacturers in the northeastern United States. Every job we performed required specific arrival, processing, and departure times. Any extra downtime would increase costs both internally on labor and externally on driver detention (see Issue Type – Driver Detention). On one job in particular, we had a series of trucks arriving over four nights, three trucks at a time. Each truck had a specific arrival time of 5:00PM, 7:00PM, and 9:00PM. If we weren’t on time we typically saw costs of:

It comes as no surprise that being organized is the key to success in project management and that means creating a functional specification.  Whether you are building one model you are going to use for analysis or two or three, organization is key.  A critical aspect of organization will be defining those elements that you are going to use in the model or share across models.  Taking the time to define the key resources, variables, attributes and other elements will allow you to potentially create one master database to test your models, saving you time and helping to keep your analysis organized as well.  Members of the Arena Consulting Team have employed this technique with great success, using one master database structure and two very different models for a client to test out potential design ideas. 

In this month’s case study, one of the chief goals of the simulation model was to test several potential operational modifications. When there are several changes to test, the questions arise: