00:00:00 Introduction to scheduling complexities
00:02:30 Interdependence and service level challenges in aerospace
00:06:14 Discussing Bill of Materials and Resources
00:13:15 Daily scheduling challenges and human limitations
00:20:45 Introducing algorithms for efficient scheduling
00:28:30 Emergency measures and AOG pricing in aerospace
00:36:02 Mathematical perspective on scheduling impacts
00:43:47 Complexity and constraints in task scheduling
00:50:17 Leveraging computational power for scheduling optimization
00:57:39 Critiquing FIFO’s limitations in MRO
01:04:15 Decision-making and automation in supply chain

Summary

In a recent interview, Conor Doherty, Director of Communication at Lokad, and Simon Schalit, COO, discussed Lokad’s breakthrough in scheduling optimization for aerospace, particularly in aircraft manufacturing and MRO operations. They highlighted the complexity of coordinating numerous interdependent parts, skills, and equipment, which traditional methods struggle to manage. Lokad’s approach shifts from a Bill of Materials (BOM) to a Bill of Resources (BOR), considering all necessary resources and their variability. Utilizing computational algorithms, Lokad can quickly generate practical solutions, minimizing financial risk and downtime. This integration of automation and human strategic insights is crucial for efficient and effective scheduling in complex environments.

Extended Summary

In a recent interview at Lokad, Conor Doherty, Director of Communication, sat down with Simon Schalit, COO and Head of Supply Chain Science, to delve into the complexities of scheduling optimization, particularly within the aerospace sector. The conversation highlighted a significant breakthrough achieved by Lokad in this domain, which has profound implications for aircraft manufacturing and Maintenance, Repair, and Overhaul (MRO) operations.

Conor began by setting the stage, emphasizing the intricate nature of scheduling in manufacturing and repair industries. He pointed out that managing a vast network of parts, tools, and personnel, which can change unpredictably, is a formidable challenge. Simon Schalit then elaborated on this complexity using the example of aeronautics, where the task of manufacturing or repairing something as intricate as an aircraft engine involves coordinating numerous parts, skills, and equipment. He stressed that unlike other supply chain segments where decisions can often be made independently, in MRO and manufacturing, especially in aeronautics, every element is interdependent. Missing even a single part out of a hundred can halt the entire process, rendering the other 99 parts useless.

Simon explained that this interdependence necessitates a shift from the traditional Bill of Materials (BOM) perspective to a more comprehensive Bill of Resources (BOR) approach. While a BOM lists the parts needed for a task, a BOR includes all necessary resources—parts, skills, and equipment. This holistic view is crucial because it accounts for the availability and variability of each resource. For instance, parts may be subject to lead time variability, skills depend on personnel availability, and equipment might be in use or under repair.

Conor and Simon discussed the practical implications of this approach. In a traditional MRO setting, daily planning often involves manually adjusting schedules based on the availability of parts and personnel. This method, while common, is inefficient and prone to errors due to the human mind’s limitations in handling complex, interdependent variables. Simon highlighted that even minor changes in a schedule can have cascading, unpredictable consequences, making it difficult to achieve an optimal plan.

The conversation then shifted to the role of computational algorithms in addressing these challenges. Simon explained that Lokad’s algorithm can quickly generate a good enough solution by considering the current state of all resources. This capability is vital in the aeronautics industry, where every minute of downtime is costly. The algorithm’s strength lies in its ability to simulate various “what if” scenarios, helping companies understand the financial implications of different decisions and emergency measures.

Conor emphasized that the goal is not to find a perfect solution but a practical one that minimizes financial risk and reflects the current state of resources. Simon agreed, noting that the ability to quickly generate a new sequence of events based on available resources is crucial for minimizing financial impact.

The discussion also touched on the limitations of traditional heuristics like FIFO (First In, First Out). While FIFO is simple and fast, it fails to account for the varying financial and strategic importance of different tasks. Simon argued that a more nuanced approach, which considers the specific context and constraints of each task, is necessary for effective scheduling.

In conclusion, Simon and Conor underscored the importance of integrating computational tools with human strategic insights. While humans excel at strategic planning, they are not equipped to handle the granular complexities of scheduling in large-scale operations. By leveraging algorithms, companies can achieve more efficient and financially sound scheduling decisions.

Simon wrapped up by asserting that the future of supply chain decision-making lies in automation, particularly in complex environments like aerospace. He emphasized that Lokad’s approach combines the computational power needed for granular decision-making with the strategic oversight provided by human experts, offering a robust solution to the challenges of scheduling optimization in the manufacturing and repair industries.

Full Transcript

Conor Doherty: Welcome to Lokad. Scheduling is one of the most complicated concepts in manufacturing and repair industries. This is because you have to manage an enormous network of parts, tools, and people, and that network can change at a moment’s notice.

Today’s guest, Simon Schalit, is COO and Head of Supply Chain Science at Lokad, and he joined me in the studio to discuss how his team tackled this problem. Now, he and I spoke primarily about scheduling in aerospace, but everything we discussed today applies just as equally to any manufacturing industry. As always, if you enjoy what you hear, like this video, subscribe to the YouTube channel, and follow us on LinkedIn. And with that, I give you today’s conversation with Simon Schalit.

The topic of today was scheduling optimization and the extensive work the supply chain science team has done on having a breakthrough in that field. So before we get into those weeds, just from your own perspective, and you can take aerospace as a vertical just to make it concrete for people, what exactly is the problem of scheduling that our team of engineers, our team of supply chain scientists, are trying to fix? What is the problem?

