Luke van Enkhuizen: Welcome
to the smart metals podcast.

I'm your host, Dennis
Gontcharov with my co host.

Luke van Enkhuizen.

Denis Gontcharov: We help
metals manufacturers on their

way to digital transformation.

And in today's episode, we will talk
about the pitfalls of digitalization

in the metals industry, and we'll take
a deep dive to see what goes wrong.

So Luke, are you excited
about this episode?

Luke van Enkhuizen: Yeah, very much.

This is one I've been looking
forward to since a while.

You know, digital transformation
is important, but there's a

whole lot of things that could
go wrong in your journey.

So let's talk about it today.

Denis Gontcharov: Yeah, fully agree.

I mean, digital transformation is all
over and I believe you were at Hanover

it's definitely very high on the agenda.

On any boardroom, but surprisingly, it's
most often even, I would say goes wrong.

Have you had the same experience?

Luke van Enkhuizen: Yes.

Or at least the expectations are being
met in the way that they should be met.

As in, I think it's a lot of,
yeah, a lot of headache in the

industry about this topic here.

Denis Gontcharov: Yeah, I think the main
topics, what go wrong in our opinion

are objectively, we see that most
digital transformation initiatives fail.

So companies set on projects and
those projects either continue for

way too long or they go out of budget.

Then again, the projects that are
successful often stay in pilot purgatory,

which means that you have a pilot
use case, but you fail to scale it.

Finally, I also see that there
is a lack of digital strategy and

especially with a focus on data
infrastructure and data quality.

Companies just tend to go too fast.

Have you seen any other
things in industry?

Luke van Enkhuizen: I think
you summarized it pretty well.

I think we should definitely explore
the, the part of pilot purgatory.

And lack of a digital strategy
is, is I think the umbrella

where everything falls in there.

I mean, if you don't have a
digital strategy, you probably

will invest into legacy solutions.

I think a lot of companies tend to present
themselves as a digital transformation

solution, but it's quite legacy.

So it will not integrate with the
rest of the stack, which is then your

fourth point about data infrastructure.

Well, I think that the digital
strategy comes first, and then

that is kind of the umbrella where
everything can fall in there.

And these topics should
be covered by that.

Denis Gontcharov: Yeah, I think
that's a good formulation.

Let's assume for an instance that
a company has a digital strategy.

Usually this means that they will begin
by implementing some pilot projects.

By this, I mean that
they have some budgets.

It's often not too big and they just want
to test the waters, you know, they want

to implement a particular a pilot, right?

And see how it goes if
it generates revenue.

Now, the problem with this approach
is that for some reason, even

though if the project is successful,
it never really manages to scale

across the entire enterprise.

Luke van Enkhuizen: Yeah.

And why would that be?

What's going wrong there?

I think you make a good point.

I think that's something we
can definitely start with.

Like, what is the pitfall there?

Denis Gontcharov: So in my experience in
the last company I worked at, one of the

issues was that The IT, so information
technology and OT, operational technology

departments, are often very misaligned.

And in some cases they are
actively blocking progress.

I think because digital transformation
is such a holistic approach, it's a

transformation of your entire business,
that if one of the parties is not

on board, you very quickly generate
a lot of resistance and friction.

Have you seen that happen?

Luke van Enkhuizen: Yeah, definitely.

And I T O T struggle is real.

I think it departments generally
want to keep the status quo somehow.

They want to preserve things, protect
things while OT wants to change the

daily operations for the better.

They want to move things forward.

Production always goes on and this
is where I think a lot of projects

end up nowhere because they don't
fit the view of the IT department or

they seem to have not enough depth
of the organization behind them.

Denis Gontcharov: Yeah, I think
one of the main causes of let's

say not being able to scale a pilot
is a lacking data infrastructure.

So essentially your existing software
tools, your classical systems from

the automation pyramid are not really
designed to handle data infrastructure,

use cases that span the entire business.

So what often needs to be done is
the implementation of an IoT platform

