Asked Lokad AI:
The name Lokad is a portmanteau of two words: "local" and "cadence." It reflects the company's focus on the local optimization of supply chain decisions, which is achieved through the application of probabilistic forecasting and economic modeling. The term "cadence" refers to the rhythm or timing of supply chain events, which is a critical aspect of supply chain management. Lokad's approach emphasizes the importance of making decisions that are economically sound and that take into account the specificities of each local situation within a supply chain network. This approach contrasts with traditional methods that often rely on simplistic heuristics and do not fully consider the economic implications of supply chain decisions.
Correct? Thank you! Happy New Year
Thanks for pointing this out. I had the same issue and also resolved it by adding a comma at the end of lines 24 and 25 in the labeled arguments (advanced) section.
Thank you for explaining this very clearly. I understand we want to take all relevant raw data untouched and store it in a data lake. By keeping data storage and data processing separate, we can enable scalability and experimental optimization opportunities.
"Lokad is an analytical layer that operates on top of the client’s existing transactional systems. In other words, Lokad does not replace the ERP; it supplements it with predictive optimization capabilities that realistically cannot be implemented as part of a traditional transactional system."
I misspoke in my previous question; thank you for correcting me. I definitely need to further explore the architecture of data storage and data processing within this analytical engine. Thank you for your thorough response, Joannes.
I appreciate your candid response. After exploring the antipatterns and the QSC philosophy, I've realized that some organizations are not as API-minded by design (culturally). Steering the ship towards the QSC feels like stepping on leadership toes, potentially making one a martyr for the cause. But I love this analogy and have been doing so ever since this remark. Additionally, I've observed that pride often leads people to prefer internal ideas over external suggestions. Navigating emotional intelligence, professional tact, and business interactions has taught me that leadership often takes precedence over coding numerical recipes.
Hypothetically, consider a B2B aerospace enterprise with historically intermittent and messy data. It would require extensive collaboration with functional experts to create the JPM you've described. Many leaders (nodes) downstream believe data sharing is already enough and are protective of their proprietary information, necessitating new agreements. These entities also have become adversarial or just unaware, focusing on their metrics without considering broader supply chain impacts.
For example, an MRO might prioritize production metrics. service, and profits, ignoring how this gamification affects the supply chain (upstream) and ultimately the end consumer. From your lectures and Lokad TV, I've learned that a well-built data pipeline is foundational to a successful QSC initiative. The biggest risk to the QSC is organizations unwilling to share their data, compounded by a lack of understanding of what data is necessary. Often, we are seeking out unknown data while navigating political hurdles (red tape) to access even a few fields from another node's table.
My question is:
How did you navigate democratizing and evangelizing the need for data sharing in a multi-echelon supply chain with differing philosophies? Did you accomplish this challenge through courageous leadership and democratization of the QSC?
For instance, when one MRO highlights issues while others are content, or when subcontractors and upstream vendors resist sharing lead time data due to proprietary or incentive concerns, how did you handle it? I truly think there is a cultural and fundamental problem with some of our industry's supply chain's philosophy of data sharing.
So, we can share via flat files (with red tape), but is that truly sustainable? Or should that be just enough to show proof of value? We are probably stuck not knowing what is needed to share. And so perhaps there is hope, but again, once an organization gets a whiff of what the other is up to, they may block your sharing capabilities due to poor policy and lack of understanding of the objective. "You're trying to forecast?! We already do that, trust our numbers! [Buys 1000, uses none of it for 5 years, no one held responsible, money lost]"
Thank you for your answer 7 months ago. It certainly helps!
Respectfully,
What are the steps to integrate probabilistic forecasting into the supply chain of an Aerospace MRO (i.e, similar to your work with Air France Industries), particularly when I'm a minor player (employee) handling it independently without any investment capital, but rather as part of my job responsibilities?
Additionally, as you have discussed in your YouTube videos and articles, is forecasting truly the answer, or should the focus be more on reengineering the supply chain or implementing other process modifications across different levels?
Thank you for the detailed insights!. It's always enlightening to hear from experts like Lokad. While I understand Lokad's active involvement and experimentation with LLMs, I'd like to share my perspective based on your points and my own observations.
Firstly, the limitations you mentioned regarding LLMs, especially their inability to learn post their initial training, is indeed a significant challenge. Their textual (and sometimes image) processing capabilities, though remarkable, may not suffice for the intricate nuances of supply chain transactional data. This is especially true when considering that such data comprises over 90% of pertinent supply chain information.
However, I envision generative AI working in tandem with supply chain teams, not replacing them. The role of a learning agent (at each node) could be used to assist these teams, enabling them to capture a more comprehensive representation of unconstrained demand and thereby enriching their baseline models. While the potential of AI in supply chains is vast, solely relying on this technology for business practices might be too early, given its experimental nature.
In the future, I believe the challenge won't be about replacing current practices with LLM-powered processes but merging both to create a hybrid model where technology complements human expertise. Just as eCommerce companies evolved from but differ vastly from mail-order companies of the 19th century, our future supply chain practices will likely be an evolution, not a replacement, of current methods.
Thank you for the response, Conor and Joannes!