The Process-First Approach to Digital Transformation Success의 전체 녹취록

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. 00:02:47.099 --> 00:02:55.754 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. 00:02:55.754 --> 00:03:00.588 Right, that happens often for us, and you've worked with countless enterprise tools. 00:03:00.588 --> 00:03:04.030 Which ones do you have the most hands-on experience with? 00:03:04.780 --> 00:03:08.443 Yeah, that's a great question and one that we often hear. 00:03:08.443 --> 00:03:16.342 So I've worked a lot with PLM tools like Teamcenter, windchill, inovia, aeris and those. 00:03:16.342 --> 00:03:27.562 But I have, you know, background across MES tools, erp tools and all that MES tools, erp tools and all that. 00:03:27.562 --> 00:03:32.396 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. 00:03:32.396 --> 00:03:34.502 It's not a universal thing for everyone. 00:03:34.502 --> 00:03:39.592 It's each client has unique needs, that one tool may prevail over the other. 00:03:39.592 --> 00:03:43.681 So, because of that, the right tool isn't chosen in isolation. 00:03:43.681 --> 00:03:48.605 It's dictated by the requirements in the business process that we're trying to enable. 00:03:48.605 --> 00:03:59.933 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. 00:04:00.014 --> 00:04:05.456 People often just come to us with our experience and say hey, you know what's the best PLM tool I should be implementing? 00:04:05.456 --> 00:04:10.467 Right, and I think that there's not an easy answer to that. 00:04:10.467 --> 00:04:12.819 Right, we can tell you the ones that are great and that can do a ton of great, great things. 00:04:12.819 --> 00:04:19.550 But again, there's no one size fits all and it's not like there is one best or the three top best. 00:04:19.550 --> 00:04:23.886 It's really based on what the wants and the needs are of the business. 00:04:24.547 --> 00:04:27.071 Absolutely, really based on what the wants and the needs are of the business. 00:04:27.091 --> 00:04:29.435 Absolutely, yeah, which is, you know kind of why I use the approach of. 00:04:29.475 --> 00:04:43.269 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. 00:04:43.269 --> 00:04:58.612 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. 00:04:58.612 --> 00:05:13.954 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. 00:05:13.954 --> 00:05:21.593 We use those against the documented requirements and see how well they support that process flow and the compliance. 00:05:21.593 --> 00:05:25.461 And then, finally, we have to factor in the scalability and the culture. 00:05:25.461 --> 00:05:39.872 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. 00:05:39.872 --> 00:05:42.062 So it helps with that user adoption. 00:05:42.622 --> 00:05:44.324 We're not just talking about PLM. 00:05:44.324 --> 00:05:51.904 Often PLM is where people come to us for because of CM2 and they think change, configuration management, they think engineering data. 00:05:51.904 --> 00:06:03.086 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. 00:06:03.086 --> 00:06:07.041 So you know it's not just PLM right, it's truly requirements management. 00:06:07.041 --> 00:06:11.608 It could be MES, it could be QMS, it could be ERP, it could be any of those Exactly. 00:06:11.608 --> 00:06:33.605 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. 00:06:33.605 --> 00:06:37.781 And so why does requirements gathering often fail? 00:06:37.781 --> 00:06:48.079 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? 00:06:49.011 --> 00:06:50.255 Yeah, absolutely right. 00:06:50.255 --> 00:07:00.879 There is a common misconception Requirements gathering often fails because teams confuse it with informal brainstorming sessions rather than structured iterative process. 00:07:00.879 --> 00:07:10.170 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. 00:07:10.170 --> 00:07:12.093 And it's because you don't dive deeper, you look at the surface. 00:07:12.093 --> 00:07:15.137 And it's because you don't dive deeper, you look at the surface. 00:07:15.137 --> 00:07:20.324 So you know why does it always fail or why does it tend to fail? 00:07:20.324 --> 00:07:23.430 There's a lack of structure. 00:07:23.430 --> 00:07:29.524 So

