Log in to watch

Log in or create a free account to watch this video.

Log in
Las Vegas 2024
Share
Download slides

Industrial DevOps and Whole-Product Thinking: Creating a Model-Based Enterprise in Pratt & Whitney

This session will discuss how industrial DevOps principles and whole product thinking are being employed within RTX's Pratt and Whitney business to create a model-based enterprise (MBE). This digital transformation targets the full life cycle of jet-engines, from early concept development through many years of post-sale support (MRO). The MBE program is not only developing and integrating digital tools, but also ways of working, policies, training, tooling, data sources, and processes. Leveraging Industrial DevOps principles and the company's lean-agile operating system, the MBE is being developed as a whole-product, just as a PW engines are themselves developed as a whole-product. The total network of development and operational value streams is evolving as a whole.

Chapters

Full transcript

The complete talk, organized by section.

Brian Moore

Three big things we're going to talk about here. First, industrial DevOps — and I'll be on my toes, 'cause we have the authors right here. We're going to talk about industrial DevOps, whole-product thinking — which probably most people have thought about, but hopefully we'll give you a new way to think about it or a new application of whole-product thinking. Then we'll talk about creating a model-based enterprise — in Pratt & Whitney. That's a concept we'll explicate. We'll also talk about what these three things have to do with each other and how we're integrating them together.

But before we launch, to give a little context — a couple of introductions. First, our company. In the lower left there: RTX, which is the company we used to be known as Raytheon Technologies, formed when United Technologies and Raytheon merged, and hence the name. Today it's the world's largest aerospace and defense company. There's three businesses within RTX: - Collins Aerospace, which makes a pretty big portion of the components that go into an airplane — everything from the landing gear to cabins to the black boxes on the flight deck. - Raytheon — probably familiar. We make things that go bang in the night and things that protect the warfighter. - Pratt & Whitney, our focus today, which has been making aircraft engines for nearly a hundred years.

I'm Brian Moore. I'm a CORE Principal — we'll talk about CORE, but CORE is our company operating system, and I helped architect it. I'm also a SAFe iSPCT, so I've been involved with what to do with Lean and Agile in big enterprises for several decades now.

My colleague David Borzillo is the Chief Agilist within our Pratt & Whitney business. He's written a book on Agile, has an Agile podcast, lots of Agile credentials. So hopefully you're in good hands for the next few minutes.

How most of us got here — unnoticed complex systems

Dave and I got here this way. Probably most of us got here, something similar — but unless you had a window seat by the wing, or you're airplane geeks, you didn't notice that underneath the wings getting us here were some of the most complex, high-consequence systems in modern society.

One aspect of that for an audience like this to think about: if you flew with one of our geared turbofan engines on a two-hour flight, each one of those engines generated something like 4 million data points.

Beyond engines, customers need whole-product solutions

Our customers need cool engines, but they truly need a whole-product solution. Pratt & Whitney has been providing whole-product solutions for nearly a hundred years. They were doing this before "whole product" was a thing, before that was something you could go to business school and learn about.

At least three elements: - Innovative design — using the latest materials, technologies, design concepts, so our customers have competitive advantage based on the design itself. - Lean operations — delivering affordably, cost-effectively, reliably, predictably. Because if Boeing is building based on our schedule, they need to count that we'll have an engine to them when we say we will. - Global sustainment — the aerospace industry has been doing this forever. Engines are used all across the world. Ongoing sustainment ensures the engines are absolutely safe, and that our customers get the full lifespan of an expensive piece of equipment.

Accelerating whole-product innovation is critical

We've been doing this for a hundred years, but we're at an inflection point looking forward to the next hundred years where we're going to have to accelerate the pace of innovation. Two elements drive that:

Unprecedented challenges face both our commercial and defense customers.

To connect and protect the world is the RTX mission. If you think about what was in the news this week, this month, or these last two years — that's an urgent mission. There's a lot of connection and protection needed these days.

To give a little flavor of the needs of our customers:

Sustainability. Airlines and air traffic are a significant part of the economy. It's really important that we address the emissions of engines, which are the biggest environmental impact of air travel. We've been working on sustainability of our engines for some time, but now we're really trying to accelerate reducing carbon.

Data. Aviation, like all our industries — what can we do with all this data? There's an urgent need to exploit the data.

AI for predictive maintenance. You can't have a talk without AI. How can AI enable predictive maintenance? It's very expensive to bring an engine off the plane for maintenance — labor of highly trained people, tooling, equipment, parts. But the biggest expense is that airplane is out of commission. So you don't want to be doing maintenance when you don't need to. On the other hand, even more expensive, tremendously expensive if you don't do maintenance that is needed — that can be catastrophic. So we're trying to use AI to finesse that: make sure engines are always absolutely maintained and safe, while minimizing the cost of doing that.

