James O'Leary 0:00:10.5: 

Before we start, this is our second time doing this. 

 

Alyssa Cox 0:00:14.9: 

Rodeo. We're going to go with rodeo. 

 

James O'Leary 0:00:16.3: 

This is a repeat show. 

 

Alyssa Cox 0:00:18.3: 

Boston wouldn't have us back. 

 

James O'Leary 0:00:19.6: 

Boston two years ago. Yes, we got kicked out of Boston. 

 

Alyssa Cox 0:00:22.2: 

Yes, it's not good. 

 

James O'Leary 0:00:23.2: 

All right, so we want to make this interactive. We want to make it a conversation along the way, so raise a hand if you have a question as we're talking. Alyssa Croft, transformation leader at… 

 

Alyssa Cox 0:00:37.6: 

Alyssa Cox. 

 

James O'Leary 0:00:38.4: 

Cox, sorry. Alyssa Cox. It's a good start. Am I on the right - there we are. 

 

Alyssa Cox 0:00:44.9: 

Yes, tell me more. 

 

James O'Leary 0:00:45.4: 

We do agree to give each other a hard time. Transformation leader at Cardinal Health. A very large organization, more than $200 billion of revenue, 50,000 employees. Seven very diverse business units. Wholesaling, distribution, direct to patient, nuclear medicine. Go on and on. 

 

Alyssa Cox 0:01:08.6: 

Whatever you need to support your healthcare, we make sure it's where it needs to be, so you can get it, right, so we drive stuff to places. We drive pharmaceuticals, we drive medical products. We have a nuclear pharmaceutical business, right, because those have zero shelf life, so we then contract to make the nuclear pharmaceuticals and get them to chemo centers, for example. We have an at home business. You need your diabetes materials. You'd need your diabetes equipment in your home because this is something you deal with every day. We do that too. So, yes, it's about getting the stuff that is required for healthcare to the places where healthcare is delivered. 

 

James O'Leary 0:01:48.9: 

Their own challenges across those business lines, so I think, complex. It's a complex business. It's a high-revenue business, very high-revenue business, but it's a very thin margin business, so I think the different operating units, the economics of each of those operating units creates a lot of complexity in managing this business. From a corporate perspective, you've got to explain it all to shareholders and internal stakeholders and investors, so how you bring it all together is not an easy feat. 

 

Alyssa Cox 0:02:17.9: 

Try harmonizing that master data. Nobody is interested. 

 

James O'Leary 0:02:23.7: 

So you're suggesting master data harmonization is a challenge across [unclear words 0:02:26.9]. 

 

Alyssa Cox 0:02:27.8: 

A little. We're also operating - I think the last count was 23 different ERP instances. Right after this, we've got Mike [unclear surname 0:02:38.7] who is my Anaplan CoE lead, and you want to ask him how hard it is to get actuals across our enterprise into Anaplan, and what that means. He's got a shocking amount of hair for all of the strain that he goes through on a day-to-day basis, making sure that the data is actually visible in any kind of consolidated way at a level of detail that people can actually do work. 

 

James O'Leary 0:03:01.4: 

Make decisions. Mike, put your hand up. Yes, okay, good. So now you know where he is. To save face, by the way, Alyssa was calling me Joe, so a little bit of a name - maybe I did it on purpose. 

 

Alyssa Cox 0:03:14.7: 

What?! 

 

James O'Leary 0:03:16.8: 

Okay, so let's jump ahead. Now we know we're talking to Alyssa. I'm James O'Leary, by the way. I lead Anaplan's customer success team for the Americas. I've been with Anaplan for eight years. I was a customer, starting back in 2014, so I've been around the Anaplan ecosystem for quite a while and have worked with some of our most successful customers and helped clients solve all kinds of problems, so I'm a resource to you as well. Feel free to tap me on the shoulder. We talked a little bit about Cardinal Health. I'll jump ahead. We do want to make this interactive. We're going to talk about a couple of key points and then, really, let's dialogue because you're all here for a reason. You're either on the journey, thinking about being on the journey, have a problem you want to solve. Let's talk about that and make this really valuable for you. To start off, there's two core themes that we'll talk about. One is, what does it take to drive successful transformation in a large, complicated organization? The other is, as technology and innovation evolves, how does that approach change and how can those outcomes be accelerated? So the left side of this is, what does it take to drive transformation? 

 