brainstorming doesn't differentiate between one's needs and constraints of the system and the process. 00:07:29.524 --> 00:07:38.812 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. 00:07:38.812 --> 00:07:46.213 So without those consistent definitions and formats, you know stakeholders interpret those requirements quite differently. 00:07:46.213 --> 00:07:57.807 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. 00:08:00.410 --> 00:08:06.500 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. 00:08:06.500 --> 00:08:12.682 That's very high level and it's barely scratching the surface. 00:08:12.682 --> 00:08:16.709 And then also there's the missing context right. 00:08:16.709 --> 00:08:27.576 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. 00:08:27.576 --> 00:08:38.009 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. 00:08:38.009 --> 00:08:44.464 So you're actively engaging stakeholders to map out, you know, the as-is processes, the to-be processes. 00:08:44.464 --> 00:08:52.625 You're confirming those through interviews, through meetings, after processes are developed and even into prototypes. 00:08:53.890 --> 00:09:00.812 And I like to use a structured format when I'm capturing that the requirements, so that they are clear and testable. 00:09:00.933 --> 00:09:16.863 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. 00:09:22.929 --> 00:09:25.159 And then, additionally, it allows us to link those requirements to the objectives we're trying to meet. 00:09:25.159 --> 00:09:28.010 Right, just because someone has a requirement doesn't mean it actually fits into the current process. 00:09:28.010 --> 00:09:36.453 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. 00:09:36.453 --> 00:09:48.825 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. 00:09:48.825 --> 00:09:50.746 And then again it's iterative. 00:09:50.746 --> 00:10:03.589 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. 00:10:03.589 --> 00:10:17.961 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. 00:10:18.789 --> 00:10:24.899 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? 00:10:26.330 --> 00:10:32.330 Yeah, out of the box is one of those things where the tool can pretty much do whatever you want. 00:10:32.330 --> 00:10:37.941 You still have to configure it to map to what your current process is. 00:10:37.941 --> 00:10:45.863 And what we most often see is the current process is years that have just built on because we had a failure here. 00:10:45.863 --> 00:10:52.802 We had that, so it's not necessarily fixing the root cause of the issue, but it is. 00:10:52.802 --> 00:10:56.532 You know, band-aiding something that didn't work or we had an escape. 00:10:56.532 --> 00:11:04.356 So you know you need to follow through and make sure that the tool is configured correctly. 00:11:04.356 --> 00:11:08.799 So commercial off the shelf or out of the box is kind of a misnomer. 00:11:09.321 --> 00:11:17.927 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. 00:11:17.927 --> 00:11:19.327 They want to automate what you do today. 00:11:19.327 --> 00:11:24.510 They're not there to improve your ways of working per se. 00:11:24.510 --> 00:11:42.506 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. 00:11:50.909 --> 00:11:54.711 Exactly, yeah, automation if you don't have a good process, just allows you to create bad data quicker? 00:11:54.731 --> 00:11:55.913 Yeah, nobody wants that. 00:11:55.932 --> 00:11:56.373 No, they sure don't. 00:11:56.373 --> 00:12:11.120 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? 00:12:11.961 --> 00:12:25.148 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. 00:12:25.148 --> 00:12:44.529 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. 00:12:44.529 --> 00:12:48.879 So business requirements are typically high level and solution agnostic. 00:12:48.879 --> 00:12:59.404 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. 00:12:59.404 --> 00:13:03.621 So that's, you know, that's how a business requirement works. 00:13:04.365 --> 00:13:10.679 Now a functional specification defines how the system will meet those business requirements. 00:13:10.679 --> 00:13:31.062 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. 00:13:31.062 --> 00:13:41.976 Functional spec would say implement a role-based access control model using active directory groups with permissions configurable at the document and BOM level. 00:13:41.976 --> 00:13:53.573 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. 00:13:53.573 --> 00:14:02.461 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. 00:14:02.461 --> 00:14:04.573 The functional spec is the how. 00:14:04.573 --> 00:14:06.940 How is it designed, how is it implemented? 00:14:06.940 --> 00:14:19.361 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. 00:14:20.009 --> 00:14:22.532 It's kind of like baking a cookie, right, like you know. 00:14:22.532 --> 00:14:25.320 The business side says what do we want? 00:14:25.320 --> 00:14:29.456 Right, this is what we want and this is what we enjoy, this is the things that we need. 00:14:29.456 --> 00:14:36.592 But then the system integrators, they need to write that recipe right, like what's the best way to achieve those requirements. 00:14:36.592 --> 00:14:38.715 There may be multiple ways to do that, depending on the tool. 00:14:39.495 --> 00:14:39.917 Exactly. 00:14:40.096 --> 00:14:45.982 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. 00:14:45.982 --> 00:14:48.346 If this was a great way, I wanted to do this. 00:14:48.346 --> 00:14:53.912 Well, that may have worked really well in one specific tool, but it may not work the same way. 00:14:53.912 --> 00:15:06.947 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. 00:15:07.830 --> 00:15:15.092 Yes, yeah, and the current tool that you've picked may not be the right tool for those set of requirements. 00:15:15.092 --> 00:15:20.191 So you don't want to tie in solution and specific tool. 00:15:20.191 --> 00:15:25.511 You would like the system integrator or the IT folks to figure out what's the best tool for those requirements. 00:15:26.674 --> 00:15:27.135 I like that. 00:15:27.135 --> 00:15:32.932 Okay, so at IPX we're more on the business side, right, like we're process people. 00:15:32.932 --> 00:15:35.938 So we want to help you with that optimized process. 00:15:35.938 --> 00:15:39.245 First, that's how you're going to get your business requirements. 00:15:39.245 --> 00:15:48.823 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. 00:15:48.823 --> 00:15:53.292 Yes, so you know some people think you know. 00:15:53.292 --> 00:15:58.995 Well, you know I, you know how do I, how do I know what my, my, my business process needs to be right. 00:15:58.995 --> 00:16:02.957 Let's say they're not using someone like yourself or IPX to help us with this. 00:16:02.957 --> 00:16:08.621 You know we, we do have a CM2-500, and how do organizations use it? 00:16:08.621 --> 00:16:23.890 Because I'm guessing many people come out of our training and they're not sure what to do with this thing, right? 00:16:23.890 --> 00:16:24.753 So tell me your thoughts. 00:16:25.333 --> 00:16:35.698 Yeah, so CM2-500 kind of is that enterprise level standard for integrating, you know, configuration management into the broader business. 00:16:36.440 --> 00:16:47.216 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. 00:16:48.138 --> 00:17:12.099 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. 00:17:12.099 --> 00:17:27.761 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. 00:17:27.761 --> 00:17:33.787 All of these tools should adhere to the same logic and the same commitment. 00:17:33.787 --> 00:17:35.127 And the same commitment. 00:17:35.127 --> 00:17:44.040 We use this to help understand and identify potential cycle time changes in improving data integrity and minimizing downstream work with the SIEM 2500. 00:17:44.040 --> 00:17:47.096 So it's all about process optimization. 00:17:47.096 --> 00:18:11.640 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. 00:18:11.680 --> 00:18:19.305 You know, a guiding light is maybe a word I might use to help organizations figure. 00:18:19.305 --> 00:18:23.667 Okay, we know we've got some problems, but we don't really know the best ways to fix them. 00:18:31.490 --> 00:18:34.878 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. 00:18:34.878 --> 00:18:52.573 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. 00:18:52.573 --> 00:18:57.434 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. 00:18:57.434 --> 00:19:03.714 So you want to use this in a tactical way to then help improve those pain points within your business. 00:19:04.356 --> 00:19:16.356 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. 00:19:22.849 --> 00:19:23.352 Okay, all right, very good. 00:19:23.352 --> 00:19:25.720 So you know, just discuss a little bit of a different standard for a second. 00:19:25.720 --> 00:19:27.566 So some of our military friends and governmental friends. 00:19:27.566 --> 00:19:32.612 They are often required to utilize EIA-649. 00:19:32.612 --> 00:19:36.513 This standard often gets referenced for the standard for configuration management. 00:19:36.513 --> 00:19:38.355 So let's talk about that. 00:19:38.355 --> 00:19:45.259 For a second, for teams who are relying on 649, what might shift if they were? 00:19:45.338 --> 00:19:55.903 that helps kind of establish those core principles for identifying, controlling and verifying configuration items. 00:19:55.903 --> 00:20:08.731 However, it's intentionally focused as guidance. 00:20:08.731 --> 00:20:15.684 It tells you what a good configuration management solution looks like, but not how to implement it across the enterprise. 00:20:15.684 --> 00:20:20.452 So you know what kind of shifts with adopting CM2? 00:20:20.452 --> 00:20:20.452 . 00:20:20.452 --> 00:20:28.150 So you know, eia 649 is the guidelines and CM2 is the prescriptive practices. 00:20:28.150 --> 00:20:50.892 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. 00:20:50.892 --> 00:20:58.801 So CM2 really just enhances 649 and provides the you know kind of how-to on it. 00:20:58.801 --> 00:21:15.859 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. 00:21:15.859 --> 00:21:26.959 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. 00:21:28.089 --> 00:21:53.280 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. 00:21:55.191 --> 00:22:27.759 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. 00:22:27.759 --> 00:22:40.701 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. 00:22:40.701 --> 00:22:45.316 So really adopting CM2 doesn't replace 649. 00:22:45.316 --> 00:22:46.806 It actually builds on it. 00:22:46.806 --> 00:23:06.827 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. 00:23:06.847 --> 00:23:20.472 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. 00:23:21.034 --> 00:23:21.255 Yes. 00:23:22.017 --> 00:23:27.616 Okay, and so I think you know, would it be fair to say EA649 is great. 00:23:27.616 --> 00:23:46.820 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. 00:23:47.904 --> 00:23:58.855 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. 00:23:58.855 --> 00:24:00.018 That's common. 00:24:00.664 --> 00:24:04.852 Okay and often people are required to satisfy 649. 00:24:04.852 --> 00:24:07.576 So they do that, which is great.