Simon Schalit: Okay, so let’s take the example of aeronautics, MRO, or manufacturing. When you’re trying to manufacture or repair something of the magnitude of a plane or a big segment of a plane, let’s say an engine, for example, you’re faced with something that is incredibly complex. Complex, of course, from an engineering perspective, but also just if you take the sheer number of parts, skills, and equipment that you’re going to need to put together to be able to carry out the task that you are assigned, whether it’s manufacturing or repair.

In most segments of the supply chain, when you’re making decisions, you could argue that decisions could be considered independent without this way of thinking being too harmful. For example, if I’m deciding to purchase item A and item A is out of stock, I’m still going to be able to sell item B or item C. There might be consequences, but in general, that’s the case. So thinking independently is not too harmful.

When it comes to MRO or manufacturing, especially in the aeronautics environment, that becomes completely untrue. If you want to be able to repair, let’s say, an engine and you need 100 parts to be able to repair that engine, having 99 of those parts and missing one will get you no further than having absolutely none of those parts.

Conor Doherty: What do you mean?

Simon Schalit: Because the engine still can’t—the plane still can’t fly even if you’re missing just one of those parts. Even if you have 99 of them, the plane still can’t fly. So you’re faced with a problem where you should not try and have each part; you need to have all parts and, in fact, all resources available at the right place at the right time. Otherwise, you just can’t do anything.

And in fact, that changes the problem completely. Because even if you were to say, “Okay, I have a 99% service level,” which most people in most companies would say, “Yeah, that’s an okay, that’s a high service level.” If you’re looking at 99% service level independently, that’s quite high. But if you’re saying, “Okay, I need 100 parts, and for those 100 parts, I’m going to have a 99% service level for each of them individually,” so 99% chance out of 100 for them to be there at the moment I expect them, in fact, if you were to say that those are independent, the combined service level of this very simple case would be actually extremely low. It would be below 40%.

So it means that even with a 99% service level, if you need 100 different parts or resources to be available, the possibility of you not being able to carry out your repair or your manufacturing step is actually not an accident; it becomes the norm. It has more than a 50% chance of actually happening. So that places you in a world that is extremely different from your usual supply chain decision-making. It puts you in a world where even with very high service levels, having problems arise is the norm and not the exception. So you need to build your supply chains and your supply chain decision-making process to be resilient towards this. So that’s a very different subject altogether.

Conor Doherty: Okay, thank you. And you mentioned a few terms there, and I just want to separate them a little bit because you talked about parts and then you started talking about resources. Now, I presume you were not using them synonymously; you were drawing a distinction there. So could you just provide a little more clarity there? When you say resources, you’re not purely talking about physical parts. Again, if we’re talking about repairing an engine or repairing an APU, there are physical parts involved in the process, yes. But when you talk about resources, what are you talking about?

Simon Schalit: Well, when you’re talking about repair or manufacturing something, people will refer to the concept of a bill of material. A bill of material is basically the list of parts that you need to put together to finish something—a plane, an engine, whatever. The problem is that this is only part of the problem. You’re going to need other types of resources to actually carry out the task.

Mainly, those resources are going to be skills that come from people and equipment that are going to be things that you don’t necessarily consume but that you’re going to use. And more often than not, they can be pretty expensive, and you don’t have an infinite amount of them, like a test bench, for example, if you’re talking about aeronautics. So it’s not enough to have all the parts available. You’re going to need to make sure that you have the equipment—test bench, crane, whatever—and the people to operate and put together the parts in a safe and technically valid way.

So when we talk about the problem of those bills of materials and how they are used, we prefer to refer to a concept of bill of resources, which is more accurate in the sense that it encompasses the problem in its entirety rather than just the materials.

Conor Doherty: Okay, well now that you’ve reintroduced the term bill of materials, which I presume anyone watching this is probably familiar with, the bill of resources perspective—can you contrast those two in concrete terms? So like, take a decision, sketch out a decision for, let’s say, an MRO using a plane just to make it simple, and explain how a BOM perspective would play out in real time versus a more sophisticated bill of resources perspective.

Simon Schalit: Okay, please. So usually, MRO activity or manufacturing activity follows different steps that have to come in a certain order. Things have to be done before, things have to be done after. But each step can be defined with its own bill of resources, meaning the list of parts that you need to carry out this particular repair step, the list of skills—not people, because you might have different people with different skills—the list of skills that are necessary to carry out, and the list of equipment.

Parts will usually be consumed in the sense that they will be mounted. Skills will not be consumed in the same manner in the sense that people still have those skills, but they will be consumed from a time perspective over a certain period of time. Same thing for equipment. All those three elements—parts, skills, and equipment—all come with their own set of variabilities.

Variabilities for parts usually are whether they are in stock or not, which is a simple way of saying it. Behind that lies the concept of variabilities of lead time, mostly, and of course, whether you place the order at the right time or not, but usually mostly variability of lead time.

The variability that is attached to the skill comes from whether the person will be present and available, but mostly present to carry out the task. So it comes with all variabilities that are attached to human beings in general, like is the person sick, was the planning done correctly, does the person have the valid skill from a legal perspective, etc. And actually, that’s the type of variability that is even more difficult to apprehend and to control than the lead time because you can’t force someone to not be sick. If the person is sick, they’re sick.