James O'Leary 0:04:31.5: 

The right side of this is, there's a narrative we can share about the tire swing. Some of you may have seen this before, but it represents perhaps the traditional way of driving innovation or transformation or bringing a solution to market inside a large organization. You start with an idea in mind, and it doesn't quite end up that way, and you go through all these extra steps, and ultimately, what you wanted - what the individual wanted was something very simple. A tire swing. It took a lot of effort to get to that outcome, and we're going to talk about, as technology evolves, how we can have a paradigm shift from moving away from this 12-step tire swing journey to something that's a little bit more upfront and obvious for stakeholders to get on board with and drive transformation faster. So, with that, I'll ask Alyssa to talk about, in your years of Cardinal but just transformation in general, what have you learned along the way? What does it take to drive successful outcomes? What doesn't work too. I think that's always an interesting thing to consider. 

 

Alyssa Cox 0:05:36.7: 

Sure. So a little more background. So I came to Cardinal Health, and my background is all in finance. I came to Cardinal Health out of industry, as well as a number of years with Deloitte leading finance transformation for the strategy and enterprise technology teams. So what I can say with confidence is that Cardinal Health is not special, right. The problems that we have that we think make us special don't. Everybody has these problems, everybody has these objectives. There are no new problems or new circumstances that make us uniquely fit or unfit for Anaplan, and I would venture to say that any of your organizations fit in that same bucket. So what it takes to drive successful transformation, whether it's Anaplan deployment or any of the other technologies out there beyond planning, right - if you want to drive master data harmonization, that's transformative. How you go do that, that's transformative. So, irrespective of where you're trying to drive transformation, I think, for me it's driving - so sponsorship and buy-in. Who is going to stand behind you and drive this with you? From a centralized transformation organization, I neither do finance nor deploy systems, right, so I'm not considered part of the business. Not part of the business that actually works and suffers. 

 

Alyssa Cox 0:07:03.9: 

So when I deploy Anaplan, it's actually not for me. Who is standing with me, standing behind me to credential me and my team in our service of other parts of the business? That's hugely important. Being able to identify who your coalition of the willing is, right. Who is willing to work for you, and work with you, and go through the hard journey of transformation? We like to say at Cardinal Health that transformation is a faith-based exercise. You will get something at the other end, but only if you actually believe in it. If you don't believe, then when it gets hard, you're going to go back to something you know. Faith that this is the right thing is going to keep you moving through the hard to what comes next. So transformation is a faith-based exercise. Find people who are willing to put their dimes in the collection plate of transformation. I would say that the last thing that really makes a difference is, do that upfront work to understand what your goals are. Understand what you're trying to accomplish, what your business stakeholders are trying to accomplish, what your finance stakeholders, your technology stakeholders - only if you're understanding what everyone is trying to accomplish can you actually craft a solution that meets anyone's goals, because what I want to accomplish on my own actually isn't all that important because I don't do the business of the business. 

 

Alyssa Cox 0:08:36.1: 

I lead transformation, which is supposed to enable the business to work better, so understanding our place in a centralized transformation function in that way and getting really crystal clear on whose goal - who we're serving, what their goals are, and really being laser-focused on those goals is hugely important. 

 

James O'Leary 0:08:55.1: 

I've got a quote that I like that I think at least is adjacent to that, but definitely in the realm of what you're talking about, which is you can get an awful lot of things done if you're willing to give others credit. So it's less about the ego of the center and how you're trying to drive the change. It's about understanding your stakeholders, making them be successful, giving them the opportunity to be successful, giving them credit for the wins. There's a psychological game, for lack of a better term, that you have to be aware of when you're trying to drive change and get people in the boat with you. 

 

Alyssa Cox 0:09:28.3: 

I know if our executives think I'm being successful. We drag all of our business partners that are hand in hand with us up to the stage to talk about the amazing things that they are facilitating. I know that our executives can see through to what my team is accomplishing based on how much money they're willing to give me year over year. When they start to pull my money back, then I know that what we're doing and what we're driving isn't being sufficiently valued by the organization, but that hasn't been the case yet. 

 

James O'Leary 0:09:58.1: 

The outcomes are speaking for themselves. 

 

Alyssa Cox 0:10:02.5: 

The transformation team is considered to be a core enabler of that. 

 

James O'Leary 0:10:07.6: 