Defense — DOD is not yet positioned for speed

Turning to our defense customers — this is a June 2024 report from the United States Government Accountability Office (GAO). All kinds of emerging threats in the news. And in red is the headline: "DOD Is Not Yet Well-Positioned to Field Systems with Speed." Some of us have been banging on this for decades, but nevertheless, that's where we are. Pratt & Whitney as a major part of that ecosystem really needs to do what we can to help our defense partners and customers meet the need for speed.

CORE — the RTX operating system

Pratt & Whitney's response to that is enabled by CORE — Customer Oriented Results & Excellence. CORE is our company operating system. It's built upon three decades of experience. It came about when we merged the companies — both Raytheon and United Technologies had industry-leading operating systems themselves (Raytheon Six Sigma; UTC's ACE — Achieving Competitive Excellence). When we merged, we said we need one operating system for the company. Let's take the best of those two things. We did industry benchmarking to see what was best. We took a shot at creating what we thought would be a really good operating system. It's still under evolution.

One thing we succeeded at from the beginning: making a framework to integrate the best thinking in industry from across our big company, and from the industry. The bottom line: it's become our foundation for addressing the challenges our businesses are facing.

At the heart of CORE are its principles. The ones we'll talk about today: - Understanding customer value - Make work visible - Grow value incrementally in connection with integrated cycles of learning

CORE intentionally integrates a lot of good practices — Lean at the middle (UTC had one of the top 5 or 10 Lean practices in the world), Agile, Theory of Constraints, process control, Six Sigma. Not exhaustive, but representative.

Industrial DevOps — three focus principles

Top of mind for us now: how do we leverage all the good thinking in the Industrial DevOps concept? There are nine principles. Today we're focusing on three:

1. Organize around value 2. Establish synchronization and flow 3. Integrate early and often

Dave will talk about what we mean by the model-based enterprise.

Organize around value — SAFe value streams

For now, just talking about how we're using the principles. Scaled Agile let us use a great slide. If you think about organizing around value, a big part is understanding what your value streams are. SAFe helps us understand that in a big enterprise, you've got two kinds of value streams:

- Operational value streams — if you're a for-profit company, you make money with your operational value streams. You make something and sell it. - Development value streams — needed to create the systems and solutions that the operational value stream uses.

The example: the chevrons on the top are a bank's operational value stream — solicit customers, qualify for a loan, make the loan, get interest payments, close the loan, make money. In this room we understand that none of those value stages happens by itself. The green boxes underneath are the systems and solutions needed for those stages — one example is the loan origination system. Just a simple green box. But if we worked in a bank, we'd know it's multiple applications, databases, security systems, algorithms, processes, policies, training materials.

What we learned from the SAFe model: those blue boxes don't fall out of the sky. We need development value streams to create them, evolve them, maintain them, sustain them over time.

With that model in place, I'll hand it off to David.

Dave Borzillo

So Brian gave you the corporate high-level hand-waving view. Let me show how we're actually making this a reality within Pratt.

Thanks, Brian. This is not the complete Pratt & Whitney value stream, but it's a good simplification. We have to design aircraft engines, and it starts with getting requirements from our customers. By the way, we want to use this opportunity to put out there: unparalleled collaboration. I think the wheel is a great metaphor here, because we're going to iterate. We work with our customers. We're the experts in propulsion. They have a mission, or the airlines have a goal. We want to iterate through the design wheel.

Then, once we have the design, it's got to be made. So in that operational value stream, we collaborate with our vendors and suppliers. We've all learned during COVID what happens when the supply chain gets disrupted. In an agile way, we want our vendors and suppliers to be able to deal with changes in the environment.

Finally, when it gets built and put on the wing, it's got to be sustained — maintained, overhauled, repaired. We want our customers to make money as much as they can. Like Brian said, when an engine comes off the wing, they're not making money. If you're in defense, you're fighting a mission — you don't want to see the equivalent of that check-engine light halfway through your mission. You want to know you're going to make it back.

The three principles Brian talked about — that's what we see in this simplified version of the wheel. We understand where value is. Each wheel has value. We understand our customer, and we're trying to grow value in each wheel. We're offering a whole-product model. Fun exercise — at some other point, look at airlines, or Lockheed Martin, or Boeing: what would their whole product look like, incorporating these wheels into their operational value stream?

The Model-Based Enterprise

Like the bank example, these three operational value streams need to be supported by solutions built on enterprise platforms — things like ERP, product lifecycle management, etc. The Model-Based Enterprise is a whole-product solution consumed by the operational value stream. It's an integrated set of solutions for the teams executing the different value streams. Our customers are the users in those different operational value streams.

Now we're going to have some fun with the operational value streams, because we need to think about who the users are going to be. This is more about the models — there are different applications in play depending on where you're at in the operational value stream. If you've ever done hardware designing — you're familiar with computer-aided design, computer analysis programs. As we progress between the different stages of the operational value stream, we're using a different application. And more importantly, we're stitching together the data that goes behind that model.

We want to be able to say we've got authoritative sources of truth. We're not just taking some data from design, and then when we go to "make" it's a completely different set of data — because then we're going to be out of sync and we're running into problems. What we want: everybody's looking at the same data, regardless of how they're manifesting that model.

It's not just left to right. You see in the operational value stream — the arrows also go right to left. If you think about sustain: we're collecting a lot of great data out there in the field. So our designers can see, "Is this actually behaving the way we thought it was going to?" Anybody here in Formula One racing — these guys do it awesomely with predictive analytics: when is this part of the engine going to fail. That's the key with getting the data. We have this great opportunity in the sustain OVS.

Like Brian mentioned with the bank example, the operational value streams need to be supported by development value streams. But we also need a fourth development value stream because of these enterprise platforms — they need to be supported. There's a lot of synchronization going on here, lots of opportunities for the development value streams to collaborate on the solutions we need to give the operational value stream.

Industrial DevOps — synchronization, flow, integrate early and often

So let's talk about industrial DevOps — establishing synchronization and flow, integrating early and often.

This chart — if you're familiar with it, planning intervals. We're incrementally and iteratively building these solutions that get deployed into the operational value streams. We split them up into sprints. You see two tracks:

Discovery track. We are building enterprise solutions. We are not building point solutions just for one program or another. We have to do a lot of discovery: "For Program A, you're looking for this type of solution. Can we make that into an enterprise-wide solution? So Programs B through Z can also take advantage of it." At some point that becomes a prioritized list, with a definition of ready, so our teams know they can start estimating at a scale where they can take it into PI planning. Then it gets handed off to the delivery track.

Delivery track. According to their sprints, the teams go into sprint reviews. As you can imagine in a program this large — how do we keep everybody in communication with what's going on? At the program level we're doing our own sprint review approximately once a month. We bring everybody together because all the leaders, all the key stakeholders can't go to 30 different sprint reviews throughout the month. We run it like a webinar. You can submit questions, submit comments. But we also encourage the key stakeholders — go talk to the team directly. If you have important feedback, they might need to know. We're trying to move as quick as we can, but at the same time satisfy the operational value stream and the users.

Wiring the Winning Organization — amplification, slowification, simplification

Here we're using the CORE principle "make work visible," and this is where we start to see the whole product coming together. From the book Wiring the Winning Organization, there are three critical success factors.

Amplification. As I mentioned, we create feedback loops. With CORE, we help prioritize, making work and problems visible. We're keen about tracking key impediments to the program, and there's an escalation path: that same day a team raises an impediment, it can go to the leadership team so they can make a decision or help implement a solution. So teams aren't frozen.

Slowification. With all this data and all these new capabilities the teams are having, we need to be able to slow down. Sometimes we use the term tactical pause, if you're familiar with the THA (Team-Habit-Approach) leadership style: "What are we looking at here? Is this making sense?" That's also creating opportunities where we have new skills folks are going to have to learn. As we bring new people into the teams, how do we make sure they've got the skills they're going to need? CORE gives us a tool to help us create a skills matrix, so we don't have anything that's not covered.

Simplification. We're creating whole-product architectures, spurring continuous improvement at all scales.

Continual improvement

Speaking of that: how are we continually improving? Well — how can we speed up the cadence? The cadence is working, but we're always looking for ways. If you have ideas, I'd like to talk to you about it. Platform upgrades — one of the challenges is there are a lot of platforms, and they need upgrading all the time. One missed upgrade, or one upgrade that goes wrong, can cause a lot of problems. Restrictions due to security requirements. We have a lot of programs, and sometimes programs have requirements that can even conflict with each other. We're creating enterprise solutions, not program point solutions. We're transitioning to new ways of working and new platforms. We're always looking at ways of communicating better, especially when it comes to strategy and execution, so that everybody at any point in the organization or the process is on the same page about what the strategy is and how it's being executed.

Brian, thank you for your leadership and guidance. I know you helped one of the development value streams this year, so I really appreciate your help. And I thank you all for your time.