Your Signshop Floor Doesn’t Need a Task for Everything

This article was written by Brooks Digh, FSG Signs (Austin, TX) and Texas State University (San Marcos, TX).

I RECENTLY CALLED UP a coworker of mine to ask him where we were on a sample for a customer. His answer, “Haven’t started. Corporate says we cannot do anything without a task now.” “Well, that is not going to work,” I replied. To me it was obvious. This was a classic example of a control-level mismatch, and one that was going to quickly lead to chaos.

Custom manufacturing is not simple to schedule and samples are even more complex. For my coworker, to have a task created, he needs to email a project manager to create a cost code for the labor and materials to be applied to. The project manager then needs to send an email to the scheduling department to have a task set up. Finally, that task needs to be received by the floor managers or shop employees. This is generally fine when a project is due weeks out, but for iterative tasks like thermoforming distortion printing or making complex samples, this process of emails can lead to scheduling lag. We also have key customers who aren’t going to accept the excuse of “well, we did not have a task” when a project is late.

But what was immediately obvious to me was clearly not obvious to our corporate office. And how do you explain a control-level mismatch and the damage it can do to a shop to someone who is totally unfamiliar with those concepts? You can make a logic-based argument, but that is not nearly as effective as a numerical one that relates to cost or late tasks. That’s when it hit me: If I can create a simulation that shows how much the policy increases late tasks, I have an argument that is going to be difficult to ignore.

The ABCs of Inventory Management

The first concept that must be understood is a control-level mismatch. It can be pretty abstract when thinking about scheduling and tasking, but inventory management has a classic example that is easy to understand. ABC Inventory Management is a style of inventory control where different items are assigned different levels of control. Inventory items assigned to the ‘A’ category are expensive and require heavy control while items assigned to the ‘C’ level can be given much lower levels of control.

Basically, every signshop uses this management style, even if they’ve never heard the term. Screws, bolts and washers are generally always assigned to the ‘C’ level. I want to know roughly how many I have so I don’t run out, but I don’t want someone counting how many washers we have or scanning a barcode to cost them into a job. Sheets of aluminum or sticks of aluminum extrusion are examples of ‘B’ level items. I want to cost them to jobs, I want to know how many are in my inventory, but if my cycle count comes up one short, nobody is tearing the shop apart to look for it. Electronic message centers are always an ‘A’ level item. Hopefully nobody has lost one out of inventory, but if they have, I would guess someone got fired.

This ABC Inventory style creates multiple levels of control and placing an item into the wrong category would cause a control-level mismatch. Placing screws into level ‘A’ would cause you to waste time counting and costing to jobs something that is only a fraction of a percent of the cost of a sign. On the other hand, assigning an electronic message center the level of ‘C’ basically guarantees you are going to lose an expensive inventory item at some point. These are real costs that are created by a control-level mismatch. Production management can have similar issues with control-level, and I’ll prove this through simulation later. But just start thinking about how having a task for everything your shop does might be similar in some ways to that employee counting washers.

Simulation in the Signshop

So now that we understand control-levels and control-level mismatches, how do we prove that having a task for anything that needs to be done in the shop is a control-level mismatch? This is where Monte Carlo simulations come in. If you don’t know what a Monte Carlo simulation is, don’t worry, I guarantee you are not the only one.

Monte Carlo simulations basically allow you to take a situation where a random event may occur and then repeat the situation tens of thousands to millions of times to see the probability distribution of the outcomes. These simulations are used commonly in financial analysis, but I’ll go over a really simple example to make it clear. Whenever you roll a die, you get a random output between 1 and 6. If you roll the die enough times, you expect to roll all the numbers about the same amount.

I wrote a program that randomly selects a number between 1 and 6 10,000 times and then outputs the frequency that each number is selected as a histogram shown in Figure 1. The horizontal axis shows each of the possible die rolls (1-6) and the vertical axis shows the frequency of times each of the numbers was rolled. Since I did this with a random number generator, as expected the frequency that each number was rolled is about the same.

Figure 1: Output from rolling a die 10,000 times using a Monte Carlo simulation. The possible responses of 1-6 are on the horizontal axis and the number of times each number was rolled is on the vertical axis.

I know what you are asking: What the heck do Monte Carlo simulations have to do with tasking on the shop floor? Often the goal of scheduling is to reduce the number of late tasks. Monte Carlo simulations create a way to determine how many late tasks occur using each control-level. The number of tasks inserted per day will be random, just like rolling a die, so we can represent those as a random variable with a normal distribution, but more importantly how quickly people respond to each of the emails required to create a task is also random.

The lognormal distribution is a classic way to model email response times. As shown in Figure 2, the lognormal distribution is densely clustered at an early mean but has a long right tail. Putting this in terms of email responses, this means there is a high probability that an email will be responded to quickly, but there is also a small probability that it could take days to get a response. If you’ve never spent days waiting for an email response, it must feel good to be that important at your shop. Going back to the die example, you basically have a massive die with thousands of sides (some of the sides have the same response time) and you roll it every time you send an email.

Figure 2: Graph of the lognormal distribution representing email response times. The response time is shown on the horizontal axis and the probability that response occurs is on the vertical axis. The peak close to 1 and long tail represent the often-immediate response to emails and the occasional long wait for responses.

Using a test schedule I created, I ran 20,000 simulations. In the first 10,000, I allowed the new task to be immediately inserted into the schedule. For the second 10,000, I summed the email response time for multiple lognormal outputs. For each simulation I counted the number of late tasks and graphed them with a histogram. Honestly, the response was astonishing. The average number of late tasks across the simulation with direct insertion was 262 and the average number of late tasks requiring the email process was 799. This is a massive increase and clearly shows that this policy leads to more late tasks and is therefore a control-level mismatch.

The histogram of the lateness can be shown in Figure 3, and though it looks complicated at first, I promise it isn’t that bad. On the horizontal axis we have the number of late tasks. On the vertical axis we have the probability that that number of late tasks occur. The direct insertion is shown in blue and the tasking with emails is shown in yellow. The graph shows that you are likely to have around 250 late tasks from direct insertion with a steep drop off as it approaches 400, but for the email process you are very likely to have 800 late tasks over the same time period.

Figure 3: Graph of the simulation output for late tasks. The yellow represents requiring tasks to be made for each need and the blue represents direct insertion into the schedule. The graph shows a massive increase in lateness when switching to the new policy.

So, what do you think? Is the tradeoff of a massive increase in late tasks worth the increased level of control? How do you do tasking in your shop? Could the friction of creating a task be reduced to solve this problem?