This was a talking point. This is coming into my mind as I'm just listening. At Anaplan, we've been doing this for 15 years. In the last three or four years, we created a framework. We call it our value assurance framework, and it speaks to a lot of what you're describing, which is - there are six pillars that we have in our framework, and they're really principles or foundational elements of success. Partnership success, transformation success. Relationships are a key part of that. You have to have the right relationships with your stakeholders. You have to have clear goals which are aligned to drive. You have to be thoughtful about developing a talent ecosystem. You talked about the CoE as a driver of that. The change management, and then the ability to sustain the infrastructure that you're building over time. You're really building products that are supporting end users. So, like any good product, you don't just deliver it and walk away. You maintain it, and you need to be in a position to be able to sustain that value that you're creating over time. So we've called it value assurance, but it really is the principles that you've just outlined, which - we use it to keep ourselves accountable, as well as our customers when we're going down the path of transformation. 

 

Alyssa Cox 0:11:19.0: 

I think that as we think about, what is the path of transformation, how do we keep our business partners on that path with us? What we're focused on is constantly trying to figure out how to put something in their hands faster. How can we make it real faster, because the sooner we can go from slideware and ideation to actually a prototype of something, that speed keeps people's attention, right. It keeps people invested; it keeps people engaged. If we go away for a long time and build something, people think we've forgotten, right, and their lives move on. Especially in a business with itty-bitty margins like we have, speed to value, and clear and demonstrable value are really critical. 

 

James O'Leary 0:12:10.5: 

So I think that's a good transition. It speaks to what you've described as a show me culture, which - in order to get believers, you have to sometimes show them. They don't just believe on faith. The good believers do, the true believers do, but others want to see, so being able to demonstrate what the future looks like, or what the outcomes will look like sooner in the traditional process of transformation or implementation, delivery is a value add. By the way, that speaks to the right half of the page. Before we jump into that, to give context, at Cardinal, as you said, you have seven operating units that are all very different businesses. In your transformation, part of why you've been successful is you thought about the center first and then the edges as inputs into the center. So the edges being the business units, the center being the corporate layer. In terms of transformation across an enterprise, I think this is a really important concept to take away. They operate differently, and you need to think about design and architecture in a way that gives you what you need at the center to support your customers at the corporate layer but also meet the needs of the business users that are in the different operating units. They operate at different levels of granularity; there's different insights that they're looking for. So, as you've built your architecture and driven the transformation, can you talk a little bit about how you've thought about the center versus the edge? 

 

Alyssa Cox 0:13:44.3: 

Sure. As you're diagramming your full end-to-end architecture, there are any number of ways that you can prioritize what you build first, second, and third, and having been with a consulting firm, I think I've been part of projects where we built them against all of those different permutations. So what we decided to do at Cardinal was to build consolidation first, right. So you start with consolidation, and then you have all of your subordinate models that the business units are using to do whatever it is they need to do to submit to enterprise FP&A. I can tell you everybody hates it. Everybody hated the journey. They were like, 'This provides no value to me as a business user.' I've got seven business units, or seven segments, all of whom are saying, 'Why am I participating here, this doesn't make my life better,' but it makes life much better for enterprise finance and it codified a minimum viable product for every other model in our architecture. The minimum requirements you have to meet are you have to be able to feed what consol needs to consol, in the way consol wants to receive it. Our consolidation model does not harmonize anyone's data. If you're going to drive complexity in your business unit, it's your job to normalize it to send up to enterprise FP&A, and that was a big change. 

 

Alyssa Cox 0:15:13.4: 

Prior to our go live on the consolidation model, everybody was sending their submissions in, in Excel, and that Excel was not a standard Excel. It started as a standard Excel, and then everybody in their empowered business unit way tweaked it because this really speaks to my business, and nobody cared that the folks sitting in enterprise FP&A were killing themselves trying to harmonize all of these disparate ways of talking about the business. Business units were taking their complexity and forcing it up to enterprise FP&A. By starting with a consol model, we forced that harmonization effort down, and if business units want to create product P&Ls, and they want to create unique allocation methods, and they want to create whatever Tom, Dick, and Harry stuff they like because that's what helps them run their business on a day-to-day basis. That's fine, go for it, but you can't prioritize that over the minimum viable product here, which is being able to feed consol what consol needs, in the way that consol needs to read it. So, in this way, it has been a multi-year journey, trying to force the cost of complexity on to the generators of complexity. You can't just create complexity and pass that bill to a central team. 

 

