Subscribe
Share
Share
Embed
"Smart Metals Podcast," hosted by Luke van Enkhuizen and Denis Gontcharov, offers a clear and practical look into the metals industry's journey through digital transformation, Industry 4.0, and the integration of the Unified Namespace. Listeners can expect in-depth discussions that break down these complex topics into understandable segments, actionable insights, and real-world applications. Luke and Denis bring their expertise to the table, guiding you through the evolving digital landscape with advice on leveraging technology for streamlined operations. Each episode aims to empower metal industry professionals with the knowledge needed to confidently adopt digital innovations and understand the impact of the Unified Namespace in creating a more connected and efficient production environment. Join us to navigate the future of the metals industry with clarity and confidence.
Luke: Welcome back to
the smart metals podcast.
I'm your host Luke van Enkhuizen
and in this episode, we're
going to be talking about
the topic of the multi site deployment,
the challenges and the opportunities
that arise when you are managing
an enterprise and just want to
successfully digital transform.
Denis: Yes.
I'm excited.
It's a big topic.
Luke: What are the top
challenges in steering a digital
transformation across multiple
sites, perhaps even internationally?
Denis: So the idea is that digital
transformation is hard enough as it is.
If you want to do it in parallel for
all of your plants of your enterprise,
it just becomes much more complex.
So essentially you have to ask
yourself if you want to do it with
one strategy that you enforce, top
down and you make sure that all the
plants are doing the same thing, are
building the same technologies or do
you give your plants more flexibility
and let them decide for themselves
how they want to digitally transform?
Luke: Right, and maybe we should
start then with the, maybe the most,
I guess the most common challenge
is that there is an IT team or an IT
strategy coming from the enterprise.
Top down towards the plants.
So I think often a consulting firm is
hired to somehow come up with a strategy.
There is some it team members trained on
this new strategy, how they can follow up
on this, usually a software vendor comes
on board with some new solution, and then
the idea is, I guess, to yeah, spread
this out over the entire enterprise,
over the various plants and sites.
Is that about right to start with?
Denis: Yeah, absolutely.
I mean, the idea sounds
very attractive, right?
You just have one solution, one strategy?
So why not would you do that
Of course they go for the
vendor or for the consultant.
Luke: Yeah.
So the architecture is designed.
It's forced upon down over the plants.
And then I guess the primary objective
that I have encountered a lot in my
work is then the idea is to copy that
as some kind of a template, a digital
use case as a project over from
plant to plant from one to the other.
Indeed, it sounds like a, a great plan.
So let's start maybe in it with the good.
So sounds great.
What are the benefits?
Yeah, and what I also can imagine that
by having this point from the top down
approach, you have a somewhat more of a
control for my reporting side as user
traditionally speaking, as in you will,
you basically send all the financial
data to the to the top of the pyramid.
And perhaps even more it
usually is combined in my
experience with an IT policy
as in just the, you know, the
infrastructure that's used on a
daily basis, the operating systems,
devices, and those kinds of things.
So there is of course, something
to say about having a over
encompassing IT strategy, which
also includes the data management.
Maybe perhaps there is some scale benefit
indeed, as you said, efficiency with.
I'm not sure why we're doing
it this way, but of course.
we wouldn't be discussing this If it
would all be like sunshine and rainbows.
And this would be just
an effortless project.
So why is this sometimes a challenge?
What things do go wrong
when we go top down?
Denis: right.
Maybe before I move on, I'll
just throw in one more point.
One more benefit is maintenance,
because as you said, when you have the
similar processes, similar technologies,
it's much easier to maintain.
What's difficult about it?
Let's give a very concrete example.
if your manufacturing company owns a
plant in France and one in Germany,
you already have a massive difference
in culture, not to speak of language.
So already one problem I encountered in
my, in my personal work was exactly this
relationship where we had to translate
all the values of the data to english.
To make it understandable for each party,
but in doing so the engineers are So,
used to work with their values in their
language, that when they see the English
translation, it doesn't immediately
make sense to them what that value is.
Luke: Oh, yeah.
This is typical, particularly in the
metals industry where we have dozens of
, specific terms that even if you are a
native speaker in that language, sometimes
you can discuss with your colleagues about
what the meaning of a specific label is.
This is So recognizable.
Yes.
Big one here.
So translation.
Communication, lost in translation
is a thing for, for a reason,
you know, it's, it happens.
So data management
translation, that's big one.
What else?
Denis: So we also tend to overestimate
how similar machines and systems are.
Even two cold mills can still
have vastly different signals
from each other, different sensors
and different technologies.
Like even an ERP system, if you look
at the IT systems, they can also differ
greatly, even if they're used for,
let's say, a similar looking plant.
And the things we've mentioned now
where more problems about technology,
there's also the whole aspect of culture.
That's plants don't
necessarily like having a
big external party from outside
dictate from an ivory tower, how
they should implement their strategy.
Luke: this is so important.
Yes, this is huge.
Indeed, the especially if a firm
comes in, that is not like part of
the group itself, which then comes
in with an overly simplified picture
of their plants as they're saying,
Oh, you guys are producing this.
So this product would just be fine.
This would just be the way.
And You know, all this custom
work, you did this, but you know,
the times have changed and this
part I can do everything better.
And I've seen quite often
Denis: Let me tell you
how to run your business,
Luke: Yeah, right and especially
if somebody comes from outside of
the group or something that doesn't
really understand why a certain
process are in place, perhaps,
of course, just for customer
requirements or, you know, there's
so many reasons you can think about.
Yeah, it's, it's a huge
topic to, to cover this.
And so we're talking about digital
transformation here, right?
And so the goal is of course,
to, to get ready for the digital
future, to, to get there.
Processes, but perhaps we should
then also from the context of data
analysis, particularly like, or like.
The data engineering perspective, what
we mean by this, because I think there
are two different approaches here.
We can look at from software
implementation, such as ERP, MAS, or
like a more Like enterprise software
migration even and then there is of
course the data engineering aspect,
which is perhaps different in this
regard, at least in my experience.
How do you feel about that?
Denis: No, I think it's a fair point.
When you talk about software,
you're essentially deploying
an application that's.
on the code, on the logic only, right?
But when you talk about data
applications, so it's from
the realm of data engineering,
you're not just have software.
You also have the whole underlying data
on which the, software has to work.
So if the data is not correct, then
application will not do its job.
And that's the big.
Unfortunately where the devil is in the
details that very often from our ivory
tower, we may assume that the data in the
plants is sufficiently similar, but then
when you really go down into the trenches,
you see that the data is not what you
expected it would be for every plant.
Luke: Yeah, definitely.
all right.
So huge challenge to work from an
ivory tower, particularly in data.
And
I think it's even harder actually
with software implementation somehow
because there is going to be some
challenge of processes there as well.
Data has the biggest challenge,
I think, to need a translation or
culture or knowing what you want to do.
Let's talk about the bottom up.
So basically where the people are working
on the sites, promoting their ideas or
even not promoting it and just internally
developing solutions all by themselves.
Let's go into the, the good, the bad,
and perhaps the ugly behind those.
Denis: Yeah, of course.
So you may indeed assume that the bottom
up would be the solution because it's
the logical opposite of the top down.
It has some advantages.
It
Like it's easier to sell this idea to
the plants when you tell them, Hey,
you can do it how you guys see fit.
We trust you.
It's not a hard sell.
What do you think about that?
Luke: Well, is it really not a hard sell?
Because most people that are
working on the on the sites
Most of them, but at a far majority
of them don't have a background
in it not even to speak data
engineering or, or automation.
And in my experience, although very
well meant, and I mean, there are of
course, lots of exceptions of companies
that do have internal it teams when
they're a bit bigger, the sites, or they
have some data analysts inside, but.
In the vast majority of my experience,
most of the people working on the sites
are too busy with the daily whirlwind
of operations, don't really have the
time or background to focus on the IT
challenges, thus they are improvising.
And then making something quickly with
an Excel sheet just to begin with and
then another Excel sheet is made and then
they think, Oh, it's getting a bit much.
Maybe we make a report out of it out
of these Excel sheets and it's, I think
it's goes very organically, but there
hasn't been a strategy in place or a
more not much more thought has been
put into it, thinking about how this
affects the rest of the enterprise
and how they could work together.
And perhaps, yeah, as you said, like
some standardization is very rare.
So yes, I think it's easy to, to, indeed,
to promote to say, Hey, here's the tool.
You guys make something out of it.
That's would be great.
It might work faster at the beginning
and they can just, you know, get going.
But I saw in my experience, it's
quite hard for them, to keep
motivated, be motivated to stay on
track, to actually have a structure.
And as I said, the, yeah, they are more
Swallowed up by the daily whirlwind
of operations that like things
need to be done on time, you know
There's going to be all kinds of
emergencies that there are fires to be put
out So in my experience, it's going to be
quite challenging though from their end.
What do you think?
Denis: Yeah.
Yeah.
you essentially summarize the bad points
of the bottom up approach that indeed it
will likely, if it's successful result in
a very chaotic and very diverse landscape
of IT technologies in your enterprise.
And of course not all the plants
even have the required digital talent
to carry this transformation out.
Luke: Just must say I did run threats
a great book please excuse me that I
don't have the author perfect, but there
was an analogy between the speedboat,
speedboat and oil tanker analogy.
So basically the example goes
that you can have a situation that
you're kind of stuck in a place.
You don't know what's working.
What's not, you do have great ideas
and then you can kind of see the
organization as the oil tanker, right?
It's steady, it sails, it's larger.
It's not very agile, but sometimes
you just want to deploy speedboat and
do a sprint or two and see what you
can create with a simple solution.
And in this case, usually it works
way better to indeed do this at one
plant, let them play around with it and
experiment because on from the top down
approach, this would hardly ever work.
It would be too bureaucratic.
It would be too complicated.
They don't know the fine
intricacies of the plants themselves
So yeah, bottom up could mean the
speedboat versus oil tank analogy, but
I think we both also agree that you
cannot keep Right keep setting that
speedboat Into into infinity you do
have to certain point make sure that the
main ship also, you know steers along.
Denis: Because otherwise you will have
like 200 speed boats at the end of the
day, because it becomes very hard to
copy a successful, let's say one speed
boat, which is a good destination.
Well, how do you copy this
across the enterprise?
You can't, you'll have
to build new speed boats.
Luke: Yeah, right.
So I think that's, that's why,
yeah, I think it's indeed it's,
it's easy and yeah, multiple
speed bows can work in parallel.
And it could be also better
adopted to the specific needs.
I had some really great successes with
other clients of mine where we did
projects similar to this, where we
were one of the first in the in the
group of companies to implement a very
like high tech automation solution.
And this was also very innovative
on the way that it worked.
It dealt with pricing, so
quoting software, for example, so
calculating the price of products.
And it was also a cloud application.
It was all these new things, right?
Cloud, software as a
service, a SaaS application.
So everything was completely
outside of the norm of how the
normal enterprise would do it.
But it was amazing, they were
moving so fast and it worked.
And it got some results, but
the problem then was, then
came the data analysis part.
There comes the integration with the
ERP and the rest of the organization.
And that's where it got a bit stuck.
So that's where the initiative slowed
down and kind of lost momentum.
And at a certain point, it just became a
tool that stood there, you know, that's,
that's usually the challenge, I think.
Denis: Yeah, this is also from my
experience with the top down approach.
It was often disappointing just how little
we could reuse a particular use case.
The dream is indeed that if you have
something working in one plant, that
you can grab the code or even the ideas
and just copy paste it to a different
plant, but in the reality that turned
out to be completely impossible.
So people overestimate just how similar
plants are and how easy it is to copy.
Not to say that I agree
with the bottom up approach.
I think the truth lies
somewhere in the middle.
And I think that's where our next step is.
Discussion we'll have
Luke: Yeah, particularly, I would like
to also discover where it goes wrong,
as in what parts are considered To be
overlooked and which parts are we missing?
What do you think?
What's the kind of biggest topic that is
overlooked in this in both ways actually
Denis: data sources.
I have struggled with the most in
terms of integration was the level two
data coming from sCADA and the level
three data coming from the mES system.
SCADA is just difficult
in terms of high volume.
And you have all the different
tags with all their local names
in the local language that all
the OT engineers understand.
But then once you
translate this to English.
You essentially lose a part
of the context of this data.
So you now have this data in
English and everyone can access it.
But the people that access it,
like the data scientists, the data
analysts, they don't have the context.
So they go and ask the OT engineer
and they ask him, Hey, what
does this tag in english mean?
And he'll tell you, I have no idea
because I don't know what this
tag represents in my language.
Luke: Oh, wow, okay, that's a big one.
Yeah, so I think I agree.
It's very hard to get the
lower level data clear out
I think the Biggest challenge in both
top down and bottom up is mostly staying
clear on the strategy somehow, having
the clarity on why you are doing things.
And everybody understands why that matters
and what the impact is off these projects,
because I think they somehow, even if they
are bottom up or top down, they happen
somewhat in isolation and they're not
connected to the rest of the organization.
They are not, they're not a
unified solution, they are
not encompassing everything.
They are somewhat focused on only a
specific set of questions of like,
why is this machine standing still?
You know, why do we have like this
interruptions or how is our energy
costs and it is high, there is a
very specific question they answer.
And then that's the end of it.
Instead of looking as data as
the, you know, the true value for
organization or your core mission of
why you do digital transformation.
That's the thing that made
it a very common challenge.
Denis: Yeah, absolutely.
Companies get stuck in the so called proof
of concept purgatory, where they launch.
No POC of the POC, but they never managed
to really transform their business.
Luke: Great one.
Yeah.
All right.
So , what would be the best way?
how do we find the middle ground for
a successful digital transformation
strategy if we have multiple sites?
Denis: So as with most things, I think
the truth lies somewhere in the middle.
Like you need some thing on top that
gives a general sense of direction and
strategy to avoid complete anarchy.
But then the strategy has to be
sufficiently flexible at its ends.
So really at the local plant
level to allow the engineers
there, the freedom They need.
to implement the solution and
not have to, redesign everything.
Luke: Mm-Hmm.
.
Okay.
So and how do we do that?
Let's, let's dive this,
Let's make it a bit practical
for the listener here.
'cause we've been quite theoretical now.
Denis: Technically, essentially, if
you have two different plants, let's
say with the same machines or super
similar, what you could say is that
they can at least keep all their current
existing automation stack systems.
So they don't have to change their eRP.
They don't have to
change their MES system.
They don't have to change
their SCADA system.
What we're going to do instead
is we're going to try to.
Get the data out of all these systems
into an external component, right?
And we're going to make sure
that this external component
is the same in every plant.
And this, is what I mean with having
sufficient flexibility at the plant
level by not dictating, but not enforcing
any changes in their existing systems.
But the new component that you add
to this stack, that one has to be the
same at every plant so that you have
sufficient control over the way data
is modeled in that new component.
Luke: Can you explain a little
bit of what this architecture
would look like for a company?
What would be the way that I can envision
this, envision this for them being done?
Because it might sound still a
bit like, Oh, we just have to, you
know, buy something, but it's not
really working like this, is it?
Denis: No, essentially it helps if
you forget about the enterprise.
Let's focus on just one plant.
If your challenge was to digitally
transform that plant, how would you do it?
Well, you would have to collect all
the data in one source of truth.
So our objective would be to
connect all the existing systems.
Some of them may be old,
some of them may be new.
So that may be legacy, but they want
all the data neatly organized in what
we call nowadays a unified namespace.
that will collect all the data in real
time in a structure that can be easily
understood by a person, by a human.
Luke: So we are using the unified
namespace, plenty of stuff to uncover
here, but practically speaking, we are
creating this system where we are going
to be storing all the data from one plant.
And then you, you explained to
me previously the idea of the
satellite and master architecture.
How does this come to being?
Denis: Correct.
So now let's consider we'd have
not one plant now, but multiple.
You have an enterprise with
let's say three plants.
Well, you would repeat this strategy.
So you would build an individual
unified namespace for each
one of the three plants.
And this gives you the same data
structure in every plant, because
you have a, if you look at the top
down approach, the people on top that
enforce this unified namespace, they
can decide how this data should be
modeled in the unified namespace.
So they can make it sufficiently similar
in all three of those unified namespaces.
So that they can build one master
unified namespace on top of those three.
That will then collect the
data from all the plants.
In one neat structure.
And that's what I meant
by having a satellite.
Collection of unified namespaces at
the plant level, but still having
one master unified namespace.
above in the enterprise that
collects the data from these plants.
Luke: Yes.
Okay.
great.
So this, in this way, we have both the
flexibility of the individual plants, the
sites, and we have an consolidation of
all the data underneath of it, and perhaps
even a single organization between them.
Denis: Yes, that's the goals.
The unified namespace is designed to
be sufficiently flexible to allow the
integration of any existing system.
So we are not forcing the.
plants at the bottom to change their
way of working, which is adding an
extra component that is designed to be
easily integratable, but then we still
maintain a matter of control over how
the data is structured and organized
in this unified namespace to allow
us still sufficient standardization.
That we can collect this data
and unite it and unify it in
one master unified namespace
Luke: Right.
Okay.
So let's say somebody is
working at one of the sites.
They are struggling with having,
better grip on their operations, a
better overview of their effective OE.
They want to have a
centralized data strategy.
Now they want to get started.
Could you maybe walk them through
to one piece of advice that you
would give to get started, where
to begin what in your experience
is the best way to approach this?
Denis: I think it boils down
to having a focus on your own
problems at the local plant.
So design the system so
that it's relevant for you.
But maintain close communication with the
people on top, on the enterprise level,
to make sure that the way you deliver your
solution, so your data works for them.
But the beauty about this approach
is that you essentially don't have
to worry too much about what's
going on in the other plants.
so the answer to your question is
that are, your current problems.
You can even start with having
a particular use case in mind.
Let's say a particular machine has a
lot of downtime and you don't know why.
Well, solve the problem for this
machine, make The revenue already quite
soon so that people stay motivated.
Luke: Right.
So it Is basically both worlds
because I mentioned previously that
in my experience, this very focused
sort of approach is also challenging
because it can Lose momentum,
but maybe it lacks the strategy.
So this is the middle way where you need
somewhat of an enterprise strategy to know
of like, so you need to have an enterprise
strategy by default, and then you, need
to work it like to a specific case.
Okay.
Saying we starting here, but then in
the back of your mind, remind that
you want to use the unified namespace
as your approach, you're looking for
something simple easy to start with.
And then expand it from there with
the satellite and master architecture.
Is that right?
Denis: think that hits
the nail on the head.
Essentially you want to go fast
enough, not to annoy everyone with
the amount of time it takes, but not
too fast to cause complete chaos.
So you have to find that sweet spot where
you're solving problems for your plants
efficiently, but having the result in
such a format that it can be collected
and reused by the enterprise level.
Luke: Excellent.
All right.
Well, I think we made a good start
here for a second episode of this show.
Anything to add or anything I forgot
to ask you, Dennis, on this topic?
Denis: No, I think the
discussion was pretty complete.
I was very happy to talk about it.
Luke: All right.
That's great.
I think so too.
I if you like this episode please
of course, give us a rating
Denis: Yeah.
Also, if you had any particular
questions or even ideas for
future topics that we can cover,
feel free to share them with us.
Luke: Yeah.
we'd love to hear from you and you find
all our contacts and the information
about the, some of the products we
talk about in the show notes below.
Mind you, this is a free show.
We don't have any sponsorship, so
we are just doing this to share
knowledge and it helps us a lot if
you also share our episodes as so we
can also get more successful at this.
Thank you so much for
listening and see the next one.
Denis: Thank you.
Bye.
Bye.