And of course, there is the availability of the equipment, which again is consumed during a certain period of time, but which is of course less likely to be sick. The equivalent would be broken, in repair, or perhaps still stuck in another engine or aircraft being repaired and still not freed from that particular task. So those are, I would say, the three, and they all come with their variabilities, and that’s what makes the problem difficult.

Conor Doherty: Well, on that note, again, to take a concrete example, and again, we can compare how a traditional MRO with a bill of materials perspective and then, let’s say, maybe one of our clients with a bill of resources perspective, we can contrast how they would approach a scenario. We’re trying to fix, I think it’s an A380. I think it’s an A380. Monday morning, we need to repair engine A. We come in, and you have a BOM perspective. So again, a physical deterministic BOM perspective. I know how many parts I need—100 parts to fix that engine. You come in Monday morning, we have all the parts. Simon and Connor are absent. Like, Simon’s teaching something, Connor’s hurt his back lifting something heavy, so we’re not available.

So you have all the parts, so that part of the equation you’re in luck. You have all 100 parts. You actually have all the tools—maybe it takes 20 tools, let’s just say 20 tools. So you have 100 parts, you have the 20 tools, but you’re missing the critical skills. And not even all the skills, just Simon to attach a certain part, you need a license to do that, and Connor to supervise. So what happens there in terms of decisions if you have a bill of resources perspective?

Simon Schalit: It’s not having the bill of resources that’s going to make the biggest difference. The bill of resources will allow you to combine the different uncertainties that exist in the three segments I’ve just described and realize how likely it is for an incident like the one you’ve just described to happen. You need to organize in a way that’s going to be able to cope with that kind of problem.

But let’s take your example. Let’s say we have all the parts, we have all the equipment, but the people are just not there, which is actually quite frequent for a lot of reasons. Currently, the way people cope with that is that each morning in the workshop, let’s say we’re talking about a big workshop that does repairs, every morning and perhaps even twice a day, people in charge of the different repair lines are going to convene and try to rebuild the schedule for the day.

They will see what is missing, whether it’s parts or people, and they will say, “Okay, the plan that we had for today is gone. It just doesn’t exist. So what is the minimum amount of changes that we could make because we’re just human beings and we don’t have a lot of time? What is the minimum amount of changes we can make to the schedule so that it can be workable and doesn’t stray too much from the objective we had for the day?”

The problem is that this logic, this kind of minimal effort logic, doesn’t work really well. That’s what people do because they don’t necessarily have anything else at their disposal, but it doesn’t work very well for a very simple reason.

Changing the plan a little derives from the idea that in a simple situation, those minimal changes will have minimal consequences because there is some sort of continuity or linearity in the amount of consequences compared to the amount of changes that you make. There is this sort of assumption, so you make minimal changes because that’s not too complex and you hope that it’s not going to have a lot of consequences.

The problem is when you’re talking about scheduling, you’re talking about rearranging potentially tens if not hundreds of different activities that each come with their own constraints and attached variability. So the idea that there is any link between the magnitude of the change and the magnitude of the impact is, let’s say, sort of delusional, unfortunately.

However, the human mind is limited because it cannot even try to estimate the general impact, so it will try and limit to minimal changes hoping that it will have minimal impact. But the one thing that is absolutely assured is that even if your initial plan was a good plan or even close to an optimal plan, the moment you make changes, you have absolutely no guarantee that your new plan is even remotely close to a new optimal plan. It’s just a plan that happens to work.

Conor Doherty: Let me try to mirror it back to you, and you can correct me if I’ve misunderstood because it’s a really interesting point. Earlier, I talked about Simon and Conor being absent and needing to work on engine A. Let’s just say Joannis, with a pen and paper or an Excel spreadsheet, says, “Oh well, Max, our engineer who’s also our videographer behind the camera, actually has the skills that Simon and Conor have. I’ll just pull him away from what he was going to do. Yes, he can work on engine A. Problem solved.” So, I just move one person, simple.

But is it possible that doing that actually introduces outsized consequences? Because with the same amount of time that Max takes to work on engine A, he could have done tasks 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 on engines B, C, D, E, and F, and those in combination have a greater financial return than just working on engine A, for example?

Simon Schalit: Yes, the example is absolutely correct. What people need to keep in mind is that you have to carry out those tasks in a certain order. So if one task is not done, the problem is not just that this task is not done, but that everything you had planned that was supposed to happen afterwards under the condition that task A was done cannot happen.

So if you pull someone from something else and say, “Do task A,” you’re going to be able to do B, C, and D. But the problem is this person was supposed to do something else, which is not going to be done and also will have cascading consequences. You have this sort of butterfly effect, and what’s very hard for a human is to say which butterfly effect has the biggest impact financially and which option should I go for. That’s really hard, even when you’re in a very small and not so complex environment. If you’re taking that to the scale of a big MRO activity, thinking that you can do something that’s going to be close to optimal is just ridiculous.

Conor Doherty: I want to be very careful about how we come across here because the message is not that people are dumb. My understanding of this, having gone to MRO conferences, is that we’re dealing with very smart, very talented people. It’s simply that it is unreasonable to expect a very smart engineer or an entire group of very smart people to rework an incredibly intricate sequence of events, each step of which has financial impacts, multiple times a day, every single day, for a multi-billion dollar aeronautics company. That is an unreasonable proposition. Your proposition is not to do that but to do something else?

Simon Schalit: Yes, you’re correct. It needs to be stated that people have been doing that for a good reason. First, because there was no alternative, and also because they relied on the assumption that, yes, of course, problems happen. There are situations where you’re going to have to reorganize everything, but it’s not going to happen too often. For the rest of the supply chain in general, yes, it doesn’t happen too often. But in this particular context, it happens every day. That’s the issue. That’s why humans will be overwhelmed, not because they are incompetent or dumb, but just because humans are not wired to handle this problem.