James O'Leary 0:16:38.7: 

So standard at the core. 

 

Alyssa Cox 0:16:40.6: 

Yes. 

 

James O'Leary 0:16:41.6: 

Standardize as much as you can. Maybe I'll make it interactive. A show of hands. How does that narrative resonate with anybody in the audience? Is this real? Does this feel real to you? 

 

Alyssa Cox 0:16:52.4: 

I'm getting some nods at the front. 

 

James O'Leary 0:16:53.2: 

Don't be afraid. 

 

Alyssa Cox 0:16:53.7: 

Oh, yes, there we go. 

 

James O'Leary 0:16:54.1: 

Don't be shy. 

 

Alyssa Cox 0:16:55.0: 

There we go. So I can tell you, we built, with another not to be named enterprise - we built from the bottom up. We started with gross margin because gross margin is hot, right. Who doesn't want to work with commercial, and commercial drives our organization which is doing what they want. At the end of the project then we tried to build a capstone module that aggregated everything. If your integrated planning solution can't aggregate things across the models that you've built, you just have a bunch of standalone models. That is not the power of Anaplan. So we built from the bottom up, and by the time we started to try to build the top, enterprise FP&A was like, 'Well, I need this.' It was like, well, commercial deprioritized that input, so I don't have it, and it was a ton of rework in the subordinate models that nobody wanted to do, and the supplement of that process with Excel to actually make the process work, when we started from the bottom and then didn't ensure that what the top needed, the top got, out of each of those subordinate models. Until you put it into a model, you can't collect corporate requirements and then build subordinate models, and then build the corporate model, or the top-level model, right. Collecting requirements isn't enough. 

 

Alyssa Cox 0:18:09.7: 

You've actually got to build it for it to be real because then part of your testing regime is sending data from those subordinate models to the top, and if that integration fails, your subordinate model is not ready, right, forcing that accountability, because everyone wants to cut corners and be done already. 

 

James O'Leary 0:18:29.7: 

I always picture a plumbing diagram or a manifold where it's all got to make it into that one entry point. There might be ten pipes, but it's all got to get into that one manifold, and so you design the manifold first. You know what the points of connection are. The pipes themselves can run anywhere in the house, but they all get back to that one consolidated area and they fit. So designing at the center first or designing those connection points and then allowing - and standardizing what goes into the - in this case, the corporate model, but this concept can really apply to any architecture where you're feeding data from multiple systems into a centralized hub. Think about the end points or the connection points very early in your process and design with those in mind. Then you can allow customization or complexity, as you describe it. I think all this is right. Complexity should be thought of in terms of cost. So if you're going to allow complexity, make sure you get an ROI for that cost or that complexity. Don't just allow complexity for the sake of, it's interesting. Make sure there's a benefit to the business in the form of a better insight, a decision that can be made, controlling cost, driving revenue. So force that discipline in your organization or in your business stakeholders to think in terms of cost as a factor of complexity. 

 

James O'Leary 0:19:51.1: 

The more you can standardize - it might feel like you're wearing a little bit of a tight jacket at first, but it actually gets a lot simpler to run the ecosystem and you focus on the things that matter most.  

 

Alyssa Cox 0:20:02.8: 

Everybody wants to standardize. Like, every single person wants everybody else to do what I do, right. Everybody wants to standardize, but they don't want to change what they do in honor of - and Cardinal is, deep in its bones, very federated, so there is not this sense of - this core [unclear word 0:20:22.4] where we're like, well, it's going to be harder for me, but it's better for Cardinal Health. I don't know if anybody actually works for Cardinal Health. I know that there are people who work for our pharma business, and the people who work for our nuclear business, and they're doing the things that make their nuclear business, their pharma business successful, but when it comes to saying, 'What is it going to take to make Cardinal Health successful?' they're like, 'Well, I don't want to experience any pain for that.' So there are a few places where you can insist and you can formalize that structure, and you've got to identify those places, and then stick to your guns. If you bring a customer service lens to those places, you will find they just don't work. I know Mike and I argued very early on in the consol model journey about whether or not we would normalize data in consol or normalize it in the subordinate models. All of the pressure he was getting from our business units was like, that's not how I submit. 

 

Alyssa Cox 0:21:30.4: 

