IpX True North Podcast
The IpX True North Podcast is a global industry resource for all things people, processes, systems, and technology created to share conversations with our network of thought leaders, innovators, and founders changing the shape of the digital future. Here we share their stories, impact, vision and tools for success in the areas of process optimization, engineering, the model based enterprise, operational excellence, and digital transformation.
IpX True North Podcast
The Process-First Approach to Digital Transformation Success
We dive into the principles of successful digital transformation by exploring the critical relationship between processes, requirements, and tools. Thomas Miller, Director of Enterprise Systems and Processes at IPX, shares his 20+ years of expertise in bridging the gap between business needs and technical solutions.
• Why processes must lead and tools should follow
• The difference between proper requirements gathering and ineffective brainstorming
• How business requirements differ from functional specifications
• Understanding the CM2-500 standard and how it compares to EIA-649
• Common mistakes organizations make when selecting and implementing enterprise tools
• Strategies for creating lasting change that's embraced rather than resisted
• Real-world examples showing how process-first approaches delivered 40% reduction in change cycle times
Stay in touch with us!
Follow us on social: LinkedIn, Twitter, Facebook
Contact us for info on IpX or for interest in being a podcast guest: info@ipxhq.com
All podcasts produced by Elevate Media Group.
Welcome to the IPX True North podcast, where we connect people, processes and tools.
Speaker 1:Hello and welcome to today's episode of the IPX True North podcast, where we dive into the principles, processes and tools that bring true operational harmony.
Speaker 1:So I'm your host, brandi Taylor, and I'm joined today by a guest whose expertise in helping organizations bridge the gap between Thomas is a really good friend of mine. He is the Director of Enterprise Systems and Processes for IPX and he has over 20 years of experience improving processes and writing requirements for the tools that then automate these processes, which exactly is the topic that we're going to explore today and and demystify. You know what Thomas does on a daily basis, in case people are wondering what we do here on the services side of IPX. So you know, often too often I feel people are simply often the recipient of a new or updated process or tool and you know they're often handed the outcome without having been a part of shaping it as much as they should have been in the future from the start. So today I want to demystify that with Thomas here and then shed some light on how these projects are kind of defined from the very beginning. So, thomas, welcome to the show.
Speaker 2:Thank you.
Speaker 1:All right. Well, to kind of kick this off a little bit with a touch of background, there's a lot of buzzwords for what we do on the services side of IPX. Right, we talk about enterprise excellence, digital transformation, process improvement, operational excellence, master data management, value stream optimization, harmonization. You know like all these so many buzzwords for what we do. Optimization, harmonization. You know like all these so many buzzwords for what we do.
Speaker 2:Just to kind of give our audience a little bit of a background, how do you describe your role at IPX when someone outside of our industry asks yeah, so my role, you know, is basically understanding the wants and needs of the people and being able to translate that from business speak into technical speak for the people that are going to implement the solution. So it's understanding what the spirit of what they're asking, instead of just the words that they're saying.
Speaker 1:Awesome, and so give an example. What does a typical day look like for Thomas Miller?
Speaker 2:Yeah, a typical day. I mean it's a lot of working with the clients and understanding you know their wants and their needs and kind of digging deeper into why it's that way, understanding how they're operating as well as you know, helping them progress and communicate to the organization where they want to go, and doing that clearly.
Speaker 1:So let's shift gears slightly here, because people often come to us at IPX because they want a fancy new tool to solve all their problems. Right, that happens often for us, and you've worked with countless enterprise tools. Which ones do you have the most hands-on experience with?
Speaker 2:Yeah, that's a great question and one that we often hear. So I've worked a lot with PLM tools like Teamcenter, windchill, inovia, aeris and those. But I have, you know, background across MES tools, erp tools and all that MES tools, erp tools and all that. And you know with this, you know each one of these tools has great strengths, but it's not being able to declare which one's the best. It's not a universal thing for everyone. It's each client has unique needs, that one tool may prevail over the other. So, because of that, the right tool isn't chosen in isolation. It's dictated by the requirements in the business process that we're trying to enable. So too often, companies pick a tool first and then they focus on the processes to conform, which creates the friction, the workarounds and the misalignment with the strategic goals.
Speaker 1:People often just come to us with our experience and say hey, you know what's the best PLM tool I should be implementing? Right, and I think that there's not an easy answer to that. Right, we can tell you the ones that are great and that can do a ton of great, great things. But again, there's no one size fits all and it's not like there is one best or the three top best. It's really based on what the wants and the needs are of the business.
Speaker 2:Absolutely, really based on what the wants and the needs are of the business.
Speaker 2:Absolutely, yeah, which is, you know kind of why I use the approach of.
Speaker 2:You know we got to understand what the business processes are first, you know, mapping them out of what they currently look like and working on future states so that we can help identify those gaps and clarify what success and what a client's utopia looks like. And then from there, you know we have to document the requirements, the business requirements, clearly, because this translates the needs and the wants into kind of a structured and testable set of requirements that distinguish the must-haves from the nice-to-haves. And then, ultimately, what we do is we take those requirements and business processes and evaluate those against the tool, and this helps us assess the capabilities of whatever tool it is, whether it's PDM, plm, erp, nes, etc. We use those against the documented requirements and see how well they support that process flow and the compliance. And then, finally, we have to factor in the scalability and the culture. Culture is a huge aspect of this and that will help or hinder the success of deploying any tool in the system if the organization isn't ready for it or there's concerns. So it helps with that user adoption.
Speaker 1:We're not just talking about PLM. Often PLM is where people come to us for because of CM2 and they think change, configuration management, they think engineering data. But CM2 truly is end-to-end right and there's multiple tools that are engaged in that process across your digital thread and we worked in all of them. So you know it's not just PLM right, it's truly requirements management. It could be MES, it could be QMS, it could be ERP, it could be any of those Exactly. Now, one thing I wanted to clear up kind of a big misconception that we often hear is too often teams say that they've gathered requirements right, and when we dive into what they mean by that, they're really pulling people together in a room and they're brainstorming in Word or Excel of what they want this tool to do. And so why does requirements gathering often fail? And then how do we help people move away from those vague ideas in Excel to communicating clearly what are the wants and needs that you're looking for?
Speaker 2:Yeah, absolutely right. There is a common misconception Requirements gathering often fails because teams confuse it with informal brainstorming sessions rather than structured iterative process. You know, just capturing the ideas in Word or Excel might help to start those conversations, but it rarely ensures the clarity, alignment and traceability across everyone. And it's because you don't dive deeper, you look at the surface. And it's because you don't dive deeper, you look at the surface. So you know why does it always fail or why does it tend to fail? There's a lack of structure. So brainstorming doesn't differentiate between one's needs and constraints of the system and the process. And also one big thing that we see is there's no shared language across teams, even within the same organization or across the same functions. So without those consistent definitions and formats, you know stakeholders interpret those requirements quite differently. And when you have those spreadsheets and documents, there's often a lack of version control or linkage between the design testing and change management, or linkage between the design testing and change management.
Speaker 2:We recently had a client that was doing a change process for their entire organization and they had 10 requirements for an entire change process. That's very high level and it's barely scratching the surface. And then also there's the missing context right. So brainstorming focuses on what we think we need instead of validating, against those process gaps, what the user does on a day-to-day business or what the business's objectives are. And in order to move forward right, you have to have that mentality, or the shift from gathering to elicitation and validation of the requirements. So you're actively engaging stakeholders to map out, you know, the as-is processes, the to-be processes. You're confirming those through interviews, through meetings, after processes are developed and even into prototypes.
Speaker 2:And I like to use a structured format when I'm capturing that the requirements, so that they are clear and testable.
Speaker 2:So I always follow an I want so that acceptance criteria format which helps distinguish between the functional and non-functional needs of the organization, so it helps those delivering it understand what the tool must do or is it business process and so forth.
Speaker 2:And then, additionally, it allows us to link those requirements to the objectives we're trying to meet. Right, just because someone has a requirement doesn't mean it actually fits into the current process. So we have to make sure that those align with the business goals and they're measurable so that we actually can say, hey, we've actually efficiently done this process. And you know this helps by implementing tools that are requirements management platforms so they help connect those requirements from design, testing and through all the changes. And then again it's iterative. It's an iterative and validation process where you treat the requirements as living artifacts that evolve through feedback, review and impact assessments, just like our change processes should. So you know, moving from these vague lists to structured requirements ensures that stakeholders share a single source of ultra driving for better decisions, reducing that rework and improving the overall quality of what their needs and wants are.
Speaker 1:So what would you say to someone who says you know, I don't really need requirements, you know we're going to go out of the box?
Speaker 2:Yeah, out of the box is one of those things where the tool can pretty much do whatever you want. You still have to configure it to map to what your current process is. And what we most often see is the current process is years that have just built on because we had a failure here. We had that, so it's not necessarily fixing the root cause of the issue, but it is. You know, band-aiding something that didn't work or we had an escape. So you know you need to follow through and make sure that the tool is configured correctly. So commercial off the shelf or out of the box is kind of a misnomer.
Speaker 1:And you know, I know, like our system integrator friends and you know tool implementers, they're so good at what they do they want to automate your ways of working. They want to automate what you do today. They're not there to improve your ways of working per se. Right, so you may get some efficiencies from automating, but if you have a clunky process that has a lot of those band-aids like you're talking about from an audit or from quality issues or whatever, where we've done these band-aids and small fixes, it becomes a very difficult and cumbersome thing to automate.
Speaker 1:Exactly, yeah, automation if you don't have a good process, just allows you to create bad data quicker?
Speaker 2:Yeah, nobody wants that.
Speaker 1:No, they sure don't. Another thing I want to get your brain on is I want to clarify something that's pretty fundamental for us but maybe not for others, is what is the difference between a business requirement and then a functional specification?
Speaker 2:Yeah, this distinction always gets blurred, but it's critical to understand what its intent is for alignment across the organization, not only with the business but also with the person that's implementing the solution. So the way I like to think about it is a business requirement defines what an organization needs to achieve and why it's focused on the outcome or the value to the business that they're seeking to improve that traceability, reducing cycle time and enabling like regulatory requirements. So business requirements are typically high level and solution agnostic. So an example is the system must allow secure, role-based access so that authorized users can only view the sensitive data of the product. So that's, you know, that's how a business requirement works.
Speaker 2:Now a functional specification defines how the system will meet those business requirements. Right, it's much more detailed, it's technical and it outlines the behaviors of the process and the tool, you know, with the inputs, the outputs and how it interacts with the users and also other systems to fulfill those business needs. Functional spec would say implement a role-based access control model using active directory groups with permissions configurable at the document and BOM level. So basically what it's saying is now we've gotten into the solution with the functional spec, whereas the business requirements are the needs and the wants of the business. One way to kind of, you know, recap that is, the business requirements are the what and why, so the value and the outcomes that are expected. The functional spec is the how. How is it designed, how is it implemented? You know, keeping the separation is quite important, because business requirements ensure that we're solving the right problem, while the functional specification ensures we're building the right solution.
Speaker 1:It's kind of like baking a cookie, right, like you know. The business side says what do we want? Right, this is what we want and this is what we enjoy, this is the things that we need. But then the system integrators, they need to write that recipe right, like what's the best way to achieve those requirements. There may be multiple ways to do that, depending on the tool.
Speaker 2:Exactly.
Speaker 1:So in so many people's solution right, they want to give you hey, I've done this in this previous tool or at my previous job. If this was a great way, I wanted to do this. Well, that may have worked really well in one specific tool, but it may not work the same way. And so you're solutioning, you're telling the tool what's the best way to do something, when in reality you need to let the tool help you figure out what is the best way to do something and come up with the most simplest, best and optimized solution.
Speaker 2:Yes, yeah, and the current tool that you've picked may not be the right tool for those set of requirements. So you don't want to tie in solution and specific tool. You would like the system integrator or the IT folks to figure out what's the best tool for those requirements.
Speaker 1:I like that. Okay, so at IPX we're more on the business side, right, like we're process people. So we want to help you with that optimized process. First, that's how you're going to get your business requirements. Then that's how you're going to communicate very clearly your wants, your needs, your expectations, to then the solution or vendor in order to get what you're looking for. Yes, so you know some people think you know. Well, you know I, you know how do I, how do I know what my, my, my business process needs to be right. Let's say they're not using someone like yourself or IPX to help us with this. You know we, we do have a CM2-500, and how do organizations use it? Because I'm guessing many people come out of our training and they're not sure what to do with this thing, right? So tell me your thoughts.
Speaker 2:Yeah, so CM2-500 kind of is that enterprise level standard for integrating, you know, configuration management into the broader business.
Speaker 2:You know, and it helps address the governance, the digital thread, you know, closed loop processes and ensuring that data stays accurate and aligned across its entire lifecycle.
Speaker 2:And this includes, you know, process mapping, maturity assessments, optimization strategies to scale CM beyond engineering and into, you know, other areas like supply chain, manufacturing, quality service with that, and so organizations can use this to assess and benchmark their current process maturity and help them identify gaps. It also helps those organizations with integration, right, because it aligns the ERP, the PLM, the MES, qms systems under a common set of principles, right, so it's not just a PLM or PDM tool. All of these tools should adhere to the same logic and the same commitment. And the same commitment. We use this to help understand and identify potential cycle time changes in improving data integrity and minimizing downstream work with the SIEM 2500. So it's all about process optimization. And then you know, if you look at it at a really big scale, it helps with that digital you know, digital transformation of roadmap, where it supports building this scalable digital thread that helps connect those design, the requirements, manufacturing, field service data into each other standard is.
Speaker 1:You know, a guiding light is maybe a word I might use to help organizations figure. Okay, we know we've got some problems, but we don't really know the best ways to fix them.
Speaker 1:So the framework of CM2 really just gives them we call it true north right of the best practices of 40 years across industry across the globe. And this is the way where you don't have to implement all of CM2, but if you have pain points, now we know how to surgically go in and use the CM2 framework and the standard to then figure out how do we surgically solve this specific pain point. Right, you may have other things you're not doing exactly the right way, but it's working for you and it's no problem. So you want to use this in a tactical way to then help improve those pain points within your business.
Speaker 2:Yes, yep, cm2 is that guiding light, or those guiding principles that help, you know, align everyone to what we want to accomplish for a specific pain point, for the entire organization.
Speaker 1:Okay, all right, very good. So you know, just discuss a little bit of a different standard for a second. So some of our military friends and governmental friends. They are often required to utilize EIA-649. This standard often gets referenced for the standard for configuration management. So let's talk about that. For a second, for teams who are relying on 649, what might shift if they were?
Speaker 2:that helps kind of establish those core principles for identifying, controlling and verifying configuration items. However, it's intentionally focused as guidance. It tells you what a good configuration management solution looks like, but not how to implement it across the enterprise. So you know what kind of shifts with adopting CM2?. So you know, eia 649 is the guidelines and CM2 is the prescriptive practices. So where EIA 649 provides those flexible principles that each organization interprets and implies differently, cm2 offers a prescriptive closed-loop methodology that helps define roles, workflows, decision points, reducing the ambiguity and variability across the teams. So CM2 really just enhances 649 and provides the you know kind of how-to on it. And with that, you know, eai 649 is kind of often applied to just engineering or in kind of programmatic silos, whereas CM2 kind of expands the configuration management across the enterprise. So it integrates, you know, engineering, supply chain, manufacturing, quality, the services into kind of this single digital thread and then with change management, right.
Speaker 2:So EA649 has a, or supports a structured change control, but it doesn't necessarily address, like the cycle time of the change or the process agility that's needed, while CM2 kind of emphasizes, you know, a fast impact assessed change that helps maintain that data integrity while working to reduce rework and delays in the system.
Speaker 2:Also, you know, eai 649 focuses on the configuration control but leaves the requirement handling to other frameworks where, you know, cm2 has requirements that are tightly integrated with everything they do and it's tied to the configurations, the change managements and this ensures that every decision traces back to a valid business need and with that, eia-649 doesn't prescribe kind of a full digital thread or an enterprise integration approach. You know you have to piece that together, whereas CM2 helps provide that roadmap for digital scalability and transformation while aligning all of your systems under kind of a single governance model. So really adopting CM2 doesn't replace 649. It actually builds on it. So CM2 kind of operationalizes the principles of EIA 649 into kind of that repeatable enterprise-wide practices, which allows faster change cycles, better data accuracy and improved cross-functional alignment across the organization improve cross-functional alignment across the organization.
Speaker 1:Okay, so EIA 649 really is a foundational set of requirements and it just doesn't really tell you that lower level tactical best practices of how to achieve it, but it kind of gives you that higher level of what you should do.
Speaker 2:Yes.
Speaker 1:Okay, and so I think you know, would it be fair to say EA649 is great. You could go and implement 649 in a number of ways and some you know it doesn't really give you the best practices of how to do it to really get your business to be more efficient and effective down at that tactical level.
Speaker 2:Yes, yeah, we see that EIA 649 is typically within an organization, is implemented in kind of siloed approaches instead of an enterprise wide approach. That's common.
Speaker 1:Okay and often people are required to satisfy 649. So they do that, which is great. It's still a great standard to follow. I guess, if you have a 649 and then you implement CM2, like you said, it's just building upon and giving you more of the best practices to get there, of the best practices to get there. I think in the other direction would you say, if you implemented CM2, would you satisfy everything that EIA 649 requests?
Speaker 2:Yes, yeah, I think if you implemented CM2, you would meet and exceed the requirements in EIA 649.
Speaker 1:Okay, so let's talk a little bit about some real world trips. Right? Like some of the biggest mistakes that people make when they're selecting, they're implementing or just trying to improve you know the tools that they got, so tell me a little bit about your brain there.
Speaker 2:Yeah. So there's a lot of areas and you know many reoccurring mistakes organization makes. When you know, selecting a tool or implementing it, or even trying to improve the process, most of this stuff, or the issues, stem from putting the tool ahead of the process and requirements or underestimating the culture and the organizational factors. So what do we mean by some of this? One is many teams rush to pick the best tool based on features or popularity, rather than mapping their current and future state processes and documenting those business requirements first, and this leads to forcing processes to fit the tool rather than selecting a tool that enables your desired ways of working. Another big thing you know is this cross-functional alignment of tools and needs. You know, whereas decisions for a tool are often made by a single department, you know, like engineering or IT, without involving, you know, upstream and downstream stakeholders, such as quality supply chain service, and this results in those, you know, data silos that persist and cause integration gaps to appear later, which drives all of that costly rework that an organization experiences. And then, you know, with all of that data right, there's this understanding of data readiness and data governance. You know, teams implement these new tools on top of incomplete or inconsistent data, so they're missing data when they go into this. And all of that does is amplifies those existing issues rather than solving them. So without the strong governance of the data, the tool quickly, you know, degrades in accuracy and trustworthiness across the organization. So folks can't rely on the data because it's not all there, it's incomplete or it's inaccurate.
Speaker 2:And then the other big thing is we see that the you know organizations focus on chasing those shiny object capabilities without asking does this feature actually really solve a business problem or improve KPIs? And so they're chasing the new cool thing without adding any context to the current features or the current business process. And that just adds complexity and slow adoption because people still have to do what they need to do to get it done. Now they have to do all this additional stuff. And then one thing you know is enterprise tools succeed or fail really based on the people, not really the technology. So skipping that training, the communication, the stakeholder buy-in results in these low adoption rates. They result in these shadow systems where people are now doing extra work because the tool doesn't meet the requirements or doesn't facilitate that fast, efficient process.
Speaker 2:And the other big thing you know is when you're rolling out a new tool, it's treated like an event and not like the life cycle of a normal product that you purchase or make right, the teams go live and once you cross that finish line, they, you know, are like we're done good and instead of starting, you know the continuous improvement. What's going on where? Where can we do better? So these refinement and feedback loops you know are required and absolutely needed so that the tools don't become misaligned and they meet the evolving business needs. So, kind of you know, ensure the biggest traps is thinking the tool is the actual solution and the key is understanding and optimizing your business processes and requirements first, then selecting and implementing the tool that fits those requirements and processes, while investing in the government's adoption and continuous improvement of the new tool that's been implemented.
Speaker 1:You know, for a long time we've heard our CM2 trainers over decades say tools lead, fools follow, right. So we always say processes lead, tools follow. If tools lead, fools follow. So that one always seems to stick in people's heads. If you need something to help remember which way it really needs to go, and you know. Again, I think, like you said, you know people think that tools are solutions and I think tools often, you know, present themselves as solutions. But you know, like you said earlier, they can automate, you know, a really great process and give you a really great solution. Or it can automate a really cruddy process and be cumbersome and just get you bad data faster. So making sure we're, you know it's just the tool's only going to do what you tell it to do. So you just need to make sure you got good stuff going in on the front side.
Speaker 1:So Yep, so we know change is really hard. We talk about that all the time. It gets kind of cliche, but it is really hard and organizations really struggle with this. You know people resist change even when it's desperately needed for an organization or even for individuals. You know they're in corrective action mode, right, they're firefighting all the day long. They show up for work and they don't know what the heck they're going to do all day, you know, and they give up on planned work because they know that they're just going to support whatever's thrown at them. So we all know that we need change, that we need to be better. You know, we really don't have a lot of excuses here anymore. So I guess, from all of your years of experience, what is the best way to create change that really sticks and is really adopted?
Speaker 2:Yeah, you're absolutely right, change is hard right, even when the need to change is completely obvious. And the biggest lessons that I've learned is that lasting change isn't just about rolling out a new process or a new tool. It's really about shifting the mindsets and embedding the new behaviors in the culture of mindsets and embedding the new behaviors in the culture. And this is what I kind of see that works for me. When we come in and do service engagements, you know we always start with the why. You know people rarely resist change itself. They resist that kind of uncertainty that comes with change. So when you can clearly connect the change to the real business pain points and personal benefits this reduces rework, this helps improve your workload you kind of start turning that resistance into the understanding and with that that involves those folks earlier. So what I've found is the fastest way to create ownership is to co-create the change with all of those stakeholders, so those that will be living it daily. This involves cross-functional teams defining the requirements, mapping out the processes, piloting those solutions so that they feel it's their change, it's not a change being imposed on them, and then make those incremental changes and make them visible. You know big bang changes can overwhelm anyone. So instead of if you can, instead of you know, the big bang change, you break it into smaller pieces and kind of celebrate those wins, show visible progress and that builds the momentum and the trust. And also you want to focus on enabling the users and not enforcing them and not necessarily enforcement of using it. So this comes along with that.
Speaker 2:Training isn't necessarily enough. There may be coaching, there may need to be additional reference materials and you know champions who can help. You know answer questions as the users come up. So training those SMEs and reinforcing these new behaviors in real time, along with bringing them along for the ride. And then, when you kind of get into the sustainment of the change, you know it needs to be part of the daily work. So it needs to be shown in the metrics or the reviews or any decision-making framework that folks should do.
Speaker 2:So this should reflect that new way of operating so people don't kind of slip back into those old habits. And a big one, we said, or a big one I noticed, is acknowledging the cultural side. Right, change impacts the identity of people. They might feel loss of control or fear of obsolescence in their jobs. So you should address those concerns openly and show them how the change benefits them as an individual, not just the organization. And really you know the change sticks when it's co-owned and not mandated and when people see that the purpose, see the purpose and are part of the solution and feel supported throughout the transition, that resistance really turns into this advocacy and you know that's what helps make the change take hold.
Speaker 1:And this is something we talk about all the time and it's just not emphasized enough is that this is important. The people piece will make or break anything, and anyone who's been through one of these experiences has learned that. You know, it's the requirements and the tool and the process. Those pieces are easy. It's the adoption piece that is the hard piece and making sure that it does serve the organization and that you're listening to the organization and continuing to take their voice and incorporate it, and it's crucial to the success of these projects.
Speaker 2:Yes, it absolutely is. The people aspect should never be underestimated.
Speaker 1:So for everyone listening, can you pinpoint one thing maybe that you wish more people understood about implementation of change to a business?
Speaker 2:Yeah, yeah, if I had to, you know kind of pinpoint one thing. It's this Change isn't just a project. It's about shifting how people think and work. You know, too often organizations treat change implementation kind of as a checklist New tool, new processes, go live date. But if you address the human side of why it matters, how it improves their day-to-day life, and you know what support they'll have, people will quickly revert to those habits, no matter how good the solution is. The real key is to design the change around people, not just systems. So when employees see their input reflected in the solution and understand the value to them, not just the company, that's when the changes truly stick.
Speaker 1:Yeah, then it becomes that new baseline and then you're starting from there for any continual improvement, moving forward.
Speaker 2:Yeah, exactly.
Speaker 1:Okay, all right, very cool. Well, we've shared a ton of really great aspects and hopefully we've demystified a little bit of what happens behind the scenes here when people get new processes and tools. Can you just maybe just take a moment before we close here and just share maybe a memorable moment for when the CM2 standards or CM2 framework really made a measurable difference from your career so far?
Speaker 2:So one example that kind of stands out is with a manufacturer that struggles with frequent rework or delayed product launches, and you know this is typically due to misalignment in the change processes and data. So you know, if you have engineering, manufacturing and supply chain, they each have their own version of the truth and changes often took weeks to flow downstream. And you know, when we started to introduce the CM2 standards, you know a few things started happening. Standards, you know a few things started happening. The change process was centralized with clear ownership and traceability. The requirements, the configuration and the change notices were all linked in a kind of a single closed loop system and the cross-functional teams began reviewing changes simultaneously. So they assessed the impact together instead of, you know, kind of this sequential or serial approach. So that helps cut down that approval time quite dramatically.
Speaker 2:So you know what were the results. You know within the year they saw a 40% reduction in cycle or change cycle time and a measurable drop in late stage change reworks, which you know savings can. That directly translated to faster time to market, improved customers' satisfaction. And you know what made it memorable wasn't just the metrics, it was watching the cultural shift. Teams that once worked in those silos started collaborating around this kind of shared framework of CM2. And then you know, for the first time folks trusted the data they were working from and that trust became the foundation for improvements across the enterprise.
Speaker 1:Another buzzword that what we're talking about here, right, is this organizational or enterprise integration is really the key, so it's just another piece of what needs to happen to gain the benefits that people are looking for Exactly All right, well, thank you so much, thomas. These have been absolutely brilliant insights. I hope they're very helpful for others listening. Just thank you so much for sharing your expertise and cracking open these nuances of digital transformation for everyone. I think I'm disappointed we haven't pulled you on here sooner. So thanks for doing this with me. And if listeners want to learn more about these topics or about how to do this better, or your lessons learned, is there a way for them to connect with you directly? How would they do that?
Speaker 2:Thank you. I always enjoy having these kinds of conversations. You know the best place to connect is on LinkedIn. I share a lot of insights there and love engaging with those others who are passionate about transformation and configuration management. You can also reach out directly to me via email at thomas at ipxhqcom.
Speaker 1:Okay, amazing. Well, that's a wrap for today, so stay tuned for more episodes where we do our best to go beneath these buzzwords and spotlight the methods that actually work. So thanks, thomas Talk to you guys. Thanks. Thank you for tuning in today. Don't forget to subscribe and review the show and for more information on IPX visit IPXHQcom.