August 29, 2025 • 39 mins
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.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Welcome to the IPX True North podcast, where we
connect people, processes andtools.
Hello and welcome to today'sepisode of the IPX True North
podcast, where we dive into theprinciples, processes and tools
that bring true operationalharmony.
So I'm your host, brandi Taylor,and I'm joined today by a guest
(00:23):
whose expertise in helpingorganizations bridge the gap
between Thomas is a really goodfriend of mine.
He is the Director ofEnterprise Systems and Processes
for IPX and he has over 20years of experience improving
processes and writingrequirements for the tools that
then automate these processes,which exactly is the topic that
(00:43):
we're going to explore today andand demystify.
You know what Thomas does on adaily basis, in case people are
wondering what we do here on theservices side of IPX.
So you know, often too often Ifeel people are simply often the
recipient of a new or updatedprocess or tool and you know
they're often handed the outcomewithout having been a part of
(01:06):
shaping it as much as theyshould have been in the future
from the start.
So today I want to demystifythat with Thomas here and then
shed some light on how theseprojects are kind of defined
from the very beginning.
So, thomas, welcome to the show.
Speaker 2 (01:20):
Thank you.
Speaker 1 (01:22):
All right.
Well, to kind of kick this offa little bit with a touch of
background, there's a lot ofbuzzwords for what we do on the
services side of IPX.
Right, we talk about enterpriseexcellence, digital
transformation, processimprovement, operational
excellence, master datamanagement, value stream
optimization, harmonization.
You know like all these so manybuzzwords for what we do.
(01:42):
Optimization, harmonization.
You know like all these so manybuzzwords for what we do.
Speaker 2 (01:45):
Just to kind of give our audience a little bit of a
background, how do you describeyour role at IPX when someone
outside of our industry asksyeah, so my role, you know, is
(02:07):
basically understanding thewants and needs of the people
and being able to translate thatfrom business speak into
technical speak for the peoplethat are going to implement the
solution.
So it's understanding what thespirit of what they're asking,
instead of just the words thatthey're saying.
Speaker 1 (02:16):
Awesome, and so give an example.
What does a typical day looklike for Thomas Miller?
Speaker 2 (02:23):
Yeah, a typical day.
I mean it's a lot of workingwith the clients and
understanding you know theirwants and their needs and kind
of digging deeper into why it'sthat way, understanding how
they're operating as well as youknow, helping them progress and
communicate to the organizationwhere they want to go, and
(02:45):
doing that clearly.
Speaker 1 (02:47):
So let's shift gears slightly here, because people
often come to us at IPX becausethey want a fancy new tool to
solve all their problems.
Right, that happens often forus, and you've worked with
countless enterprise tools.
Which ones do you have the mosthands-on experience with?
Speaker 2 (03:04):
Yeah, that's a great question and one that we often
hear.
So I've worked a lot with PLMtools 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.
(03:27):
And you know with this, youknow each one of these tools has
great strengths, but it's notbeing able to declare which
one's the best.
It's not a universal thing foreveryone.
It's each client has uniqueneeds, that one tool may prevail
over the other.
So, because of that, the righttool isn't chosen in isolation.
It's dictated by therequirements in the business
process that we're trying toenable.
(03:48):
So too often, companies pick atool first and then they focus
on the processes to conform,which creates the friction, the
workarounds and the misalignmentwith the strategic goals.
Speaker 1 (04:00):
People often just come to us with our experience
and say hey, you know what's thebest PLM tool I should be
implementing?
Right, and I think that there'snot an easy answer to that.
Right, we can tell you the onesthat are great and that can do
a ton of great, great things.
But again, there's no one sizefits all and it's not like there
is one best or the three topbest.
It's really based on what thewants and the needs are of the
(04:23):
business.
Speaker 2 (04:24):
Absolutely, really based on what the wants and the
needs are of the business.
Absolutely, yeah, which is, youknow kind of why I use the
approach of.
You know we got to understandwhat the business processes are
first, you know, mapping themout of what they currently look
like and working on futurestates so that we can help
identify those gaps and clarifywhat success and what a client's
utopia looks like.
And then from there, you knowwe have to document the
(04:47):
requirements, the businessrequirements, clearly, because
this translates the needs andthe wants into kind of a
structured and testable set ofrequirements that distinguish
the must-haves from thenice-to-haves.
And then, ultimately, what wedo is we take those requirements
and business processes andevaluate those against the tool,
and this helps us assess thecapabilities of whatever tool it
(05:10):
is, whether it's PDM, plm, erp,nes, etc.
We use those against thedocumented requirements and see
how well they support thatprocess flow and the compliance.
And then, finally, we have tofactor in the scalability and
the culture.
Culture is a huge aspect ofthis and that will help or
(05:32):
hinder the success of deployingany tool in the system if the
organization isn't ready for itor there's concerns.
So it helps with that useradoption.
Speaker 1 (05:42):
We're not just talking about PLM.
Often PLM is where people cometo us for because of CM2 and
they think change, configurationmanagement, they think
engineering data.
But CM2 truly is end-to-endright and there's multiple tools
that are engaged in thatprocess across your digital
thread and we worked in all ofthem.
(06:03):
So you know it's not just PLMright, it's truly requirements
management.
It could be MES, it could beQMS, it could be ERP, it could
be any of those Exactly.
Now, one thing I wanted toclear up kind of a big
misconception that we often hearis too often teams say that
they've gathered requirementsright, and when we dive into
(06:24):
what they mean by that, they'rereally pulling people together
in a room and they'rebrainstorming in Word or Excel
of what they want this tool todo.
And so why does requirementsgathering often fail?
And then how do we help peoplemove away from those vague ideas
in Excel to communicatingclearly what are the wants and
(06:47):
needs that you're looking for?
Speaker 2 (06:49):
Yeah, absolutely right.
There is a common misconceptionRequirements gathering often
fails because teams confuse itwith informal brainstorming
sessions rather than structurediterative process.
You know, just capturing theideas in Word or Excel might
help to start thoseconversations, but it rarely
ensures the clarity, alignmentand traceability across everyone
(07:10):
.
And it's because you don't divedeeper, you look at the surface
.
And it's because you don't divedeeper, you look at the surface
.
So you know why does it alwaysfail or why does it tend to fail
?
There's a lack of structure.
So brainstorming doesn'tdifferentiate between one's
needs and constraints of thesystem and the process.
And also one big thing that wesee is there's no shared
(07:32):
language across teams, evenwithin the same organization or
across the same functions.
So without those consistentdefinitions and formats, you
know stakeholders interpretthose requirements quite
differently.
And when you have thosespreadsheets and documents,
there's often a lack of versioncontrol or linkage between the
(07:53):
design testing and changemanagement, or linkage between
the design testing and changemanagement.
We recently had a client thatwas doing a change process for
their entire organization andthey had 10 requirements for an
entire change process.
That's very high level and it'sbarely scratching the surface.
And then also there's themissing context right.
(08:16):
So brainstorming focuses onwhat we think we need instead of
validating, against thoseprocess gaps, what the user does
on a day-to-day business orwhat the business's objectives
are.
And in order to move forwardright, you have to have that
mentality, or the shift fromgathering to elicitation and
(08:36):
validation of the requirements.
So you're actively engagingstakeholders to map out, you
know, the as-is processes, theto-be processes.
You're confirming those throughinterviews, through meetings,
after processes are developedand even into prototypes.
And I like to use a structuredformat when I'm capturing that
(08:58):
the requirements, so that theyare clear and testable.
So I always follow an I want sothat acceptance criteria format
which helps distinguish betweenthe functional and
non-functional needs of theorganization, so it helps those
delivering it understand whatthe tool must do or is it
business process and so forth.
(09:22):
And then, additionally, itallows us to link those
requirements to the objectiveswe're trying to meet.
Right, just because someone hasa requirement doesn't mean it
actually fits into the currentprocess.
So we have to make sure thatthose align with the business
goals and they're measurable sothat we actually can say, hey,
we've actually efficiently donethis process.
And you know this helps byimplementing tools that are
requirements managementplatforms so they help connect
(09:44):
those requirements from design,testing and through all the
changes.
And then again it's iterative.
It's an iterative andvalidation process where you
treat the requirements as livingartifacts that evolve through
feedback, review and impactassessments, just like our
change processes should.
So you know, moving from thesevague lists to structured
(10:06):
requirements ensures thatstakeholders share a single
source of ultra driving forbetter decisions, reducing that
rework and improving the overallquality of what their needs and
wants are.
Speaker 1 (10:18):
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 (10:26):
Yeah, out of the box is one of those things where the
tool can pretty much dowhatever you want.
You still have to configure itto map to what your current
process is.
And what we most often see isthe current process is years
that have just built on becausewe had a failure here.
We had that, so it's notnecessarily fixing the root
(10:49):
cause of the issue, but it is.
You know, band-aiding somethingthat didn't work or we had an
escape.
So you know you need to followthrough and make sure that the
tool is configured correctly.
So commercial off the shelf orout of the box is kind of a
misnomer.
Speaker 1 (11:09):
And you know, I know, like our system integrator
friends and you know toolimplementers, they're so good at
what they do they want toautomate your ways of working.
They want to automate what youdo today.
They're not there to improveyour ways of working per se.
Right, so you may get someefficiencies from automating,
but if you have a clunky processthat has a lot of those
(11:31):
band-aids like you're talkingabout from an audit or from
quality issues or whatever,where we've done these band-aids
and small fixes, it becomes avery difficult and cumbersome
thing to automate.
Exactly, yeah, automation if youdon't have a good process, just
(11:53):
allows you to create bad dataquicker?
Speaker 2 (11:54):
Yeah, nobody wants that.
Speaker 1 (11:55):
No, they sure don't.
Another thing I want to getyour brain on is I want to
clarify something that's prettyfundamental for us but maybe not
for others, is what is thedifference between a business
requirement and then afunctional specification?
Speaker 2 (12:11):
Yeah, this distinction always gets blurred,
but it's critical to understandwhat its intent is for
alignment across theorganization, not only with the
business but also with theperson that's implementing the
solution.
So the way I like to thinkabout it is a business
(12:34):
requirement defines what anorganization needs to achieve
and why it's focused on theoutcome or the value to the
business that they're seeking toimprove that traceability,
reducing cycle time and enablinglike regulatory requirements.
So business requirements aretypically high level and
solution agnostic.
So an example is the systemmust allow secure, role-based
access so that authorized userscan only view the sensitive data
(12:58):
of the product.
So that's, you know, that's howa business requirement works.
Now a functional specificationdefines 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 andthe tool, you know, with the
(13:19):
inputs, the outputs and how itinteracts with the users and
also other systems to fulfillthose business needs.
Functional spec would sayimplement a role-based access
control model using activedirectory groups with
permissions configurable at thedocument and BOM level.
(13:41):
So basically what it's sayingis now we've gotten into the
solution with the functionalspec, whereas the business
requirements are the needs andthe wants of the business.
One way to kind of, you know,recap that is, the business
requirements are the what andwhy, so the value and the
outcomes that are expected.
(14:02):
The functional spec is the how.
How is it designed, how is itimplemented?
You know, keeping theseparation is quite important,
because business requirementsensure that we're solving the
right problem, while thefunctional specification ensures
we're building the rightsolution.
Speaker 1 (14:20):
It's kind of like baking a cookie, right, like you
know.
The business side says what dowe want?
Right, this is what we want andthis 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 wayto achieve those requirements.
There may be multiple ways todo that, depending on the tool.
Speaker 2 (14:39):
Exactly.
Speaker 1 (14:40):
So in so many people's solution right, they
want to give you hey, I've donethis in this previous tool or at
my previous job.
If this was a great way, Iwanted to do this.
Well, that may have workedreally well in one specific tool
, but it may not work the sameway.
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 outwhat is the best way to do
(15:03):
something and come up with themost simplest, best and
optimized solution.
Speaker 2 (15:07):
Yes, yeah, and the current tool that you've picked
may not be the right tool forthose set of requirements.
So you don't want to tie insolution and specific tool.
You would like the systemintegrator or the IT folks to
figure out what's the best toolfor those requirements.
Speaker 1 (15:26):
I like that.
Okay, so at IPX we're more onthe business side, right, like
we're process people.
So we want to help you withthat optimized process.
First, that's how you're goingto get your business
requirements.
Then that's how you're going tocommunicate very clearly your
wants, your needs, yourexpectations, to then the
solution or vendor in order toget what you're looking for.
(15:48):
Yes, so you know some peoplethink you know.
Well, you know I, you know howdo I, how do I know what my, my,
my business process needs to beright.
Let's say they're not usingsomeone like yourself or IPX to
help us with this.
You know we, we do have aCM2-500, and how do
organizations use it?
Because I'm guessing manypeople come out of our training
(16:21):
and they're not sure what to dowith this thing, right?
So tell me your thoughts.
Speaker 2 (16:25):
Yeah, so CM2-500 kind of is that enterprise level
standard for integrating, youknow, configuration management
into the broader business.
You know, and it helps addressthe governance, the digital
thread, you know, closed loopprocesses and ensuring that data
stays accurate and alignedacross its entire lifecycle.
(16:48):
And this includes, you know,process mapping, maturity
assessments, optimizationstrategies to scale CM beyond
engineering and into, you know,other areas like supply chain,
manufacturing, quality servicewith that, and so organizations
can use this to assess andbenchmark their current process
(17:09):
maturity and help them identifygaps.
It also helps thoseorganizations 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 shouldadhere to the same logic and the
(17:32):
same commitment.
And the same commitment.
We use this to help understandand identify potential cycle
time changes in improving dataintegrity and minimizing
downstream work with the SIEM2500.
So it's all about processoptimization.
And then you know, if you lookat it at a really big scale, it
(17:53):
helps with that digital you know, digital transformation of
roadmap, where it supportsbuilding this scalable digital
thread that helps connect thosedesign, the requirements,
manufacturing, field servicedata into each other standard is
.
Speaker 1 (18:11):
You know, a guiding light is maybe a word I might
use to help organizations figure.
Okay, we know we've got someproblems, but we don't really
know the best ways to fix them.
So the framework of CM2 reallyjust gives them we call it true
(18:32):
north right of the bestpractices of 40 years across
industry across the globe.
And this is the way where youdon'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 frameworkand the standard to then figure
out how do we surgically solvethis specific pain point.
Right, you may have otherthings you're not doing exactly
(18:55):
the right way, but it's workingfor you and it's no problem.
So you want to use this in atactical way to then help
improve those pain points withinyour business.
Speaker 2 (19:04):
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 specificpain point, for the entire
organization.
Speaker 1 (19:22):
Okay, all right, very good.
So you know, just discuss alittle bit of a different
standard for a second.
So some of our military friendsand governmental friends.
They are often required toutilize EIA-649.
This standard often getsreferenced for the standard for
configuration management.
So let's talk about that.
For a second, for teams who arerelying on 649, what might
(19:43):
shift if they were?
Speaker 2 (19:45):
that helps kind of establish those core principles
for identifying, controlling andverifying configuration items.
However, it's intentionallyfocused as guidance.
(20:08):
It tells you what a goodconfiguration management
solution looks like, but not howto implement it across the
enterprise.
So you know what kind of shiftswith adopting CM2?
.
So you know, eia 649 is theguidelines and CM2 is the
prescriptive practices.
So where EIA 649 provides thoseflexible principles that each
(20:33):
organization interprets andimplies differently, cm2 offers
a prescriptive closed-loopmethodology that helps define
roles, workflows, decisionpoints, reducing the ambiguity
and variability across the teams.
So CM2 really just enhances 649and provides the you know kind
(20:57):
of how-to on it.
And with that, you know, eai649 is kind of often applied to
just engineering or in kind ofprogrammatic silos, whereas CM2
kind of expands theconfiguration management across
the enterprise.
So it integrates, you know,engineering, supply chain,
(21:19):
manufacturing, quality, theservices into kind of this
single digital thread and thenwith change management, right.
So EA649 has a, or supports astructured change control, but
it doesn't necessarily address,like the cycle time of the
change or the process agilitythat's needed, while CM2 kind of
(21:42):
emphasizes, you know, a fastimpact assessed change that
helps maintain that dataintegrity while working to
reduce rework and delays in thesystem.
Also, you know, eai 649 focuseson the configuration control but
leaves the requirement handlingto other frameworks where, you
(22:03):
know, cm2 has requirements thatare tightly integrated with
everything they do and it's tiedto the configurations, the
change managements and thisensures that every decision
traces back to a valid businessneed and with that, eia-649
doesn't prescribe kind of a fulldigital thread or an enterprise
(22:26):
integration approach.
You know you have to piece thattogether, whereas CM2 helps
provide that roadmap for digitalscalability and transformation
while aligning all of yoursystems under kind of a single
governance model.
So really adopting CM2 doesn'treplace 649.
It actually builds on it.
So CM2 kind of operationalizesthe principles of EIA 649 into
(22:53):
kind of that repeatableenterprise-wide practices, which
allows faster change cycles,better data accuracy and
improved cross-functionalalignment across the
organization improvecross-functional alignment
across the organization.
Speaker 1 (23:06):
Okay, so EIA 649 really is a foundational set of
requirements and it just doesn'treally tell you that lower
level tactical best practices ofhow to achieve it, but it kind
of gives you that higher levelof what you should do.
Speaker 2 (23:21):
Yes.
Speaker 1 (23:22):
Okay, and so I think you know, would it be fair to
say EA649 is great.
You could go and implement 649in a number of ways and some you
know it doesn't really give youthe best practices of how to do
it to really get your businessto be more efficient and
(23:44):
effective down at that tacticallevel.
Speaker 2 (23:47):
Yes, yeah, we see that EIA 649 is typically within
an organization, is implementedin kind of siloed approaches
instead of an enterprise wideapproach.
That's common.
Speaker 1 (24:00):
Okay and often people are required to satisfy 649.
So they do that, which is great.
It's still a great standard tofollow.
I guess, if you have a 649 andthen you implement CM2, like you
said, it's just building uponand giving you more of the best
(24:21):
practices to get there, of thebest practices to get there.
I think in the other directionwould you say, if you
implemented CM2, would yousatisfy everything that EIA 649
requests?
Speaker 2 (24:33):
Yes, yeah, I think if you implemented CM2, you would
meet and exceed the requirementsin EIA 649.
Speaker 1 (24:43):
Okay, so let's talk a little bit about some real
world trips.
Right?
Like some of the biggestmistakes that people make when
they're selecting, they'reimplementing or just trying to
improve you know the tools thatthey got, so tell me a little
bit about your brain there.
Speaker 2 (24:59):
Yeah.
So there's a lot of areas andyou know many reoccurring
mistakes organization makes.
When you know, selecting a toolor implementing it, or even
trying to improve the process,most of this stuff, or the
issues, stem from putting thetool ahead of the process and
requirements or underestimatingthe culture and the
(25:21):
organizational factors.
So what do we mean by some ofthis?
One is many teams rush to pickthe best tool based on features
or popularity, rather thanmapping their current and future
state processes and documentingthose business requirements
first, and this leads to forcingprocesses to fit the tool
(25:44):
rather than selecting a toolthat enables your desired ways
of working.
Another big thing you know isthis cross-functional alignment
of tools and needs.
You know, whereas decisions fora tool are often made by a
single department, you know,like engineering or IT, without
involving, you know, upstreamand downstream stakeholders,
(26:05):
such as quality supply chainservice, and this results in
those, you know, data silos thatpersist and cause integration
gaps to appear later, whichdrives all of that costly rework
that an organizationexperiences.
And then, you know, with all ofthat data right, there's this
(26:27):
understanding of data readinessand data governance.
You know, teams implement thesenew tools on top of incomplete
or inconsistent data, so they'remissing data when they go into
this.
And all of that does isamplifies those existing issues
rather than solving them.
So without the stronggovernance of the data, the tool
(26:47):
quickly, you know, degrades inaccuracy and trustworthiness
across the organization.
So folks can't rely on the databecause it's not all there,
it's incomplete or it'sinaccurate.
And then the other big thing iswe see that the you know
organizations focus on chasingthose shiny object capabilities
(27:09):
without asking does this featureactually really solve a
business problem or improve KPIs?
And so they're chasing the newcool thing without adding any
context to the current featuresor the current business process.
And that just adds complexityand slow adoption because people
(27:30):
still have to do what they needto do to get it done.
Now they have to do all thisadditional stuff.
And then one thing you know isenterprise tools succeed or fail
really based on the people, notreally the technology.
So skipping that training, thecommunication, the stakeholder
buy-in results in these lowadoption rates.
(27:51):
They result in these shadowsystems where people are now
doing extra work because thetool doesn't meet the
requirements or doesn'tfacilitate that fast, efficient
process.
And the other big thing you knowis when you're rolling out a
new tool, it's treated like anevent and not like the life
(28:12):
cycle of a normal product thatyou purchase or make right, the
teams go live and once you crossthat finish line, they, you
know, are like we're done goodand instead of starting, you
know the continuous improvement.
What's going on where?
Where can we do better?
So these refinement andfeedback loops you know are
required and absolutely neededso that the tools don't become
(28:35):
misaligned and they meet theevolving business needs.
So, kind of you know, ensurethe biggest traps is thinking
the tool is the actual solutionand the key is understanding and
optimizing your businessprocesses and requirements first
, then selecting andimplementing the tool that fits
those requirements and processes, while investing in the
(29:00):
government's adoption andcontinuous improvement of the
new tool that's been implemented.
Speaker 1 (29:06):
You know, for a long time we've heard our CM2
trainers over decades say toolslead, fools follow, right.
So we always say processes lead, tools follow.
If tools lead, fools follow.
So that one always seems tostick in people's heads.
If you need something to helpremember which way it really
(29:26):
needs to go, and you know.
Again, I think, like you said,you know people think that tools
are solutions and I think toolsoften, you know, present
themselves as solutions.
But you know, like you saidearlier, they can automate, you
know, a really great process andgive you a really great
solution.
Or it can automate a reallycruddy process and be cumbersome
and just get you bad datafaster.
(29:47):
So making sure we're, you knowit's just the tool's only going
to do what you tell it to do.
So you just need to make sureyou got good stuff going in on
the front side.
So Yep, so we know change isreally hard.
We talk about that all the time.
It gets kind of cliche, but itis really hard and organizations
really struggle with this.
You know people resist changeeven when it's desperately
(30:12):
needed for an organization oreven for individuals.
You know they're in correctiveaction mode, right, they're
firefighting all the day long.
They show up for work and theydon'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'rejust going to support whatever's
thrown at them.
So we all know that we needchange, that we need to be
better.
You know, we really don't havea lot of excuses here anymore.
So I guess, from all of youryears of experience, what is the
(30:35):
best way to create change thatreally sticks and is really
adopted?
Speaker 2 (30:41):
Yeah, you're absolutely right, change is hard
right, even when the need tochange is completely obvious.
And the biggest lessons thatI've learned is that lasting
change isn't just about rollingout a new process or a new tool.
It's really about shifting themindsets and embedding the new
(31:03):
behaviors in the culture ofmindsets and embedding the new
behaviors in the culture.
And this is what I kind of seethat works for me.
When we come in and do serviceengagements, you know we always
start with the why.
You know people rarely resistchange itself.
They resist that kind ofuncertainty that comes with
change.
So when you can clearly connectthe change to the real business
(31:25):
pain points and personalbenefits this reduces rework,
this helps improve your workloadyou kind of start turning that
resistance into theunderstanding and with that that
involves those folks earlier.
So what I've found is thefastest way to create ownership
is to co-create the change withall of those stakeholders, so
(31:48):
those that will be living itdaily.
This involves cross-functionalteams 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 thoseincremental changes and make
(32:08):
them visible.
You know big bang changes canoverwhelm anyone.
So instead of if you can,instead of you know, the big
bang change, you break it intosmaller pieces and kind of
celebrate those wins, showvisible progress and that builds
the momentum and the trust.
And also you want to focus onenabling the users and not
(32:30):
enforcing them and notnecessarily enforcement of using
it.
So this comes along with that.
Training isn't necessarilyenough.
There may be coaching, theremay need to be additional
reference materials and you knowchampions who can help.
You know answer questions asthe users come up.
So training those SMEs andreinforcing these new behaviors
(32:52):
in real time, along withbringing them along for the ride
.
And then, when you kind of getinto the sustainment of the
change, you know it needs to bepart of the daily work.
So it needs to be shown in themetrics or the reviews or any
decision-making framework thatfolks should do.
So this should reflect that newway of operating so people don't
(33:14):
kind of slip back into thoseold habits.
And a big one, we said, or abig one I noticed, is
acknowledging the cultural side.
Right, change impacts theidentity of people.
They might feel loss of controlor fear of obsolescence in
their jobs.
So you should address thoseconcerns openly and show them
how the change benefits them asan individual, not just the
(33:36):
organization.
And really you know the changesticks when it's co-owned and
not mandated and when people seethat the purpose, see the
purpose and are part of thesolution and feel supported
throughout the transition, thatresistance really turns into
this advocacy and you knowthat's what helps make the
(33:57):
change take hold.
Speaker 1 (33:59):
And this is something we talk about all the time and
it's just not emphasized enoughis that this is important.
The people piece will make orbreak anything, and anyone who's
been through one of theseexperiences has learned that.
You know, it's the requirementsand the tool and the process.
Those pieces are easy.
It's the adoption piece that isthe hard piece and making sure
(34:20):
that it does serve theorganization and that you're
listening to the organizationand continuing to take their
voice and incorporate it, andit's crucial to the success of
these projects.
Speaker 2 (34:32):
Yes, it absolutely is .
The people aspect should neverbe underestimated.
Speaker 1 (34:37):
So for everyone listening, can you pinpoint one
thing maybe that you wish morepeople understood about
implementation of change to abusiness?
Speaker 2 (34:48):
Yeah, yeah, if I had to, you know kind of pinpoint
one thing.
It's this Change isn't just aproject.
It's about shifting how peoplethink and work.
You know, too oftenorganizations treat change
implementation kind of as achecklist New tool, new
(35:08):
processes, go live date.
But if you address the humanside of why it matters, how it
improves their day-to-day life,and you know what support
they'll have, people willquickly revert to those habits,
no matter how good the solutionis.
The real key is to design thechange around people, not just
systems.
So when employees see theirinput reflected in the solution
(35:31):
and understand the value to them, not just the company, that's
when the changes truly stick.
Speaker 1 (35:40):
Yeah, then it becomes that new baseline and then
you're starting from there forany continual improvement,
moving forward.
Speaker 2 (35:45):
Yeah, exactly.
Speaker 1 (35:47):
Okay, all right, very cool.
Well, we've shared a ton ofreally great aspects and
hopefully we've demystified alittle bit of what happens
behind the scenes here whenpeople get new processes and
tools.
Can you just maybe just take amoment before we close here and
just share maybe a memorablemoment for when the CM2
(36:07):
standards or CM2 frameworkreally made a measurable
difference from your career sofar?
Speaker 2 (36:13):
So one example that kind of stands out is with a
manufacturer that struggles withfrequent rework or delayed
product launches, and you knowthis is typically due to
misalignment in the changeprocesses and data.
So you know, if you haveengineering, manufacturing and
supply chain, they each havetheir own version of the truth
(36:34):
and changes often took weeks toflow downstream.
And you know, when we startedto introduce the CM2 standards,
you know a few things startedhappening.
Standards, you know a fewthings started happening.
The change process wascentralized with clear ownership
and traceability.
The requirements, theconfiguration and the change
notices were all linked in akind of a single closed loop
(36:58):
system and the cross-functionalteams began reviewing changes
simultaneously.
So they assessed the impacttogether instead of, you know,
kind of this sequential orserial approach.
So that helps cut down thatapproval time quite dramatically
.
So you know what were theresults.
You know within the year theysaw a 40% reduction in cycle or
(37:22):
change cycle time and ameasurable drop in late stage
change reworks, which you knowsavings can.
That directly translated tofaster time to market, improved
customers' satisfaction.
And you know what made itmemorable wasn't just the
metrics, it was watching thecultural shift.
Teams that once worked in thosesilos started collaborating
(37:47):
around this kind of sharedframework of CM2.
And then you know, for thefirst time folks trusted the
data they were working from andthat trust became the foundation
for improvements across theenterprise.
Speaker 1 (38:01):
Another buzzword that what we're talking about here,
right, is this organizational orenterprise integration is
really the key, so it's justanother piece of what needs to
happen to gain the benefits thatpeople are looking for Exactly
All right, well, thank you somuch, thomas.
These have been absolutelybrilliant insights.
I hope they're very helpful forothers listening.
(38:22):
Just thank you so much forsharing your expertise and
cracking open these nuances ofdigital transformation for
everyone.
I think I'm disappointed wehaven't pulled you on here
sooner.
So thanks for doing this withme.
And if listeners want to learnmore about these topics or about
how to do this better, or yourlessons learned, is there a way
(38:45):
for them to connect with youdirectly?
How would they do that?
Speaker 2 (38:48):
Thank you.
I always enjoy having thesekinds of conversations.
You know the best place toconnect is on LinkedIn.
I share a lot of insights thereand love engaging with those
others who are passionate abouttransformation and configuration
management.
You can also reach out directlyto me via email at thomas at
(39:08):
ipxhqcom.
Speaker 1 (39:11):
Okay, amazing.
Well, that's a wrap for today,so stay tuned for more episodes
where we do our best to gobeneath these buzzwords and
spotlight the methods thatactually work.
So thanks, thomas Talk to youguys.
Thanks.
Thank you for tuning in today.
Don't forget to subscribe andreview the show and for more
information on IPX visitIPXHQcom.
Welcome to the IPX True North podcast, where we
connect people, processes andtools.
Hello and welcome to today'sepisode of the IPX True North
podcast, where we dive into theprinciples, processes and tools
that bring true operationalharmony.
So I'm your host, brandi Taylor,and I'm joined today by a guest
(00:23):
whose expertise in helpingorganizations bridge the gap
between Thomas is a really goodfriend of mine.
He is the Director ofEnterprise Systems and Processes
for IPX and he has over 20years of experience improving
processes and writingrequirements for the tools that
then automate these processes,which exactly is the topic that
(00:43):
we're going to explore today andand demystify.
You know what Thomas does on adaily basis, in case people are
wondering what we do here on theservices side of IPX.
So you know, often too often Ifeel people are simply often the
recipient of a new or updatedprocess or tool and you know
they're often handed the outcomewithout having been a part of
(01:06):
shaping it as much as theyshould have been in the future
from the start.
So today I want to demystifythat with Thomas here and then
shed some light on how theseprojects are kind of defined
from the very beginning.
So, thomas, welcome to the show.
Speaker 2 (01:20):
Thank you.
Speaker 1 (01:22):
All right.
Well, to kind of kick this offa little bit with a touch of
background, there's a lot ofbuzzwords for what we do on the
services side of IPX.
Right, we talk about enterpriseexcellence, digital
transformation, processimprovement, operational
excellence, master datamanagement, value stream
optimization, harmonization.
You know like all these so manybuzzwords for what we do.
(01:42):
Optimization, harmonization.
You know like all these so manybuzzwords for what we do.
Speaker 2 (01:45):
Just to kind of give our audience a little bit of a
background, how do you describeyour role at IPX when someone
outside of our industry asksyeah, so my role, you know, is
(02:07):
basically understanding thewants and needs of the people
and being able to translate thatfrom business speak into
technical speak for the peoplethat are going to implement the
solution.
So it's understanding what thespirit of what they're asking,
instead of just the words thatthey're saying.
Speaker 1 (02:16):
Awesome, and so give an example.
What does a typical day looklike for Thomas Miller?
Speaker 2 (02:23):
Yeah, a typical day.
I mean it's a lot of workingwith the clients and
understanding you know theirwants and their needs and kind
of digging deeper into why it'sthat way, understanding how
they're operating as well as youknow, helping them progress and
communicate to the organizationwhere they want to go, and
(02:45):
doing that clearly.
Speaker 1 (02:47):
So let's shift gears slightly here, because people
often come to us at IPX becausethey want a fancy new tool to
solve all their problems.
Right, that happens often forus, and you've worked with
countless enterprise tools.
Which ones do you have the mosthands-on experience with?
Speaker 2 (03:04):
Yeah, that's a great question and one that we often
hear.
So I've worked a lot with PLMtools 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.
(03:27):
And you know with this, youknow each one of these tools has
great strengths, but it's notbeing able to declare which
one's the best.
It's not a universal thing foreveryone.
It's each client has uniqueneeds, that one tool may prevail
over the other.
So, because of that, the righttool isn't chosen in isolation.
It's dictated by therequirements in the business
process that we're trying toenable.
(03:48):
So too often, companies pick atool first and then they focus
on the processes to conform,which creates the friction, the
workarounds and the misalignmentwith the strategic goals.
Speaker 1 (04:00):
People often just come to us with our experience
and say hey, you know what's thebest PLM tool I should be
implementing?
Right, and I think that there'snot an easy answer to that.
Right, we can tell you the onesthat are great and that can do
a ton of great, great things.
But again, there's no one sizefits all and it's not like there
is one best or the three topbest.
It's really based on what thewants and the needs are of the
(04:23):
business.
Speaker 2 (04:24):
Absolutely, really based on what the wants and the
needs are of the business.
Absolutely, yeah, which is, youknow kind of why I use the
approach of.
You know we got to understandwhat the business processes are
first, you know, mapping themout of what they currently look
like and working on futurestates so that we can help
identify those gaps and clarifywhat success and what a client's
utopia looks like.
And then from there, you knowwe have to document the
(04:47):
requirements, the businessrequirements, clearly, because
this translates the needs andthe wants into kind of a
structured and testable set ofrequirements that distinguish
the must-haves from thenice-to-haves.
And then, ultimately, what wedo is we take those requirements
and business processes andevaluate those against the tool,
and this helps us assess thecapabilities of whatever tool it
(05:10):
is, whether it's PDM, plm, erp,nes, etc.
We use those against thedocumented requirements and see
how well they support thatprocess flow and the compliance.
And then, finally, we have tofactor in the scalability and
the culture.
Culture is a huge aspect ofthis and that will help or
(05:32):
hinder the success of deployingany tool in the system if the
organization isn't ready for itor there's concerns.
So it helps with that useradoption.
Speaker 1 (05:42):
We're not just talking about PLM.
Often PLM is where people cometo us for because of CM2 and
they think change, configurationmanagement, they think
engineering data.
But CM2 truly is end-to-endright and there's multiple tools
that are engaged in thatprocess across your digital
thread and we worked in all ofthem.
(06:03):
So you know it's not just PLMright, it's truly requirements
management.
It could be MES, it could beQMS, it could be ERP, it could
be any of those Exactly.
Now, one thing I wanted toclear up kind of a big
misconception that we often hearis too often teams say that
they've gathered requirementsright, and when we dive into
(06:24):
what they mean by that, they'rereally pulling people together
in a room and they'rebrainstorming in Word or Excel
of what they want this tool todo.
And so why does requirementsgathering often fail?
And then how do we help peoplemove away from those vague ideas
in Excel to communicatingclearly what are the wants and
(06:47):
needs that you're looking for?
Speaker 2 (06:49):
Yeah, absolutely right.
There is a common misconceptionRequirements gathering often
fails because teams confuse itwith informal brainstorming
sessions rather than structurediterative process.
You know, just capturing theideas in Word or Excel might
help to start thoseconversations, but it rarely
ensures the clarity, alignmentand traceability across everyone
(07:10):
.
And it's because you don't divedeeper, you look at the surface
.
And it's because you don't divedeeper, you look at the surface
.
So you know why does it alwaysfail or why does it tend to fail
?
There's a lack of structure.
So brainstorming doesn'tdifferentiate between one's
needs and constraints of thesystem and the process.
And also one big thing that wesee is there's no shared
(07:32):
language across teams, evenwithin the same organization or
across the same functions.
So without those consistentdefinitions and formats, you
know stakeholders interpretthose requirements quite
differently.
And when you have thosespreadsheets and documents,
there's often a lack of versioncontrol or linkage between the
(07:53):
design testing and changemanagement, or linkage between
the design testing and changemanagement.
We recently had a client thatwas doing a change process for
their entire organization andthey had 10 requirements for an
entire change process.
That's very high level and it'sbarely scratching the surface.
And then also there's themissing context right.
(08:16):
So brainstorming focuses onwhat we think we need instead of
validating, against thoseprocess gaps, what the user does
on a day-to-day business orwhat the business's objectives
are.
And in order to move forwardright, you have to have that
mentality, or the shift fromgathering to elicitation and
(08:36):
validation of the requirements.
So you're actively engagingstakeholders to map out, you
know, the as-is processes, theto-be processes.
You're confirming those throughinterviews, through meetings,
after processes are developedand even into prototypes.
And I like to use a structuredformat when I'm capturing that
(08:58):
the requirements, so that theyare clear and testable.
So I always follow an I want sothat acceptance criteria format
which helps distinguish betweenthe functional and
non-functional needs of theorganization, so it helps those
delivering it understand whatthe tool must do or is it
business process and so forth.
(09:22):
And then, additionally, itallows us to link those
requirements to the objectiveswe're trying to meet.
Right, just because someone hasa requirement doesn't mean it
actually fits into the currentprocess.
So we have to make sure thatthose align with the business
goals and they're measurable sothat we actually can say, hey,
we've actually efficiently donethis process.
And you know this helps byimplementing tools that are
requirements managementplatforms so they help connect
(09:44):
those requirements from design,testing and through all the
changes.
And then again it's iterative.
It's an iterative andvalidation process where you
treat the requirements as livingartifacts that evolve through
feedback, review and impactassessments, just like our
change processes should.
So you know, moving from thesevague lists to structured
(10:06):
requirements ensures thatstakeholders share a single
source of ultra driving forbetter decisions, reducing that
rework and improving the overallquality of what their needs and
wants are.
Speaker 1 (10:18):
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 (10:26):
Yeah, out of the box is one of those things where the
tool can pretty much dowhatever you want.
You still have to configure itto map to what your current
process is.
And what we most often see isthe current process is years
that have just built on becausewe had a failure here.
We had that, so it's notnecessarily fixing the root
(10:49):
cause of the issue, but it is.
You know, band-aiding somethingthat didn't work or we had an
escape.
So you know you need to followthrough and make sure that the
tool is configured correctly.
So commercial off the shelf orout of the box is kind of a
misnomer.
Speaker 1 (11:09):
And you know, I know, like our system integrator
friends and you know toolimplementers, they're so good at
what they do they want toautomate your ways of working.
They want to automate what youdo today.
They're not there to improveyour ways of working per se.
Right, so you may get someefficiencies from automating,
but if you have a clunky processthat has a lot of those
(11:31):
band-aids like you're talkingabout from an audit or from
quality issues or whatever,where we've done these band-aids
and small fixes, it becomes avery difficult and cumbersome
thing to automate.
Exactly, yeah, automation if youdon't have a good process, just
(11:53):
allows you to create bad dataquicker?
Speaker 2 (11:54):
Yeah, nobody wants that.
Speaker 1 (11:55):
No, they sure don't.
Another thing I want to getyour brain on is I want to
clarify something that's prettyfundamental for us but maybe not
for others, is what is thedifference between a business
requirement and then afunctional specification?
Speaker 2 (12:11):
Yeah, this distinction always gets blurred,
but it's critical to understandwhat its intent is for
alignment across theorganization, not only with the
business but also with theperson that's implementing the
solution.
So the way I like to thinkabout it is a business
(12:34):
requirement defines what anorganization needs to achieve
and why it's focused on theoutcome or the value to the
business that they're seeking toimprove that traceability,
reducing cycle time and enablinglike regulatory requirements.
So business requirements aretypically high level and
solution agnostic.
So an example is the systemmust allow secure, role-based
access so that authorized userscan only view the sensitive data
(12:58):
of the product.
So that's, you know, that's howa business requirement works.
Now a functional specificationdefines 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 andthe tool, you know, with the
(13:19):
inputs, the outputs and how itinteracts with the users and
also other systems to fulfillthose business needs.
Functional spec would sayimplement a role-based access
control model using activedirectory groups with
permissions configurable at thedocument and BOM level.
(13:41):
So basically what it's sayingis now we've gotten into the
solution with the functionalspec, whereas the business
requirements are the needs andthe wants of the business.
One way to kind of, you know,recap that is, the business
requirements are the what andwhy, so the value and the
outcomes that are expected.
(14:02):
The functional spec is the how.
How is it designed, how is itimplemented?
You know, keeping theseparation is quite important,
because business requirementsensure that we're solving the
right problem, while thefunctional specification ensures
we're building the rightsolution.
Speaker 1 (14:20):
It's kind of like baking a cookie, right, like you
know.
The business side says what dowe want?
Right, this is what we want andthis 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 wayto achieve those requirements.
There may be multiple ways todo that, depending on the tool.
Speaker 2 (14:39):
Exactly.
Speaker 1 (14:40):
So in so many people's solution right, they
want to give you hey, I've donethis in this previous tool or at
my previous job.
If this was a great way, Iwanted to do this.
Well, that may have workedreally well in one specific tool
, but it may not work the sameway.
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 outwhat is the best way to do
(15:03):
something and come up with themost simplest, best and
optimized solution.
Speaker 2 (15:07):
Yes, yeah, and the current tool that you've picked
may not be the right tool forthose set of requirements.
So you don't want to tie insolution and specific tool.
You would like the systemintegrator or the IT folks to
figure out what's the best toolfor those requirements.
Speaker 1 (15:26):
I like that.
Okay, so at IPX we're more onthe business side, right, like
we're process people.
So we want to help you withthat optimized process.
First, that's how you're goingto get your business
requirements.
Then that's how you're going tocommunicate very clearly your
wants, your needs, yourexpectations, to then the
solution or vendor in order toget what you're looking for.
(15:48):
Yes, so you know some peoplethink you know.
Well, you know I, you know howdo I, how do I know what my, my,
my business process needs to beright.
Let's say they're not usingsomeone like yourself or IPX to
help us with this.
You know we, we do have aCM2-500, and how do
organizations use it?
Because I'm guessing manypeople come out of our training
(16:21):
and they're not sure what to dowith this thing, right?
So tell me your thoughts.
Speaker 2 (16:25):
Yeah, so CM2-500 kind of is that enterprise level
standard for integrating, youknow, configuration management
into the broader business.
You know, and it helps addressthe governance, the digital
thread, you know, closed loopprocesses and ensuring that data
stays accurate and alignedacross its entire lifecycle.
(16:48):
And this includes, you know,process mapping, maturity
assessments, optimizationstrategies to scale CM beyond
engineering and into, you know,other areas like supply chain,
manufacturing, quality servicewith that, and so organizations
can use this to assess andbenchmark their current process
(17:09):
maturity and help them identifygaps.
It also helps thoseorganizations 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 shouldadhere to the same logic and the
(17:32):
same commitment.
And the same commitment.
We use this to help understandand identify potential cycle
time changes in improving dataintegrity and minimizing
downstream work with the SIEM2500.
So it's all about processoptimization.
And then you know, if you lookat it at a really big scale, it
(17:53):
helps with that digital you know, digital transformation of
roadmap, where it supportsbuilding this scalable digital
thread that helps connect thosedesign, the requirements,
manufacturing, field servicedata into each other standard is
.
Speaker 1 (18:11):
You know, a guiding light is maybe a word I might
use to help organizations figure.
Okay, we know we've got someproblems, but we don't really
know the best ways to fix them.
So the framework of CM2 reallyjust gives them we call it true
(18:32):
north right of the bestpractices of 40 years across
industry across the globe.
And this is the way where youdon'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 frameworkand the standard to then figure
out how do we surgically solvethis specific pain point.
Right, you may have otherthings you're not doing exactly
(18:55):
the right way, but it's workingfor you and it's no problem.
So you want to use this in atactical way to then help
improve those pain points withinyour business.
Speaker 2 (19:04):
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 specificpain point, for the entire
organization.
Speaker 1 (19:22):
Okay, all right, very good.
So you know, just discuss alittle bit of a different
standard for a second.
So some of our military friendsand governmental friends.
They are often required toutilize EIA-649.
This standard often getsreferenced for the standard for
configuration management.
So let's talk about that.
For a second, for teams who arerelying on 649, what might
(19:43):
shift if they were?
Speaker 2 (19:45):
that helps kind of establish those core principles
for identifying, controlling andverifying configuration items.
However, it's intentionallyfocused as guidance.
(20:08):
It tells you what a goodconfiguration management
solution looks like, but not howto implement it across the
enterprise.
So you know what kind of shiftswith adopting CM2?
.
So you know, eia 649 is theguidelines and CM2 is the
prescriptive practices.
So where EIA 649 provides thoseflexible principles that each
(20:33):
organization interprets andimplies differently, cm2 offers
a prescriptive closed-loopmethodology that helps define
roles, workflows, decisionpoints, reducing the ambiguity
and variability across the teams.
So CM2 really just enhances 649and provides the you know kind
(20:57):
of how-to on it.
And with that, you know, eai649 is kind of often applied to
just engineering or in kind ofprogrammatic silos, whereas CM2
kind of expands theconfiguration management across
the enterprise.
So it integrates, you know,engineering, supply chain,
(21:19):
manufacturing, quality, theservices into kind of this
single digital thread and thenwith change management, right.
So EA649 has a, or supports astructured change control, but
it doesn't necessarily address,like the cycle time of the
change or the process agilitythat's needed, while CM2 kind of
(21:42):
emphasizes, you know, a fastimpact assessed change that
helps maintain that dataintegrity while working to
reduce rework and delays in thesystem.
Also, you know, eai 649 focuseson the configuration control but
leaves the requirement handlingto other frameworks where, you
(22:03):
know, cm2 has requirements thatare tightly integrated with
everything they do and it's tiedto the configurations, the
change managements and thisensures that every decision
traces back to a valid businessneed and with that, eia-649
doesn't prescribe kind of a fulldigital thread or an enterprise
(22:26):
integration approach.
You know you have to piece thattogether, whereas CM2 helps
provide that roadmap for digitalscalability and transformation
while aligning all of yoursystems under kind of a single
governance model.
So really adopting CM2 doesn'treplace 649.
It actually builds on it.
So CM2 kind of operationalizesthe principles of EIA 649 into
(22:53):
kind of that repeatableenterprise-wide practices, which
allows faster change cycles,better data accuracy and
improved cross-functionalalignment across the
organization improvecross-functional alignment
across the organization.
Speaker 1 (23:06):
Okay, so EIA 649 really is a foundational set of
requirements and it just doesn'treally tell you that lower
level tactical best practices ofhow to achieve it, but it kind
of gives you that higher levelof what you should do.
Speaker 2 (23:21):
Yes.
Speaker 1 (23:22):
Okay, and so I think you know, would it be fair to
say EA649 is great.
You could go and implement 649in a number of ways and some you
know it doesn't really give youthe best practices of how to do
it to really get your businessto be more efficient and
(23:44):
effective down at that tacticallevel.
Speaker 2 (23:47):
Yes, yeah, we see that EIA 649 is typically within
an organization, is implementedin kind of siloed approaches
instead of an enterprise wideapproach.
That's common.
Speaker 1 (24:00):
Okay and often people are required to satisfy 649.
So they do that, which is great.
It's still a great standard tofollow.
I guess, if you have a 649 andthen you implement CM2, like you
said, it's just building uponand giving you more of the best
(24:21):
practices to get there, of thebest practices to get there.
I think in the other directionwould you say, if you
implemented CM2, would yousatisfy everything that EIA 649
requests?
Speaker 2 (24:33):
Yes, yeah, I think if you implemented CM2, you would
meet and exceed the requirementsin EIA 649.
Speaker 1 (24:43):
Okay, so let's talk a little bit about some real
world trips.
Right?
Like some of the biggestmistakes that people make when
they're selecting, they'reimplementing or just trying to
improve you know the tools thatthey got, so tell me a little
bit about your brain there.
Speaker 2 (24:59):
Yeah.
So there's a lot of areas andyou know many reoccurring
mistakes organization makes.
When you know, selecting a toolor implementing it, or even
trying to improve the process,most of this stuff, or the
issues, stem from putting thetool ahead of the process and
requirements or underestimatingthe culture and the
(25:21):
organizational factors.
So what do we mean by some ofthis?
One is many teams rush to pickthe best tool based on features
or popularity, rather thanmapping their current and future
state processes and documentingthose business requirements
first, and this leads to forcingprocesses to fit the tool
(25:44):
rather than selecting a toolthat enables your desired ways
of working.
Another big thing you know isthis cross-functional alignment
of tools and needs.
You know, whereas decisions fora tool are often made by a
single department, you know,like engineering or IT, without
involving, you know, upstreamand downstream stakeholders,
(26:05):
such as quality supply chainservice, and this results in
those, you know, data silos thatpersist and cause integration
gaps to appear later, whichdrives all of that costly rework
that an organizationexperiences.
And then, you know, with all ofthat data right, there's this
(26:27):
understanding of data readinessand data governance.
You know, teams implement thesenew tools on top of incomplete
or inconsistent data, so they'remissing data when they go into
this.
And all of that does isamplifies those existing issues
rather than solving them.
So without the stronggovernance of the data, the tool
(26:47):
quickly, you know, degrades inaccuracy and trustworthiness
across the organization.
So folks can't rely on the databecause it's not all there,
it's incomplete or it'sinaccurate.
And then the other big thing iswe see that the you know
organizations focus on chasingthose shiny object capabilities
(27:09):
without asking does this featureactually really solve a
business problem or improve KPIs?
And so they're chasing the newcool thing without adding any
context to the current featuresor the current business process.
And that just adds complexityand slow adoption because people
(27:30):
still have to do what they needto do to get it done.
Now they have to do all thisadditional stuff.
And then one thing you know isenterprise tools succeed or fail
really based on the people, notreally the technology.
So skipping that training, thecommunication, the stakeholder
buy-in results in these lowadoption rates.
(27:51):
They result in these shadowsystems where people are now
doing extra work because thetool doesn't meet the
requirements or doesn'tfacilitate that fast, efficient
process.
And the other big thing you knowis when you're rolling out a
new tool, it's treated like anevent and not like the life
(28:12):
cycle of a normal product thatyou purchase or make right, the
teams go live and once you crossthat finish line, they, you
know, are like we're done goodand instead of starting, you
know the continuous improvement.
What's going on where?
Where can we do better?
So these refinement andfeedback loops you know are
required and absolutely neededso that the tools don't become
(28:35):
misaligned and they meet theevolving business needs.
So, kind of you know, ensurethe biggest traps is thinking
the tool is the actual solutionand the key is understanding and
optimizing your businessprocesses and requirements first
, then selecting andimplementing the tool that fits
those requirements and processes, while investing in the
(29:00):
government's adoption andcontinuous improvement of the
new tool that's been implemented.
Speaker 1 (29:06):
You know, for a long time we've heard our CM2
trainers over decades say toolslead, fools follow, right.
So we always say processes lead, tools follow.
If tools lead, fools follow.
So that one always seems tostick in people's heads.
If you need something to helpremember which way it really
(29:26):
needs to go, and you know.
Again, I think, like you said,you know people think that tools
are solutions and I think toolsoften, you know, present
themselves as solutions.
But you know, like you saidearlier, they can automate, you
know, a really great process andgive you a really great
solution.
Or it can automate a reallycruddy process and be cumbersome
and just get you bad datafaster.
(29:47):
So making sure we're, you knowit's just the tool's only going
to do what you tell it to do.
So you just need to make sureyou got good stuff going in on
the front side.
So Yep, so we know change isreally hard.
We talk about that all the time.
It gets kind of cliche, but itis really hard and organizations
really struggle with this.
You know people resist changeeven when it's desperately
(30:12):
needed for an organization oreven for individuals.
You know they're in correctiveaction mode, right, they're
firefighting all the day long.
They show up for work and theydon'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'rejust going to support whatever's
thrown at them.
So we all know that we needchange, that we need to be
better.
You know, we really don't havea lot of excuses here anymore.
So I guess, from all of youryears of experience, what is the
(30:35):
best way to create change thatreally sticks and is really
adopted?
Speaker 2 (30:41):
Yeah, you're absolutely right, change is hard
right, even when the need tochange is completely obvious.
And the biggest lessons thatI've learned is that lasting
change isn't just about rollingout a new process or a new tool.
It's really about shifting themindsets and embedding the new
(31:03):
behaviors in the culture ofmindsets and embedding the new
behaviors in the culture.
And this is what I kind of seethat works for me.
When we come in and do serviceengagements, you know we always
start with the why.
You know people rarely resistchange itself.
They resist that kind ofuncertainty that comes with
change.
So when you can clearly connectthe change to the real business
(31:25):
pain points and personalbenefits this reduces rework,
this helps improve your workloadyou kind of start turning that
resistance into theunderstanding and with that that
involves those folks earlier.
So what I've found is thefastest way to create ownership
is to co-create the change withall of those stakeholders, so
(31:48):
those that will be living itdaily.
This involves cross-functionalteams 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 thoseincremental changes and make
(32:08):
them visible.
You know big bang changes canoverwhelm anyone.
So instead of if you can,instead of you know, the big
bang change, you break it intosmaller pieces and kind of
celebrate those wins, showvisible progress and that builds
the momentum and the trust.
And also you want to focus onenabling the users and not
(32:30):
enforcing them and notnecessarily enforcement of using
it.
So this comes along with that.
Training isn't necessarilyenough.
There may be coaching, theremay need to be additional
reference materials and you knowchampions who can help.
You know answer questions asthe users come up.
So training those SMEs andreinforcing these new behaviors
(32:52):
in real time, along withbringing them along for the ride
.
And then, when you kind of getinto the sustainment of the
change, you know it needs to bepart of the daily work.
So it needs to be shown in themetrics or the reviews or any
decision-making framework thatfolks should do.
So this should reflect that newway of operating so people don't
(33:14):
kind of slip back into thoseold habits.
And a big one, we said, or abig one I noticed, is
acknowledging the cultural side.
Right, change impacts theidentity of people.
They might feel loss of controlor fear of obsolescence in
their jobs.
So you should address thoseconcerns openly and show them
how the change benefits them asan individual, not just the
(33:36):
organization.
And really you know the changesticks when it's co-owned and
not mandated and when people seethat the purpose, see the
purpose and are part of thesolution and feel supported
throughout the transition, thatresistance really turns into
this advocacy and you knowthat's what helps make the
(33:57):
change take hold.
Speaker 1 (33:59):
And this is something we talk about all the time and
it's just not emphasized enoughis that this is important.
The people piece will make orbreak anything, and anyone who's
been through one of theseexperiences has learned that.
You know, it's the requirementsand the tool and the process.
Those pieces are easy.
It's the adoption piece that isthe hard piece and making sure
(34:20):
that it does serve theorganization and that you're
listening to the organizationand continuing to take their
voice and incorporate it, andit's crucial to the success of
these projects.
Speaker 2 (34:32):
Yes, it absolutely is .
The people aspect should neverbe underestimated.
Speaker 1 (34:37):
So for everyone listening, can you pinpoint one
thing maybe that you wish morepeople understood about
implementation of change to abusiness?
Speaker 2 (34:48):
Yeah, yeah, if I had to, you know kind of pinpoint
one thing.
It's this Change isn't just aproject.
It's about shifting how peoplethink and work.
You know, too oftenorganizations treat change
implementation kind of as achecklist New tool, new
(35:08):
processes, go live date.
But if you address the humanside of why it matters, how it
improves their day-to-day life,and you know what support
they'll have, people willquickly revert to those habits,
no matter how good the solutionis.
The real key is to design thechange around people, not just
systems.
So when employees see theirinput reflected in the solution
(35:31):
and understand the value to them, not just the company, that's
when the changes truly stick.
Speaker 1 (35:40):
Yeah, then it becomes that new baseline and then
you're starting from there forany continual improvement,
moving forward.
Speaker 2 (35:45):
Yeah, exactly.
Speaker 1 (35:47):
Okay, all right, very cool.
Well, we've shared a ton ofreally great aspects and
hopefully we've demystified alittle bit of what happens
behind the scenes here whenpeople get new processes and
tools.
Can you just maybe just take amoment before we close here and
just share maybe a memorablemoment for when the CM2
(36:07):
standards or CM2 frameworkreally made a measurable
difference from your career sofar?
Speaker 2 (36:13):
So one example that kind of stands out is with a
manufacturer that struggles withfrequent rework or delayed
product launches, and you knowthis is typically due to
misalignment in the changeprocesses and data.
So you know, if you haveengineering, manufacturing and
supply chain, they each havetheir own version of the truth
(36:34):
and changes often took weeks toflow downstream.
And you know, when we startedto introduce the CM2 standards,
you know a few things startedhappening.
Standards, you know a fewthings started happening.
The change process wascentralized with clear ownership
and traceability.
The requirements, theconfiguration and the change
notices were all linked in akind of a single closed loop
(36:58):
system and the cross-functionalteams began reviewing changes
simultaneously.
So they assessed the impacttogether instead of, you know,
kind of this sequential orserial approach.
So that helps cut down thatapproval time quite dramatically
.
So you know what were theresults.
You know within the year theysaw a 40% reduction in cycle or
(37:22):
change cycle time and ameasurable drop in late stage
change reworks, which you knowsavings can.
That directly translated tofaster time to market, improved
customers' satisfaction.
And you know what made itmemorable wasn't just the
metrics, it was watching thecultural shift.
Teams that once worked in thosesilos started collaborating
(37:47):
around this kind of sharedframework of CM2.
And then you know, for thefirst time folks trusted the
data they were working from andthat trust became the foundation
for improvements across theenterprise.
Speaker 1 (38:01):
Another buzzword that what we're talking about here,
right, is this organizational orenterprise integration is
really the key, so it's justanother piece of what needs to
happen to gain the benefits thatpeople are looking for Exactly
All right, well, thank you somuch, thomas.
These have been absolutelybrilliant insights.
I hope they're very helpful forothers listening.
(38:22):
Just thank you so much forsharing your expertise and
cracking open these nuances ofdigital transformation for
everyone.
I think I'm disappointed wehaven't pulled you on here
sooner.
So thanks for doing this withme.
And if listeners want to learnmore about these topics or about
how to do this better, or yourlessons learned, is there a way
(38:45):
for them to connect with youdirectly?
How would they do that?
Speaker 2 (38:48):
Thank you.
I always enjoy having thesekinds of conversations.
You know the best place toconnect is on LinkedIn.
I share a lot of insights thereand love engaging with those
others who are passionate abouttransformation and configuration
management.
You can also reach out directlyto me via email at thomas at
(39:08):
ipxhqcom.
Speaker 1 (39:11):
Okay, amazing.
Well, that's a wrap for today,so stay tuned for more episodes
where we do our best to gobeneath these buzzwords and
spotlight the methods thatactually work.
So thanks, thomas Talk to youguys.
Thanks.
Thank you for tuning in today.
Don't forget to subscribe andreview the show and for more
information on IPX visitIPXHQcom.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.