Insisting that consol doesn't harmonize means that consol is always right. If consol was doing harmonization, then any time a business unit owner changes the way they submit, and the consol isn't right because they didn't bother fixing the consolidation rules, because it's like - that's a Cardinal Health thing, not a business thing. Then consol is wrong, and we're on the hook, right. So picking those points and then just being really steadfast in your willingness to control those points of integration and control those points of complexity reduction. 

 

James O'Leary 0:22:06.9: 

So now to tie it back to the show me culture, in order to get your stakeholders in the boat - let's say a corporate - we're all in the boat. We know this is the right thing to do. We have to do this. You're running a $200 billion business. You have to be able to consolidate the revenues, the expenses, calculate the margin, understand how the business is performing. That's great. We want this model. How do you get the business units in the boat? You've got OpEx planning, driver-based OpEx planning. You've got cash flow, you've got COGS, revenue modeling. You've had some fits and starts in the past with not being able to get folks in the boat. I think you guys have muscled your way through. 

 

Alyssa Cox 0:22:46.1: 

Muscled and picked who we work for. I can tell you we do very, very little for the medical segment because they are miserable to work with and they don't want to go on the journey. 

 

James O'Leary 0:22:56.5: 

Nothing leaves this room, folks. 

 

Alyssa Cox 0:22:58.9: 

Whatever I say to you, I say to everyone. Mike's laughing because I have no filter, right. The medical segment doesn't want this. I can beat myself up trying to get their buy-in and then their participation, because even if they say, 'Yes,' they've got to participate. That's just a recipe for failure, and so what we do with the medical segment is they submit the Excel to the consol model because that's the enterprise requirement. Enterprise FP&A pulls the answer from the consol model, and that's it. We have more opportunity than we have time and resources to take advantage of it, so we prioritize development and deployment with a coalition of the willing, but even the willing, they don't want to go on a 50,000-year journey, right. 

 

James O'Leary 0:23:47.4: 

What was your comment earlier about that? 

 

Alyssa Cox 0:23:50.8: 

So we have some model deployments. I think the business wants things fast and they think that it's easy, right, because it's Anaplan. So Mike got an email several weeks ago from our corporate FP&A lead, asking what we can do about a long-range plan. What can Anaplan do for me? Mike had an answer. Radio silence for three, four weeks, and then she came back, and she was like, 'Great, go ahead and get started.' Just to be clear, our long-range plan submissions are due 27th October. There is exactly nothing that anybody can do from zero to deployed model in that time frame. The business is reacting to fires, so there is this disconnect between what people think it ought to take and how long they want it to take, and how long it actually takes, and the challenge is, sometimes how long it actually takes - I have people conceive and deliver babies in the time that it actually takes, right. If I can get the duration of these projects down to below the gestational period of human beings, that would be great. 

 

James O'Leary 0:25:02.2: 

That's a quote you guys can take with you. 

 

Alyssa Cox 0:25:03.6: 

Yes, that's just a tribute. 

 

James O'Leary 0:25:10.3: 

Eight years with Anaplan and over a decade - some projects have taken a long time. I'm sure folks in the room have been around projects that have taken longer than you would have liked, or the human birth cycle as you - so what are we doing about it? The conversation really is, as we evolve and we recognize that being a limiting factor for our clients and the ecosystem, our solution is not this thing on the right, which is collect requirements to traditional development cycle, software implementation cycle, elongated requirements gathering, many iterative conversations. Translation of what one person said into something that doesn't look or feel or smell or walk or act anything like what they wanted. Reiterate, get halfway there, decide if you're going to quit or not, ultimately get to a finish line, and maybe it looks like what the desired intent was. So that's a really challenging - that's been the traditional life cycle. [?Lee] had the slide up on this, this morning. We want to shift the paradigm. There's two ways that we want to do that. We want to do it with applications, which - I'll use the term 'application-led design'. This is the - start with the show me. So when you have a finished product that you can show to a set of stakeholders at the start, you shrink the cycle down. You shrink the part of the cycle that's based on defining requirements or understanding what's possible. 

 

James O'Leary 0:26:35.9: 

You get folks in the boat sooner upfront. Maybe never, medical. 

 

Alyssa Cox 0:26:41.5: 

I don't care. I don't talk to them. 

 

James O'Leary 0:26:42.4: 