that allows us to build the use
cases upon when that doesn't happen,

we tend to build siloed use cases.

I've even seen use cases that
were developed in parallel by

different teams in the same plant.

It all boils down again to
a lack of communication and

alignment across the business.

Luke van Enkhuizen: Yeah, definitely.

Again, the digital strategy has to be
carried around the entire organization

so that's both departments know in what
direction they should move, in which

way they should approach projects,
what is in scope, what isn't, what

fits their plans, what doesn't, and
when that's clear, it's pretty easy to

then launch the projects into action.

I think when an initiative is
launched only from one department

without encompassing the strategy.

It becomes an us versus them discussion.

We want this, but they don't want to
help us, but it's, it should be coming

from the, we all want the same thing.

It's our strategy.

This is a vision.

We agreed on this and now
let's fit in how we can do it.

I think that's a major pitfall.

That's always forgotten.

In projects.

Denis Gontcharov: That's a key point
you raised there about us versus them.

And I think this becomes even worse
when you like hire expensive external

consultants who essentially come and
tell your people how they should run

their business and do their job that
generates even more friction, right?

And often I don't know about you, but
without naming any specific names, let's

say very known and expensive external
consultants I had to work with and the

companies I have been at the strategy
they develop is not necessarily aligned

with the interests of the company.

What do I mean by that?

I mean that for them,
they have an incentive.

Or let's say at least they are not
punished when the project just takes

way longer than expected because usually
they are paid by the week or by the hour.

And then I see a potential of
manufacturers falling prey to these

external businesses who are really just
there to milk them off their finances

and sell them castles in the sky.

Have you seen it happen?

Luke van Enkhuizen: Yes.

And I must say, yes.

And I've seen this go wrong.

In various occasions,
but I can also say no.

And from other perspective that there are
exceptions to the rule and in other ways,

no, consultants can definitely be super
useful for a lot of strategic changes,

making strategic discussions, getting
those conversations going, facilitating.

The, the, the open interaction
between different departments

and getting everybody on board
for that digital strategy.

I think that's just very important.

I think it's also very useful to
bring in experts that can help

you build things when they have
the experience building things.

But I think the one thing
that is forgotten is domain

knowledge or domain expertise.

And I think that's where it goes wrong.

You have a generic consultant, Oh,
you have a domain knowledge and then

generic one would be one that indeed
just there for that stays too long, you

know, they, they should have already
have gone after a certain point, I

think a strategic consultant comes in
and should finish their job after, you

know, a certain amount of time when the
strategy is set, and then they should

pass it on to people that build it.

And I think that's where the, it goes
usually a downhill when the person that

comes up with the idea with the strategy
thinks that they can also handle the

execution and there are exceptions for it,
but I think most of the time it's better

to then, you know, find the right people
for the implementation going forward.

I've seen this going wrong quite often
that, that indeed there are companies

are being pulled into very long running
it projects that are actually initiated

by a company that came in with strategy,
which then, you know, Kind of ended up

nowhere, like it just kept on going.

Denis Gontcharov: Yeah, I think again,
you made a very important distinction

there between what the responsibility
of those external consultants is.

And I think as you put it, when they
are there to supplement a skill that

you don't have in your company or assist
you with a very IT specific topic,

then I think it makes sense, right?

The problem that occurs in my opinion,
when you hire external consultants

for the complete package, let's
say strategy use case and hoping

they have the domain knowledge to
tell you how to run your business.

That's where it often went wrong.

So I think because the company has a
domain knowledge, the manufacturer,

they in fact should have the majority
of the work in defining the strategy

because only they really know.

How they can improve their business.

Luke van Enkhuizen: Yeah, I always
picture it is that if you bring in

, a company brings in a consultant or
you bring in a consultant, the act

of hiring somebody is a great thing.

Actually, you invest in your future.

I mean, I might be, might be a little
bit biased because I am a consultant

myself, but I do think it's generally
very good to bring in external expertise.

