00:00:00 Introduction to the interview
00:00:47 Paul Jan’s background and teaching experience
00:02:16 Data’s role in supply chain and teaching
00:04:00 Collaboration with Lokad and its impact
00:06:20 Real-world supply chain challenges and teaching hurdles
00:10:49 ‘Wicked’ problems in supply chain explained
00:14:37 Company messaging’s impact on product perception
00:16:11 Continuous data analysis and Excel’s limitations
00:19:11 Handling relational data and Excel’s shortcomings
00:21:49 Transition to SQL for data processing
00:24:11 Benefits of introducing Lokad to students
00:26:33 Teaching cost considerations in supply chain
00:29:13 Use of Envision and critique of enterprise software
00:32:24 Solution thinking and tool limitations
00:35:16 Better tools for better supply chain solutions
00:37:57 Joannes Vermorel’s teaching experience and philosophy
00:41:15 Fundamental data structures and forecasting limitations
00:45:31 Visual teaching methods and strong assumptions
00:48:32 Need for disruption in supply chain industry
00:51:12 Supply chain as a collection of wicked problems
00:54:24 Being approximately correct in supply chain
00:57:55 Teaching wickedness in supply chain
01:00:47 Final words and importance of private sector investment
01:03:24 Overcoming fear of statistics and closing remarks
Summary
Conor Doherty, host of Lokad TV, recently engaged in a discussion with Joannes Vermorel, founder of Lokad, and Paul Jan, a supply chain professor at the University of Toronto. The conversation centered on the evolving field of supply chain management, the role of data, and the importance of education. Vermorel introduced the concept of “wicked problems” in supply chain, highlighting the limitations of Excel and the need for tools like SQL Server. Jan shared his experience transitioning from Excel to more programmatic options, praising Lokad’s tool, Envision. Both emphasized the need for industry disruption and the importance of education in supply chain management.
Extended Summary
In a recent interview, Conor Doherty, the host, engaged in a thought-provoking discussion with Joannes Vermorel, the founder of Lokad, and Paul Jan, an Associate Professor of Operations and Supply Chain Management at the Rotman School of Management. The conversation revolved around the evolving landscape of supply chain management, the role of data, and the importance of education in this field.
Paul Jan, with his extensive experience in consulting and corporate America, has been teaching operations and supply chain analytic courses at the University of Toronto for about four years. His courses, which include a foundational class on operations and supply chain management and a class in collaboration with Lokad, aim to bridge the gap between theory and practice. Jan acknowledges that while data has become more prominent in the industry, students often lack confidence in applying what they learn to the real world. This is where Lokad’s collaboration comes into play, providing a ready environment for students to work on supply chain tasks, allowing them to focus on the supply chain aspects rather than the technicalities of setting up a coding environment.
Vermorel introduced the concept of “wicked problems” in supply chain, which are problems that defy direct, first-level analysis and require a journey of discovery. He highlighted the limitations of Excel in handling modern supply chain data, stating that it does not scale to the extent required by today’s supply chains. Vermorel suggested that Microsoft’s answer to this issue is SQL Server and other tools that handle relational data. He also mentioned that Lokad’s playground aims to expose students to the reality of relational data.
Jan shared his experience of transitioning from Excel to more programmatic options, agreeing with Vermorel’s points about Excel’s limitations. He mentioned that he learned SQL in one of his projects and appreciated its power in processing and simplifying data. Jan also praised Envision, Lokad’s tool, for its simplicity and ease of use, which has helped simplify the process of adjusting assumptions and reduced errors that could occur in Excel.
The conversation then shifted to the mindset required to use these tools and whether understanding concepts like opportunity cost is taught in class. Jan responded that while the concept of opportunity cost is not straightforward, students with training in economics can understand it. He noted a gap between what executives and operational folks understand and pay attention to, with the former focusing on financial bottom lines and the latter on traditional metrics.
Vermorel agreed with Jan’s points and discussed the limitations of thinking within the Excel paradigm. He explained that if Excel is the only tool one can think of, it limits the solutions one can imagine. Vermorel criticized the perception that digital technologies are constantly changing and that knowledge in the field is disposable. He argued that many fundamental subjects, like relational data structure and basic data types, are unlikely to change significantly over time.
The interview concluded with Vermorel and Jan emphasizing the need for disruption in the industry and the importance of education in supply chain management. Vermorel explained that supply chain management involves a series of complex problems due to the interconnected nature of modern companies. He argued for the use of paradigms and tools that can handle these complex problems, rather than seeking exact solutions that may be incorrect. Jan, on the other hand, described his teaching approach as both gradual and disruptive, starting with traditional theories before introducing real-world complexities through collaboration with companies like Lokad. He acknowledged the difficulty of teaching about wicked problems, which are complex and dependent on the actions of others.
Full Transcript
Conor Doherty: Welcome back to Lokad TV. The skills required to excel in supply chain have evolved dramatically in the last 20 years and will continue doing so for the time being. None of this, of course, is news to today’s guests. Joining us remotely from the Rotman School of Management, Associate Professor of Operations and Supply Chain Management, Paul Jan. Paul, welcome to Lokad. Thank you for having me. It’s great to be here.
Now Paul, I said, welcome to Lokad, a bit of a misnomer. I mean, we’re already very familiar. You’ve collaborated with us for a while and in fact, you visited us here in the new offices in Paris. But for people who are not familiar with your work, could you give an introduction, describe your background, please?
Paul Jan: Thank you for having me. My name is Paul Jan. I’m currently a professor at the University of Toronto, teaching operations and supply chain analytic courses. I come from an industry background with extensive experience in consulting and also in the corporate America industry. I’ve spent the last 15 or so years in both the industry and consulting, and now I’m teaching, sharing my knowledge and experience with all the students here at UofT.
Conor Doherty: And how long have you been teaching at Rotman School of Management?
Paul Jan: I’ve been at Rotman for about four years, and before that, I was with the University of California, Irvine. So in total, I’ve been teaching for about seven or so years.
Conor Doherty: And how have the courses on supply chain evolved even just over that short time frame?
Paul Jan: Here at Rotman, I teach a foundational class, which is an introduction to operations and supply chain management. That’s where students learn the foundational theories, the applications, and some of the practices. I also teach another class which is in collaboration with Lokad. That is to take those theories and practices and put them into action with a company. Over the years, there are more and more data that exist from a company’s ERP, and even from midsize to smaller businesses, they all have some sort of a data capture or ERP system. So data has become more prominent, and students, from what I observed, they lack the confidence and experience in how to apply what they learn in school to the real world.
Conor Doherty: Well, and Joannes, I will come to you in a moment, but I just want to follow up on that because you do have extensive private sector experience. When you’re selecting the foundational theories to teach students, how much of that is traditional supply chain knowledge and how much of that is influenced by your extensive experience?
Paul Jan: In the foundational class that I teach, I don’t have a lot of room to deviate. I need to follow a syllabus and the requirements set forth by the university and the department. So most of those are the traditional theories and models that a student will learn. What I do is I supplement those with anecdotes and stories or things to watch out for as a supplement to the students when they go into the workforce. But as a requirement from the school, the foundation is the traditional theories, which is what they will learn in that class. In the other one, in the collaboration with Lokad, I have the freedom to apply more of the teaching from a practitioner’s point of view. So in terms of being aware of realities, being aware of the financial bottom lines, which from a financial perspective, the foundational traditional theories don’t account for that. But in practice, executives will be looking at the financial impact of doing XYZ. So that is the difference between the two and how I apply my experience to these different classes.
Conor Doherty: Well, thank you, Paul. And now Joannes, to come over to you, could you describe what exactly the collaboration is with Paul as part of Lokad’s broader education initiative?
Joannes Vermorel: Yes, at Lokad, we started an initiative about a year ago to make our technological stack more broadly available. Lokad comes normally as an enterprise piece of software, which is only accessible to our VIP prospects and clients. What we have done is to repackage that as what we called a playground, which is a slightly simplified version of Lokad accessible at tr.lo.com. This gives access to a coding environment powered by Envision and a small file system. In terms of educational purposes, the idea is to have a series of workshops where students can actually take a data set that is a simplified version of what is found in actual setups but still fairly representative. We didn’t want to make the task too easy and too theoretical. The idea is that we can provide a ready environment where the student can directly start with a data set and a small challenge of a supply chain task that has to be executed on top of this data set. This reflects the sort of challenges that people can have when they enter a company where there are problems with suppliers. You need to analyze and figure out who the suppliers are who are not able to deliver on time and in full, or you want to forecast the demand or any other of those supply chain analytical tasks. The idea is that Lokad wanted to provide an environment to do that. The reason being that students who study supply chain materials are not software engineers. So yes, if you were asking a classroom full of future software engineers to do that, they could take the time to set up a Python environment, to set up their own data pipeline and parsing logic and whatnot so that they can actually work on a data set using open-source technologies. The problem is that considering the timeframe that we have for students who are not software engineers but actually supply chain engineers or future supply chain engineers, we need to have an environment that is ready for a workshop that is primarily about supply chain, not about the intricacies of how to parse a CSV file in Python. So that sort of thing needs to be readily prepared, and that’s what we can do with this environment. We share an environment where the data has already been prepared, the script that reads the data is already written, so they can directly jump into the meat of the problem, which is to figure out what to do with a supply chain, with a supplier, with the demand, and apply supply chain reasoning through a programmatic tool. Our ambition is to let those curriculums that are typically very light in terms of technical tools do things that are more advanced but without being completely bogged down into pure technicalities. So bottom line, we provide an environment that could be replicated no problem in 5,000 lines of code of Python. That’s very much doable, but the problem is that if you do that, then suddenly you cannot expect to do a fruitful three-hour work session with your supply chain students. You will be doing a three-hour pure coding session where you will just figure out how to parse a CSV file, which is not very interesting from a supply chain perspective.
Conor Doherty: And Paul, just a follow-up on this. How challenging are these engineering skills like coding for the average foundational level supply chain student?
Paul Jan: I can give you a real-world example where we started the semester here a couple of weeks ago. I would just say maybe 20% of this new class has some sort of prior coding experience, but in that, they had taken, for example, Python in a classroom setting before. So the majority has not. So when they come in, I think they’re excited because they realize that this is a skill that will benefit them in the future since a lot of things are there, a lot more data, and Excel just is cumbersome when it comes to analyzing such a large amount of data. So coding helps simplify this process. But at the same time, they’re also a bit scared, worried because they don’t have the experience. It’s a very important skill now, but it’s also something that’s lacking in the training of business students, not just supply chain alone but business students in general.
Conor Doherty: Well, thank you. And that actually transitions perfectly. Joannes, something I’ve been waiting a long time to ask. You’ve described in the past in your lectures, you’ve described supply chain problems as being wicked. So two parts of this question. One, what exactly do you mean by wicked problems in supply chain? And two, following on what Paul just said, why are tools like Excel just not equipped to deal with these wicked problems?
Joannes Vermorel: The notion of a wicked problem doesn’t originate from me. It’s essentially problems that defy direct, first-level analysis. It’s something where it has to be a journey, no matter what, where you will discover the problem itself.
An example of that is, what is a good ad? If I ask you to calculate the surface area of a geometric shape in square inches or square centimeters, the shape might be very complicated, so the calculation might be difficult, but it’s a closed problem. There is an analytical solution that will give you either the exact answer or a very good approximation.
But if I ask you about what is a good ad, the answer really depends, and it also depends on what your competitors are doing. For example, if you create a fantastic ad, but then your competitors copy you so much that your ad, which was brilliant, has now become indistinguishable from all the competition, it was a very good ad but it became a bad ad just because everybody had copied it.
That’s the sort of wickedness. The very answer that you give can potentially undo the answer itself. It’s kind of weird. I give a very good answer and because it is a very good answer, it is copied and because it is copied, it becomes a bad answer. That’s a sort of wicked problem.
Supply chain is full of wicked problems. You decide to put a distribution center somewhere to outcompete somebody else. This somebody else decides to replicate and respond by rearranging their own distribution centers to outcompete you. That’s the sort of thing.
So things are not stable. An answer is not stable. These wicked problems are problems where they are competitive in nature. There are people that respond to what you’re doing. This is not like the problem of calculating the surface of a geometrical shape, which is a problem where the answer does not depend on what the rest of the universe is doing, what other people are deciding. This is well isolated.
And then you also have problems where you’re not even sure that you’re framing the problem correctly. What does quality of service mean? Yes, we can say that quality of service is about increasing the service level, but the reality is that quality of service is in the eye of the client and what does it even mean? It’s a very difficult question.
For some people, they might think that if there are substitutes, it’s okay. They are not expecting this one product to be available. Maybe if there are substitutes, they’re okay. Some other people might disagree. They might have a very narrow conception of what they actually need and they say, “I want exactly this barcode or it doesn’t work.”
And then, depending on the messaging that the company has, the broader communication, you might actually amplify or diminish whether people see other products as substitutes or not. If you have a communication that says this thing is completely unique, there is no substitute whatsoever, then don’t be surprised that people are not even willing to take other of your own products as substitutes because that’s your communication. That might be good against the competition, but that can be more challenging if you want to convince people to accept alternatives.
Situations are incredibly varied. So, the bottom line about these wicked problems, and that’s a typical thinking of Lokad, is that usually when you have these wicked problems, it’s better to iterate over the problem with data as opposed to operate without data.
No matter the question that is being asked, like is it a good ad, it’s easier to answer this question if you can measure the sales and correlate a little bit with your advertising spending, for example. It doesn’t mean that it will solve the question entirely, but you will be more informed as opposed to just trying to answer this question without any data.
Usually, even if you’re dealing with a wicked problem, having data around helps. The problem is that due to the wicked nature, you need to be able to revise your position on what sort of analytics and processing it means that there won’t be a one-for-all answer. You will process the data and then you will think and then you will maybe ask a slightly different question depending on what is happening.
So, wicked problems, that’s where we come in. When you’re facing a wicked problem, having data is good because it lets you be more informed, which is generally better. But it also means that you will need to repeat your analysis from time to time because there will not be a definitive answer.
Excel is good in this respect. Excel lets you revise your analysis as frequently as you want. The problem is that Excel does not scale to the extent that modern supply chains require. Nowadays, we are talking about tens of thousands of products, millions of transactions, a lot of transactional data. Excel is just not suitable for that.
The key challenge is that modern supply chain data exceed what can reasonably fit into Excel, and it exceeds in two ways. First, it exceeds in the number of lines. Excel is limited to one million lines. But this part is not actually the big problem. In theory, Microsoft could re-engineer Excel a little bit and make it extend to 100 million lines. That’s not impossible, and actually, there are a few competitors of Excel that can do that.
But when we say a modern supply chain exceeds, it’s that fundamentally, Excel has a one-table-at-a-time mindset. It assumes that data is like a flat one table. But the reality is that the transactional data as found in a supply chain is multiple tables. You have a table for suppliers, a table for transactions, a table for clients, a table for products, a table for colors or shapes or whatever.
So, you will very frequently end up dealing with at least half a dozen tables. And so what you’re lacking is something like a relational algebra, which is really at the core of your transactional data. Your data in supply chain is transactional and relational. You have like half a dozen tables, and that’s where Excel really doesn’t work.
Not only do you have this constraint on the number of lines, but this could be fixed. But more generally, you have this problem that you’re limited in terms of semantics. Excel does not give you this multi-table thing.
And by the way, this is due to this reason that is much more profound that Microsoft isn’t even really bothered into expanding this 1 million limit. The people at Microsoft know, and they have known for a long time, that even if they can expand to 100 million lines, the next stage will be, “Oh, we need several tables,” and then it’s not going to work very well with Excel.
That’s why the answer from Microsoft was, “If you want relational data, you have SQL Server, or you have tools that take relational data as a first-class citizen,” as opposed to trying to have that into a spreadsheet. And by the way, this is also something that we’re trying to do with this playground, is to expose students to this reality of relational data by offering a language that has relational data as a first-class citizen.
Because that’s something that I believe is not going to change. Forty years from now, ERPs will still have tables and columns. This thing was established four decades ago, so it has been a very stable aspect of the digital supply chain for more than four decades already.
Conor Doherty: Paul, an interesting point to follow up there on because you have extensive background in the private sector and were formally trained in this field. When you were sort of coming up and developing your experience, I presume you worked with Excel. And if so, at what point did you say, “I need to consider richer, more programmatic options”? So, what caused the divergence from Excel?
Paul Jan: The divergence is what Joannes alluded to before. Excel is great, you know, it’s one kind of one table at a time, and it’s very cumbersome to link all these tables or tabs within Excel. And even if you’re successful in doing so, it’s also another very time-consuming task if you need to change your assumptions, variables to double-check all the changes that you have made in Excel.
You often run into errors. You almost often make mistakes at the end because you forgot to change this variable there or this assumption there, which caused the end result to look a bit different. So, I think it was maybe a couple of years in that I had the chance to learn SQL. I didn’t know SQL before, but I learned SQL in one of the projects, and I really appreciated the language and also the power that you can process and simplify, at least the first part, the finding the descriptive data, trying to find the anomalies within the data itself.
This simplifies at least the first part, finding the descriptive data and trying to find the anomalies within the data itself. Making sure the data is clean and finding ways to integrate different data sources together really simplified things quite a bit. That’s when I really made a transition. At the time, SQL became my first choice of analytic tools that I would go to process, or rather pre-process, the data to understand what the data looks like and if there are any anomalies. Then, I would do the first descriptive type of analysis from that, and Excel would be used more for the ease of visualization. Once that’s complete, we would visualize it easier with Excel by doing the charts and graphs and stuff like that.
I would like to add on to what Joannes mentioned about discovering Lokad. I also discovered Lokad a couple of years ago, but I did not take a similar initiative as the one that I took last year to introduce this to students. I was afraid, to be honest, that the coding aspect would deter students from using the tool and from enjoying or learning from the class. But I must say, I was wrong. Given the past couple of months of our collaborations, I discovered that Envision is a very easy to understand tool. Even with my programming and database background, it’s very easy to understand, and I think it’s also easier for students to understand because the codes can be read sort of like a layman’s language.
It’s different from, for example, Python and others where sometimes things may not make so much sense and they don’t follow one to the other without the explanation of someone who wrote the program. So far, it has been a very helpful exercise to introduce this. It really simplified the process of adjusting for assumptions, things that we may not have accounted for in the data, but to update that in the code itself and then reflect it in the dashboard for the student to see.
I still call this an introductory level. For students, it’s for them to understand from a high level, from a top-down standpoint, what a company is doing and how it is doing from these descriptive data such as the number of customers they have, the highest sales, the ABC trend of their product. From there, they can understand how they set up the supply chains, and then we dig deeper into their supply chain from there. So, having this program, this coding experience with Envision, has really helped dramatically from that aspect and also reduced the errors that we may make in Excel.
Conor Doherty: I’ll follow up with you, Paul, and then Joannes. So, welcome, it’s a philosophy question you’ll like. It occurs to me we’ve talked about the tools, so Envision is the tooling, but using or leveraging tooling comes with a mindset. As you just alluded to, something that is the foundation of what Lokad does with Envision is taking a purely financial perspective to supply chain problems and reducing dollars or Euros of error. This is a mix, I guess, of economics but it’s also a little philosophical, understanding well if I do this, I can’t do that, opportunity cost.
In terms of the mindset, understanding how to use these tools, is that something that you also have to teach in the class or do students just automatically understand, “Oh yeah, opportunity cost, I’ll just use this tool and it’s really obvious to them”?
Paul Jan: I wouldn’t say it’s straightforward obvious, but students have had training in economics so they understand what the tradeoff, the opportunity cost is. Even in the foundational supply chain class or operation class I teach here, we do introduce students to the excess cost, salvage cost, the different costs that may come with the decision that you make, how much to stock in terms of inventory and when. These are understandable and relatable to students once you explain to them that the way we come up with this financial bottom line is based on ABC.
In practice, these financial bottom lines are what we also try to quantify for executives on any sort of consulting projects. Executives understand that when you tell them this is your cost in dollars or opportunity in dollars. But for the supply chain folks, I would say, or operations folks, they are mostly driven by the traditional metrics, the turns, forecast accuracy. They understand but they pay more attention to that. So there’s a bit of a gap between what the executives understand and what the operational folks or at least they are educated or instructed to follow. From a student standpoint, introducing or explaining these concepts is not a difficult task.
Conor Doherty: Thank you, Paul. And Joannes, back to you. So again, building on what’s just been said, I perfectly understand why things like Python, SQL, and obviously Envision, our domain-specific language, can be unfamiliar to new supply chain practitioners. But the concept of scarce resources, alternative uses, the bedrock of economics, is more than a century old. So why would that aspect of the economic mindset be so different in supply chain circles versus, as Paul just described, it being intuitively understood in the classroom?
Joannes Vermorel: I would like first to bounce on the remark of Paul. When you were saying you were worried about using Envision, I think you were right. Just for the audience, my personal belief is that the vast majority of enterprise software is complete crap, literally complete crap. And purchasing software, I’m just looking at you. So it is understandably a very reasonable assumption to assume by default that it’s going to be pure crap and then be pleasantly surprised if it turns out to be not the case. But I think it’s a reasonable assumption. I firmly believe Envision is not in this camp, we did a good job. But again, I think it’s by default to expect that enterprise software is going to be very low quality, especially compared to popular open source projects. It’s a fair and very rational assumption to be made about the applicative landscape.
Now, the thing with this sort of mindset with the financial thing, and when Paul mentioned ABC as in activity-based costing, by the way, not ABC analysis course. The thing is, it is very difficult to think about problems if you cannot imagine the solution. So the thing is, when people say people want to think in terms of accuracy or service level, these are very classical metrics. The thing is, if all you have is an Excel spreadsheet, that’s pretty much all you could implement. Thus, if you can only think in terms of spreadsheets, then you have a struggle to go for those things because it needs you to think of problems. How am I going to turn all of that into dollars while you have a really hard time to think about the solution?
People often think of the solution first before the problem. It’s very hard to even state a problem without conceiving a solution first. You will first stumble upon an approximate solution and then, when you want to explain what you’ve done to somebody else, you will actually invent the problem that matches the solution. People instinctively imagine the solution first and then, in order to be able to communicate about it, they invent the problem.
Your capacity to think of solutions depends on the tools that you have available in your mind. If you have Excel in your mind, then all the solutions that you can think of are the ones that can work in Excel. This limits you to the paradigm of accuracy and service level because those are the sort of things that you can do in Excel.
That’s why it’s very important in foundational courses to familiarize students with better tools where they can think, for example, with tables and columns and concepts like SQL. The problem is not SQL per se, it’s the paradigm that you get with SQL - tables, filters, aggregations, columns, value types like strings versus numbers, booleans. These things are very important and suddenly, when you have these paradigms, you can think of classes of solutions that are more elaborate.
To think about financial indicators, you need to connect the cost of storage, so you need another table that will give you some assumptions about the cost of storage. You need to have the cost of stock out, so you need to have this information somewhere else. It’s not that people traditionally are incapable of thinking about the cost of storage or the cost of insurance, they know it. But when it comes to imagining a solution, if Excel is all they can think of, it’s very hard for them to think of a spreadsheet that will be able to plug those 20 different things in.
But if you can think with relational data, then suddenly you have the tools that let you think, “Okay, I’m just going to plug all those costs with as many tables as it takes.” And conceptually, if those costs are individually simple, it’s just a matter of aggregating all of that.
This is a long explanation, but it’s also why traditional supply chain management is very hesitant. They didn’t have the chance to get this sort of education where they can really think with more modern tools.
Paul Jan: I completely agree with Joannes’ assessment. If we were to do a competency assessment in any company’s supply chain operations, I think you’ll find a big gap in their understanding of what we just talked about. That’s really the challenge in educating this next generation of young professionals about a mindset to think differently and innovate.
Joannes Vermorel: I’ve been teaching for seven years, not supply chain, but distributed computing and software engineering. My philosophy when I was teaching at the Eon Normal Superior of Paris, where I had complete freedom to decide what to teach, was to focus on topics that would still be relevant four decades from now.
My biggest fear was to teach something that was just a fad, something that five years down the road you realized was just a technicality and is now gone. So, my approach was to always ask myself, is this something that will stand the test of time? That 40 years from now has a very good chance to still be a point of importance?
For example, SQL has been established as a standard since 1989. It has been evolving, but the bulk of it has not changed since then. The underlying model, the relational data, has not changed since the late 70s. It has proven incredibly successful, with virtually 99% of the ERP market using this relational data format one way or another.
People have the impression that digital technologies are changing all the time, that you have to learn something and two years from now it will be gone. I believe that’s a problem because it gives people the impression that this knowledge is disposable. It also gives a false impression to the management that they can bypass that and they don’t care because in two years it’s going to be something else.
If it’s done correctly, we have plenty of subjects that are very fundamental. Relational data structure would be one of them. The basic data types, text, booleans, numbers, were already like that at the end of the 70s. Even Python 3, the latest version, still has that at their core. It’s something that is very unlikely to change over the course of the next four decades.
Similarly, if we think about forecasting, the idea of how to think about the future, time series, what are the limitations of time series, what a time series forecast gives us, what it doesn’t give us, what this thing cannot give us by design, that’s also not going to change. The most basic sort of forecast four decades from now will still be a time series forecast per day, per week, per month, and the limitation of such a forecast will still be the same.
If I had to teach forecasting, instead of focusing on what is the best time series forecasting model, which is going to change, I would focus on the built-in assumptions that you have with time series forecasting, what it gives you and what it does not give you, and the dangerous limitations and how to think about uncertainty.
I understand it’s a very big challenge. Most university professors did not have the luxury that I had, where the administration didn’t care in the slightest about what I was actually teaching.
Conor Doherty: Paul, when you’re covering demand forecasting in class, do you get into probability distributions, understanding the uncertainty of the future?
Paul Jan: In the foundational class, we talk about it, and also in demand management, forecasting, and inventory management. But we make the assumption that the variabilities, uncertainties follow the normal distribution, which makes things a lot easier to teach.
However, in applying the probabilistic approach, which looks at the probability of variations throughout for a product, you can graphically look at that. People are visual, so they can understand why one product behaves differently than another.
This semester, I’m considering bringing some content from the upper class down into the lower class as a way to explain uncertainties and variations in a more visual way.
Joannes Vermorel: Making strong assumptions for teaching purposes is fine. I remember when I was at university, a physics teacher of mine would simplify calculations by assuming a cow was a sphere. Obviously, a cow is not a sphere, but for the sake of the exercise, it is reasonable to let students do a simplified calculation. This helps them experiment with the concepts without getting bogged down in the calculations.
However, in the supply chain world, people make equivalent assumptions, such as assuming demand is normally distributed. This is a teaching assumption that doesn’t hold up in the real world. Yet, enterprise software vendors go with that and hardcode these assumptions into their software. This is madness. It’s as if General Motors was hardcoding assumptions about spheres and passengers in their cars. People would think this is nuts. You should not do that for a real car that is going to drive on the real world.
Yet, bizarrely, supply chain software vendors say it’s no problem to have these assumptions hardcoded into their software. This is my reaction to the status quo in this industry, which I find a little bit nuts. There is a need for disruption. For some weird reasons, it seems that supply chain software vendors are translating these crazy assumptions introduced for teaching purposes directly into the software.
But maybe it’s not fair to demand that from professors. Maybe it’s the supply chain enterprise software vendors themselves that need to come to terms with reality.
Conor Doherty: That’s something I was just about to ask. From Paul’s perspective at the Rotman School of Management, it’s his responsibility to teach these concepts. But for Lokad, a supply chain software vendor, why is education such an important thing? Why focus on this so much?
Joannes Vermorel: Supply chain is a collection of wicked problems due to the fact that we are putting together all the forces of the companies. By definition, the supply chain is gluing the company together, so it means that we are putting sales, production, transport, marketing, finance, everything together. This is not a simple proposition. Modern companies operate over many countries, so not only do you have sales versus marketing, but you can also have France versus Italy versus Spain.
Supply chain is a series of wicked problems by design or by the very nature of supply chain connecting together a lot of conflicting interests inside and outside the company. We need to think in terms of paradigms and tools that let you embrace these wicked problems, even approximately. People instead of going for the approximately correct, they go for the exactly wrong and they double down with a lot of numerical recipes that are way more precise than they ought to be.
Conor Doherty: We’re winding down a bit, but I want to pitch it back to you. Joannes’ conception of supply chain seems deeply philosophical to me. When we talk about first and second order problems, it’s almost like Wittgenstein. I’m curious, do you take a similarly deeply philosophical approach to supply chain? Does administration even let you? On day one, do we need to rethink the whole sphere of supply chain philosophies? Is this the sort of thing you tell students, that we need to rethink the wheel completely, or is it more gradual?
Paul Jan: It’s gradual and also disruptive. In university, as a student is learning, they start with the foundations, then some intermediate supply operation management class, and then they come to a more advanced class that I’m teaching this semester in collaboration with Lokad. They gradually learn traditional theories and applications. But then the disruption comes when in this class, at least in my experience, I don’t know how to teach students the wickedness in supply chain without them experiencing it. That’s why we work with a company. We handle real data and think with a tool. They see the wickedness, the uncertainty, and realize that things they learned in the prior year or two classes can’t be applied straight away. You can do it, but it may not make sense.
So, it is a philosophical question. And by the way, this is an open problem. If you go to the Wikipedia page on Wicked problems, all the disciplines that are facing this sort of problem, where a good or bad answer to a problem statement depends on what other people are doing, are incredibly difficult to teach. It’s not specific to supply chain, there are other areas where it’s just incredibly difficult.
Joannes Vermorel: There are even areas where, for example, we had a guest recently about trading on public markets, where if you even reveal how you do it, you undermine your own solution and your own revenue stream. So secrecy is paramount in these sorts of things. If you understand something, you should professionally not talk about it because if you do, people will use that against you.
But my take is that Lokad will keep trying. We’ll keep trying to support the good universities who are, like the University of Toronto, trying to go in this direction. We don’t expect any solution, but any step taken in this direction is already something better than just pretending it doesn’t even exist.
Conor Doherty: Exactly, approximately correct. Well, Paul, it’s customary here to give the last word to the guest. Is there anything you’d like to tell people about or advise your students on for finals?
Paul Jan: No advice on finals yet, but I would like to go back to Joannes’ comment about why private sectors are investing in education. You invest in lectures, articles, and blogs, and I do appreciate that. Many of these students, after they graduate, turn to vendors, suppliers, and websites to find information or to understand what supply chain management is, or to refresh their memory.
For example, statistics is a very fearful subject for students. So, not just assuming everything’s normal makes things a lot easier because it takes that fear away. But if you have real substance to substantiate different behaviors, then they may be more willing to learn to overcome that fear. After university, your information becomes more accessible to them, so it becomes a reinforcement in getting us out of this mindset that we can apply the same solution to all the different wicked problems.
Conor Doherty: Perfect. On that note, I don’t actually have any more questions. Joannes, thank you for your time.
Joannes Vermorel: Thank you very much for yours and for your ongoing collaboration.
Conor Doherty: And thank you all for watching. We’ll see you next time.