So how we propose to do it differently is, of course, to have a machine, a computer, do that, an algorithm. It’s not new. This type of organization problem has been tackled by computers for some time now, especially with the rise of computational power in the last few decades. The problem here is that you’re in an incredibly complex context, as I said, with a very intricate sequence of events. Each event comes with a complex bill of resources, dependencies, and uncertainties.

Traditional ways of tackling that usually don’t work in a very satisfactory manner and, even more importantly, don’t work fast enough. That’s where the problem is. If you ask a computer to solve a problem like that and if you build a good enough algorithm, chances are you’re going to have a good solution if you dedicate enough time and computational power to that particular problem. It’s going to be hard; a lot of solutions just don’t get even to this point, but you can do it.

The problem is that the situation you’re in is Monday morning. The workshop needs to start working if they are not already because it’s usually, let’s imagine, Monday morning. They need to reschedule everything because such and such parts are missing and this and this person are missing. You don’t have a few hours ahead of you to solve the issue; you have a few minutes because you need to get a move on. Every minute counts, and in aeronautics, every minute is expensive. So you need to solve that problem within a few seconds or a few minutes maximum, and it’s a very pressing matter.

That’s where it becomes really difficult. So what we’ve developed is an algorithm that’s going to allow us to solve that problem in a good enough manner. It’s impossible to prove that your solution is going to be optimal, but at least a very good solution compared to other solutions that you could find, and where you can prove that financially speaking, you’re going to have a very good solution within a matter of minutes. Our clients usually can be quite stringent on the number of minutes that we have to solve the problem.

The idea behind it, I’m not going to get into the details of the math and computers, but it’s about using computer capacity and relying on the fact that what you’re looking for is not the solution itself but how you structure the solver that’s going to be able to solve the problem within a few minutes. Actually, that’s sort of a meta problem. It would be very interesting to talk about that for hours, but we don’t have that time now. The crux is that you don’t want to find the solution; you want to find the solver that’s going to find the solution based on the previous ideal solution that you have had time to calculate during the night or when you had more time.

Conor Doherty: From the client’s perspective, they want the solution, they want the new sequence generated as quickly as possible. I just want to dig down a little bit on a point that you made there because from the perspective of managing expectations in this conversation, we’re not presenting the idea that you will always have in six minutes, I think, or three to six minutes, you said you can regenerate an enormous schedule of operations for, let’s say, repairing an engine to reflect the new state of the bill of resources.

In terms of managing expectations of what that means, you’re not saying that this is perfect, that if you spent 10 years thinking, you wouldn’t come up with a better one. It’s simply this is a good solution that reflects what is available now and manages your financial risk.

Simon Schalit: Yes.

Conor Doherty: Doing this new sequence of events with these available resources results in a specific outcome financially.

Simon Schalit: Yes, okay, that’s exactly what we do and what you want as well because that’s something that is necessary. You not only want to regenerate one schedule, you also want to give your clients the possibility to change reality in a way. That’s what you would call a “what if” scenario.

For example, if one person is absent for today, we’re going to be late. I can find a good solution, but the good solution I find still leaves me one person short, so it’s not going to be better than what I had with that additional person. Everything is going to be slightly late. So, I want to give my client the possibility to generate a scenario where he says, “Okay, I was one person short today. I need to make up for lost time. Perhaps I could add someone on top of my regular schedule tomorrow or perhaps open for one additional day where the workshop was supposed to be closed.” I want to know what would happen, how much time would I gain if I were to open on a Saturday, for example, where the workshop might be closed on a regular basis.

So, you want the tool to be able, of course, to simulate what’s really happening because that’s probably what you’re going to do today, but also want the client to be able to simulate a “what if” scenario where they integrate the sort of emergency measures that they could take right now. But it’s important for them to understand what would be the consequences of these emergency measures because these emergency measures are called that for a reason. You don’t resort to that kind of thing for your regular activity because they cost money. They usually cost a lot of money. That’s why you don’t use them on a regular basis.

Conor Doherty: Example like AOG prices to source parts at the last moment.

Simon Schalit: Exactly, it’s like if you have one part missing and it’s going to cause a work stoppage, the price that you’re willing to pay for that particular part can be sky-high. It’s something that is, of course, true in the aeronautics industry and it’s something that is very well known in the automotive industry, for example. They’re ready to ship parts that are missing at an astronomic price.

Conor Doherty: Because the financial cost of not shipping at all is even greater.

Simon Schalit: Exactly. So, what you want is to give the client an estimate of the gain so that they can factor that in when considering the cost of that emergency measure and make an informed decision on whether resorting to that emergency measure actually makes sense from a financial perspective. They need to know that to take the decision and document that to defend that decision within the company. Because when you resort to costly emergency measures, you’re going to have to answer for that to your boss or to the company in general.

Conor Doherty: Again, I want to be very careful with language here. You have mentioned “what if” emergency scenarios, but earlier in the conversation, you talked about the perception of emergencies and how that’s somewhat skewed. People’s understanding of what constitutes an emergency is a bit naive perhaps. So, could you just tease those apart?