Once you're stuck, I mean,
I invest in coaches myself.

I invest in trainings.

I do this because sometimes
I get stuck with something.

You get too much in your head or you
just don't know how to communicate.

There's so many places in the world
where you get help from what is the

important distinction here is that most
companies that hire those consultants.

They maybe don't have a plan in advance
of where it should stop, where it

should end, what is the end station.

And I think having that in mind
is important because that's, that,

that kind of gives you a goal.

And then on the side note of that,
I think if you hire somebody,

you can bring somebody in
to do the work for you or

somebody that helps you with it.

And I think it's better to do this
with somebody to And instead of

like, you know, sitting backwards,
crossing your arms and just, you

know, watching the thing develop, I
think you should be very engaged with

this, these companies learning from
it, putting your own people on it.

So I think bringing in
somebody is a great thing.

I just, you cannot just expect them
to do everything by themselves.

You need to give them
that domain knowledge.

If they don't have it already and support
them and be very involved in that.

And I think a lot of companies
underestimate how much time and energy

that takes from their employees.

And if you don't align them behind that
goal, that this is going to be done.

The project doesn't get further.

I think from my experience, doing
the various implementations for

software systems, such as MES
systems, ERP systems, and so forth.

It was very challenging for the business
and for also for me as the consultant to

make the employees aware of their role
in this and how much they should do and

that they should make time for this and
take the take foot in the effort to learn

the new developments, new solutions.

And this conversation has to
come from the company internally.

That's why the strategy has to come
first to know that this is a priority

that somebody is actually available for.

Like a day or two a week, for example,
for a project like this, for a short

amount of time to get something done.

That's at least my observation.

How about, how's yours about this?

Denis Gontcharov: No, it's the same.

In fact, in teams I've worked at one
of the main complaints was that this

new digital transformation project that
essentially becomes additional work

that goes on top of their daily work.

And so the company doesn't sufficiently
accommodate the fact that this is

actually a very big project, right?

For which they have to allocate.

And it becomes even worse if you
have an external consultant, because

they, of course, that's their main
job and they tend to, I wouldn't say

bug or like annoy the local employees
asking for their domain knowledge.

So I think as I said correctly, that
you have to really align the whole

company that this is happening.

You have to reinforce that the definition
of the digital strategy is definitely.

At least.

Half of it is a responsibility of
the company, but also you have to

prepare your employees and give
them ample time to implement.

The strategy together with
the external consultant.

Luke van Enkhuizen: Yeah,
fully agree with this.

So important.

So a major pitfall is not aligning the
consultant that is coming in with your

internal staff, I would say, and then that
you have a plan in place, how you would

handle that external energy coming into
your company, the external motivation,

those changes and how you deal with those.

Denis Gontcharov: Yeah, because again,
in implementation, I think if we

move forward, the two common problems
are unclear use cases that we don't

really know why we're implementing
the use case, or we don't really

know what the benefit will be.

And the second would be the
lack of T shaped expertise.

The fact that companies are now
faced, especially in the metals

industry, with a demand for skills
that they don't necessarily have.

Let's say very data focused,
very IT and focus on analytics.

And I think that's a great opportunity
to hire external consultants to

supplement this knowledge, but then
from like internal company, the

responsibility to clear up the use
cases using their domain knowledge.

Luke van Enkhuizen: Yes, exactly.

Yeah.

Huge, huge one.

I think this is also so in line with
the IT versus OT discussion, because

again, the IT or nor or the OT
department might not agree with the

plan from the external consultant.

Now, who is going to be right?

Who's going to call the shots here?

Yeah.

Who is the project leader?

And who has.

Which ability to move or move around
and especially even more so when

there is a multi company multi sites
challenge, if it's, if it's coming from

top down, as we discussed earlier, it's
even becomes a bigger challenge or a

bottom up, you know, it might be a very
specific consultant coming in for a

very specific reason on a OT challenge.