00:24:07.576 --> 00:24:10.359 It's still a great standard to follow. 00:24:10.359 --> 00:24:24.414 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. 00:24:24.414 --> 00:24:32.821 I think in the other direction would you say, if you implemented CM2, would you satisfy everything that EIA 649 requests? 00:24:33.541 --> 00:24:42.558 Yes, yeah, I think if you implemented CM2, you would meet and exceed the requirements in EIA 649. 00:24:43.244 --> 00:24:47.571 Okay, so let's talk a little bit about some real world trips. 00:24:47.571 --> 00:24:48.012 Right? 00:24:48.012 --> 00:24:58.714 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. 00:24:59.925 --> 00:25:00.006 Yeah. 00:25:00.006 --> 00:25:05.817 So there's a lot of areas and you know many reoccurring mistakes organization makes. 00:25:05.817 --> 00:25:22.686 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. 00:25:22.686 --> 00:25:25.893 So what do we mean by some of this? 00:25:25.893 --> 00:25:48.817 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. 00:25:48.817 --> 00:25:55.952 Another big thing you know is this cross-functional alignment of tools and needs. 00:25:55.952 --> 00:26:21.739 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. 00:26:21.739 --> 00:26:30.152 And then, you know, with all of that data right, there's this understanding of data readiness and data governance. 00:26:30.152 --> 00:26:36.992 You know, teams implement these new tools on top of incomplete or inconsistent data, so they're missing data when they go into this. 00:26:36.992 --> 00:26:42.770 And all of that does is amplifies those existing issues rather than solving them. 00:26:42.770 --> 00:26:52.775 So without the strong governance of the data, the tool quickly, you know, degrades in accuracy and trustworthiness across the organization. 00:26:52.775 --> 00:26:58.213 So folks can't rely on the data because it's not all there, it's incomplete or it's inaccurate. 00:26:59.155 --> 00:27:14.932 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? 00:27:14.932 --> 00:27:26.640 And so they're chasing the new cool thing without adding any context to the current features or the current business process. 00:27:26.640 --> 00:27:32.727 And that just adds complexity and slow adoption because people still have to do what they need to do to get it done. 00:27:32.727 --> 00:27:34.771 Now they have to do all this additional stuff. 00:27:34.771 --> 00:27:44.055 And then one thing you know is enterprise tools succeed or fail really based on the people, not really the technology. 00:27:44.055 --> 00:27:51.936 So skipping that training, the communication, the stakeholder buy-in results in these low adoption rates. 00:27:51.936 --> 00:28:02.575 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. 00:28:03.625 --> 00:28:25.195 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. 00:28:25.195 --> 00:28:26.807 What's going on where? 00:28:26.807 --> 00:28:27.971 Where can we do better? 00:28:27.971 --> 00:28:38.224 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. 00:28:38.224 --> 00:29:05.797 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. 00:29:06.257 --> 00:29:15.480 You know, for a long time we've heard our CM2 trainers over decades say tools lead, fools follow, right. 00:29:15.480 --> 00:29:18.383 So we always say processes lead, tools follow. 00:29:18.383 --> 00:29:20.864 If tools lead, fools follow. 00:29:20.864 --> 00:29:23.249 So that one always seems to stick in people's heads. 00:29:23.249 --> 00:29:27.586 If you need something to help remember which way it really needs to go, and you know. 00:29:27.586 --> 00:29:34.914 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. 00:29:34.914 --> 00:29:41.605 But you know, like you said earlier, they can automate, you know, a really great process and give