When we’re talking about producing or repairing an APU or manufacturing an APU, we’re talking about lots of parts, lots of tools, and many people. If you’re talking about manufacturing an entire plane, even more so—half a million parts, hundreds of tools, possibly hundreds of engineers and technicians. So, when we talk about emergencies, like an element of the bill of resources is missing, given the scale of resources we’re talking about, is “emergency” the correct term to reflect something that surely happens quite a bit or is at least probabilistically very likely?

Simon Schalit: Yes, well, there is one thing that we need to understand. If we’re talking about aeronautics, aeronautics is by nature or by design a very risk-averse industry for very good reasons. The problem is that in supply chain, every decision you make, without exception, is a bet. You’re betting that the future is not going to be too different from what you expect it to be. You place your bets based on this assumption.

This bet can be risky or not risky, and we could go into this metaphor of the bet where you want to act more like the casino rather than the player. But in essence, the important part is that when it comes to scheduling, the context that we were talking about, the bet that you’re placing on the future is extremely complex. The idea that the future is going to fall into place exactly as you expected or rather as it was planned is not realistic. It’s not going to happen the way you plan.

Conor Doherty: Forgive me for cutting you, but just because that’s a nice point. When you say, for example, to repair an engine, I need 100 parts. On Monday morning, I need 100 parts, I need 10 tools, and I need five engineers. That is the future that I am planning for. How likely is that? Please go from there.

Simon Schalit: Yes, you’re going to plan all your resources based on the assumption that those resources are going to be there. You planned a sequence of events that in theory should fall into place. But given the sheer number, this sort of curse of dimensionality, it’s not going to happen. We took the example of 100 parts at 99% service level. You already see that the probability of things actually all being there at the right place at the right time simultaneously is less than 40%. So, it’s not going to happen.

The problem is that since companies are risk-averse, the reflex they have is to say, “Okay, if 99% service level is not high enough, I’m going to go higher.” When you’re talking about parts, what you mean by 99% service level is that you’re going to place orders for parts to arrive earlier, even earlier, just to account for the variability in the lead time—the time it takes for the parts to actually arrive. Because that’s the main uncertainty you have for parts.

So, you’re going to take more and more buffer until you go from 99% to 99.9% service level. Except if you need 100 parts or more than 100 parts, the amount of money that you would need to be able to get to a combined service level that would be satisfactory is just something you can’t afford. So, the traditional approach of saying, “I’m going to push the service level to the point where I’m going to be comfortable and that will guarantee that I can enact the plan that I’ve come up with,” is not necessarily a valid way to work.

Of course, you’re going to need high service levels because that’s aeronautics. But what you’re going to need is a way to change your plan in the most efficient and cost-efficient way that guarantees that the new plan you have to come up with on the fly is the best plan that you can devise based on the information that you have. In fact, that makes a very big difference compared to just wishful thinking that things are going to go according to plan and having humans every morning without the correct tools trying to devise a new plan.

Conor Doherty: So again, just to collapse that down, the argument that you’re making is that when you take it—and we’re not going to get too deep into the maths—but from a purely mathematical perspective, when you plot out or simply list all the physical parts you need, all the physical tools you need, and then all the abstract skills or physical people needed to be present for completing a sequence of actions, and then you also consider that none of these things happen in isolation. I mean, you don’t just repair one engine and then these people go home. They work on something else. There’s an interconnected nature to all of these sequences.

So, when you arrive on Monday morning, mathematically, the likelihood, the probability that something will be missing is much, much higher than people either realize or want to realize. The financial consequences of that, like literally every single second that you move around trying to figure out what to do next, where to go, who’s here, what’s available, etc., working, sending Excel spreadsheets—all of that has immediate significant financial consequences. Have I understood correctly?

Simon Schalit: Correct, and I would also add that it’s the time you lose rearranging the plan and the time lost by following a new plan that is anything but optimal. Usually, this second part is not as painful because it’s a bit harder to quantify, but it’s actually very, very costly. You have to imagine that when it comes to MRO or aeronautics manufacturing activities, every minute counts because every minute is a segment or a fraction of an additional plane that could come out and go fly, whether it’s a new plane or generating money. So even a small increase in the efficiency of your capacity to make new plans on the fly can have a tremendous impact from a financial perspective.

Conor Doherty: It occurs to me as well, and you just said that, just made a note. We’ve been talking largely about the direct implications, like the immediate direct consequence of the person missing is, well, that part of the engine doesn’t get repaired. But indirectly, there’s the knock-on effect not only to the other processes because a lot of the time, let’s be realistic, these don’t happen in vacuums. You go from one to the other, or this part is then added to this part again. The BOM subassemblies make the larger parts completely. But there’s also contractual obligations that have to be considered as well. I mean, if you fail to return a plane back into circulation, depending if you’re an MRO, that has financial consequences as well.

So there’s direct, there’s indirect, but again, the key takeaway here is there are hundreds if not thousands of decisions that go into an optimal or a very good schedule, and each one of these decisions has a financial impact. And when they go wrong because something’s missing, and apparently it’s very probable, even if it doesn’t happen tomorrow, it’s still probable that it will happen the day after or the day after or the day after. This carries financial costs.

Simon Schalit: Yes, and actually in practice, let’s be very practical here. In the day-to-day work, what I’ve witnessed in those companies is that the exercise of making a new plan is so time-consuming and so hard that the workshop will focus on only the problem that they know about today. They don’t have time for anything else. So what happens is that the next day, new problems exist, like old problems that still haven’t been fixed, plus new problems.

