Name: Gurdip Singh, Chief Product Officer of Blue Yonder
Uploaded: 2025-03-27T17:00:00.000Z
Duration: 44 min 38 s

Clips

Gurdip Singh

CPO

Blue Yonder

play_circle_outline Supply chain applications vs traditional apps

play_circle_outline Importance of alignment of objectives and uncertainty management

play_circle_outline Use of statistics and machine learning for scenario evaluation

play_circle_outline Enhancing Operational Efficiency Through Multi-Variable Scenario Analysis and Real-Time Data Optimization

play_circle_outline Transition from exception-driven planning to data-driven insights and continuous improvement

play_circle_outline Use of agents to augment human operators in decision-making process

play_circle_outline Role of semantic network architecture in harmonizing data for analytics

play_circle_outline Implementation of AI agents to guide less experienced planners

play_circle_outline Infusing personas in user experience for personalized recommendations

Info

Gurdip Singh, Chief Product Officer of Blue Yonder

Gurdip Singh

CPO Blue Yonder

>> We are with Gurdip Singh, chief product officer of Blue Yonder, a leader in supply chain management. Gurdip is here to explain how Blue Yonder represents the prototype of the intelligent data application of the future. This is more than data products. This is about integrating analytics to drive mission critical operational applications, and specifically Blue Yonder builds on relational AI to up-level and harmonize supply chain data in Snowflake as well as legacy applications so companies can plan, simulate, optimize, and align their activities from top-level corporate goals, down to low-level activities like what to pick, pack, and ship to fulfill an order. We're going to start by talking about what supply chain applications are and how they're different from traditional applications. Then we'll go into how these supply chain applications do planning simulation optimization to align activities. And finally we'll get into the platform technology. So with that, let's get into the interview. Gurdip, good to have you here.

>> Thank you for having me, George. It's a pleasure.

>> Okay, so now explain how are supply chain apps different from enterprise apps, the ones that we've grown up with, ERP, CRM, and even traditional supply chain applications. What's new about this generation?

>> Right, so I'm going to date myself a little bit, but paradoxically, the way the supply chain solutions industry grew up was very much in silos, and those silos were both a function of the technological limitations on the one hand, but also perhaps a more limited view of what supply chain meant to enterprises. What has happened certainly in the recent past, certainly since COVID, but even prior to that, with the advent of e-commerce and the explosion of shopping choices for customers, what used to be a fairly stable objective of supply chains, which was to minimize the cost of fulfillment to the customer, has suddenly now to be almost equally managed right alongside the objective of how do you make supply chains not just efficient but actually resilient. And so in some very fundamental ways supply chains, which supply chain solutions from the '90s and 2000s and 2010s even, which were originally designed much along the lines of ERPs with the standard and pure architecture and the traditional way of exchanging data between business processes fell far short of the need to reduce the latency of decision making, not just at corporate, but frankly decision making at the edge in the warehouse where automation is now infused and robots are working side by side with humans to finish the activity that's required. So fundamentally certain things have changed and supply chain applications have had to evolve to deliver and meet the need that's out there. The most fundamental thing, George, is it was okay in some ways for supply chain applications to be very focused on just the data that they needed to make or execute a decision, not worrying about what was happening in the prior process or in the subsequent process because there was the time and the latency to deal with it. All that has gone and now the expectation is that not only are the processes interconnected, but they're actually interoperable and that decisions that are made in one function are optimal for the entire objective of the organization. So the objective is to meet the customer need without the excessive cost, but also be sustainable. Then that entire cost, that entire objective has to be taken into account whether it's planning, warehousing or transportation, and they have to interoperate in a very fundamental way. That's what's changed.

>> Okay, so let me see if I can distill two themes out of that. One is the alignment of objectives across functions and time scales, and that's something that we haven't really been able to do before because there was a level of integration that wasn't really possible. But the other is dealing with uncertainty and the uncertainty could come from two things. One, there's an event and that scrambles plans and requires replanning and then realigning all that activity. But the other thing is dealing with uncertainty as a first-class citizen where every plan has uncertainty baked into it. Now maybe you could elaborate on that and how that manifests itself in the application and in the management practice that goes with that.