you a really great solution. 00:29:41.605 --> 00:29:47.446 Or it can automate a really cruddy process and be cumbersome and just get you bad data faster. 00:29:47.446 --> 00:29:52.246 So making sure we're, you know it's just the tool's only going to do what you tell it to do. 00:29:52.246 --> 00:29:55.273 So you just need to make sure you got good stuff going in on the front side. 00:29:55.453 --> 00:29:58.633 So Yep, so we know change is really hard. 00:29:58.633 --> 00:30:00.622 We talk about that all the time. 00:30:00.622 --> 00:30:05.055 It gets kind of cliche, but it is really hard and organizations really struggle with this. 00:30:05.055 --> 00:30:13.935 You know people resist change even when it's desperately needed for an organization or even for individuals. 00:30:13.935 --> 00:30:16.006 You know they're in corrective action mode, right, they're firefighting all the day long. 00:30:16.006 --> 00:30:23.953 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. 00:30:23.953 --> 00:30:28.182 So we all know that we need change, that we need to be better. 00:30:28.182 --> 00:30:31.190 You know, we really don't have a lot of excuses here anymore. 00:30:31.190 --> 00:30:40.426 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? 00:30:41.367 --> 00:30:48.833 Yeah, you're absolutely right, change is hard right, even when the need to change is completely obvious. 00:30:48.833 --> 00:30:58.098 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. 00:30:58.098 --> 00:31:08.988 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. 00:31:08.988 --> 00:31:09.970 And this is what I kind of see that works for me. 00:31:09.970 --> 00:31:13.806 When we come in and do service engagements, you know we always start with the why. 00:31:13.806 --> 00:31:16.832 You know people rarely resist change itself. 00:31:16.832 --> 00:31:21.067 They resist that kind of uncertainty that comes with change. 00:31:21.067 --> 00:31:39.856 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. 00:31:39.856 --> 00:31:50.795 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. 00:31:50.795 --> 00:32:08.700 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. 00:32:08.700 --> 00:32:12.471 You know big bang changes can overwhelm anyone. 00:32:12.471 --> 00:32:23.531 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. 00:32:23.531 --> 00:32:34.296 And also you want to focus on enabling the users and not enforcing them and not necessarily enforcement of using it. 00:32:34.296 --> 00:32:36.548 So this comes along with that. 00:32:36.587 --> 00:32:38.432 Training isn't necessarily enough. 00:32:38.432 --> 00:32:45.160 There may be coaching, there may need to be additional reference materials and you know champions who can help. 00:32:45.160 --> 00:32:48.147 You know answer questions as the users come up. 00:32:48.147 --> 00:32:55.730 So training those SMEs and reinforcing these new behaviors in real time, along with bringing them along for the ride. 00:32:55.730 --> 00:33:04.292 And then, when you kind of get into the sustainment of the change, you know it needs to be part of the daily work. 00:33:04.292 --> 00:33:10.804 So it needs to be shown in the metrics or the reviews or any decision-making framework that folks should do. 00:33:10.903 --> 00:33:16.958 So this should reflect that new way of operating so people don't kind of slip back into those old habits. 00:33:16.958 --> 00:33:22.477 And a big one, we said, or a big one I noticed, is acknowledging the cultural side. 00:33:22.477 --> 00:33:25.973 Right, change impacts the identity of people. 00:33:25.973 --> 00:33:30.153 They might feel loss of control or fear of obsolescence in their jobs. 00:33:30.153 --> 00:33:37.354 So you should address those concerns openly and show them how the change benefits them as an individual, not just the organization. 00:33:37.354 --> 00:33:58.296 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. 00:33:59.288 --> 00:34:05.512 And this is something we talk about all the time and it's just not emphasized enough is that this is important. 00:34:05.512 --> 00:34:10.596 The people piece will make or break anything, and anyone who's been through one of these experiences has learned that. 00:34:10.596 --> 00:34:15.514 You know, it's the requirements and the tool and the process. 00:34:15.514 --> 00:34:16.677 Those pieces are easy. 00:34:16.677 --> 00:34:31.275 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. 00:34:32.467 --> 00:34:33.572 Yes, it