Has a great solution, but it doesn't
recognize this as the way forward.

And the top management doesn't even
know about this initiative in the

first place, or doesn't understand why
this is part of that digital strategy.

And that's the project basically
doesn't get any further.

The OT will then still have to pay that
consultant because he has to try things.

Or she has to contact
the, the IT departments.

Doesn't get the answers, cannot get
further and nobody's getting anywhere.

Lots of meetings, extra costs, so

Denis Gontcharov: Yeah.

Yeah.

And it's hard, right?

Because we talk about there's one
company, but in reality this company

consists of departments and us
being all humans, we all have our

own desires and our own concerns.

Right.

And if you think about different
departments, so when they ask what's

in it for me, digital transformation,
you could argue that for OT, it

just brings extra risk, right?

Suddenly they have to give this
external company or the IT department

additional access to their PLCs.

And for them, this could only mean a
potential production halt interruption.

And this literally costs them money.

So for them, it's really a risk.

And that's why I think it's so hard to
align anyone within the company, because

some departments stand to gain from
it while others stand to lose from it.

Luke van Enkhuizen: I think you
made a point perfectly clear there.

This is a huge one.

And I think this is a good step up
towards getting access to the necessary

data or systems to make any changes.

Don't you think?

Denis Gontcharov: Absolutely.

And I think to circle back to
the unified namespace or let's

just call it IOT platform.

Let's say a central single source
of truth for all your data becomes

that important because in my opinion,
it addresses one of this problem.

We essentially democratize all
the data, so meaning all the

information of the enterprise.

And in that way we don't, we no longer
have to, let's say, put all the risk on OT

or on it, and we can really share in the
responsibility of keeping this data clean.

Luke van Enkhuizen: Definitely, yes.

Because how often have we seen
from our experience that we

need data from various sources?

And it takes days, weeks, to just
get access to it and it doesn't,

has the right structure it needs,
it doesn't, has the right context.

We both have to talk about here, of
course, the digital transformation about

data analytics, and we have to talk
about automation purposes and process

improvement, which do have a little
bit of a different set of requirements.

One would talk probably about
having access to APIs and making

changes and calling up some kind
of events and the other would be

more about finding a structure.

But in any case, you know, You
don't have to start somewhere

with , making an analysis of
how things are right now, right?

Making it, making your dashboards,
making your real time insight.

And then it is, it all comes down to
having a somewhat unified solution

that covers your, your entire stack
from up to bottom for your enterprise.

Denis Gontcharov: Yeah.

And as I've seen throughout this
episode, right, I think it all

begins again with your central
strategy that hopefully involves

building a central data repository.

Let's say usually a unified namespace
and hopefully this will involve all

stakeholders actively to make them want
to make this transformation succeed.

I think this is the only way.

And by unified, I guess in this
sense, we not just mean unified data.

We really mean a unified
business unified strategy.

Luke van Enkhuizen: Yes, definitely.

Definitely.

I think this, this also touches on
the point, which I often have to

explain is that a lot of manufacturers,
they tend to misunderstand

what, what The Ford industrial
revolution is about what industry 4.

0 really is about.

I think, you know, it isn't just
about like buying a new software

solution or bringing a bunch of robots.

It's not about like connecting a
couple of software systems together

to just perform basic tasks.

I mean, that stuff is already there.

That is already common knowledge.

That is not.

Did we have a revolution there?

I mean, the third industrial
revolution was really about automation.

We've taken this a couple of steps
further with office processes and

machine connections, but to truly
digitally transformed to really,

truly become that industry 4.

0 factory.

You need to be able to let the
systems interact with each other.

And for that, you need a data source that
is somewhat structured to do that in.

And this is where I think you need to
make sure that you using that software

and that data to reinvent your business
and how you can apply it instead of like

thinking about buying another tool and
then connecting it together, which go back

to the point that you said, like, it has
to be some kind of data strategy in there.

Denis Gontcharov: Yeah.