But if you look at the details of the new problems, half of them you could have known about the day before. They could have been predicted. But in practice, what we’ve witnessed is that people are so focused on the problem they have to solve today that they don’t necessarily have the time or the intellectual bandwidth to be able to anticipate the problems of the next few days, which can make the problems bigger and bigger over time and usually leads to accumulated delays in MRO activities or manufacturing activities. So the contractual breaches in their contractual obligations, of course.

Conor Doherty: Again, that’s a really good point because just like the processes don’t happen in isolation, the externalities or simply the consequences of actions are not in a vacuum. So again, the accumulation of the backlog and by extension, the accumulation of the financial impact just continues in the background, whether or not you’re willing to acknowledge it, think about it, or act on it. Or even if you do act on it and you think, “I’ve solved that problem,” in the background, because there’s a variable that you missed, because again, I’m human, you’re human, we’re humans, the ledger, the bill, the meter is still running in the background. You might not even know that it’s happening.

Okay, well, let’s push on a little bit because in terms of the details of scheduling optimization as we see it, we’ve talked about the inventory aspects of the parts, tools. When you talk about the skills, are you simply—let me rephrase this question. The decisions as we present them to clients, is it simply, for example, take that part, that tool, and send Simon over there to work on that engine, or is it a bit more nuanced than that?

Simon Schalit: Well, it’s going to be a bit more nuanced in the sense that usually it comes with a whole set of complexities. Basically, the output would look like a set of recommended allocations for materials, parts, and equipment with a planning. This part needs to be allocated to that plane or that engine. This particular equipment needs to be used by that plane or that engine during this time segment. And then this particular person, who has this particular skill, needs to be allocated to that particular engine or plane over this period of time. The system needs to guarantee that we do not violate any of the constraints that are set for each of the tasks that we’re going to place.

In terms of complexity, if you’re talking about parts, usually that’s quite simple. The part is allocated to a task because it’s part of the bill of material, and that’s fine. Of course, you need to have the parts, which is not guaranteed. So usually, you can swap whenever possible, but you decide when to allocate and you try to allocate at the last minute possible to avoid reallocation. But that’s the simple part. Oddly enough, that’s the one people will focus on the most because that’s the one they usually feel they have most control over.

But for the allocation of people and equipment, usually they come together, it becomes a bit more complex, especially since there are tasks that require not just one skill or not just the skills of one person, but perhaps different skills from different people at the same time, whether it’s for technical purposes or just safety purposes. Just operating a crane when you’re moving an engine in the middle of the workshop requires at least two people, just for security reasons. One who can operate the crane and the other one who’s just there to make sure that we’re not doing anything wrong and that the way is clear. At the very minimum, that’s what would happen.

So you can’t think of all those resources, especially skilled resources, as completely independent entities. That would be too easy. More often than not, you want to think of them as coming with constraints where they need to be available at the same place at the same time for the same task. And you have a choice where tasks can be done by one, two, three, four people at the same time, not at the same time, in sequence, or not in sequence. A wide array of different types of combinations where the algorithm simply needs to find which is the best valid solution, considering that while you’re consuming those skills, they are not present elsewhere.

That makes the problem quite difficult. To do task A, if you need two people, you need them to be available at a certain time. So whatever they were doing, they need to finish at approximately the same time so that they can both be available to move to that particular task. And that’s actually not trivial because more often than not, one of those is probably going to be waiting for the other one to finish, and that costs quite a lot. So you want to avoid that as much as possible. Every minute counts. Those skills are worth a lot of money.

Conor Doherty: Okay, and again, to someone listening, it might sound like magic. I’m aware of that because what it sounds like you’re saying is what Lokad now does is, we’ll just focus on the scheduling. We’ve already discussed inventory, we have other materials on that. We can tell you, take this, make sure that this part and this tool is at that place at that time, and that Simon goes there and works for this amount of time starting at this time and ending at this time. Is that what you’re saying?

Simon Schalit: Yes, that’s pretty much what we’re saying. But in fact, if you take the problem as a whole, there are, I’d say, two elements that separately from one another could be considered like that are not easy and, in fact, borderline impossible for a human being to do right without the help of the computer. There is the bets part, like understanding the consequences of your bets, and there is the arrangement part, the rearrangement part, the planning part.

On the bets side, it has to do with understanding the strategy and making things about money. A very simple image I used a bit earlier: humans, when they have to place those bets, will rely on their knowledge, their gut feeling. Basically, they will act as a player in the casino with all the bias that comes with that and all the emotions that come with that. If recently they’ve had a problem with a part that caused a big disturbance, chances are they are going to over-purchase, over-buy, put a very big buffer on that part because they were burned on that particular one. That’s a bias.

The machine, if fine-tuned correctly, will follow a strategy exactly like the casino. Same bet, same game. One follows a strategy and wins; it’s the casino. One doesn’t follow a strategy, or at least not a documented and consistent strategy; that’s the player, that’s the human being. In our case, the casino wins. The casino always wins. It’s not magic. It’s understanding that there is, even if it’s hard to calculate, an optimal strategy, and you don’t want to deviate from this optimal strategy.

So on this particular part, it’s not magic. It’s making sure that we get from the people’s minds, from the people who are actually good at this business, the key strategic ideas and we translate them into a strategy within the computer. That’s what a supply chain scientist does. It’s not magic. It’s a consistent process of building the strategy.

The rearrangement, it’s not magic. Again, it’s a combination of computational power and a few mathematical tricks. Computational power is accessible to most people, especially if you use cloud computing the way we do. But we’re not the only ones; definitely, we’re not the only ones. A lot of people have access to even more computational power, way more than we do. But used correctly, you can solve that problem plus a few tricks.

