Building a Modern Production Scheduler (I)

This May, we're going to implement a production scheduler at Bold, and I've set out to share what the whole process of developing a feature like this looks like. This will be the first post in a series of articles in which we'll analyze the decisions made and why we made them.

Understanding the problem to solve

For the sake of brevity, we'll skip the process of deciding whether this is the feature we should be implementing right now, and assume that decision has already been made.

The complexity of this type of problem is infinite. In fact, it belongs to its own category of software called Advanced Planning and Scheduling (APS). Therefore, our approach will be to timebox development to one month (May) and deliver an MVP that we can then iterate on using real customer feedback.

If we take a look at the competition, we can find, even among the market leaders (Siemens Opcenter, SAP, Oracle...), absolute monstrosities with dozens of buttons and options that make it impossible to implement software like this without a consultant to guide you.

I understand that years of evolution and new use cases have led them to add this much complexity, but at least we know that NOT what we want to build at Bold.

User experience must come first. Ideally, a planning manager should be able to use the tool without even receiving training.

Let's talk about features

So, what is the minimum a factory needs from a production scheduler?

To answer this question, we'll broaden the scope and first list everything the perfect scheduler should do, then analyze the impact and complexity of each item to see where we should start.

Easily visualize the entire schedule

Currently, manufacturing operations in Bold are displayed as an ordered list, where it's easy to change the priority, but you do it machine by machine, so you lose sight of the big picture.

That's not enough, so a more consolidated interface is essential—one where it's easy to make changes across machines and see the dependencies between operations.

Automatically send the plan to operators

This can be more complex in APS systems that are independent of the MES, but at Bold it's trivial. There should be an option to work on a plan before applying it in the real world, so operators don't go crazy.

Automatically calculate the optimal manufacturing sequence

This is the core feature to develop; without an automatic algorithm, it doesn't add value. Now, the algorithm can be more or less complex. Let's look at the constraints it should be subject to when scheduling:

Precedence relationships

In other words, being able to specify that operation B cannot start until operation A has been completed. Absolutely essential, because without it the plan would make no sense.

Raw material availability dates

This would be useful, because otherwise we could schedule urgent work to be done immediately even though we don't yet have enough material. Fortunately, this is also very inexpensive for us to implement at Bold, since it's already in place.

Machine constraints

Another essential requirement. If we don't restrict which machines can perform each operation, the scheduler doesn't add enough value.

A nice extra would be different efficiency rates for each machine performing the same task. We can implement this using the Machine/Process Type concept we already have in Bold.

Non-production periods (breaks, non-working shifts, broken machines, etc.)

We need at least one global calendar per plant to account for weekends, nights (if no work is done), and so on.

Ideally, this calendar could be customized for each machine to represent breakdowns or sections of the plant that are closed during certain shifts.

Workforce constraints

This adds a lot of value, because otherwise the system will assume infinite workforce capacity, and this will often be one of the key limiting factors. The problem here is that we haven't yet developed a system for managing shifts, calendars, operator skills, etc.

We should have this, but we'll add it after the constraints we've discussed so far.

Changeover times between products

This is extremely complex and requires huge matrices and data that most companies don't have. Calculating it requires a great deal of historical data.

We'll definitely do it, but not for the MVP.

Manually adjust the plan

We have to assume that the algorithm won't be perfect on day one, so we must provide a way to manually manipulate the resulting plan.

That manipulation should also highlight which constraints are no longer being met and the impact on estimated delivery dates.

Compare “what-if...” scenarios

We've said that we'll have at least one plan to edit and an “apply” button for the current production orders, so at least comparing these two things should be relatively inexpensive, even if they're in different browser tabs.

Being able to save more than one plan and compare them without applying them is another matter. That sounds interesting, but the use cases I can think of are more niche, so we'll leave it for later.

Lock the short-term planning horizon

This seems very useful for avoiding continuously disrupting the operators' short-term plans.

Ideally, we could also lock certain operations at a given point in time and force the algorithm to find a solution that takes those fixed constraints into account.

Use different optimization criteria

This could be interesting for an advanced planner, but at this stage of development, having a single working algorithm should be enough.

We'll need to think of an optimization criterion that can be “configured” in some way (and I can think of converting everything to euros and minimizing cost).

Pass planned dates through to sales orders to get estimated delivery dates

This comes for free in Bold :D

Our MVP

So Pablo, what features are you going to include in the MVP?

Well, the answer is... I still don't know! Since the capacity (cost) we have available is fixed, and we're going to spend a fixed amount of time (one month), only one variable remains free: the scope (or, in plain English, which features are included).

So we'll start developing the most critical features and keep going until we run out of time. That will be the MVP.

We'll continue talking about the design in the next article.