absolutely is. 00:34:33.572 --> 00:34:36.454 The people aspect should never be underestimated. 00:34:37.505 --> 00:34:47.635 So for everyone listening, can you pinpoint one thing maybe that you wish more people understood about implementation of change to a business? 00:34:48.565 --> 00:34:51.851 Yeah, yeah, if I had to, you know kind of pinpoint one thing. 00:34:51.851 --> 00:34:56.967 It's this Change isn't just a project. 00:34:56.967 --> 00:35:00.737 It's about shifting how people think and work. 00:35:00.737 --> 00:35:10.014 You know, too often organizations treat change implementation kind of as a checklist New tool, new processes, go live date. 00:35:10.014 --> 00:35:24.293 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. 00:35:24.293 --> 00:35:28.295 The real key is to design the change around people, not just systems. 00:35:28.295 --> 00:35:38.797 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. 00:35:40.184 --> 00:35:45.371 Yeah, then it becomes that new baseline and then you're starting from there for any continual improvement, moving forward. 00:35:45.391 --> 00:35:47.175 Yeah, exactly. 00:35:47.195 --> 00:35:50.023 Okay, all right, very cool. 00:35:50.023 --> 00:36:00.237 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. 00:36:00.237 --> 00:36:12.539 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? 00:36:13.045 --> 00:36:26.925 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. 00:36:26.925 --> 00:36:37.161 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. 00:36:37.161 --> 00:36:44.358 And you know, when we started to introduce the CM2 standards, you know a few things started happening. 00:36:44.358 --> 00:36:48.547 Standards, you know a few things started happening. 00:36:48.547 --> 00:36:50.693 The change process was centralized with clear ownership and traceability. 00:36:50.693 --> 00:37:03.409 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. 00:37:03.409 --> 00:37:10.996 So they assessed the impact together instead of, you know, kind of this sequential or serial approach. 00:37:10.996 --> 00:37:15.608 So that helps cut down that approval time quite dramatically. 00:37:16.271 --> 00:37:18.255 So you know what were the results. 00:37:18.255 --> 00:37:30.951 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. 00:37:30.951 --> 00:37:37.132 That directly translated to faster time to market, improved customers' satisfaction. 00:37:37.132 --> 00:37:42.547 And you know what made it memorable wasn't just the metrics, it was watching the cultural shift. 00:37:42.547 --> 00:37:50.300 Teams that once worked in those silos started collaborating around this kind of shared framework of CM2. 00:37:50.300 --> 00:38:00.516 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. 00:38:01.125 --> 00:38:17.114 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. 00:38:17.114 --> 00:38:19.184 These have been absolutely brilliant insights. 00:38:19.184 --> 00:38:22.235 I hope they're very helpful for others listening. 00:38:22.235 --> 00:38:29.713 Just thank you so much for sharing your expertise and cracking open these nuances of digital transformation for everyone. 00:38:29.713 --> 00:38:33.630 I think I'm disappointed we haven't pulled you on here sooner. 00:38:33.630 --> 00:38:35.231 So thanks for doing this with me. 00:38:35.231 --> 00:38:46.990 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? 00:38:46.990 --> 00:38:47.753 How would they do that? 00:38:48.275 --> 00:38:48.655 Thank you. 00:38:48.655 --> 00:38:52.016 I always enjoy having these kinds of conversations. 00:38:52.016 --> 00:38:55.715 You know the best place to connect is on LinkedIn. 00:38:55.715 --> 00:39:02.891 I share a lot of insights there and love engaging with those others who are passionate about transformation and configuration management. 00:39:02.891 --> 00:39:10.492 You can also reach out directly to me via email at thomas at ipxhqcom. 00:39:11.795 --> 00:39:12.737 Okay, amazing. 00:39:12.737 --> 00:39:21.476 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. 00:39:21.476 --> 00:39:23.108 So thanks, thomas Talk to you guys. 00:39:23.108 --> 00:39:23.768 Thanks. 00:39:23.768 --> 00:39:25.994 Thank you for tuning in today. 00:39:25.994 --> 00:39:33.996 Don't forget to subscribe and review the show and for more information on IPX visit IPXHQcom.