>> It's a great observation, George, and I think this is very akin. If you think about the evolution of physics almost, it's very akin to how Newton's laws work just fine when you don't get to the atomic or the subatomic scale. But when you try and manage events and activities with that minimal latency, what works just fine architecturally and from a design principle's perspective goes away and that uncertainty becomes the first-class citizen like you called it. Let's talk fundamentally about what that means. What that means is if in the past it was acceptable for a supply chain operator to imagine the two or three things that they need to do in a given day to react to a disruption that was sufficient and the systems were enough to do it, the technology was enough to do it, you could potentially even duplicate the data a couple of times and rerun all of the actions that you might to get to the final outcome. But when you have events coming at you literally at the speed at which the business is occurring, and it's not just an event in a warehouse where perhaps the inventory is no longer exactly what you expected to receive or from a supplier where they're unable to deliver the product on exactly the date you needed or perhaps a pricing change that's now shaping the demand quite dramatically differently in the marketplace because you're reacting to what a competition that the competitor is doing. All of that basically means that those one or two scenarios have now become hundreds of scenarios. And the traditional fundamental approach or basically saying, I'm going to go duplicate the data and rerun everything all the time has to go out of the window because no amount of computational capability and capacity and/or the ability to spend money is going to solve that problem for you. You have to do it much more smartly and you cannot come to solve that problem in an after-the-fact manner. So almost like how quantum mechanics within physics takes a different approach to solving essentially the same problems, but for dealing with that inherent uncertainty in a very fundamental way, you now architect your solutions to essentially be able to account for the fact that every action that you might take as a corporation could lead to uncertainty in how the market behaves. And every response of the market is something that you take into account. And in doing so, you critically do not put the burden on the user or on the systems to replicate the data to imagine all the different business levers that have to be operated or even to figure out what the ramifications of a decision in one function are going to be on a downstream function three levels away. All of that is fundamentally what the architecture needs to now take care of.

>> Let me pause you there, and we've talked about how uncertainty, we've talked about it at an abstract level and we've talked about alignment of plans and activities. Now, maybe give us a concrete example where you have a set of North Star objectives that you quantify as corporate metrics, but then those form a tree of more and more detailed operational metrics that can be levers. Maybe turn that into an example where I create scenarios either with uncertainty or by turning leavers or both.