However, those tricks are not purely mathematical. They are a combination of core mathematical aspects but applied in a way that takes into account the actual form of the problem. Yes, you could put that in a very big general solver, let it run for hours, and hope that you get a good solution at the end. Probably, it’s not going to work, or even if it does, it will take way too long. What you want is to make sure that the mathematical approach is going to be tailored for the type of constraints, the type of structure that is specific to that particular kind of problem.

Conor Doherty: Well, what I wanted to follow up on is a key point, which again ties into a broader message that I feel needs to be underlined about what Lokad tries to do. You said you might have, let’s say, a practitioner at the client company who obviously has great insight. The goal is to get that information and fold it into the strategy, let’s just say the decision-making process, which is the algorithm that produces the decisions.

The reason for that is, sure, I think you would agree, and correct me if I’m wrong, on any one choice or decision, a really skilled person could be as good or even better than an algorithm, than an automated decision-making process. However, when we’re talking about the scale of complexity when it comes to repairing an entire plane or a fleet of planes, possibly hundreds of thousands of parts, hundreds of tools, hundreds of people, the idea that a person will be able to make all of those decisions at scale better than an automated decision-making process is just unreasonable. That’s the adjective I use: unreasonable.

Simon Schalit: A person or even a team.

Conor Doherty: A team, exactly.

Simon Schalit: The human mind is not made for that. And I’ll take this opportunity to address something like this sort of duality between computer and human. If I were to use the buzzword AI, it’s simply a tool. It’s a tool, nothing more. The real challenge when we build those algorithms is to extract the knowledge from the human mind. What I like to say is that the human mind is extremely good at strategy, but at a tactical level, at a more granular level, it gets lost.

It gets lost because of the sheer number of things, and it gets lost because beyond a certain number of variables, especially if they are non-continuous, non-linear, you might be the best mathematician in the world, but you’re not going to solve that in your head. That’s not possible. It’s not a matter of who you are; humans just can’t do that. It’s beyond what you can do without the tool. But humans are incredibly good at strategizing at a higher level, understanding the financial consequences of things.

Ultimately, they are the ones to decide in which direction the company should go, how important it is for the company to be able to service its clients in a certain way with a certain reliability compared to the cost. They have an idea of what those numbers are. The problem is that they don’t know that they have an idea. They have gut feelings, and those gut feelings have led them to say, “I want high service levels.” If you were to ask them why they want high service levels, they will say that it’s important.

One of the main things that a supply chain scientist needs to do is to make them explain why it’s important. If it’s important, it means that you think your cost of being out of stock is high. Let’s go further. What does it mean, high in dollars, in euros, in financial terms? Once you’ve extracted that knowledge, you can use that to implement the strategy, the optimal strategy that I was talking about, optimized in the sense that it will make the optimum decision considering the strategic information that it was provided.

In this case, it will output the sequence of actions and the allocation of resources that is best suited to achieve the goals that were stated at the strategic level. That’s what the computer does. It doesn’t invent anything. It doesn’t render humans useless, but it will do what the human mind cannot.

Conor Doherty: Perfect transition. So, on that note, previously, I’ve attended MRO conferences and trade shows. One of the templates that we have for our posters in a booth is a hand directly above a paper waste bin, a basket, and it’s just dropping pieces of crumpled paper into it. On these pieces of paper are certain terms, and we adapt it depending on whether we’re at a retail or aerospace event. At this event, we had FIFO and Min-Max, Safety Stock on the pieces of paper falling into the bin. It’s a provocative thing.

Obviously, people come up, and if they get it, they comment on it. But also, it works because if you don’t actually know that we’re kind of critical of these concepts, you come up and say, “Oh, hey, I’m interested in that. Can you tell us more?”

Simon Schalit: Yes.

Conor Doherty: Now the fact of the matter is a lot of people really like FIFO. That is the one that we heard the most about. When you talk, you mentioned earlier about having solutions in emergencies that work fast. It’s critically important to work fast. So, the question, if I were to represent someone who just disagrees with you, they might say, “Well, I already have a heuristic. I already have a general decision-making solver, a very low-fi solver that works super fast in real-time, and that is FIFO, first in, first out.” What would you say to that?

Simon Schalit: Well, FIFO is definitely an algorithm that has been around for a long time. It’s, in fact, I would say, our biggest competitor on the market. The problem with FIFO is that, yes, it works super fast, and yes, it’s very easy for human beings to grasp because, I mean, first in, first out, what’s more straightforward than that? Also, the good advantage is that it seems to make sense. If something came in first, you want to deal with that first because that’s probably the one where you’re most likely to be late if all things considered, everything is equal and should take the same amount of time.

However, as with a lot of dated concepts in supply chain, not necessarily bad, just a bit dated, it relies on a few assumptions. The first assumption is that you are in a simple environment. What do I mean by that? If you work using FIFO, it’s first in, first out. The assumption is that every engine, every plane you’re working on, if we’re still in aeronautics, is perfectly exchangeable. In the sense that they are the same financially from the point of view of the company, from the point of view of strategy, they are just the same. From a risk management perspective, they are all the same. Being late on one or being late on the other is the exact same thing.

Is it true in reality? Absolutely not. You have different clients, you have different types of planes, so it’s not going to be the same thing. One day of delay on one of them is not the same thing as one day of delay on another one. But even if it were, let’s imagine a perfect world where you only service one type of plane with one customer.

