 All right, am I hot? All right, thank you. So let's go ahead and go to the next slide. And clicker, there we go. So as a reminder, this is what we entered with yesterday when Roy and I were introducing the business value of using some of these updates to Togaf within our company. And this is what I'll be walking through in a lot more detail today. On the left, I will introduce the update that has been made to Togaf and the associated guides in the ecosystem. And on the right, after I introduce each artifact and methodology, then I will show how we've applied it for a particular strategic transformation initiative in our company. And so with that, I intend to go relatively quickly so that Steve and I can spend a fair amount of time on discussion and questions that any of you might have about how this is done, exactly what it means and so forth. So with that, I will launch right in. You see a structure here you'll see for each area that we've added to the business architecture ecosystem in Togaf. A definition of what we mean by this methodology or concept, where you will find it in Togaf, the, what the concept is, and you see all those on the right in those bullets. So business models are meant to be a, as it says, a description of the rationale for how the enterprise creates, delivers, and captures value. The reason why we elevated business models from something that was originally in 9.1 brought up in phase B up to phase A is because we believe the more appropriate use for these methods and artifacts is a way for the architect to either understand business strategy in a fairly defined framework and approach, or in some cases, the architect may help the leadership to find the strategy into a specific artifact like a business model. So it is now introduced in phase A and we've elevated that to a strategic role as opposed to the operational level modeling like use cases, processes, and so forth. On the left of the slide, you see the business model canvas that is an approach to business modeling. It is not the only one. So in our draft business model guide that is out for company review right now, you will find a quick introduction to various types of business modeling and then we use the business model canvas as an example that you'll see next. So we are, that draft guide is out for review to become a serious guide as part of the TOGAP ecosystem. So here is a version of how we've applied that methodology in the context of sales and operations planning, one of our strategic initiatives to transform how we do business in my company. As a reminder on the left, sales and operations planning is about creating value for the organization through one baseline business plan, balancing supply and demand. Just like you learned in college or in somewhere in your career that all of economics is about balance of supply and demand, sales and operations planning is about a better portfolio or aggregated view for your company of balancing supply and demand. So you might remember yesterday, Roy highlighted that for our company Raytheon, one of our strengths is that we have over 15,000 contracts. So if one area of the business or the market goes down, others are always there and that's a strength. But can anyone guess one of our greatest weaknesses as a company, if we try to do aggregated demand and supply planning? You've got it, we have over 15,000 contracts. So that inherently means that programs, your profit and loss centers that are the holders of the contract are all individually driving resource demands into the supply base, the factories, the equipment, the manpower and so forth. And you're clearly not going to get optimized results of efficient use of your resources and your capacity if you have 15,000 different internal customers driving use of those resources. Sales and Operations Planning is a methodology that comes from the commercial sector that is about optimizing your supply and demand at an aggregate level. You have to have a better understanding of the aggregate view of demand coming over the three to five year horizon, roughly speaking. And then use the decision making process in the aggregate view of your data to say with that demand forecast, how do we best optimize our supplied material, our factory capacity, our manpower and so forth to efficiently achieve profitability for the company? So capturing that in a specific literal business model to describe what we mean by that at the strategy level is a useful construct. You see here for this particular version of the business model canvas that the customer or market segment side of it on the right is grayed out because Sales and Operations Planning is inherently an internal strategy. When we use the term business strategy, we're really talking about two distinct but related things. Most of our companies have a product and market driven strategy about how you're going to evolve and drive your offerings in the product and services. But we're also talking about an internal business strategy of how do we need to transform our company such as many of us are going through a digital transformation we're usually more talking about how we do business differently as part of our strategy for that part. Sales and Operations Planning is an internal business strategic transformation. Therefore what we're really shifting in the business model is on the left side. It's about your capabilities, your value proposition, what it's going to cost you and how you're going to treat your costs differently than before. So you see there some key highlights about value proposition, how is that changing? It's not changing the value of the products and the services we offer. It's changing the value proposition of how we optimally use those resources and doing more robust aggregate planning. It's about that reporting and forecasting as key activities. In a company like ours, we generated the forecasting in individual programs in the past across those 50,000 contracts. So looking at your forecasting as an aggregate view is a new beast. It's a new way of doing things. Therefore you are impacting your business model. You're impacting your whole strategic approach to planning for your company. Resource data integrity and having a sales and operations planning team are key resources. Your partnerships shift in terms of how you manage your supply base and then your cross structure shifts. You could no longer drive your investments in your allocation of factory manpower, your allocation of supplied material by each of those individual contracts. You need to do them at an aggregate level. So having this formalism of a business model helps scope the enterprise architecture effort and understand here's what the business value is that needs to be delivered. From there I'll go to business capabilities. So when you look in the TOGAP update, you will find a definition of particular ability that a business may possess or exchange to achieve a specific purpose. Let me step back for just a moment. In TOGAP 9.2 we made a distinction between capabilities as a generic term, which we're often used to refer to your ability to do architecting and the more specific term business capabilities about abilities of your business. So that is now introduced in phase A. The reason we started it in the vision phase is because right up in front of the vision, in fact a couple of people mentioned this yesterday, you want to establish does your organization or agency or business have a business capability framework. That framework, the description of the things your business is able to do and using the stratification I'll talk to here in a moment on the left is an important starting point to be able to do that kind of mapping. And you saw an example of that type of approach with the IBM brief earlier this morning. We then put it into practice in phase B. And so I'll show you an example here of that in the next slide. You want to know if your framework is there as part of your scope and your vision. You want to then put it to practice in phase B as you're doing your business architecture. Those capabilities allow you mapping to know what is needed before specifying how to do it. So business architecture in general should not be how you've operationalized or at least starting business architecture should not be how you've operationalized and implemented it in the current state or in the future state. You need to start with what is it we need to do and have that driven by your business strategy, your imperatives, your leadership priorities and so forth. There is also a TOGAF guide on business capabilities in the ecosystem. It is being taken from its original version as a TOGAF guide in the architecture forum and is now going through final review to be elevated to a series guide, meaning that it is part of the open group the open group ecosystem for TOGAF and not just inside the architecture forum. So to give you a couple understanding there on the left side, business capability should be stratified. That is the strategic core and supporting terminology you see on the left. So strategic as in outside anyone project or program or product that goes across your company, supporting as in your financial management, your information technology management and so forth that are supporting and core meaning your customer facing business capabilities. Here's what is unique to your type of company and what we offer. So that stratification is something you want and then you see on the top a level one map of business capabilities. What are the big categories in this case? I think it shows about 18 level one capabilities. That's just a starting place. It doesn't mean there's 18 for your company. It could be 10, 12, maybe even a little bit more than 18. But as a rule of thumb, if you start getting more than about that number, you're probably not talking about business capabilities anymore, you're probably trying to put processes into your business capability map, what you want to avoid. And then each one of those is decomposed into a level two, sometimes a level three or even beyond, set of capabilities such as HR management, you see there decomposed into performance, compensation planning, employee recruiting, and resource matching. So to put this into action, here's how we've applied business capability mapping for our sales and operations planning strategy. So you see a reminder there on the left of some of the things that drive your business capabilities which came from the business model. The left side of a business model when speaking in context of the business model canvas, drives where we need to shift some of our business capabilities. So a sales and operations planning approach of balancing supply and demand at the aggregate level impacts business planning, of course, that one's pretty obvious at the strategic level outside all programs, it impacts customer management and it impacts some of our supporting capabilities. To focus on one, let's look at operations management and decompose that a little bit. So for a company like mine, which is an engineering and manufacturing company, that operations management you see down there at the bottom left on that overall business capability map, it's shown as supporting. That is true of some companies, operations management is a supporting capability. For my company, operations management is core. That's a key part of what we do is product development and then operations management to say how we manufacture because that's where we make our money is once we've manufactured the products and delivered them. So operations management would be elevated from a supporting capability up to the tier of core business capabilities. And then a second level or level two map of that might say show material allocation, manpower allocation, factory management and product allocation. If you don't have a business capability framework to start with, strategic initiatives like this are a great way to start to build out your business capability framework because where do you build it out and put the more detail down to a level two or level three where you need it to be able to understand capabilities that are being driven or impacted by the business strategy like sales and operations planning. Therefore, if my company hadn't already had a business capability framework, I would be focusing down on defining and putting some detail around material allocation, factory management, manpower allocation and so forth because that's where sales and operations planning needed the detail and to be clear about our ability to do things to be able to support that strategic initiative. Next, we'll go into value streams. So similar to the other artifacts, we have a definition in TOGAF 9.2 for that that wasn't there before and end to end collection of value adding activities that create an overall result for a customer stakeholder or end user. It is also introduced in phase A now as something you want to determine right up in your scope. Do you have a set of value streams in your company? Are there some that are already modeled? Make sure you know what those are before you then look at revising, using those or adding a new one if necessary. But we put value streams to practice in phase B and say here's how you now use these as part of solving a business problem in your business architecture. These value streams allow complete mapping of value-driven activities before specifying implementation. So let me make a key point here for those of you who may not have done value stream modeling before, they are not processes. Value streams come before you have operationally described your current state or your future state in terms of detailed processes. They are about value-driven activities, understanding your key stakeholders, what value is being delivered and the stages that moves through without specifying in any way how to do it. So it is truly a business architecture artifact, not how you've chosen to then implement that in your company. There is a Togaf series guide on value streams. So it's introduced in 9.2, but if you want to learn how to do value streams, you want to go to the guide and look at that series guide. The example, one of the examples we use in that guide is shown on the left about recruiting employees. So one of the reasons we use something that everybody can understand, how you recruit your workforce and recruit employees, is that is an externally triggered value stream because the value is in being able to find the, no, I'm sorry, recruit employees is an internal triggered value stream. I'll show you an example of an externally triggered one in a bed, but recruiting employees is about the hiring manager that needs the competency and the manpower and then defining the position, communicating it, assessing responses, interviewing candidates and then onboarding those employees. So the triggering stakeholder is the hiring manager, the person with the need for that expertise. The value is at the end of it is that they get the right person for the right job in a timely manner to be able to then, to be able to start working. So you see there a description, a stakeholder and the value statement that is part of what you want to characterize in your value stream. And then further, and I'll show you an example of this on the next slide, you want to be able to describe the definition of each of those value stream stages, who the participating stakeholders are in that stage, entrance and exit criteria and then the value items for each of those particular stages. So you will see in the meta model in Togaf 9.2 value streams and where those fit in relationship to the other facts, we have not yet gotten to the level of depth of describing the role of individual stages in the value stream. That might be part of the next update, but you do see that in the guide that's been published. So now I'll put it into action for you. This is our version of the sales and operations planning value stream. Four distinct stages, forecasting demand, planning your supplied resources, and supply doesn't just mean supply base here, it means also factory manpower and factory equipment that might be inside our company. Generating scenarios to resolve the balance of supply and demand and conflicts between those and then driving to one business plan based on having de-conflicted that supply and demand. So this value stream fundamentally did not exist in our company before we did the enterprise architecture effort. Many primitive value streams existed about how we manufacture solutions, how we develop products, how you manage your finances and so forth and what the value is that does provide. But sales and operations planning is an aggregate view, an aggregate planning approach didn't exist. So it required a completely new value stream analysis. When you go look at the value stream guide, you will see those definitions down the left. You will see them the other direction, you'll see a description of a value stream in a couple of our examples and then each of those definitions. Just as a matter of style or personal preference, I like to define the value stream from top to bottom on the left and then align it with the stages, literally in that representation at the top. So you see a definition of each one of those stages, the specific stakeholders for those, interest and criteria and the value from just that individual stage. In a century what you're doing is you're going across the sales and operations planning value stream is you're saying, let's start, it is generally run on a monthly cycle, that's just a best practice, it's not a requirement. Your SNOP cycle may run a little differently but you're starting in the case of a monthly cycle with updating your demand forecast. So what is happening in terms of new contracts that might be coming in, combining your non-firm or things that have not yet been booked or contracted in your company along with your firm demand or the aspects that already have been contracted and are part of the plan, looking out some number of years of that aggregate demand overview. You're then going to the next stage of planning supply resources in that forecast, what is the availability of our capacity of our supply of material, factory manpower, equipment and other key resources in that same timeframe out a year, two years, three years. You're then looking at where there's conflicts between supply and demand and you're generating some scenarios or options for your leadership of how do I optimize or organize in a different way or increase capacity that has the right balance of the cost to do that with the benefits of doing that. So it can't always be about just increasing capacity because it may be a relatively narrow window two years from now where the demand is going to significantly exceed the supply. You don't want to add a bunch of new capacity to your factories or hire a bunch of additional people for a short-term demand spike. You want to even things out including perhaps having to go back to customers and when I say customers, I mean your real paying customers, not internal stakeholders and say we need to move the deliverables for your contract out a couple months because we're going to be able to offer you a much better price if you'll allow us to do that and the company wins, the customer wins and then the key is and this comes back to what you've heard yesterday and a little bit again this morning at the end of the day, the leadership, the business leadership, the value stream is a guiding construct to say what is it you need to do different as leaders? The thing they need to do different in sales and operations planning is to drive out and communicate to the whole business. Here is our one business plan going forward. We've resolved these conflicts, we've balanced the plan demand, we've increased capacity, we moved out a contract, we did whatever and here is the plan that everybody shall operate to for the next month. Now, on the next month you go through these four stages again and there's the opportunity, update, demand, look at what's happened on the supply side and all that but everybody knows the plan that they have to operate to and so that is a leadership strategy driven value driven down into the organization to say that to improve profits and improve our ability to execute on business and our company, everybody's gonna do things this way. So then finally, and I've now gone out from the switching back and forth between a description of the methodology from one of the guides and then giving a Raytheon example, this is a specific artifact now out of that same value stream guide because now I wanna show you the mapping of value streams to business capabilities. So in this case, I'm using the same recruit employee value stream. Again, still internally triggered in this case. Down below it, to each of those stages, you see a short set of business capabilities that have been mapped to. Here are the key business capabilities to enable that value stream stage. So defined position program management is the business capability that includes the hiring manager that has the need for their program of additional engineers, additional production workers, whatever it might be. Human resource management is a key capability and policy management might be a key capability. So it does not mean it's every business capability that is touched in that stage. It means it's the critical ones to understand where you're going to then go drive your enterprise architecture. Community position has business capability, you notice some of them might repeat. And then below the level one or the gray box, you see some level two business capabilities that are color coded. And I'll talk to the color coding in just a moment. Notice over in the onboarding employee, once you've found the right employee to bring into your organization, then we have some business level two capabilities that are color coded as red. So let's make an important distinction here. When you first do this mapping from a value stream that is a way of describing how your business is going to deliver and achieve value to business capabilities, there's no color coding. You're just mapping the key business capabilities to those value stream stages. Once you've done that, then you can do something very powerful. You can say to achieve the value described by that business, by that value stream, which was related back to the business model or some other description of business strategy, I can now drive the need to deliver that value down into a heat mapping of my business capabilities. So to deliver this particular recruit employee value stream value that might be looked at, and it may be your company's been recruiting employees for a long time, but your business strategy might say, we're gonna have to re-look at this value stream. Why? Because we're not able to hire enough people with the right kind of skills for where our transformation is taking us. We can't hire enough skilled engineers. We can't hire enough skilled IT professionals who understand artificial intelligence because it's such a hot field. We're gonna have to fundamentally re-look at how we deliver that value and achieve that approach. That value of trying to, in a more timely way, obtain those kind of skills is what then drives a gap in tracking your onboarding or employee information management you see down there on the right. Not because somebody thought there was an IT system that was broken or had their own opinion about how to solve that problem, but because the business strategy drove that evaluation of strategic need to value to a business capability gap to then drive the rest of your enterprise architecture. That's the magic formula to business architecture is strategy top down driven definition of value and gap analysis to why you go invest in particular areas. And then you see that business capability decomposed further into roles, processes, information and tools. There's other ways to decompose business capabilities. Togaf is not meant to be prescriptive and say that you can only decompose your business capabilities one way, but this is an approach that's introduced in the business capability guide. So once you understand what your business capability gaps are in the value proposition that drove why those are the gaps and the areas to invest in, you then start looking at what needs to shift in roles, processes, information types and characterization and tools or infrastructure and systems to be able to address that gap. And I'll propose to you just again as a rule of thumb, not as a universal answer, having been a certified architect for 15 years, I have never seen a strategic initiative driven enterprise architecture effort that has ever found that technology alone can solve any problem. Business capability gaps driven by this top down flow and methodology always result in a combination of roles, processes, information characterization flow and technology to be able to solve the problem. So for this recruit employee example and saying the key roles that need to be addressed is assigned responsibilities for doing onboard tracking. Why? Because no one function in your organization owns tracking of onboarding of employees. We have somebody here and I did Stephanie who is very passionate about this subject that you don't, facilities, IT, HR, security, if you have a security organization, they all have pieces of responsibility for onboarding an employee. If they don't view that as an end to end process and service, you're gonna do badly at. So you need a role that's responsible for that and you need to understand the processes. And then technology can be a supporting part of that but it's not gonna be solved by the technology alone. So let me put this to practice then for our sales and operations planning journey. So going back to that same value stream, forecasting demand, plan your supply resources, generate scenarios and drive one business plan. These are then the key business capabilities that are critical to enabling that journey. And again, you see that heat map. We had to do the mapping first from our business capability framework and then we said, where's the value of achieving this new aggregate portfolio planning approach realized or need drive the need to fill in some business capability gaps such that our organization is capable of doing it and doing it well because it wasn't an existing value stream. You have to know that our company, just like many others that was aggregate of many different companies coming together back in the 90s didn't just inherently have all the right things in place to be able to do this aggregate value stream approach. Of course we didn't, it didn't grow up that way. So there are some key areas, financial management, procurement management, operations management where there are gaps in our ability to do things to be able to achieve the value of the sales and operations planning value stream. But the biggest gaps are into that area called generating scenarios and then driving one business plan about business planning and customer management. So I know this is pretty high level but to just give you an idea in each of those. Business planning is about linking together disparate processes, establishing new portfolio management roles. So we literally had to challenge the way our program management is done to say, no, we don't care if you have a spreadsheet that you know how you're running your program, what your demand is coming in and then what you need for supplied material and factory capacity and so forth. Just putting that into a spreadsheet and you knowing it isn't acceptable. You are going to have to shift how you do business planning with recognition that our leadership needs visibility at the aggregate level and you better make sure your data is correct in the system, not just in your spreadsheet. That is a culture shift, that's a process shift, that's a role shift and it's a technology shift. So our program managers and the program teams had to be driven to say, you'll make sure the data is right in the system. Why do you have the incentive to make sure the data is right where it belongs in the system of record? Because the next week on driving one business plan, the business leadership is sitting there looking at the recommended balance of supply and demand and if that team has to say, but we weren't able to include this program in the aggregate because their data was bad. Guess what those executives are gonna do? They're gonna go tell that program or that mission area or that customer area, you better go fix your data. So that's how you start to fix data problems is have a business level of your enterprise architecture that shows value directly to the executives and the executives then go drive and say, your data is bad, you go fix it because we need to make better decisions for the company not just your individual program. In the customer management area, a key point to call out here, when we say customer management is a business capability, it truly means customers. It doesn't mean internal leadership or internal stakeholders, but your program management or whatever the equivalent is in your company may be the advocates for the customer. They may be the ones saying, customers need this, I have this contract, we need to be able to deliver these kinds of things. So the reason why customer management was a big gap for us was that portfolio information with historical trends to mitigate customer concerns. You remember I mentioned that balancing supply and demand could mean that we have to go back to a customer and say, we know we already signed this contract with you to deliver these number of units in these times, but we need you to be willing to accept a delay. That's a hard conversation and it better be a data-driven conversation and then be able to show, here's how we're going to get you a lower risk or a better price or something that's a value to you customer because you're willing to shift out delivery which is going to allow us to optimize our portfolio of results and deliver a win-win for us and the customer. So the ability to do that and have that data-driven conversation and put that into hands of a program manager or business development professional to discuss with their direct customer is a challenge. It's not something our company was inherently set up to do. So there again, the business model, the value stream, the mapping of business capabilities and the understanding of the gap and then what was required to fill that gap provided a powerful construct to enable those kind of conversation which led directly to improve business results. And then finally, even though I know I didn't have time to focus on this presentation, technologies were a big enabler to this process. So once we understood those key gaps in business planning, customer management and so forth, the big risk, there was no reds on the business capability map because of technology but technology could enable filling in where there were big capability gaps. So being able to add analytics, just tracking how you do with the sales and operations, planning, decision-making, some data integrity improvements. Those were some key areas where technology then supported that journey but we knew we weren't just going and fixing a system or data issue for its own sake because it was cool or we could do some nice analytics or it made somebody on the IT team happy. We knew it was directly traced to and driven by the strategy, the value we were delivering, the key capability gaps and enabling it with that technology. So with that, I will stop and have questions with Steve. All right, thank you very much, very enlightening. I've had quite a few questions coming in as predicted. So the first one is it looks like you've been using these techniques, call them that for some time inside Raytheon and they now find some of them that I found themselves in the TogoStandr version too. Is that, can I read into that, but effectively what's been added into the standard is based on what's been found to actually work in practice? I think that's completely fair but to give credit where it's due, Raytheon certainly didn't invent any of these techniques. There's a group called the Business Architecture Guild that has been collecting business architecture best practices across the world for a number of years and so when those of us on the work stream for business architecture into the opening group architecture forum build these into guides and the Togaf update which includes Steve Marshall from IBM, Alec Blair from Alberta Health Services, Shailen Mullins who is the official guild representative and then Steve Dupont from Boeing and myself. We're all drawing from those best practices and then putting them in the context of enterprise architecture. Yeah, yeah, it's been a good partnership. Good, good, thank you. Taking back to the operating model canvas, have you used that to connect to the business modeling with operational layers? It's a wonderful question and one that we hope to possibly start tackling in some real detail as the business director of the work stream by way to this year. It isn't a simple subject of the distinction between a business model and an operating model, but generally the approach in the business architecture community is the business model is that description formulation of strategy in a level which then says, here's how we're going to deliver value for the business and an operating model should be more about how you're going to operationalize it or practice it in your company. So there's a definite relationship and we'll probably try to get to an operating model guide sometime in the next year or so, but the exactly how you trace from the business model to an operating model is a little bit of a subtle subject. Okay, value streams and value streams are key to another open group standard to the IT for IT reference architecture. Can you explain the difference between a value stream and a value chain? Sure, and I think I'm pretty sure we tackled this right up front with a quick mention right in the value stream guide. Value chain is a very valuable strategy methodology and technique with Porter's value chain and others have been around for quite a number of years and it is related but different in the value chain says we want to go achieve something. Now let's look at the whole chain in my organization or business of everything that relates in any way to delivering that. Value streams are not the same. They are a business architecture methodology that is about the key activities, the key stakeholder, the value you're delivering and they're definitely more specific than a value chain analysis in that they don't try to map everything that delivers to deliver a specific type of value. They're more a representation of the activities, the stakeholder, the entrance and exit criteria and so forth to be able to deliver that value that is really gonna give you a little bit more focus and guidance. Here now is where I'm gonna scope my enterprise architecture effort. For a little more detail, see the guide again. Yes. Okay. How do you relate business capabilities and functions which is one of the key discussions among architects and how do you relate them with business process? So one of our primary goals in this next TOGF update, the cycle we're going into right now is in the business architecture phase is to draw a clear distinction between business capabilities and then the use of the term functions services which you didn't mention but is a key part of that and then relationship to processes. So we did in TOGF 9.2 and in the business capability guide draw some of that distinction between business capabilities and processes which are definitely related but different. We're going to I think reserve the term functions when you're in the business architecture phase as an organizational term. So we're gonna make it more specifically business functions and it is an artifact or decomposition of your organizational map that there are business functions that perform certain things in your organization. They can then have business capabilities but it's not one to one. So a business capability such as human resource management in the example that was shown may have human resources function, business function has some parts of that but the hiring manager in engineering or production has pieces of that for example. Okay. How did you engage with the program management community to really drive culture change in a way that they felt empowered by the change not done to? So I'm glad to say that as an architect I did not have responsibility for driving the change. I had responsibility for mapping and the blueprints and understanding the change. So I'll put it in context of enterprise architecture and the business components of that. The understanding of the value stream approach and the stages of sales and operations planning, the activities and the value delivered by each of those was certainly an enabler to our leaders who had to drive that change. And so they went to our program managers who owned a particular contract and said here's why you're gonna have to shift some of your practices. They could have a clear description of here's the value that's going to be achieved for sales and operations planning and yes you are going to have to change because you cannot just now have your scope of my contract, my deliveries, my customer. There is something you're doing or failing to do in the case of updating their data about demand forecast and supply needs into the systems of record that you're now going to have to do so that we can get this aggregate view. The, somebody asked yesterday, do you sell enterprise architecture? And I come, no, you don't sell enterprise architecture. You use it as a sales itself at the business strategy level. It wasn't about showing value stream maps to stakeholders like program managers. You don't tend to do that. You show that you fully understand how you're characterizing value, how it's being delivered and why they need to participate that and shift some of their practices. Yeah, you say there must be some hard conversations to push out. Last question that we have so far at least. You talked about the four stages of the planning value stream. Can you say a little more specifically about how to generate scenarios to deal with resource conflict resolution? So the four stages are very critical. Number one in that sales and operations planning is a best practice out there across multiple industries. So you can go read the sales and operations planning handbook. You can go look at case studies and that's part of the, as we well know in the open group, the power of standards. Because if you have a standard, then you can go look at the best practices using that standard. And so it's the same for sales and operations planning and pretty much the universal best practice goes through those four stages. It is inherently a value stream approach. So by going through those four stages of an aggregate view of demand forecast and then aggregate view of your supplied resources and capacity, you then get to that scenario generation stage. It's sometimes called the business partnership stage to draw the point that it's a partnership between program demand and the resource managers and together at the end of the day, hopefully being partners and saying we all care about best results for the company even though we sometimes fight. So the way those stages enable that scenario planning is you then literally have a better view of with the stakeholders in the room in the demand planning stage, understanding the aggregate demand and the resource leaders understanding how that aggregate demand was represented. You have them in the room together doing the supply planning to say here to you program representatives and ones that own the demand forecast is a view of our aggregate view of supply, resources and capacity in that same timeframe looking a year, two years, three years out. Now when you get to the scenario generation, yes, there's a technical aspect of that with running in a tool, some scenarios generating and looking at options for moving demand in or out, increasing supply and capacity up or down and so forth. But it's first and foremost a people conversation where the director level and that level of seniority in your company are together sitting in the room looking at what the data is telling them and say okay, now there's no sense in arguing about the data unless we fail to get the data right. We can now together look at how we're going to better generate those scenarios. So it is a technology enabled conversation but the key is the conversation. Right, we are where we are and we have, how do we get the best for the company overall? Yeah. Yeah, okay, great. Brian, we'll leave it there. Thank you very much for the last two days presentations and for your ongoing work in the forum. All right. Thank you very much.