>> Sure. So let's first take this first step of stating most of for clarity purposes that uncertainty is not just on the sales side or in the supply lead time, but actually in every inherent constraint that the supply chain operates with. Let's take the example of a warehouse. At the warehouse, you can if you so choose, from a simplification perspective, say that you have a fixed amount of labor capacity or a fixed amount of machine capacity to support the labor needs that are out there. The reality is that you actually don't have that fixed capacity. You have a variable capacity because you can exercise the lever of overtime. People may not show up for a variety of reasons. And so what you think is a fixed number, a one number in the capacity that's at the warehouse is not. Just like if you think about the ability for you as a business to exercise the lever of price, it's true that you might have a regular price and a promotion price, but nothing prevents you from saying, I am willing to diverge from the promotion price in a particular region or a particular market if the market opportunity so dictates. And so I think it's important to first recognize that one number simplicity goes away at every decision and every constraint in the supply chain. So let's stipulate that because sometimes that gets lost in the conversation. But now imagine a situation where let's say you are, take a supply chain, which is pretty prototypical, a brand owner getting some products manufactured from a contract manufacturer, which in turn is getting products from a supplier. And this could be true in the high-tech space, in the auto space, in the pharmaceutical space, every single industry operates somewhat similarly or some variation thereof. Imagine for a minute that because of a disruption at a port, not just to the supplier of the contract manufacturer, but somewhere to the supplier of the supplier of the contract manufacturer, you now have a delay in the material coming available. When that happens, George, that is a need for the supply chain to respond to that delay. In a classical way, the expectation would've been let me go figure out how to create those one or two scenarios and the burden is put entirely on the supply chain operator. First, perhaps with the logistician before moving it to the warehouse and finally to the corporate planner that's making the commitments to the customers on how to deal with that delay. What you ideally want is a situation where the supply chain recognizes that this delay first has an impact to your business. The business impact is then calibrated in the context of how much should I actually be bothering to respond to it because not every delay or every impact is a problem, but let's just say it is. And then instead of putting the burden on the supply chain operator in each function to figure out what needs to be done, the supply chain needs to be able to take a step back and in some sense, in a multiverse of different options, run through every single combination of all the different choices you might have in the logistics network, in the warehouse, in the commitments to customers, in the pricing levers that you might have, for example, and come up with the right potential set of levers that you would want to exercise in order to meet the business objective. The intention of doing so though can only be correct if in exercising those levers, one is able to account for the fact that the demand is probabilistic, the ability to impact the price is not just a one-number change. It could change in different ways at different locations, the capacity is not fixed. And so if as a corporation I'm willing to bear an overtime capacity of up to 15%, then I should be able to exercise that lever, except it can go in increments of say 1%, 2%, 3% all the way up to 15%. And then similarly, I have the option to expedite or go to an alternate supplier. The combination of all those things is what needs to be evaluated and a good outcome needs to be concluded. And in doing so, we have to also make sure that we haven't disturbed anything else that might be going on in the supply chain that very minute because all these decisions have a real impact on what's happening in the supply chain.

>> So those scenarios that you described, it sounds like they have potentially multiple variables and multiple that they can move variables like what was a constraint like lead time, but it could also have probability in it. So who takes that bundle of variables and uncertainties and turns it into a scenario and then evaluates all those different scenarios to pick the best one? How is that done?

>> Great question. So clearly there isn't enough time in a day or enough humans in a company typically to run through those hundreds of different combinations that are out there. And so really the only answer is to apply the capabilities that have been developed leveraging advances in statistics and machine learning to go through the search space of all the different combinations in a manner that allows you to very quickly almost in real time identify the three different options that perhaps work best for you and serve them up as alternatives for the planner to select. So you are essentially then leveraging the power of the data and the power of the analytics that can be applied to the data to be able to deliver, I guess, the examination of all the different options that are out there instead of asking the human to go through and do it manually in a one by one manner. And I think that's a huge advance because it's essentially saying, I'm not going to be putting that burden on you Mrs. or Mr. Planner. I am leveraging the power of what's possible today to take away all of that tedium from you and then allow you to actually make the smart and intelligent and collaborative decisions that need to be made in order for that truth to come to bear.

>> Okay, so maybe let's turn that into a concrete scenario and then tell me about how frequently, one, how computationally expensive it is to do a fine grain set of scenario analysis and how fine grain that is, and then how frequently you would replan based on external events or just periodically deciding to, we're not going to do it annually, we're not going to do it quarterly, we're going to do it monthly, that sort of thing. How does this shrink the latency from changes in assumptions to changes in plans and execution or operational plans?