The problem is that the efforts that you’re going to have to put in to solve the problem that you face on one aircraft or one engine is not necessarily the same and probably not the same as the effort you need to put to solve the problem on another. Even if the engines are the same, the bill of repair, the things you need to do on those engines, is not the same. Even if it were the same, the parts that are broken within those two are not exactly identical. That’s part of the uncertainty you have when you open an engine. You discover what’s broken, what’s corroded.

Conor Doherty: I didn’t know that was going to be there.

Simon Schalit: Exactly. So saying that, “Oh, I’m going to focus on engine A because it came before engine B,” doesn’t really make sense. Chances are, even if you were to dedicate all your effort to engine A, it would take you a lot of time to actually fix the problem. While perhaps on engine B, you can fix it very quickly.

Yes, you could say, “I’m still making progress on engine A,” but if you finish engine B, it’s out of your workshop. So you have room for another engine to come in, you have room for this engine to be inspected and know in advance what you’re going to need for it. You’ve serviced one of your clients, so potentially you’re going to get money for that earlier, which is going to help you finance the rest of your operations.

So you’re going to have consequences attached to the order in which you do things. Each minute invested in the different activities doesn’t have the same value because it doesn’t have the same consequences. It doesn’t unlock the same potential.

FIFO is completely oblivious to that. FIFO is a simplistic vision of your repair or manufacturing chains. Don’t get me wrong, it’s not bad. Among all the solutions that you could use without the appropriate tools, that’s probably the best or at least one of the best. But if you think about it, you don’t want to oversimplify the problem, especially considering the financial consequences that are at stake.

Conor Doherty: Of course. And again, we’ve taken a deliberately trivial example there just to illustrate the point. But of course, it’s not just two processes. Fixing engine A and fixing engine B are two separate schedules or sequences. There’s usually far more. So you have to tabulate in your head or with an Excel sheet or just using the solver. You have to account for a lot more. And the point there being that the costs are nonlinear. They’re not necessarily the same, and you have to be mindful of that or have something that gives you insight into the financial implications of working on this versus working on that.

Simon Schalit: And of course, there is the simple allocation problem where you have engine A and engine B, and they both need the same part. If engine A is older, by default, you would allocate to engine A. But if for some reason engine A needs five different parts that are missing, while engine B only needs that one part, there is a very good case to be made that the part should go to engine B. Because that’s the only thing that’s missing. It can go, while the unique part that you have, if you put it on engine A, it doesn’t do anything because there are still four other parts missing. FIFO is oblivious to that.

Conor Doherty: Well, again, and I do want to underline quickly a point that was made earlier. Where possible, I think it’s important to signal what our positions are. And I’ve certainly never said this publicly or privately: applying FIFO is not dumb or naive or anything like that. In many cases, again, it is the human mind approaching the problem and often using the best available tools. In the absence of arguably superior tooling, people default towards what is at least understandable and what at face value appears to work.

My understanding based on this long conversation is the base value diagnosis is often very limited in terms of financial scope. What I mean by that is, “Oh well, the engine is out, that’s financial value that has been added, or value has been added, that thing is done.” And a key insight that you seem to be explaining today is that there are both direct and greater indirect financial considerations that, let’s be honest, the human mind is just blind to by nature. You talked about the nature of design. By nature, it just can’t comprehend at scale the often nonlinearities and the external financial consequences of decision making. Which brings us back to using automation, using a supply chain scientist who’s capable of extracting this information and converting it into a repeatable decision engine.

Simon Schalit: Yes, well, our position on this is quite clear. The future of decision making in supply chain is all about automation. And the more complex the contexts, the more important it becomes. For us, that’s just where we’re heading.

Conor Doherty: To wrap up, for people who are listening and have heard some incredible claims, incredibly precise and consequential claims about what can be done, to someone who still thinks, “Simon, what you’re describing is far-fetched, it’s magical, it’s impossible,” your 30-second response to that as a concluding thought?

Simon Schalit: Well, it’s already happening. It’s something that has been happening for the past few years, and that’s the direction supply chain in general is headed towards. Automation at scale and automation at lower and lower levels of granularity. Why? Because we have the computational power and, thanks to supply chain scientists, the concept and the role of supply chain scientists. We have the capacity to bring the necessary data and information, strategic and financial information, to the algorithm, to the computer, so that the strategy that is applied at scale is the one that is designed by humans and can be optimized toward that goal.

Conor Doherty: You also mentioned before, in response to a very similar question, actually, I can’t remember what the context was, but you said on this topic, people’s incredulity or people not believing that it’s possible is surprising considering this is effectively what people are trying to do in real time. So any person, again, a key decision maker, key stakeholder, on a Monday morning needs to revise the schedule because Simon and Conor are absent. What they’re doing in real time is what we’re describing using a computer, using algorithms. They are essentially the same process. You’re looking for an optimized solution. So it’s not magic, it’s just the technological intervention on that process.

Simon Schalit: Yes, they are doing it by hand. They are doing it in a very painful way, let’s say. Painful for them and to some extent painful for the company because they are not getting to an optimized solution, not because of lack of skill but because of lack of tools. And so what we’re bringing is the tool that is necessary to actually replace the human element that is deficient at a granular level and keep the human element that is ideal, which is the strategic level. So we combine the granular level of the computer and the strategic level of the human.

Conor Doherty: Simon, thank you very much for your time. I have no further questions. It has been a pleasure.

Simon Schalit: For me too. Thank you again for your time and thank you all for watching.