I mean, data and it and technologies
is just a means to an end.

As you put it, we indeed want
to automate business decisions.

And for that, we need information.

And this information comes from the
data that's stuck in the old systems.

So once we have all data unified,
then we can finally achieve the

fourth industrial revolution.

Luke van Enkhuizen: Yes, and I think also
to add to that, that if we talk about the

metal fabrication industry or metal metal
manufacturers industry from the beginning

to the end, you know, sure, we talk about
the entire supply chain, starting at

the smelters or the metal producers all
the way to the end products and perhaps

even the whole recycling cycle after
that, I think if we look over the entire

spectrum, there is of course different
challenges that each of them have.

Especially in the fabrication
sector where I'm active in.

I think a lot of companies are still
focused on buying machineries and

they perhaps buy a machine that then
has this label of like industry 4.

0 connectivity on it,
which then leads to OPC UA.

And there's a lot of misconceptions
about what that means for them.

Because just that the machine has this
OPC UA standard doesn't mean that you

have a system to handle that data,
nor that you know how to work with it.

Not even to speak about the challenges
that OPC UA has, there's lots to

be discussed over there, but I
just wanted to make the point that.

It's more than just thinking about
machinery or buying software solutions.

It's really about how you're going
to use that and interact it in your

into your strategy and your systems.

And how do you want to store that data?

How are you going to combine that
with various sources to actually

get to knowledge that you can
use to improve your business on?

And I think this is where a
domain expertise is necessary.

And this is very often forgotten because
it's quite easy to buy this, you know,

process automation tool That interacts,
interacts with various programs.

So it's quite easy to buy this BI tool and
then start working with one data source.

But it starts to get extremely complex if
we bring various data sources that change.

Denis Gontcharov: Oh yeah, absolutely.

I think this new holistic
approach to data systems.

IE uniting them all into
one is pretty new, right?

Over the past decades, vendors
have always pushed their solutions.

Like, Oh, buy this new ERP system.

It will solve all your problems, get
SAP and everything will work perfectly.

Or get this new MES,
get this new historian.

But as you said, we indeed need to
move on one level above that and

really think about how do we now
connect all these individual systems?

And for that there isn't
really any blueprint available.

At least not today.

Luke van Enkhuizen: Yes.

I think the blueprint is the one that
somehow you have to create yourself.

I think the major shift that you
have to do is instead of thinking in

products or softwares or machines,
you have to think in functions.

And if you start thinking in functions,
as in what you want to achieve, then

it becomes possible to define what
step does the process has to do.

And that's also goes for your data system.

If you know the function of your data
solution that you're bringing in, you can

then find various ways to achieve that.

And so for example, when you talk
about OT, IT, when you talk about

the interaction between for example,
the sales departments and then going

to production, following up by the
continuous improvement of that production

process quality, registration, and
so forth, all the way to compliance

and, and all the finances around it.

These have different functions.

And I think a major pitfall is that
you are trying to find a one, one size

fits all solution, which is very hard.

If you don't, first of all,
know your functions that

you're serving, what you need.

And then secondly, how this fits
into your data strategy again,

because if you buy one solution.

So apparently going to be in
one database sounds great.

But what if you do have to bring in
some things extra, some extra tool

solutions, if you have to start again.

So if you skip that step of making your
own functional plan, this can be done in

various ways, like value stream mapping,
business process, modeling, notations,

data flows, et cetera, all these, these
things that you need to do advance with

ideally somebody that's knowledgeable
about your business and the it Then

you can define what your functions are.

And if that step is forgotten,
yeah, you don't have a steering

wheel for your business to see
what you want to improve on first.

I think this also leads into what
you mentioned earlier, like somewhat

of a a use case, because you can
only define the true use case.

If you know what function you want to fix.

What's function you want
to improve your business.

So knowing what you need to improve first
is the most important thing from my end.

As it goes back to which part of
the business needs, needs help in

the digital transformation vision.

Denis Gontcharov: I think if you're asking
yourself the question which technology