>> Great. So let's take a very concrete example because this is real. This is what happens in the real world in supply chain, virtually every supply chain. If you think about a warehouse, in a typical warehouse, the vast majority of the cost is really borne by the unproductive movement of labor and machines. And by unproductive I don't mean that they're moving around aimlessly. What I mean is they're not actually moving the product to where it needs to go, they're just trying to go from one place to the other. And so if you think about it, what it points to is that the root causes, we probably don't have the right products in the right place within the warehouse. This problem is generally defined as slotting within the warehouse. And traditionally for a variety of reasons, the way warehouses have been slotted is simply on the basis of how historically products have moved. And on occasion, maybe ahead of the peak season the slotting is redone or once a year the slotting is redone to gain the efficiencies that are out there. But in reality, the thing is that which products are going to be the fastest selling products, which products sell together so that you actually have them placed together so that you can pack them together, changes by month, by week, and even by events that occur. And what you need is a system that allows you to do this in a much more continuous manner. And so let's talk about that very extreme about what I mean by continuous out here. And so now what you have to understand is you are going from doing it once or twice a year to try and get to some average optimal value because that's the best you thought you could do to essentially saying, I'm going to evaluate where I need to be in the slotting problem from an actual placement perspective at any given point in time. And every time I have an opportunity to move a product for every pick or put away within the warehouse that's happening anyways, I'm going to take the opportunity to also optimize the slotting. And so instead of it being a decision that's made once a day, or sorry once a year or maybe just ahead of the peak season, twice a year, it's actually happening in every single move because you have the ability to actually nudge or influence and do the same big task except in small steps and without having any dedicated downtime to re-slot the warehouse. That's an example of in a fairly extreme way, how you can leverage the power of a data and intelligence to make these kinds of informed choices, giving the benefit that the warehouse wants and actually reducing the cost, improving the efficiency, but also doing it in a far more intelligent way so that the workers don't feel like they are having to take time off to go do an activity that's not considered very productive. So that's an example of that.

>> Okay. But just to make sure I'm distilling this properly, that would be where slotting has to fit into a higher level objective of let's say the throughput or the latency of fulfilling an order. But what you're doing is you're informing the tactical operational activities with that larger goal so that it's not taken offline to pursue that larger goal. It's informing the day-to-day implementation of the picking or packing or shipping?

>> Yeah, it's almost, George, like if I'm trying to lose weight, I can go ahead and set aside a half an hour, an hour for exercising each day, or I can just make it a point that I'm walking to get my lunch or I'm walking up the stairs and I'm accomplishing the same task in a way that does not even seem burdensome. And that's maybe a good analogy to outline that.

>> Okay. All right, so let's talk about, to distill, that's an example of trying to align activities across different timescales across different functions to serve higher level goal?

>> Correct.

>> Okay. Now let's talk about how these plans get smarter over time because you talked about how uncertainty is a first class citizen uncertainty built in, but as operational results come in, how frequently do you update the plans and how do you update the plans so that they get more reliable over time?

>> Yep. So for the longest time, I would say 30 years now, the industry has operated on this paradigm called exception-driven planning and execution. And all that meant was that if the metric that you were tracking in our prior example, the one about fulfilling orders in a timely manner, let's say that on-time in full metric was violated, then I won't get an exception. And then that exception would lead to a planner figuring out on their own what to do next, what is the reason that it's happening and what can I do to resolve it so it doesn't happen as much? What we are able to do now is because firstly we've tied these end-to-end systems together in a manner where the data is there for us to go do this kind of analysis, both the planning and the execution data together. What we're seeing now is it's great that you have an exception, but it's a little bit useless too because I actually didn't get any insight from it. What I mean by insight are two very specific things. What I mean by insight is it's great that I had an exception. Tell me whether that exception is perhaps persistent or pervasive in some manner, and perhaps more importantly tell me what the likelihood is of a particular set of root causes being the reason that that exception is occurring. And the reason that's important is because then I can actually guide, it's difficult when you think about how things happen in the real world where you can say, it's only this one reason or only that reason that caused this exception to occur. You do have a probabilistic interpretation of what might have happened and you want to serve it up, but you want to serve it up alongside a way to resolve that exception. And what you want to use is the human's validation and intelligence to say, when this exception occurs and this insight is served up, of the three probable root causes, this one seems to be the one, or these two seem to be the ones that the human says is most likely to be the cause, and hence takes the action to resolve the problem. That closed loop of using the data to serve up the probability of what might have been the cause, and then tracking very closely what the human is doing so that over time you're essentially able to eventually go back to the human and say, these are the three possible causes, but these two have a higher probability of being the root cause. And oh, by the way, this is the resolution workflow. Do you want me to trigger it for you?

