Name: Engineering the Future: How the Digital Thread Transforms Aerospace & Defense
Uploaded: 2026-03-24T19:30:42.649Z
Duration: 56 min 36 s
Description: Engineering the Future: How the Digital Thread Transforms Aerospace & Defense

Transcript for "Engineering the Future: How the Digital Thread Transforms Aerospace & Defense": Hello everyone. I'm Lisa Bergstrom, Senior Marketing Manager for Deltek. Thank you for joining us for today's presentation. Before I get started, I have a few administrative items to note. For the best webinar experience, please use Google Chrome. If you have a question, please type it into the Q and A box anytime during the presentation. We will address as many questions as we can at the conclusion of the webinar, and any questions left unanswered will be addressed individually offline following today's presentation. Resources, including the presentation slides, are available for you to download in the Resources tab on your screen. You will also receive the on demand recording of today's webinar via email within twenty four hours after the webinar ends. So with that, let's go ahead and get started. Welcome to our feature presentation, engineering the future, how the digital thread transforms aerospace and defense. At this time, it is my pleasure to introduce today's speaker, Padma Raghunathan, senior product marketing manager for Deltek. Welcome, Padma. Thanks, Lisa, and hi, everyone. Thank you for joining today. I really appreciate you carving out time. I know how packed calendars can get. For those of you who have attended previous sessions with me, welcome back. I truly appreciate you continuing the conversation. And for those who are new, I am Padma Raghunathan, senior product marketing manager at Deltek, focused on pricing, manufacturing, and quality solutions for aerospace and defense. You know, we we've all heard the typical story. Right? It's all about, hey. We won a contract. We had a great start to the program. Our requirements were solid. The design was clean. Everyone was aligned. And then somewhere between that clean start and actual execution, things started to drift. And by the time we saw it in our numbers, we were already too far gone to fully recover. Right? I'm sure maybe some of it or all of this sounds pretty familiar. And I'm guessing at least, you know, I'm getting a few heads that are nodding in the audience. And that's what today is all about. You know, not the theory of the digital thread. There's plenty of content out there if you want the theoretical version. Today, we are going to talk about what this means for real programs with real cost and schedule consequences. What's changed in the regulatory and contract contract environment that makes this urgent now? What good what good actually looks operationally and where most of the strategies, break down? Alright. So this is what we're gonna be covering today, five sections, and I'll try to be quick about it because, you know, I understand everyone's times cons time constraints. We'll talk about where programs actually lose control. We'll kind of set the stage with that. And then we'll get into, like, why, you know, the the digital thread is now a compliance requirement and not simply a strategy conversation, what the digital thread operationally changes, where most strategies fall short, and why that gap is expensive, and how to actually close it. And by the end, I want you to be able to finish one sentence, which is our thread breaks that. And if you can do that, today was worth your time. So let's get into it. So I want to start with something that sounds obvious when you say it out loud, but it's actually counterintuitive when you're in a middle when you're in the middle of your program. Most aerospace and defense programs lose margin on the shop floor, not in design reviews, not in requirements discussions, not in the systems engineering plan, in execution where cost, schedule, and quality start to diverge from what the model set what the model said was supposed to happen. And the real gut punch is this. You don't see it until it's too late to fix. So if you look at the left side of the slide, this is the program at the start. Right? Your requirements are defined. Your architecture is complete according to you. Design has been validated. Your specs have been approved. Everything looks clean. Right? The model is solid. If you show this to your customer, they would be really happy. Now look at the right side. Now this is the execution reality. So manufacturing is building to a revision that engineering changed, about three weeks ago because the change was approved at in the PLM system, and it just sat there. It didn't propagate downstream. And then your first article inspections fail, and it takes maybe two or three weeks just to trace the root cause because the quality system and the manufacturing system and the engineering system are all separate, and connecting them manually takes time. And then your rework happens, and the cost of that rework doesn't get tied back to the project. It disappears into the overhead or gets coded to the wrong cost center, and nobody flags it because there's no automated link. And then you look at your EAC or what's called as your estimate at completion, which is your projected program cost, And that's reflecting data from thirty to forty five days ago. And here's the analogy I, use for this typically. Like, imagine you're driving, you know, on the highway and your GPS is showing you where you were forty five minutes ago. Right? You'd make terrible decisions. You'd miss your exit. You'd be reacting to road conditions that no longer exist, but that's exactly what a lot of program reviews look like. You're navigating based on last month's gap. The color at the bottom of the slide is the one that I want you to sit want you to sit with. By the time it shows up in your EAC, the opportunity to fix is already gone. And aerospace and defense programs don't feel because of bad engineering. No. The engineering is usually excellent. Like, teams are talented. The models are detailed. The requirements are thorough. I'm not sitting here telling you there's something wrong with how you do your engineering in your organizations. No. Programs fail because execution is often disconnected from that engineering. So the data that your engineering organization creates, the design, the requirements, the change orders, like, all of that doesn't flow downstream. It stops at that engineering boundary. It doesn't update manufacturing in time, and it doesn't feed the quality record. It doesn't reconcile with the cost system. So by the time a problem shows up, whether it's a nonconformance or it's a, schedule slip or a cost overrun, you're already weeks or sometimes even months downstream from where the the actual problem happened. And the consequence is, four things that I best I sorry, that I bet, most of you are experiencing, right now. Maybe one, two, or all of them. One is decisions get made on outdated information because nobody has a real time picture. Engineering changes don't reach manufacturing fast enough, so you get bills to the wrong revision. And then your cost and schedule start to diverge silently. There's no flashing red light. It just quietly widens. And by the time the issues surface, it's already expensive to fix. So there's a lot of, you know, jargon around what is, digital thread. Like, what is this concept? And I want to cut through it immediately. The digital thread is a connected flow of data that ensures every decision you make reflects current operational reality across the life cycle of a program. And that's the whole definition, not a technology product, not a platform you buy. It's a data architecture, a structural commitment that when something changes in engineering, it propagates. When something happens on the shop floor, it feeds back into cost. When a supplier delivers a part, it updates traceability. Everything flows, Nothing gets entered or reentered manually. Look at the flow across the middle of the slide. Right? You have engineering. You have manufacturing. You have quality. You have supply chain, finance, and then sustainment. Every one of those phases generates data that every other phase needs. Right now, in most organizations, those phases are connected by people manually transferring information. Could be exports, could be emails, spreadsheets, status meetings. The digital thread replaces that with a connected data architecture, and it does three specific things that I want to name carefully because they're each operationally distinct. Right? So one digital thread, it connects, which means no reentry of data. There are no version gaps. No there's no, like, someone emailed the drawing to someone else. Like, no. It's one authoritative source that flows. Second, the digital thread enables, which means when engineering makes a change, execution, your operations teams, they see it within hours, not weeks. And the cost system updates automatically, not at month end. And the digital thread aligns, which means your operational reality and your financial picture are synchronized, not reconciled after the fact, actually in sync. That last one is the one that transforms program reviews. Because right now, a lot of program reviews are essentially archaeology, like finances reconstructing what happened over the past thirty days and presenting it as current status. When the thread is working, you're not doing archaeology. You're looking at what's actually happening right now, and that's when decision making actually changes. So now I want to shift to why this conversation has changed urgency, in the last eighteen months because I still, you know, talk to teams. You know, we talk to, you know, organizations, and we talk to customers who think of digital thread as something on, say, like, a three year or a five year road map road map. And I want to respectfully but directly challenge that. The DOD instruction 5,000 dot 97 went into effect in December 2023. And it did not say, oh, consider digital engineering whenever feasible. No. It said it's mandatory. It said that the digital thread must be established in your systems engineering plan. It said digital models are required contract deliverables, like same category as your technical data package. And it said all program data must be, and I quote, must be visible, linked, trustworthy, and auditable. And so let me walk through what each of those requirements actually mean and how they ladder up to your day to day needs. Right? So one is your acquisition strategy. So digital engineering has to be in your acquisition strategy for every new program, not as an appendix, not a future section in the strategy document from day one. And then you have your systems engineering plan, which is the thread has to be explicitly defined and maintained throughout the life cycle. So not defined at the program start and never really updated later on. So it has to be maintained continuously. So digital models are your new Cedrals audio CDRLS, which is commonly called as Cedrals. This is the one that still surprises people when it's when it's mentioned. Like, your your your authoritative digital models are now contract deliverables. Right? Your customer can evaluate them. They can reject them if they don't meet, the standard. They're not supplementary documentation anymore. Data standards, you know, as I mentioned, visible, linked, trustworthy, and auditable. I want to park on auditable for a second because that's the word with real teeth in a GovCon environment. Like, a manually maintained spreadsheet doesn't meet the standard. Like, a PLM system that stops at that engineering boundary, doesn't meet the standard. The data has to be traceable, end to end. And here's the bottom line. Right? Your DOD instruction is not a memo. It's not a guideline. It's not something programs can opt out of. It's a structural default for every new DOD acquisition. And the question for every organization on this call is whether your current data architecture actually supports these four requirements or whether you have a compliance gap, you haven't fully mapped yet. So, again, when I talk about DOD instruction, you know, in general, it may seem a little abstract. But what I want to show in this slide is that it is now in the contract language because this is no longer a policy sitting in a document somewhere. It's showing up in solicitations and award documents that your business development and contract teams are working with right now. So I'm sure many of you are aware of, you know, the whole Golden Dome initiative. So that stemmed from an executive order from January 2025, when a new administration was sworn in. And then, you know, if you look at that, the framing in that director was pretty striking. Right? Threat failure on a program like this isn't a compliance issue. It is characterized as a national security event. Now that's a different category of consequence than simply a contract finding. And then you have the war fight of first executive order from earlier this year. That's actually, that ties executive compensation directly to on time delivery. So think about what this means operationally. Right? When executive's pay is linked to a production speed and production speed requires real time program visibility, now your digital thread readiness stops being a technology decision and starts being a business performance decision at the highest level of your organization. Right? And then look at some other active program requirements like, you know, your your your f 47 program. It's a full digital threading is one of the three core contractual principles of this program. This is the first major combat aircraft designed entirely in a digital environment, and the thread is foundational to how that contract is architectured. And then you have your army directive of, you know, that, that explicitly invokes the the duty instruction. And the the stated goal is building digital threads from requirements all the way through sustainment. Then you also have your army's modern software development IDIQ, which now evaluates digital, engineering artifacts as part of the proposal scoring. And then you also have, you know, DLA. They have it in their additive manufacturing strategy. And then also, you know, your golden dome, it's it has a closed loop, digital thread, architecture as foundational requirements across more than 2,100 firms. Again, I want to make sure the implication of the last one lands. 2,100 firms. That's not just price. That's the entire ecosystem of suppliers, subcontractors, and integrators who actually touch that program. Alright. Now I want to zoom in on something, that I think is critically important for anyone on this call who is a subcontractor or a supplier and equally important for primes as well who are managing complex multi tier supply chains. Now the accountability for digital thread doesn't stop at the prime contractor. It flows down. And the DOD instruction is pretty exclusive about this. Like, specifically, section 3.2 says that suppliers must, in some instances, be integrated into the digital engineering ecosystem to complete the threat. That's not a recommendation. That's the text of the directive. So think about the architecture. Sorry. Think about the structure. Sorry. The DOD mandates digital engineering to the prime. Now the prime is, accountable for full life cycle traceability. I mean, they are the ones who signed the contract. Now that accountability flows to the subcontractor who has to provide connected execution data, so which, basically flows to the supplier who has to integrate into the digital ecosystem. So here's the analogy that I that I think captures this best. Like, something as simple as, you know, as a water pipe. Like, you have a perfectly engineered pipe from the source all the way down to the line. And but if one section corrodes or develops a break, nothing after that break gets clean water. So it doesn't matter how good the upstream infrastructure is. The weakest point determines the outcome for the whole system. So your compliance posture works the same way. It's only as strong as your weakest supplier. And let's make the consequences of that break concrete. Like, one supplier without traceable data makes the entire program noncompliant, not partially compliant, noncompliant. So the prime cannot produce the complete digital artifacts the contract requires in a situation like that, then your contract deliverables fail. You're exposed in your next program review. And the question that program leadership has to answer is, do we fix the supplier's capability gap, or do we replace them with someone who's already ready? And I want you to hear that framing because it's the framing that primes are actually using in their supply chain conversations right now. Your digital thread readiness is already a source selection criteria criteria for some of the programs that I mentioned in the previous slide. So if you're in that supply chain or if you want to be in that supply chain, your ability to demonstrate connected traceable data is being evaluated. This is a real fork on the road, and I want to be honest about both parts. Right? If you're not ready, you become the gap in your prime's threat. They don't absorb that risk. They address it. And increasingly, addressing it means replacement. This is happening on, some of these active programs today. It's not hypothetical. And if you're ready, if you have traceable BOMs, digital work instructions, ERP data that links to your project and contract, you become a source selection differentiator, not just compliant. You actually become competitive. And primes are actively looking for suppliers who close the thread rather than break it. So the question isn't whether to build this capability, the question is whether you're building it before your competition does. And this is where I want to spend a moment on what waiting actually costs because the consequences don't stay flat over time. They compound. Think of it as a pyramid. And as you move up the pyramid, the consequences get harder to reverse. At the base is straight up disqualification. So if the digital engineering compliance is an evaluation factor and you can't demonstrate it, you're not even in the competition. Right? You're excluded before the evaluation starts. And I want to be clear. The list of programs with DE or the digital engineering departments is growing every quarter. So programs that don't have it today will have to have it in their next recompete most likely. So if you make it past source selection, but you're not genuinely compliant, then you're exposed to supplier replacement mid program. So primes who get contract findings then trace them back and make supply chain adjustments. Now that's a loss of revenue and also a loss of relationship that's very hard to rebuild. Above that is audit exposure. So so so DCA findings can actually become cost disallowances. And that's not a warning letter. That's money that gets taken back. It's disproportionate to the original problem because of the time and resources that go into the audit response. And at the top is program failure, missed milestones, contract termination, the consequences that make the news. And the thing about this pyramid is that every level has current examples. So this isn't a projection of future risk. These consequences are actually playing out in programs right now. And the organizations that are investing in digital thread infrastructure today, even when it's hard, even when it's expensive, they're making the investment precisely because they've done the math on what this pyramid looks like if they were to, wait. Alright. So the the the next thing that I want to focus on is is is what, you know, what that what does what does actually means in terms of, you know, where where the programs actually fail at at hand off. Right? So you have, for instance, you know, like, you you have a change, like, you know, the engineering, say, made changes to the design. But it did it as I said, it didn't propagate and, you know, it it it didn't propagate downstream. And then what happens is you have your engineering, and then the next step over there is your manufacturing. Right? Because if if you don't if the change doesn't get passed on to the next next phase of your manufacturing life cycle, then guess what? You know, you you end up building your products, you end up manufacturing to the wrong specs, to the wrong revision, which then means it it fails quality. And then what happens is then you have to go back, and then you have to go and either rework it or expects of change. And if some of those, you know, units are not salvageable, then they end up getting scrapped. So what happens so if if you don't have the digital thread in place, so you clearly didn't have any warning signals that, you know, something changed and you didn't catch it. And then you go ahead and and it it gets it gets built, and down the line, you realize, like, okay, this is not something that, you were supposed to do in the first place, and then you have to go back and fix the problem. So and then if you're you're also seeing that in if when you don't have the digital thread, your your audits, you know, then become a little your audit posturing becomes weaker because you end up doing things in a more retroactive manner. So what doesn't get pushed downstream, it ends up in your it ends up showing up in, your in your in your balance sheet because then what happens is whether it's lag, whether it's cost, whether it's a recovery window that's already closed, all of this then impacts finance, and that's where having that thread or the lack of having that digital thread, you know, impacts what your finance sees. So what you started off with the design intent, you know, with with starting to build something really cool, the the execution and financial reality is completely different from what you actually started off with. So yes. So programs fail at handoffs. And as I said, at an execution layer, if you were to fail at every at every gate, then, yeah, the consequences multiply and it shows up in in your numbers. Alright. I wanna do a quick, self assessment here, and, I'm gonna ask you to be a little honest with yourself. So if any of the following are true in your organization right now, then you're making decisions on data that's already wrong. Like, your, your EAC or estimated completion, say, you know, it's say it's lagging by more than a month. Right? Or your audit prep is manual and it's happening seasonally. Meaning someone scrambles for months before a DCA review or a DCMA review, rather than having a continuous always audit ready posture. And then your, rework costs are not linked back to the specific project or contract that they belong to. And then your, engineering changes takes days or sometimes even longer to reach the shop floor, or your program reviews are built on last month's data. So I'm gonna guess that for a lot of people on this call, at least one of these of those of the of these points listed are true. And I don't say that as criticism. I say it because these conditions have kind of become normalized, across the aerospace and, defense sector. I mean, they feel like the cost of doing business, you know, in a complex of program environment, like the spreadsheet reconciliation at every month at at at the end of every month, the manual traceability exercise before an audit, the the EAC that's always a bit behind. But here's the implication, and I wanna say it directly. On a fixed price program, delayed visibility directly increases unrecoverable cost. So if your EAC lags, say, thirty days, the program review you held last week was based on numbers that were already wrong when you presented them or they were they were late when you presented them, actually. And the decisions that come out of that review, whether it's resource allocation or risk posture or contract chain decisions, they were all made based on an incorrect picture. So that's not a reporting problem. That's a data architecture problem, and it's exactly what the digital thread solves. On one more framing before we flip to solutions, and I think this is actually the most important insight in the whole conversation. So your disconnected data doesn't create one problem. It creates four problems simultaneously, and each function experiences it as a different problem. So they often end up solving for their symptom rather than the root cause. So your program management team sees it as a schedule visibility problem and, you know, an estimated completion accuracy problem. Then, you know, they're trying to improve forecasting. Then you have your engineering and manufacturing. They see it as a design to build alignment problem, for which they're trying to improve the change control. And then you have quality and compliance teams. They see it as a traceability problem because they are trying to build better audit processes. And then your finance and executive leadership see it as a margin visibility problem, and they are trying to get better cost data. So four improvement initiatives, four separate budget conversations, four teams working on what looks like four different problems, but they're all working on the same issue. And that's why so many improvement efforts in this space produce incremental results instead of a structural change because the root cause is never actually addressed. Here's the leverage. Fix the data architecture, fix the thread, and you improve all four simultaneously. So now you're not solving four problems with four investments. You're solving one problem that happens to have four distinct expressions. That's a fundamentally different investment case, and it's why the organizations that approach this correctly see results across the business rather than just one just in one function. Alright. Let me put some numbers to this, and I wanna be transparent about where these came from. These are directional benchmarks based on industry research, open source data, and what we consistently see across programs. So they're not meant to be exact for every organization, but they're very representative. So, you know, as you can see in the slide, eight to 12% of direct labor cost goes into rework and scrap. So think about this. On a $100,000,000 program, that's like 8 to 12 mil that was never in the budget. And that number is almost certainly understated because rework that isn't linked to a project cost code doesn't show up in that calculation. Then look at your estimated completion lag. Right? I've already said what that means for decision quality. But on a fixed price program, the financial implication is specific. The difference between a thirty day lag and a five day, EAC lag is often the difference between a recoverable variance and a program loss. So you recover a 3% overrun if you see it, say, in week six. You cannot recover it if you see it in week 14. Right? So three to and then then you have your audits, which, you know, is another, almost like another function. Right? Like, three to six months of manual prep. You know, you're constantly getting audited, especially if you're a manufacturing organization. You have DCA, DCMA. You have your, ISO or a s 9,100. And if you have, you know, if you do stuff, you know, on the commercial side, maybe even FAA audits. Right? Now that's not just a time cost. It's an opportunity cost. Your most experienced compliance people are not working on program delivery during those months. They are reconstructing audit trails, and that capability is being consumed by a problem that a connected data architecture largely eliminates. And then if you look at your first article inspection, like, roughly twenty five percent, you know, failure rates. Like, one in four article first articles fail. Not because teams aren't skilled or because the engineering change that should have updated the build instruction didn't get right there in at the right time. And here's the compounding dynamic that makes this particularly painful. Now these don't compound linearly. Like, rework drives scrap, scribe that drives schedule delay, and then that delay drives overtime. And then your overtime, you know, obviously, erodes margin. And then your margin erosion triggers audit scrutiny, And that cycle repeats because, again, the root cause was never fixed. You paid the price over and over and you still kept the problem. So let's talk about what good looks like, you know, with an inch with with the digital engineering. Right? So and I I don't wanna be pretty precise about this. I'm not describing a different program or a better team or a more capable engineering organization. No. I'm talking about same program, same complexity, same contract, different data architecture. So if you look at the slider on the left side, so before deploying a digital thread, right, what what does that picture look like? Your data is delayed. Your engineering changes takes days to reach execution, sometimes even weeks. Finance is spending its time reconstructing audit trails retroactively, and your projected program costs gets updated weeks after the event that actually, you know, weeks after the event that actually happened. And then the team is structurally reactive, not because they're not good at their jobs, but because by the time they see the problem, the problem is already expensive. And then cut to if you were to actually deploy a digital thread, end to end digital thread. What does the picture look like after that? Right? Your design changes reach execution within hours. Right? Your cost, your schedule, and quality reconcile continuously, not at month end and not manually, but it's happening continuously. And then your program costs are reflected in real time. And the team can actually be proactive because signals surface much earlier and much before they become events. So you see the rework trend in week two and not necessarily in week eight or week nine or week 10. You see the schedule pressure building before it becomes a slip. And then the line at the bottom of the slide is the one that I keep coming back to. Right? So the difference is not capability. It's data continuity. So the same people doing the same work, making the same engineering decisions, now they just have access to current information instead of old information. And that one change ripples through every function. Now here's the architecture question that the before and after raises. Right? So the digital thread is connected, is a connected flow of data. What is the system that everything actually connects through? Right? Where does it all land? So let me use an analogy. Think about what an air traffic control tower does. Like, every plane, in the airspace is generating data. Right? Altitude, speed, fuel. Now the control tower doesn't generate the data. The planes do. But the tower aggregates it. It reconciles it and gives controllers a unified real time picture that enables safe decisions. Without the tower, every pilot is flying on their own instruments. Capable pilots, good instruments, but no system level coordination. ERP is the control tower for program execution. Whether it's cost, whether it's compliance or schedule or execution or risk management, all of it flows flow all of it flows in, and all of it reconciles against a project or a contract and a cost baseline. So without ERP as a convergence point, you have capable systems like your PLM, quality management system, scheduling tools, shop floor systems, all generating valuable data that never adds up to the program level visibility. So the digital thread becomes the enterprise control system for program execution. So every execution event, whether it's a manufacturing order or a quality finding or a labor charge or supplier delivery, right, all of them reconcile in real time against the program baseline. And that changes what program management actually, looks like. And this is a specific point I want to make clearly because I think it gets glossed over in a lot of digital thread conversations. So ERP basically equals your cost, your schedule, your compliance, execution, all four, Not one or two of them. All four in one place continuously reconcile. Look at what feeds in from the left side. Right? So you have your your PLM and your CAD data, basically, design intent. And then you have your, model based system engineering, which basically is your system models and your requirements and your supply chain, your procurement, and your sourcing data. Now look at the right side. So you have your quality management, which is your whether your inspections or nonconformances, your corrective actions, and then you have your shop floor data, which is labor and time against your program activities. And then finally, you have your, earned value and scheduled performance data. All of it flows through ERP at the center, and all of it reconciles against project, contract, and cost baseline in a system that is built for, FAR, DFAR, CAS, and DCA compliance by default. And here's the line I want you to leave this slide with. If your digital thread doesn't reach ERP, you don't have a digital threat that drives decisions. You have data, possibly very good data, but data that lives in engineering systems and never reconciles with financial reality isn't a threat. It's a fragment, and fragments don't prevent, program failures. And so this is a slide I always find generates the most recognition from audience because I think it names something people have experienced but haven't quite articulated. Like, most digital threads thread strategies, stop at design. That is the data flows beautifully, you know, through requirements, through architecture, design, simulation, all that good stuff. Right? And then the design hits the shop floor, and that's when a lot of conversation stop stops. What happens when that, design hits the shop floor? How does an engineering change connect to a manufacturing order? How does a nonconformance on the shop floor connect to project accounting? How does a supplier quality event connect to a DCA audit trail? So how does any of that even connect to your projected program costs? Like, those are the questions that most digital threat strategies, typically never answer because it's all around, you know, your design and your design intent and your requirements. And those are the exact questions, you know, around which programs lose money. So on the left side of the slide, that's where most of the digital engineering, you know, folks operate. Like, as I said, requirements, models, CAD, digital twin, all of that in the engineering space. It's real capability, and it has value, but it stops at that engineering boundary. On the right side, that's where execution actually happens. Manufacturing orders get linked to design, cost incurred per project and contract, quality events that are tied to manufacturing and procurement, your supplier traceability that's happening in real time, and then your program costs are updated as execution happens. Audit trail, you know, also gets built in continuously. So most programs break at that boundary, and that's exactly where Deltec starts. Right? So now let me talk about why the where Deltec starts matter and specifically why per why it is purpose built and why it is different from, you know, being, you know, an adaptive type of a solution. So when we say purpose built, there's a reason why we say that. Right? There there's there's a there's a category of ERPs out there, you know you know, typically, you know, are built around commercial manufacturing or professional services or general enterprise. And then, you know, you add compliance modules for, you know, GovCon customers, you know, your FAR compliance as a configured thing. Your other audit readiness is pretty much like an add on. Those systems can work. You know? It it there there's there's nothing wrong with that. But every transaction, every data structure, every workflow, was typically designed, for a different operating environment and then retrofitted for highly regulated industries like aerospace and defense and GovCon. But if you look at Deltek, right, CostPoint, which is like our system of records, that is our, you know, flagship ERP, that was designed from day one for project based, contract based, and compliance first organizations. Like, every transaction is tied to a project. Every project, you know, ties to a contract, and every contract ties to a compliance framework, whether it's a whether it's FARs or DFARs, a CAS, and what have you. Right? That's not configuration. That's the underlying data model. So look at the four pillars over here. Right? The core architecture. You have your your FAR and the CAS compliance by design, your DCA audit ready, you know, you're always audit ready, your contract based project accounting, traceability across multiple programs, and then your manufacturing and quality. Right? QMS, shop floor inspections, nonconformance, CAPA management, and then you have your schedule and supply, your your EVMS, shop floor time, supply chain. All of that, you know, gets gets together in this one, digitally connected ecosystem. And then last but not the least is the intelligence intelligence layer, and many of you are probably aware of Della. So Della AI, you know, your smart summaries, our project level insights, agents that surface our information without requiring someone to go looking for it. Right? So that's the intelligence layer. So you have, you know, a digitally connected thread, and then you also have an intelligence layer, you know, that is also operating simultaneously with with this thread. So the callout at the bottom of the slide is the one I'd encourage you to really think about in the context of the compliance requirements we we talked about earlier. Like, every transaction is tied to a project, a contract, a compliance framework by design, not configured, not bolted on, but by design. So when d when the DOD instruction 5,000 dot 97 says, data must be visible, linked, trustworthy, and auditable. This is the architecture that satisfies the requirement out of the box, not through a compliance module someone installed on top of a commercial ERP. So that is the big thing. When we say purpose built, yes, it is purpose built for GovCon industry, for for those highly regulated industries like aerospace and defense. And, again, Deltek, you know, offers those solutions, you know, and it meets you where you actually work on a day to day basis. Right? Now let me show you specifically how the components connect. Like, think about this as some sort of a hub and spoke diagram. Like, you know, here is you know? And it's actually a really useful picture of what that thread, looks like in practice. Right? So you have cost point, which is a system of record right at the center. So you have your compliance foundation that is built in, and then everything reconciles through CostPoint against project, contract, and also your costs. So on the left, you have feeding in, like, and right you know, at the beginning of the GovCon, your project life cycle. You know? So you look at ProPricer, many of you are probably aware of it. You know, it's it's it's our pricing solution. Right? So that is where ProPricer is where proposal pricing lives, you know, whether it's estimates, whether it's your CAS and FAR compliance at the proposal stage or your, your your pricing information. So the thread pretty much starts before contract award. So your cost baseline is built in a compliant environment and flows directly into program execution. And then you have your cost point manufacturing and procurement, which basically connects manufacturing orders to design. Your engineering changes are built to instructions, to your work instructions and sourcing, you know, to your project accounting. So and you have your shop floor time, which basically captures, labor against specific program activities. So whether if you're tracking FAR requirements or if you're, you know, tracking some stringent, you know, requirements like your California Milan break rule. So every hour worked is connected to the program baseline in real time. And on the right side, you know, you have you know, it extends that that operational framework here. Right? So the capabilities that close the loop. So look at tip technologies. Again, some of you may already be our tip customers. Right? That's our quality management system. It's our shop floor solution. It brings together your inspection, nonconformance, first article, and also all your, audit related information, whether it's ISO or a s 9,100, all of that, again, within, you know, that single framework. And so when when a nonconformance happens, right, it's tied immediately to that manufacturing order or to that project, to that audit trail. It doesn't live in a separate quality system that someone has to manually reconcile, you know, later with cost point. No. It's all connected. And the good thing with tip is, you know, and just so, you know, for just additional information. Right? If if you are using, you know, a different ERP, then solutions like TIP, they're pretty ERP agnostic. So you can still build, you know, your digital thread, you know, with with, with TIP, which is basically your your execution layer on the shop floor when it comes to quality and, and shop floor management. And then, you also have your, project portfolio management, which is, which connects your schedule and earned value to the rest of the program data. So your EVMS isn't a separate reporting exercise. It's actually a live reflection of what's actually happening in execution. And as I said, Dellah, which is our, you know, intelligence layer, it sits across the platform, and it surfaces information inside anomalies and also answers without requiring, program managers to go run, you know, some long reports. So what I want you to take from this diagram is that every component closes a specific gap in the thread. So ProPricer closes a proposal to baseline gap, your manufacturing and procurement closes the engineering to execution gap, and TIP closes the comp the quality to compliance gap. And finally, your PPM, it closes your schedule to, finance finance, gaps as well. And Deller, which is, you know, as I said, it, it it closes that inside, gap. So all of it reconciling through one GovCon specific system, and that's the trend. Here's what I what I'll say as a gentle teaser. If you're curious about why any of these what any of these connections look like in a live environment, we do a demo that walks through, those specific, scenarios. Alright. So where does an organization actually start? Because I think one of the things that causes paralysis in the space is that the full picture looks pretty complex and teams don't know which end to pick first. And here's the principle I'd offer. Right? Start where the execution risk is highest, not where the architecture is easiest. A lot of digital thread initiatives start with the engineering data, like the PLM integration, the requirements traceability, or the model based work instructions. And that makes sense from an architectural perspective because engineering is where the data originates, but it's backwards from a risk perspective because the financial and compliance exposure is in execution. So the DCA audit isn't examining your PLM implementation. It's examining whether your cost data is traceable and compliant. So think about this. Right? Like, think about the three phases, and phase one should typically be, you know, your your connect execution. So, basically, establishing that core system of record for cost, schedule, and compliance. You connect your manufacturing and quality to that program execution, and then you enable real time visibility into your operational performance. And then you build the baseline for auditability and traceability that everything else builds on. So this is the phase that closes that that financial audit gaps and also ends your, EAC lag problem before a single PLM integration goes live. And then your phase two is about, you know, you know, is your integrate engineering, you know, where you are, once you have your execution, connected and compliant, you bring that engineering data into, the workflow. And then you have phase three, which is, you know, you close the loop. Right? Performance analytics, AI driven insights. You know, you're connecting your operational data back to, design and planning. So, basically, full life cycle, data continuity. So, one thing I'd say to anyone who's looking at phase one and thinking, like, that's already a lot. Let me tell you, phase one alone produces measurable, auditable improvement in financial and, compliance, posture. You don't have to wait for all the phases to be implemented to start seeing the results. No. You can actually implement phase one and you can start to see, you know, some measurable tangible results. So finally, as I close, I want to leave you with the framing that I think matters most because I find that when people hear digital thread, they default to thinking about it as an engineering initiative, like a modernization project. Right? Something for the engineering organization to want. The digital thread is not an engineering initiative. It's an execution strategy. Most programs have PLMs. A lot of them have model based systems engineering, you know, or a version of that. And the engineering side of the house is usually not the problem. What programs don't have is a connected backbone from the design intent that engineering creates all the way to the execution reality that finance sees. So one system that keeps costs, your schedule, your quality and compliance aligned in real time. And so that's what the digital thread is when it's working. Not just technology, not just a platform, a connected operational reality. And here's the line I'll leave you with because I think it's the right question to be asking right now. The digital thread doesn't start with engineering. It starts where you're losing control today. So here's my ask to you. Before your next program review, identify one place in your current program where data stops flowing, where someone is manually moving information from one system to another or where you're working from, you know, the data is, say, of more than a week old. Just one. Just just look at that one area where you see that gap. That's your thread break. That's where you start. So you can either schedule a demo with us, for any of the areas or solutions that you see as a fit for your organization or, you know, contact one of our a and d experts and, you know, set up some time to talk about, you know, how we can help you. And, with that, you know, thank you so much for being a great audience, and, I'll hand this over to Lisa. Okay, great. Thanks, Padma. Okay, I think at this time, we're going to pause for a moment, and we'd just like to have everyone answer a polling question that we have for you today. So we are going to go ahead and ask, would you like to be contacted by a sales representative to learn how Deltek's intelligent AI enabled platform powers project success. Just give it a minute here. Just allow everybody to answer here, and then we will move on to our q and a. Okay. All right. So at this time, we'd like to open the floor to questions. If you haven't already submitted an inquiry, type it into the Q and A box now. Alright. I think I I can take I think there are a couple of questions here, Lisa. If I can just now we have some time left. We'll just try to address them quickly. So for I think one question we have over here is for an A and D organization with data spread across engineering, quality, ERP, and a shop floor. What are the first one to two workflows you would pilot and what governance decisions need to be made upfront? A good question. And I think I may have I I say this, you know, in in many of my webinars as well. Like, know, lot of many organizations, you know, one of the basic mistakes they make is, you know, they they try to start too big. Right? And the fastest wins come from picking one or two workflows where the cost of disconnect is already visible and measurable. Right? So in the aerospace and defense sector, right, like, it's one of a few things that we typically come across, you know, is that, you know, one is that engineering change, you know, into updated work instructions of build packages, and the other one is quality events, like, you know, through disposition into closed loop corrective action. So the the reason why I say these two are one of the most biggest and common failure points is because, one, we see many times changes not propagating to the next step. And two, when we talk about quality, you know, what I'm trying to say is, like, you know, a lot of times audit evidence is getting reconstructed later. Right? Now this now the key isn't just picking the workflow. It's putting a little governance, around it upfront. So, there are three things, at least, that comes to my mind that matter. Like, one is, when you talk about change, you know, like, what's your authoritative source for things like your bill of materials, your routing, your revisions, and then what are those typical identifiers that have to stay consistent end to end, you know, whether it's part numbers or serial numbers or lot numbers. Right? Or if there are revisions or project numbers or contracts, like, what what is that common identifier that has to stay the same? And third is, you know, who actually approves what so that way evidence gets, created as the work happens. And, again, it doesn't have to be assembled after the fact. So once those are in place, you can connect execution systems to so that, your inspections and your nonconformance, pretty much your shop floor activity, you know, all flow into a a consistent record. So that's that's really when the digital thread starts to become, you know, starts becoming real, you know, not not conceptual. So, again, I mentioned these two points specifically because when you make those, you know, adjustments or those shifts, whether it's change or audit traceability, you know, both you you start seeing results, and measurable impact, you know, in a shorter frame of time. I see we have, one more question here around, it's a good one actually, around metrics. Like, what actually like, what what metrics actually indicate that a digital thread is working, especially around audit readiness and cost of quality, and, you know, without adding manual reporting. So so, yeah, I'd focus on a small set of, you know, proof points that tell you whether your data is actually staying connected. So one thing that you you wanna wanna track for sure is, and I even mentioned this in the previous question, is change propagation time. So, like, how long does it take for an engineering change to actually show up on the shop floor, whether it's work instructions or an inspection plans? The second that everyone should be measuring is your audit prep time. Like, how long does it take to assemble an audit package today versus if, you know, you were to if your audit trails were automatically generated, then what does that what does that difference look like for you? And then third is the cost of quality visibility. And many times, you know, people think quality is, you know, just like another function. No. You know, quality can actually be your strategic, you know, differentiator. Right? And quality also has a lot you know, has a financial impact. So so for instance, if if your cost of quality is really high, that means, you have some pretty, you know, poor quality processes. So you need to take a take a look at that. So so it's it's important that, you know, you you track the cost of quality because, you know, that can actually reflect, on your program budget. So the the reason that some of these metrics are powerful is because they don't require a new reporting layer. Right? They come from your normal execution data, whether it's traveler history or material or labor postings or whether it's quality workflows. Right? That's a real shift. So when systems are connected, you don't report your way into the digital thread. You actually operate your way into it. So yeah. So, again, look at those metrics that are not going to create extra work for you. You know, it's something that's already there, just connecting, you know, some of these workflows digitally, and then you can start seeing the I think I have time for one more question, which is about, let's see. This is actually a great, this is actually a great question and, you know, this, but again, with with a little caveat here. But, the question is as Teltek advances, more for aerospace and defense, what is the forward looking road map to make Costpoint a true digital threat system of record across engineering, planning, procurement, manufacturing quality, and financial execution while preserving end to end traceability, reducing dependence on customer reports and point integrations, and giving customers a governed a truly analytics ready data foundation for gov gov con compliance, decision making, and to scale. This is a great question, and, thank you for posting this. And I'll answer this direct directionally because, typically, any road map related questions are, addressed by our product management team. But I can definitely give this audience a little bit of the direction on what it is. Like, what you're seeing is, you know, again, when we talk about digital thread, we're not talking about it as a feature. Right? It is, it is really about making CostPoint the place where operational truth becomes program truth. And that's why, you know, it is our flagship ERP. That's why we call it the system of records. There are three themes behind that. Obviously, one is the governed data continuity, making sure identifiers, your transactions, your audit trails stay consistent across execution. Second is closing the biggest gaps in the threads of connecting your proposal to baseline, your engineering to execution, quality to cost so that way teams rely less on manual reconciliation and customer reporting. And then third is building analytics ready foundation. So the same execution data supports compliance, decision making, and scale without stitching systems, together. Right? So that's really, you know, why we say that if the digital thread doesn't reach our ERP, it doesn't drive decisions. So, again, engineering dives intent, but your ERP is the one that connects all your key variables like cost, contracts, and compliance. So, again, if you're interested learning more about the future of CostPoint, you know, the road the road map. And if you're an existing CostPoint customer, I'm sure many of you already do this, but if you're not, please make sure that you sign up for our quarterly town halls. That's a great place for, you know, you to connect with our product teams. They actually, talk about they provide product updates, and they also talk about the road map. So, I'm sure they would always be happy to, connect with you if you have any special questions on on the road map. So so, yeah, that that was a great question. And, yeah, you know, please keep them coming. And if there's anything else we can help you with, you know, we're we're here at your service. Think that's all we've got, Lisa. Yeah. Okay, great. Thanks, Padma. Before we officially conclude, we want to remind you that you'll receive an on demand recording of today's webinar via email within twenty four hours. If we are not able to get to your question today, we will be sure to follow-up with you directly offline. And with that, I'd like to thank you for joining us today. Please visit delltech.com for more upcoming Deltek events. Have a great rest of your day.