You don't care. Maybe never, but for others, you get them in the boat faster, and you execute faster. There are some things you can deliver in Anaplan for four weeks, but for certain business processes, four weeks is a pretty tight development cycle for an end-to-end solution. 

 

Alyssa Cox 0:26:56.6: 

I'm sorry, no. Absolutely not. You cannot deliver something in four weeks. 

 

James O'Leary 0:27:02.2: 

Well, finish your thought. 

 

Alyssa Cox 0:27:02.3: 

When was the last time you had a bunch of businesspeople come together and articulate their goals and their requirements in four weeks? I haven't even started building, and we haven't tested anything. Nothing has gone wrong yet. 

 

James O'Leary 0:27:18.0: 

That's the part I want you to talk about, the testing, which you can never compromise. 

 

Alyssa Cox 0:27:21.6: 

Yes, so when I talk about acceleration - and what I love about app-led design, right, is that you don't start requirements with a blank sheet of paper, and you don't negotiate with people who have a fundamentally Excel-based process and are just looking to replicate that in Anaplan. You start with the guts. That's already documented. I'm not offering you whatever dessert you want. I'm telling you I serve cupcakes. Vanilla cupcakes with chocolate frosting. That's the dessert we're serving tonight, but you get to choose your sprinkles, right. Here's a standard way of doing this. Why wouldn't this work? What would need to be true about this model for it to work for your business? Then people start giving you their actual customer requirements. You don't need them to opine on the guts. You don't need them to opine on how to put together the dough, right, because all they really care about is the decorations. I've got a boat load of kids, and I can tell you right now, once they're done licking off the decorations, they're over it. So figuring out how to accelerate design and requirements gathering. Don't short-change it. Don't screw it up, but don't spend your requirements gathering time building requirements around the basics. It should be requirements around the true value add, which are the sprinkles. Then the development time. Don't spend your time whipping a batter if you can just go buy a cupcake at the store and put the sprinkles on it, right. 

 

Alyssa Cox 0:28:50.6: 

Use the application as a way to accelerate development and then spend all of your time in testing. What your customers want is to put their hands on something. They're not interested in the vaporware. The sooner you can get beyond vaporware. You're starting with something real they can put their hands on and tell you why they hate it. Fine. Then get to testing where they can put their hands on it and tell you, here are the little tweaks that we need to make, to make this actually work for me. That's the goal. That's the accelerator, because it's… 

 

James O'Leary 0:29:18.5: 

Boom. You got it. 

 

Alyssa Cox 0:29:19.6: 

Also, putting their hands on things is when our customers engage. 

 

James O'Leary 0:29:23.9: 

You got it. 

 

Alyssa Cox 0:29:25.1: 

Otherwise, we're all just talking shop, and I'm checking my email and nodding. 

 

James O'Leary 0:29:30.3: 

Apps allow your stakeholders to focus on the things that really matter the most to them and not have an opinion about things that they shouldn't have a say around. Core architectures, certain elements of process. There should be no discussion around some of those things in these programs, but when you start with - when you give your stakeholders the opportunity to have free-form… 

 

Alyssa Cox 0:29:56.0: 

Oh my God. 

 

James O'Leary 0:29:56.3: 

…unfettered thinking, unconstrained thinking about what's possible, you end up in a little bit of trouble. 

 

Alyssa Cox 0:30:03.7: 

Any question you ask, by virtue of having asked it, you are obligated to do something with the answer. So stop asking questions for which the answer is already known and you need to live with it. I don't ask my kids if they want to go on vacation, or even where they want to go on vacation, or do they want to take a plane. I just ask them which underwear they want to take, right. Don't ask kids questions. Organizations work like families. Don't ask kids questions if you're not going to do anything with their answers. Don't ask your business partners questions if you're not actually going to honor their answers, and they're much more powerful in forcing you to honor their answers than my children are. 

 

James O'Leary 0:30:50.3: 

Does this make sense? Does this resonate? So as we fundamentally evolve our business from a platform that you can build anything on, which you still can, we want to help you get to your destination faster by starting with a cupcake. You pick the icing and the sprinkles, but we'll bake the cake. We think that's going to be a much more effective way for you to drive innovation in your organizations faster, using the show me approach to get your stakeholders in the boat faster, and focus on the things that matter to them that are most relevant. Can I get a round of applause, please? [Applause] All right, on to the next session. Thank you all very much. 

 

[END OF TRANSCRIPT]