>> Okay. All right, Gurdip. This is really good. But dig into this with a concrete example and where your knowledge of the semantics of not just the data but the supply chain configuration, the supply chain layout itself and all the operational activities they've been harmonized, how that helps you diagnose potential root causes and surface those for a human operator then to take action on.

>> All right, great. So let me come at that example that we had about the delayed shipment but in another way. Let's say that the metric that is impacted is on time and full. It's a common metric in supply chain. It basically says, did I get the order? Did I fulfill the order in the complete quantity and on time? And let's say that it's falling below my threshold and my threshold say was 90% or 95% and it fell below it. And let's say that was the exception that first got triggered. What should happen at that time is based on the fact that the on-time in full metric is triggered, I can probably go back and say it may have to do with the fact that the shipment came late, but you know what? It could just as well have to do with the fact that the warehouse doesn't have the capacity to process the shipment, which came in perfectly on time. Or it could have to do with the fact that I have an unreliable third party logistics provider that is such that I have buffered my lead time unnecessarily. So it is not even a real problem, it's just that in my systems I have buffered the lead time with a probability distribution that says this particular supplier, this particular logistics provider is unreliable. And so even though on average they take three days, the variability it says it could take up to seven. And so hence that's causing the problem. For me, it could be any of those things. What is, sorry, go ahead.

>> Well, so my question is to what extent, if you've got all this data harmonized, and in other words you have a rich representation of all the people, places, and things and activities in this supply chain, shouldn't the analytics most of the time be able to surface with a fair amount of confidence, which is the root cause?

>> It should be able to service which are the probable root causes. And then I think the challenge, and this is where the real world meets the digital twin that might exist, is for that particular movement, what has actually happened. Historically, I know what has happened, that's great. I planned it in a particular way, but for that movement, can I go out to that supplier and get a real-time ping either through a PLD device that the third party logistics provider is using all through some other means of an update that they might be able to provide to actually confirm for me, you know what, it's still three days, it's not seven, so I shouldn't worry about it. Or can I go to the supplier which is not controlled by me and get an ASN notification that tells me when is that product actually going to be shipped? And I think that ability to actually go between what is a digital representation or what is happening as well as what may be happening married to the ability to actually then extend into both within the four walls of the enterprise if it's your own or a third party, and get that notification, get that confirmation is what's critical. And that bringing that together then allows you to make the right kind of decision. Because one thing that I think is important out here, George, is we're still expecting the supply chain operator to be able to communicate, collaborate, influence, let's call it that, the ecosystem so that they achieve the objectives collaboratively. That is not something that we believe will necessarily just go away entirely.

>> So okay, now let's generalize from this diagnosing, let's say the analytics in the application diagnoses several probable root cause and ranks them by confidence, and there's then the judgment of the human operator, the judgment to choose from and maybe to explore some more. Now, how do you take these exception conditions as well as the ongoing operational results that come back in the form of data? And how do you then update the plans that were based on predictive models so that the probability distribution of these plans themselves gets tighter?

>> Yep. I think it starts with, we didn't talk about it much, but it really starts with having a true semantic network architect, a knowledge graph if you will, in place that allows you to very clearly articulate what that interconnectedness looks like both from a graph and a dimensional perspective. And it does it in the terms that we use internally, does it both from a static model perspective, which is to say where the locations and the lanes and the carriers might be. But it also does it from a dynamic perspective in the sense that both the plan data and the actual transactions that are being created as a result of things actually happening, whether it's in the network or within the four walls of the supply chain, that is brought back and superimposed on this semantic network architect model that's underlying it. That logical model, that logical construct of how things work then becomes the basis of how these analytics are brought to bear. And so as data accumulates, whether it's transactional data, say related to the lead time, and you are then saying that, you know what, my original assumption of this being an unreliable carrier can morph and change because I'm looking at the actual data coming in and my variability doesn't need to be set at that high benchmark like I had before. It can get tighter and tighter with more time. So that's the kind of capability that's out there. But the same thing is on other aspects of your supply chain, be it capacities, be it forecasts and demands, all of them learn from that variation between the prediction and the error. And as more data accumulates, the model tightens because you are able to use that data to make those kinds of predictions even better.

