Electrical Systems podcast (Ep. #3): “Change Management and the Digital Thread”

The disruptive force behind change. In our industry, the ripple effects of a late-stage change can have unfortunate consequences. Change is inevitable. But how do we avoid a change order that never should’ve happened in the first place? When we talk about change management what do we mean? Of course, some change is good – if you’re talking about a productivity improvement.

Welcome to Talking Aerospace Today – a podcast for the Aerospace and Defense industry. The place that brings the promise of tomorrow’s technology to the ears of our listeners today.

In this episode “Change Management and the Digital Thread” we’ll be discussing the many sides to change management. When change happens late in the game, how do you keep configuration control? And what about change orders tied to certification? Really important stuff. We’ll also talk about how the digital thread can have a huge impact on change management in the area of electrical system design and development.  

My guests today, the always insightful Tony Nicoli, the Aerospace & Defense Director of Integrated Electrical Systems for Siemens Digital Industries Software. Also joining the conversation is Steve Caravella, a Solutions Architect from the Capital Team at Siemens Digital Industries Software. Steve has many years’ experience in the aerospace and defense industry as an electrical engineer and architect.  

We’re in a period of intense innovation these days and in order to survive, A&D companies must find rapid solutions to get to market faster ahead of the competition. Companies of all sizes have to be flexible, productive, and more efficient in finding new ways to reach their goals.

My name is Scott Salzwedel and I’m the host of Talking Aerospace Today. I invite to take a listen to our latest episode on change management in the A&D industry. I hope you’ll join me.

In this episode, you will learn:
The different sources of change (1:56)

• Why every change you make brings you back to the starting point (4:30)
• Regulatory changes (6:58)
• How design closure brings change (7:42)
• The components of change management (10:05)
• How the model-based environment helps improve change management (12:53)
• The benefits of digital thread in change management (13:49)
• The certification side of change management (14:48)
• Recommendations for managing change (15:57)

Connect with Tony:

• LinkedIn
  
  

Connect with Steve:

• LinkedIn

 Resources:

• Capital E/E Systems development website
• Blog: The Capital E/E Systems development solution. Exactly how has Capital evolved?
• White paper: A closer look: Next generation electrical systems platform development

Scott Salzwedel: Hello and welcome! This is Talking Aerospace Today – the podcast for the Aerospace and Defense industry and the trends that drive the digital enterprise, a place that brings the promise of tomorrow’s technology to the ears of our listeners today.

I’m your host, Scott Salzwedel. Welcome to episode three of our five-part series. In this episode “Change management and the digital thread” we’ll be discussing the disruptive force behind change. When change happens, how do you keep configuration control? And how do you implement a change across the enterprise with minimal impact? We know this is a time of great innovation and transformation for the industry, and when it comes to electrical system design and development, there’s a lot to discuss.

Before we begin, a reminder that our previous episode covered the tools past, present, and future of the aerospace industry – a great walk down memory lane, and a look into the future. I urge you to give that episode a listen. You’ll find our Talking Aerospace Today podcast on iTunes, Spotify, Stitcher, Google, or wherever you go to listen to your favorite podcast.

Okay, I’m excited to get started. In this episode, I’ll be talking with Steve Caravella, a Solutions Architect from the Capital team at Siemens Digital Industries Software, and Tony Nicoli – the Aerospace and Defense Director of Integrated Electrical Systems for Siemens Digital Industries Software. Tony and Steve love to carry on about the digital transformation, and how it’s affecting the industry so, it should be a good conversation.

Tony, I’d like to start with you. What comes to mind when you hear change management?

Tony Nicoli: I think one of the interesting topics on change that we discussed in the past was the idea of the streams of change, that there’s these different sources driving change, these different activities that are going on as development takes place that result in the need for it in the design.

Scott: Steve, do you want to build on that?

Steve Caravella: Yeah. If I think about it from sort of an ironic standpoint for a moment, everybody dislikes change, right? Because it’s disruptive, it costs money. However, everybody wants changes made. So, I’ll give you an example: you’re working on a development project, and it’s some customer requirements – well, they’ve maybe thought about something and they’re seeing how it’s shaping up, and they wanted it a little differently. So, there might have been a requirement that should have been verbalized and documented earlier that they didn’t realize was a requirement, or, in their mind, it was always a requirement, it was an assumption that didn’t get written down.

Scott: I get it! These changes are the result of miscommunication or perhaps certain assumptions made incorrectly?

Steve: Sometimes you’ll run into change simply because all the requirements weren’t fully written down. And until you see how the design is shaping up, you don’t realize that in your mind you had a requirement that just wasn’t verbalized. So, sometimes that’s a source of change. And as long as you pick that up during the design process, the impact of that can be mitigated to some extent. It may delay your design completion, and release. It may have knock-on effects on other designs, but hopefully, you can do that. It would have been better to have the requirement upfront. If that got missed, the next best thing is to find it as soon as you can.

Tony: Right! That’s sort of a missed requirement. And then there’s the changes that arise from designing something that you thought satisfy the requirement but really didn’t and then you find out later – a typical iteration kind of change.

Scott: I don’t like hearing “iteration kind of change.” That can’t be good…

Steve: And I would say, in some cases, now you’re venturing into the types of change that can be very painful. Because if you’re finding it out later, you know, my mind jumps to, I’m finding it out during tests or I’m finding it out as I’m building. At that point, you’ve got to realize that every change you make brings you back to the starting point. And then you’ve got to run the cycle again, and how long is that path of everybody adjusting to the change? If it’s just upfront, when you’re having a conversation about, you know, what is it do you want? You’re having that discussion and adapting to that across the table. If you’ve got a product that’s built and ready for delivery, that’s a whole different story.

Scott: Okay, let’s talk about that. How does this change the story?

Steve: Because what you’re doing is you’re having now that discussion, you’re documenting it, and you’re having to run it through your engineering and materials cycle and manufacturing cycle and test cycle potentially, and delivery acceptance – time-consuming, very costly. So, that’s potentially another source. Most commonly, though, I’ve seen changes come from a couple of areas. One is just an error – let’s just call it an error. There’s a design or something got missed, it has to be fixed. And you’re finding that when a supplier is maybe fabricating parts or fabricating something. You may find it when things are being installed, you may find it when things are being turned on or when things are tested. But that’s coming from an error, so it’s really important to do everything you can to prevent errors, because those, in theory, are more within your control. There’s the changes that come about that, hopefully, have a business case, maybe in the best interest of the business, so that maybe you’re in production already, and you identify, “Hey, if we make this change, we will save hours on the manufacturing floor.”

Scott: So that sounds more like a productivity improvement?

Steve: Yes, you know, reroute these wires so that we’re not reaching underneath the floor to do a hookup, for example, which requires tons of access to things, etc. So, those who generally will have a business case, and those will be done not because they’re necessary but because they have benefit to you. And so, at least, then, you can manage the timing of that and contain the cost of doing that, and get some benefit. So, that’s another source. And then there’s, I’ll say the dreaded, regulatory end of the process source.

Scott: Regulatory changes… Time for certification.

Steve: Save the best for last, right? Yeah, so that tends to be the biggest challenge because that is found at almost the worst time. You’re trying to get through all your reviews, all your certification, and those are the things that have a high probability of having a knock-on effect with other things. So, not only are you making a change to one thing, but it might be something inherent in how a system is functioning. So, that’s not just rerouting a wire, that’s potentially changing the wiring itself, and the routing of all the wires, and the software that’s in the system. So, that’s usually not very good. So, you want to get ahead of that.

Tony: There is one other source of change that comes to mind for me, and that is that around design closure, and often people don’t think about this one because it’s sort of par for the course. And what I’m talking about here is you’ve got one group upstream in the development process, say, in logical capture or something, trying to finish their schematics, and we’ve got the guy downstream in harness engineering trying to finish his build-to-print package, and they’re both making changes in parallel toward the end of a program. And what they do can impact each other, right? And getting those changes communicated between those two groups inside the organization itself is often a difficult thing, especially if they’re not in an environment that actually inherently passes that data back and forth in quasi-real time. So, if somebody changes something and then upstream, they gotta account for it in the design, or maybe even approve it, and they don’t even know what happened.

Scott: This is exactly the sort of thing we mean when we talk about digitalization – the digital twin and digital thread. Tony, in the scenario you’ve just described, if you had the guy doing schematics talking downstream to the harness engineering team, we could eliminate a lot of these late-stage change orders.

Steve: So, let’s say I’m doing wire routing within the platform. In order to do that, I need structural points where I can secure the wiring – it might be additional brackets and things like that. So, imagine trying to do that in a world where your models for your structure are in one system, and maybe you’re using a different system for your wire routing, and they don’t share information. So, now, the only way you’re going to get that integration to happen is to have people in the middle looking at both of the systems to look up the structure and the wire routing. That is really a challenging situation because of just the amount of detail and the amount of checking.

Tony: Yeah, well, it would be ideal, if you could just have those two systems communicate with each other in real time so that someone who’s making a change on the mechanical side, can expose that to the electrical side and vice versa.

Scott: Really, what we’re talking about here is buying down change risk. Of course, some change is inevitable, but whether you considered an engineering error, a coordination error, or even an integration error, what we’re trying to avoid are these kinds of changes.

Steve: So, going back to just change management in general, I tend to think of it as – there’s really two aspects to it. One is the change request process. And then, the second is actually implementing a change. So, when people talk about change management, we often see them think about it in terms of the request process. So, generally, somebody needs to write up their request, it goes through a vetting process, an estimation process, coding process, and a business case needs to be put together to get to an approval point.

Tony: Is the emphasis here on workflow? Is that what you’re thinking?

Steve: I mean, this is more of an administrative process in my mind. You have to do engineering studies – you know, that’s how you get your costing and that is really important as well. Somebody is going to request something. There needs to be feasibility studies done. You want to do those as quickly as possible, you need to get your recording done as quickly as possible, so a decision can be made. What can happen within an organization while the change request is being evaluated? They’re going to pause, or manufacturing planning is going to pause, or, who knows. So, when we talk about change management specific to the tools we use, really, in the design and manufacturing realm, we do use those tools to support the request process to really get feasibility worked out and get an idea of what’s involved so we can quote it. Who needs to sign off on it and all that is administrative in my mind and less about the design tools and the value of having integrated design tools and the digital thread.

Tony: Yeah, it sounds like there is one value there, in that, if people can be informed as to the status of the change request, they can take either an appropriate pause or an appropriate acceleration of their work, as opposed to being blindsided when something comes down the pipe or just doing things in a vacuum because they haven’t been informed.

Steve: What I’ve seen in the past is usually the change request tracking tools are separate spreadsheets or databases. If there is a way in your design systems to get visibility of a potential change. Imagine being a design lead or a design engineer, and you’re working on a design or it’s going through review for release, and you get notified in your design system that a change request has been submitted. That allows you to make decisions as to how you’re going to proceed, and have the conversation.

Scott: And I think this is where Capital comes into play! It has this model-based environment that can really help design leads or the design engineers communicate downstream.

Tony: Yeah, and that’s one of the powerful things, I think, in integrating a model-based environment with the overall product lifecycle management system, and even ERP downstream, from the perspective of impacting manufacturing and manufacturing planning, right? Because you can actually have a common workflow environment communicate the changes, the change status as they evolve. And when you have a tight linkage between the authoring environment for the different disciplines and the overall management environment, that’s something that is just a natural piece of that digital thread.

Scott: Yes, Tony… The digital thread! Can you explain a bit more how that might help us in this particular situation?

Tony: You need to be able to manage those revision states and be able to trace back to what is in each of those states. You need the configuration associated with those different changes. And you need to do that while you’re doing the work, and then, as you go through different levels of release so that you don’t — you do it while you’re doing the work so that you don’t lose track of that as you go through, and then you need to associate the analytical information to that so that they have some way of connecting the evidence that they’re going to use to make the decision to a configuration controlled revision of the design.

Scott: And then there’s certification. There’s so much complexity these days! I would imagine a significant amount of change orders to occur during this process so late in the game. Steve, care to dive into this?

Steve: On the certification side, if you present a revision, then everybody realizes that they looked at the previous version, and they’re going to look for what changed in the revision and update your analysis for that change. Sometimes just determining the change is a challenge, because it might be rather involved. But in the simple example I’m giving about just changing the labeling requirements, they should be able to look at that and see a revision, realize that you’re probably not going to have to do much analysis or testing as a result of that. You probably just have to document that in a report. So, it’s really straightforward. But again, go back to now the materials organization might have some trouble keeping track of that, so we’re going to go to a new part number. So, if you process that as a new part number, the folks in the certification area see that as a completely new design. So, they’re going to perform a full analysis on it and document it as if it’s new, even though you made a small change. So, inherent in there, you know, it’s easier for the materials organization to manage a part number change. It’s harder for the certification area, and the reverse is true about revisions.

Scott: Okay, so what do we do? What’s the answer?

Steve: The obvious answer is, Change Illustrator is one piece of this, right? So, how do I take an old versus new and see what’s changed? That’s a valuable thing. The question about how do I know that I’m replacing an old design with a new number that’s virtually the same is a little bit fuzzier to me as to how that trail is established.

Scott: Steve just touched on revision management and configuration control, but I’m sure the digital enterprise has ways of addressing this, right Tony?

Tony: We have the digital thread itself. And the digital thread comes under the topic of communication. And the digital thread allows you to do the communication from stage to stage throughout the development process inherently in the environment. So you don’t have to worry. Like, when I brought up the thing about people are working in parallel, they’re making changes they don’t know about it. Well, the digital thread lets that happen. It enables them to know and to respond to what other people are doing in the development process. And then, there’s also Team Play, which is not strictly a database, or algorithmic function, but it’s a communication environment that’s built into the authoring portfolio that lets people just reach out and talk to people who are also working in the environment. And that could even be people working in other disciplines like MCAD, and call them up and send them task lists or work that needs to be done and all that sort of thing so that they don’t get out of sync with what’s going on in there, in a downstream stage or an upstream stage.

Scott: Tony, I love it! You just said it’s a communication environment that’s built into the authoring portfolio, that lets people reach out and talk to other people who are also working in that same environment. I think that’s the beauty of the digital thread. Interdisciplinary communication, collaboration, it’s also good at the Capital E/E systems development environment – something our listeners, if they’re really concerned about change management, should investigate further. Listeners, if you google Siemens E/E system solution you’ll find all the details.

All right, really good stuff today, but I’m afraid we’ve run out of time. Thank you, Tony. Thank you, Steve.

And, of course, I’d like to extend my deepest thanks to our listeners. Thank you, listeners! I’m glad you tuned into this podcast. At the top of the show, I mentioned we’ll be doing a five-part series on the evolution of electrical system design in aerospace. If you enjoyed this episode and you want to check out previous episodes, please take a look at the links in this podcast description. Be sure to subscribe to Talking Aerospace Today on Apple Podcast, Spotify, or wherever you go for your favorite podcast. Sign up and you won’t miss a single episode! Our next episode will be on compliance and certification, how increased complexity and more integration within an aircraft platform have impacted compliance and certification. Very important stuff, folks!

My name is Scott Salzwedel, and this is Siemens Talking Aerospace Today. I hope you’ll join us again for our next podcast.

Until then… Bye for now…