should I buy to digital transform you're
asking the wrong question It's really

about how can I rethink my business
processes to make them more efficient and

technology is really an after thought.

This is in fact a solved problem.

There's a lot of great solutions available
and I would even be as bold to say that

the technology is not a difficult part.

Even the unified namespace is not
an architecture, it's a philosophy.

The way you.

implement this unified namespace, which
technologies you use but matters much less

than the definition of what you really
want to transform about your business.

Luke van Enkhuizen: I fully agree in my
experience, not coming as much from the

data science part as you are into, but
more from ERP MES implementations and

everything around that, the more I, the
more I learned, the further I get in

my career and the further we develop in
the industry, the more I see that all

ERP systems have a lot of in common.

A lot of MES systems have a lot in common.

They all have the same functions,
a lot of overlap between the two.

And indeed, it's about knowing how you
want to use that tool to orchestrate

your entire enterprise and how this has
to interact with other things outside of

business, how you want to measure this.

What, what, what is your plan?

I think that is, that is indeed the most
important question to answer because

I can imagine this with data science
is really similar from my experience

as well with my experience with doing
process mining projects as well.

It's really about what
do you want to zoom into?

Like, what do you want to see?

What is the thing that is the
key component of my business?

What is the part that the business What
does, what, how does it generate money?

You know, where does it come from?

What is that key process?

What is this one lead indicator
that you have to focus on that will

improve everything on the end line.

And that's, if you know that, then
you can make the functions around it.

And then you can find.

A technology last for that.

So you know, maybe we can mention
an example here, but in, for my

experience, for example, it has
been in continuous production.

It's always been OEE, right?

Like how many interruptions does
your machine had in discrete

production: has all the materials
always been there on time delivered

to the stations when they need it.

So there's no waiting
times, no rescheduling.

For any of these different
business models, there is a

specific indicator that you could.

Find and to get the answer to how you
can optimize that bottleneck there.

That's why you need to data for.

So this is a use case that you zoom into,
but I think rarely ever do companies do

this thought process of thinking about
the enterprise, what is our core business?

What are the lead indicators?

What are the lagging indicators?

What are the outcomes?

What functions do I have?

And then start working it down from
there and then saying, okay, great.

Now we need a technology that
can answer that question to us.

And this is where you need an
expert to, you know, build that

technical solution for you.

Or you do it yourself, but I
would highly recommend doing

with an expert for that one.

Denis Gontcharov: Yeah, I agree.

And to circle back to the pitfalls,
that's indeed what happens if you

completely outsource your strategy, right?

But if we recap this
episode and we say that.

We begin with a good strategy
that we define mostly ourselves

based on our domain knowledge.

Then we identify the gaps in our
own knowledge and hire external

experts for that, individual
consultants, or even big companies.

Then we can start implementing the
digital transformation strategy,

which would involve building
a unified source of the data.

Is that correct?

Luke van Enkhuizen: Yes.

I think the typical failing projects
will go by beginning with technology,

buying a tool, then saying, Hey
guys, make something out of it.

This is the way.

Then they don't explain
the business benefits.

That's the second problem that goes wrong.

It's not taught as a
encompassing strategy.

Then it forces upon the OT and
IT, all kinds of new technologies.

They don't even know about what it's for.

What is the purpose of it?

They, some consultants come
in, they start working with it.

They make their own prototypes.

Nobody really understands what it's for.

It's creating some unrest because
nobody has scheduled time for it.

You know, the organization has to change.

It drains resources the team's
getting resistance and you can

hear it at the snowball rolling.

It's getting worse and worse and worse.

Right.

Then at a certain point, you realize
this project should actually maybe

stop because it's, you know, maybe
not getting anywhere, but you already

have this contract and you have this
partnership and you have the software.

You already bought the software.

So now this sunk cost balance, the
sunk cost balance is coming on the pay.

Then to make things even worse,
the other consultants that continue