>> So let me try and distill and play it back to you. This semantic network architect or semantic network architecture, which is increasingly built on the relational AI knowledge graph. That's what provides what techies would call a type system for the application, the way to model the people, places, things and activities. And it harmonizes all this data so that the models might have a functional or very narrow and specific capability, but the models themselves are harmonized by this semantic network are architecture. And so all this data that comes in then is contextualized and updates the models and then all these models, their output is synthesized essentially and harmonized by this semantic network so that that's what organizes and makes coherent all this operational activity and then it updates the predictions and the plans.

>> That's right. And George, if you go back to where I started with how supply chain solutions were originally architected, a decade ago, even two decades ago, forget about the data and the compute, storage and compute wasn't quite separated, and so almost perforce applications were built the way they were. What we are able to do with the semantic network architect is not just capture the business relationships and the enterprise relationships and exactly the way you outline with resources and constraints and objectives all clearly defined and established for not hidden within applications, if you will. But actually the other thing that's happening behind the scenes is this very interesting change where I no longer need to actually have disparate data sources and different ways of storing information because the logical model serves it up for me in a manner that the analytics can come to the data. And so I don't have to have this notion of different applications being created that then have the whole latency and communication problem. It's a very core part of it as is the element of, hey, because uncertainty is a first-class citizen, it's very easy for me to use this kind of a construct and create without having to duplicate the data, leveraging the data cloud capabilities and stuff, now be able to say, I'm going to go create the perturbed data set for this other scenario in a matter of in a real almost instantaneously and keep that very true to that objective that we outlined of we are really living in an uncertain world. We need to deal with it upfront, not as an afterthought.

>> So maybe a couple forward-looking questions, now that you have this harmonized representation of what's going on in the enterprise across the data that is already in Snowflake. So that would be perhaps from other applications as well as Blue Yonder, and then you somehow have a proxy for external partners. When you have this, it's all in a common language. So how might you build agents that then augment human operators where the agents have special functionality, they've been trained or tuned for a particular task, but they can collaborate with other agents as well as other humans. How might that look?

>> Yeah, so this is the benefit that we didn't imagine when we first started this exercise a few years ago, to use your words, having this tight definition of what a digital twin looks like allows for us to create those persona agents, whether it's a corporate demand planner or a warehouse operator or a logistician in the supply chain to actually create these tight agents that are capable of acting on behalf of and with the associated degree of autonomy that a particular enterprise may feel comfortable allocating to the agent to in effect take care of all of what you would expect the planner to do, hey, I need to be able to understand what are the top 10 challenges I need to deal with today. I don't want to have the planner go through a hundred different dashboards and things like that to figure out what's going wrong. I need them to be surfaced and if there is a set of actions that I can take, I want to know if the agent can actually exercise it. Remember agent means someone with agency, someone with the ability to orchestrate. And so our vision first and foremost, George, is not one of an agent being a summarizing or a reporting agent, but really an actioning agent. And so for us, what we've worked hard to do is to say, you know what? Our Blue Yonder orchestrator, which is the underlying platform technology that we are leveraging, understands our semantic network architect created logical model and can operate on its behalf, can operate on the behalf of the user with the same understanding of not just data but actionable APIs that need to come together. And to your point about the collaboration across agents, I think that's something that is steadily evolving. There are certain things that are easier than others. So an agent that's focused on forecasting and demand management, collaborating with an agent that's more focused on supplier interactions and collaborating with suppliers is an obvious one. And there are patterns that we can expect to see emerge pretty quickly. I think on the other hand, we are certainly imagining a world where the entirety of the orchestration, imagine in the warehouse all of the different roles that are required, the non-physical roles, those should be possible as well. And you can even get into specialized agents that focus in on certain types of activities and we can go from there.

