Shifting Constraints and Systems Thinking

Constraints in Factorio

One thing that Factorio taught me well is the idea of constraints or bottlenecks in production. When observing your factory, it’s very apparent that your slowest moving process in your factory is holding up the entire production line. It’s so easy to see because all the work being done is visible on-screen. Here, we’re going to explain Shifting Constraints and Systems Thinking!

While this blog post is able to be read on its own without any prior knowledge, it is a part of our Lessons in Factorio series, so if this is your first time reading one of this series’ blog posts, I recommend starting from the first one and working your way through them. The first post can be found here: Why I Learned from Factorio: Lean Networking

Identifying a Constraint

Identifying a constraint when there’s visible work is easy. You just need to look for where inventory is piled up, and where inventory is starved. The line between the two is where your constraint is. This is because you’re producing too much before the constraint, so it piles up at the constraint. Afterward, everything is starved for inventory.

In the screenshot below, you can tell immediately that the constraint here is green circuits. There’s enough inventory of everything else. Increasing green circuit production will increase throughput of blue circuits.

So let’s take a look at the green circuits. I included a screenshot below. Over here, we’re running low on iron. Increasing the throughput of iron will increase the throughput of green circuits, which in turn will increase the throughput of blue circuits.

Increasing our Scope and Identifying the Greater Constraint

Before we go rushing ahead and look at increasing our blue circuit production, we need to zoom out and consider if we’re even solving the right problem. Us engineers are great at solving the problems put in front of us, but we’re pretty terrible at considering if we even needed to solve that problem in the first place, though.

To combat this, as an engineer, we need to consider the larger system. Luckily here, we can literally zoom out and look at the whole situation.

Notice, we actually have enough blue circuits. In fact, yellow science is piling up too. We don’t even need to make yellow science. To really increase the throughput of our factory, we need to follow this backwards and see why that’s the case.

This is where I’m processing science. If you look on the labs in the bottom right, those are the ones that are active. The rest aren’t active at all because they’re missing purple science. So to increase the throughput of my factory, we need to be looking at purple science!

I think you know what I need to do from here to increase the throughput of purple science.

Increasing our Scope Even Further and Identifying the Even Greater Constraint!

What’s interesting was that we got a lot of insight into the situation when we literally zoomed out. We learned that we were solving the wrong problem entirely. If I hadn’t, I would have continued increasing the throughput of yellow science and it wouldn’t have had any immediate improvement on my factory.

But what if I ‘zoomed out’ even further? Would it be possible to identify a different constraint? Could it be possible I’m still working on the wrong thing entirely?!

Measuring Engineer Output as Well as Factory Output

To do this, we need to take zoom out from looking at how quickly we are researching science. We’ll no longer be able to physically zoom out and will need to start doing this logically. We need to consider, are we even researching the right thing in the first place?

To answer the question of what to research next, we need to apply systems thinking and take into consideration the factory as a whole and everything that affects it.

There’s probably more than this, but here’s the components I’ve identified:

Engineer Throughput

• Engineer input
  • This is the materials that are needed to build stuff. This is the belts, machines you’re placing down, power poles, rail, etc.
  • This also includes available space to build.
• My own processing power
  • This is my ability to think and solve problems.
• My own output
  • This is my ability to manifest the solutions I’ve thought of into the game.
  • As your base gets larger, this can get throttled by you needing to run around to collect materials and place them down.
  • Later, you can augment this through the logistic network and construction robots.

Factory Throughput

• Factory Input
  • The available materials and collection of them.
    • Iron, Copper, Oil, etc.
  • Transportation of materials to processing areas.
  • Power – Electricity or coal required to power the factory.
• Factory Processing
  • This is all the automation machines and such that process the materials.
  • Transportation between processing machines.
• Factory Output
  • Science Research.
  • Materials for construction.
  • Claiming land from the biters to acquire more space and resources.

Determining The Goal

The last component we need to consider is the aim or goal of our factory. This may seem silly, but if you’ve read my other Factorio blog posts, you’ll find that my goal had a strong impact on how I played. This also plays a strong role in what I researched next.

In the case of yellow science described above, we don’t really need to discuss the goal. It’s quite obvious because it only has one job. The green circuit production’s goal is to produce green circuits. When considering the throughput of the engineer, we need to first consider the goal or how do we measure throughput?

Identifying the Larger Constraint

To avoid from ‘zooming out’ too far and losing you guys. Let’s just assume the end-goal is to launch the rocket. My immediate goal is to optimize both the output of the engineer and the factory.

In my specific case, I didn’t really need to research anything to increase the throughput of purple science, so I just went ahead and expanded that area.

I then kind of looked at my factory as a whole. I can tell by just looking at my iron lines that they’re being stretched a little thin. It’s not an issue right now, but I I know that it’ll quickly become an issue when I expand, so I’ll want to start working on fixing that.

Problem is, I’m already mining all the iron that’s within my controlled territory. To increase my iron input, I’ll need to claim additional space. We’re entering the part of the game where my construction robots are taking forever to get out there and it’s almost quicker for me to run out there and build it myself.

Solution to my Constraint!

