I was responsible for the process improvement of a product comprising the biggest pharmaceutical launch in the history of the world. The product, Celebrex, was slated to be the largest money maker the industry had ever seen. As you might imagine, we had planned the launch in great detail from production to marketing. Production was confident they had the process and manpower in place to match the high demand to be generated from intense, coordinated marketing. You know how you get those uneasy feelings that something is just not right. Well, I had that feeling about production.
How the Production Process Worked
We acquired accurate processing times for every aspect of production and inspection, this allowed us a better understanding of the entire production process. This was achieved by conducting a detailed analysis of each stage of the production process and recording the time it took to complete each task.
We then used this data to calculate the throughput using spreadsheets that took into account the time it took to produce a batch of the product, the time it took to test the batch, and the time it took to release the batch for shipment. The spreadsheet also accounted for the time needed to clean and prepare the equipment for the next batch.
The basic production process worked as follows: raw materials were received, processed, and turned into finished products. A sample was then taken from the batch and sent to the central lab for testing. The lab would test the sample for quality and safety. If the sample passed the lab’s tests, the corresponding batch would be released for shipment. However, if the sample failed the lab’s tests, the entire batch would be rejected, and the production process would start again.
The spreadsheet illustrated that one shift of testing could handle 24 hours of production. This meant that we could produce and test products around the clock, without any delay.
However, after rechecking all the work, it still didn’t feel right. That uneasy ‘feeling’ finally caused me to request a process simulation of production line by creating a digital twin of what we do. After much research, I found ProcessModel to be the right tool for this.
Creating a Process Map
I started by creating a simple process map in ProcessModel. I did that by identifying the various objects involved in the process. These objects included products, workers, machines, materials, and anything else that was relevant to the process. Next, I added entities for arrivals to represent when these entities (raw materials for the medicine) entered the process. For example, products might arrive at the production line. This helped to identify the starting point of each entity within the process. Then came the time to add activities to the process map that showed how the entities would flow through the process. Activities represented the steps involved in producing the product or delivering the service. For example, a product might be mixed, inspected, and packaged before being shipped to customers. Each activity was connected to other activities by routes that showed the flow of entities through the process. The I added storages to the process map where entities would wait for further processing or for the next activity to be available. For example, a warehouse could be used to store medicine until the lab report comes back, and then they are ready to be shipped. Lastly, the resources were added to the process map that were located near activities where they would be used. Resources included workers, and machines.
Using this process map, I was able to get a clear picture of how the actual process flow looked like. This became the base model.
Getting the Model Simulation Ready
To get the base model ready for simulation, the first step was to update the simulation settings. This involved setting the number of hours the simulation would run for, which would determine the length of time the model would be simulated. Next, the arrivals information was updated to show when the arrivals (raw materials for the medicine) would happen during the simulation. This involved specifying the frequency and the number of entities that would arrive during each period. After that, the activities in the model were updated to reflect the actual capacity of each activity in the real system. This involved setting how much time an entity would spend at each activity, as well as how many entities could be processed by each activity at a given time.
Some activities might also have input or output queues, which needed to be specified in the model. The next step was to update the resources in the model. This involved updating the resource properties to reflect the number of resources they represented in the real system, as well as the cost of each resource. Some resources might also require multiple shifts, which would need to be created in the model. Once all of the updates were complete, the model was simulation ready.