>> So just in the last two minutes that we have, what tools are you using to build those agents and then maybe a little elaboration on what a human operator working with that agent might look like, because the agents aren't really going to be presumably autonomous, they're just going to do a lot of the routine stuff and the higher level stuff will go to the human.

>> So let's start. So again, thanks to some of the early partnership we have with Microsoft. We did have early access to what Microsoft was bringing to the market and have the opportunity to work in fairly close collaboration with them. And we launched the Blue Yonder Orchestrator back in December of last year. And what that agent was focused on, George, like you correctly surmised was hey, it's very much around all of the mundane activity that you expect the planner to be able to do. But what we also were able to get it to do was truly serve as, imagine I'm an inexperienced planner and you are the experienced planner, but I don't have your benefit. But because the agent has been trained on much of what you would have done, we trained the agent on our runbooks of how we help companies run their supply chains. We were able to, if you will, leverage the available technology at the time, and this is almost a year ago now, so whatever was available then even to build out this agent that sat next to the less experienced planner and guided them in if you wanted certain answers, how you should go about doing things. So it went beyond the summarizing and analysis into, okay, I have this problem, what should I do?

>> So what I'm hearing is that you captured best practices and used that to up-level the less experienced planners?

>> Yes. And actually we even used it from our support functions because it's a very interesting experience in seeing how our customers are reacting to dealing with when an issue comes up for them, they now have the ability to actually interact with our AI agent and get a response that's in 80, 85% of the cases exactly what they needed to do without ever having to go and speak to anyone in our support organization. Fast forward to where we are right now, we basically said, okay, that was great. Obviously we've gone past the single technology to using the kinds of models that one would expect to use and not necessarily being tied to the one model that was initially there. That's something that we've done technologically. What we are really focused on right now is making sure that those personas that we talked about, the demand planning persona, the warehouse operator persona, those are infused in the user experience so that when you as a supply chain operator, let's say in the warehouse are driving into work in a, imagine on your phone that agent interacting with you, essentially giving you the summary of all the things that you need to be doing as a priority that day because those are the top actions that are required of you having done all the mundane work that it can. Or if you as a planner are expected to have a meeting, a sales and operations planning meeting in a week from now and it requires for you to have a certain presentation pulled together and/or certain conversations with colleagues, then let's go ahead and pull that content together. May not be the prettiest, but let's have all that content together and let's create what you need to have that presentation ready and good to go. So there are certain things like that that we can take care of that are coming. This is not that far off at all, George, in terms of what we expect our customers to be able to leverage.

>> Okay. Gurdip, I think we should leave it at that point because that gives us somewhere to pick up again for our future conversation. But this has been really interesting for me because we've taken an example of, our audience is very familiar with data platforms and the analytic artifacts you build on them, but you've built an intelligent analytic application that can operationalize those analytics and talk about the technology to harmonize that, why you need to use uncertainty and the ability to orchestrate and align activities on different timescales and even beyond the four walls of an enterprise. And then now that everything's harmonized, even how you can build agents on top of that. So I'll let you take us home. What's the last word?

>> Thank you, George. Firstly, it's been a pleasure having this conversation with you. I think it builds on what I know you've been focused on in terms of data apps and that evolution of bringing data and analytics together in a meaningful way going past what was possible even maybe just a few years ago. For us in the supply chain world, the last five years, frankly, like I said earlier, post-COVID has meant that we've had to rethink in some very fundamental ways what applications that were built a decade ago or two decades ago. And at Blue Yonder, we've been fortunate to, in effect, get the advantage of what a Snowflake, a RelationalAI and the Microsoft have been able to do and leverage them for the good of our customers and looking forward to having a future conversation where we can delve even deeper into how that progress has been made over the next few months.

>> All right. Gurdip, we'll leave it there.

>> Thank you.

>> Thanks very much.

>> Appreciate it, George.