Based on that knowledge, I think the next best research to take on is worker robot speed. That’ll help increase my engineer output so that I can more quickly increase the factory’s input.

Common Engineer Constraints

Hopefully I didn’t lose you in my problem-solving workflow for expanding my systems thinking to include engineer output. If you were able to follow along, you should now be able to consider how maximizing factory output alone could hamper engineer output and vice-versa.

Here’s a list of some other common constraints you’ll run into. I’ve included some solutions for the ones where they aren’t obvious.

• Not enough materials to build
  • You immediately start with this problem until you get green science running and making belts and inserts automated.
  • This usually becomes a problem for me again once I have construction robots and my output is suddenly a lot higher
• Placing down solutions takes too much time.
  • This is usually most apparent before you complete blue science and get construction robots.
  • A “clean” design usually calls for a single straight bus in the middle. The problem with this design is that this forces you to spend a lot of time running before you get construction robots. Ironically a spaghetti design doesn’t have this problem.
  • Once you get construction robots, there’s 3 common sub-constraints here.
    • Electricity required to power roboports.
    • The number of construction robots you have.
    • Travel time for robots.
• Solutions take too much time to design.
  • This is the problem you have with spaghetti or ‘artisanal’ designs. They’re very clever, but makes your factory more complex to create solutions for. If you have a more templated and modular design that allows for scalability, this can become trivial.

Applying this to Network Engineering

Now that I’ve shown you how to apply systems thinking to Factorio, let’s try to apply that to Network Engineering.

Am I Solving the Right Problem for my Organization?

On one of my NetEng contracts, I was working on a team that was overwhelmed. It was pretty rough. I tried to make improvements, but using The Five Why’s I was able to identify the root cause for most of my issues and they were outside the control of my team.

This led to me being very frustrated. Why did it seem that my team was the only people that cared about our work? Shouldn’t the company as a whole care about what we’re trying to accomplish and give us the resources we need to succeed?

I then ‘zoomed out’ to consider, what role do I play in this company’s system? and what is the company as a whole trying to accomplish?

After some consideration, I realized that no one cared, because it didn’t matter too much. Of course, my role was important to the company, but in this story, I’m the blue circuit processing team crying that we’re not getting enough green circuits. Sure, it’s important that we get blue circuits, but as of right now, we have enough.

The company I was working for had most of their revenue (output) coming out of the cloud. I was on the team that did NetEng for the corporate network. Most of the outages they experienced didn’t impact production, or even the developers who were working on it.

With this in mind, I was able to relax knowing that my team was doing well enough and meeting the expectations of the company. If I was a manager, I might have spent some effort to identify some greater constraint in the company and put my team’s efforts there or found a way to tie our efforts to that constraint in order to get us more funding.

Increasing Network Engineer Throughput

There’s a lot of parallels between Network Engineer and Factorio Engineer Throughput. Let’s draw them out.

• Input
  • Factorio Engineer
    • This is the materials that are needed to build stuff. This is the belts, machines you’re placing down, power poles, rail, etc.
    • This also includes available space to build.
  • Network Engineer
    • Materials required to build stuff. This is cabling, routers, switches, firewalls, etc.
    • This also includes the available time to build.
• Processing power
  • Factorio Engineer and Network Engineer
    • This is affected by how easy the designs are to work with.
      • Are they very complex?
      • Are they modular?
      • Are they scalable?
• Output
  • Factorio Engineer
    • Starts off doing everything manually. Later as the base gets larger, templates and automation through the logistic network is necessary to keep up with growing demand.
  • Network Engineer
    • Smaller organizations are fine doing everything manually. As the organization grows, templates and automation tools become necessary to keep up with growing demand.

I’m not going to attempt to come up with examples of how to solve these types of problems in the network engineering space. With each situation being unique, it’ll be hard to come up with helpful examples that are applicable to you. Hopefully this gives you enough visibility into the greater issue and empowers you to better solve your problems.

Conclusions This Run

After learning how to maximize throughput and such, it’s been a lot harder for me to enjoy the game. The same goes to my network engineering work as well. Prior to this, I was too focused on optimizing the factory. I forgot to optimize myself, the engineer.

Including my throughput in scope for consideration on what to improve next has made the game a lot more enjoyable. In general, engineer happiness is correlated to engineer productivity and I found this to be true with my Factorio runs in general.

When comparing the speed of this run vs some of my other runs, this one wasn’t the fastest if you compare actual time played. Instead, it was faster if you compared the amount of progress I made across calendar days.

It’s a better strategy overall compared to my previous runs if you take into consideration that this also was more enjoyable and took less energy. Especially when applying this to Network Engineering, engineer effort is an important metric to consider. Sustained high intensity effort projects back to back can eventually lead to burn out.

Thank you for checking this out. I hope you learned something new or enjoyed reading this. If you had any comments, questions, or just wanted to share your thoughts on this article, you can contact me at blog@e-mayhem.com

e-Mayhem helps companies successfully deliver business projects. We also help companies avoid losses associated with IT disruptions and security threats. You can learn more about our services at e-mayhem.com or by emailing sales@e-mayhem.com