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.