with it don't have the domain on it.

So they build things you don't need.

They'll build too many things.

Usually they built too many reports,
too many indicators, but it's only

one indicator that really matters.

And at the end of the day,
it's ends up some kind of.

That's like kind of a hobby project that
some employee maybe he still works on

a little bit on the side when he has
a few hours here and there, but nobody

Denis Gontcharov: I've been there.

Luke van Enkhuizen: integrating it
into the core business and then it,

you know, it turns it to a siding
activity without, Any impact.

And you mentioned the last
one you've been there.

So perhaps you could briefly explain that.

Denis Gontcharov: Yeah.

I think you nailed the problem.

Exactly.

Like in one of my previous projects
companies I've worked at this exact

scenario happened and they ended up
with a very expensive, fancy dashboard.

Whose most features were not used at all.

They were completely scrapped and the cost
of development was well over a million.

So they use a small part of this
dashboard that could probably have

been built by an intern in a couple of
months instead of this huge Project.

I think symptoms you listed are
very clear and very important.

Like when you're a local, when your own
employees check out, when they say, no,

I have my own stuff to do, and I want to
interact with this external consultants

anymore, it's getting too busy.

Yeah, I think that list
is pretty complete.

Would you add something?

Luke van Enkhuizen: No, no.

I think if a project ends as a hobby
project and it costs you over a million,

then I think we did something wrong.

And this is the example.

I mean, the worst case scenario
would be that the project

never is getting launched.

I mean, that's, of course, the worst one
in your case, at least it was launched.

There's plenty of examples of where
ERP systems never got launched at all.

That would be like the worst
case scenario, as in you spent

a year or something with cost.

And then it's just.

Stays there.

Which is of course, that's
the thing you want to avoid.

I would just only say like to start
a successful project indeed, we

start with strategy and a business
problem, and this has to be

somewhat done partially internally.

And as you said, and bring in domain
experts is really, really important.

You know, like getting.

Domain experts, both industry
specific, but also technology specific.

You need that help.

Because whoever tries to do it
themselves will be caught in the

daily whirlwind of operations and
we'll probably get to the same place.

Cause you do need to be very
thorough in the beginning.

You need some kind of an
engineering approach for this.

But this could be a next episode again to
discuss about how to engineer your success

for a digital transformation because
there is a system to it, but you can

actually do this with strategic decision
making with various steps, tools that

I already mentioned to get this right.

So I think we can keep that for
our next episode and to keep that

teaser up for the listeners here.

Denis Gontcharov: Yeah, I fully agree.

And I think we've made
the tour of this subject.

I think it was very interesting.

I surely enjoyed it.

What do you think?

Is there something you want to add?

Luke van Enkhuizen: Yeah, I've
just wish we had less of these,

these stories, but things going
wrong on more stories of success.

I would only add that in the, the
technology is moving so rapidly.

So it becomes even more important
to think about your projects on a

strategic level, because you will
have so much choice and it's such a

great thing as you know what you want,
because people that do know what they

want, they are being super successful.

They can switch very quickly.

So yeah, it's, it's time to get going.

Denis Gontcharov: Yes, and stay positive.

Even if we fail, we are still learning.

We can always do it again.

And I think the future looks bright.

Luke van Enkhuizen: Right.

Because then it's an experiment
and that is also completely fine.

Experiments are completely fine for
various reasons, but if we're talking

about a digital transformation where we're
actually going to invest significantly,

you need to have to take it a bit serious.

So yeah.

Denis Gontcharov: You

Luke van Enkhuizen: All right.

I hope it motivates a bit.

Yeah.

I hope this through the flowers,
you can, what you can hear that we

are say, giving you the steps to
do this and you can be successful.

So I wish you great success with
your digital transformation.

Denis Gontcharov: Yeah, likewise.

Good luck and thank you for listening.

Luke van Enkhuizen: All right, guys.

See you next time on the
smart metals podcast.

Denis Gontcharov: Bye bye.