Expert Talks with Federico Milan: innovate from processes, not technology

Federico Milan's journey: from a passion for electronics to artificial intelligence

Daniele: Hello everyone, my name is Daniele Delle Case and this is Expert Talks, the Things5 podcast about technology and smart products with industry experts. Today we're joined by Federico Milan, who has more than 25 years of industrial experience in digital transformation. Federico has been through practically every stage of this journey: from designing OT architectures, to automation, to developing industrial software platforms like SCADA, MES and WMS, all the way to IoT, Machine Learning and artificial intelligence projects applied to industrial machines. Welcome Federico, how are you? It's a pleasure to have you here with us.

Federico: Hi, thank you for inviting me on this podcast. It's a pleasure to be here with you and have a chat.

Daniele: The pleasure is ours. For those who don't know you yet, even though you're fairly well known in the industry, would you like to tell us about your experience in a few minutes?

Federico: I'll try, it's always hard. But if I had to find a common thread in my journey, I'd say it has always been curiosity: understanding how things work and, above all, making them work and optimizing them in some way.

I started out as an electronic engineer. At first I designed analog electronics; in 2000 I developed an MPPT for photovoltaics, and in 2001 I entered the world of automation. I started very close to the machine, developing the PLC, the automation framework, process control, and then moved up to supervision and MES, which I basically developed from scratch for our production process. Gradually I realized something: the higher up I went, the less the problem was simply controlling the machine and the more it was understanding the process.

An interesting step came in 2005, when I developed a self-adaptive regressor on a PLC. Back then we didn't talk about machine learning the way we do today, but the problem was already the same: using machine data to adapt the system's behavior. My interest in what we now call artificial intelligence was born much earlier, in high school, when Federico Faggin came to visit us and talked about neural networks. For me, being passionate about electronics and liking computer science, it was like a short circuit: I realized that maybe that was the thing I liked, even before AI. I still remember that I'd grown fond of what was called Fuzzy Logic and of expert systems, and then neural networks. Technologies change, but the question always stays the same: how far can we make a system capable of understanding its own context and therefore adapting? That has pretty much been my common thread.

Daniele: And what answer have you given yourself to that question?

Federico: That question created the desire to develop something new, which I called Smart SCADA. It was an idea to break the traditional CIM pyramid, the industrial automation pyramid: not simply connecting the levels to each other better, but questioning the architecture itself. From there the whole technical side evolved: along came IoT, WMS, business intelligence, Industry 4.0 and finally AI. In 2016 I was given responsibility for the digital division, and in 2018 a business unit also dedicated to AI was formally set up.

If I had to sum it up, it might look like a career that goes from electronics to AI, but I see it differently: I've always stayed on the same problem, understanding the process and finding a way to govern it.

Daniele: It seems to me there's a common thread beyond the one you described, tied to curiosity. Your journey starts from OT, from hardware, and then moves from software to data all the way to digital innovation. Do you think it was a conscious choice or just the result of this desire to understand the process?

Federico: I'd say both. Essentially it's a natural evolution, because every problem opens up another one. Let me give you an example: you control the machine and you discover you need to supervise it. You supervise it and you discover you need to contextualize what it's producing. At that point you build an MES and you discover that the data has to talk to other systems. You connect the systems and you discover that having lots of data doesn't mean having information. When you start having information, another question comes up: can we use this knowledge to optimize the process? At this point, with the technologies we have today, machine learning and AI become almost a consequence.

That's why I've never seen digital transformation as a success of technologies. I see it as a progressive extension: we keep adding pieces to govern and close a problem, to provide a solution.

Daniele: That assumes there's a technology that solves the problem. How would you approach a problem that doesn't yet have a technology to solve it?

Federico: That's today's problem: we think we can take technology, drop it into a context and hope it solves things for us. I start a bit from philosophy. First we need to contextualize the problem, but even before that I'd start from an important concept: the value proposition we want to achieve. If I have a problem, I have to define its boundaries and give it meaning, give it value. From the value proposition comes a strategy, from the strategy come the objective and the goals we need to set ourselves, and from the goals we find the KPIs.

All of this comes from understanding what mission we give ourselves, how we structure our path and how we want to analyze it, because designing also means designing the measurements to understand where the problem is. We have to contextualize. Once we understand the problem, we might realize that changes are needed, and the changes are often not technological, they're procedural.

What innovation means for Federico Milan: resolving contradictions, not applying technology

Daniele: You mentioned something that's often underestimated in companies, and also by people who build products: understanding the problem. People start with the solution without really understanding the problem of the user who will then have to use it. Do you have a framework for identifying these problems and for being able to articulate and communicate them well, both within your team and for yourself?

Federico: There are lots of frameworks: think of brainstorming, design thinking. They're tools that allow people to communicate with each other, and the value of a company, as clichéd as it may sound, is its people: they have the cognitive ability to understand the problem and then govern a process of change.

Each of us, though, builds our own frame, and each of us gives a different meaning to innovation. For me, innovation is when I find a way to bring together two needs that are very far apart; I have to resolve one or more contradictions. If I think of Smart SCADA, I needed to standardize something while keeping it flexible, and standardization and flexibility are often antithetical. If you manage it, you automatically create innovation. I admit I'm very close to Altshuller's thinking in this context, without claiming to apply TRIZ rigorously, but that's the idea: break the problem apart, understand it. There are other techniques too, like DoE (Design of Experiments), but they all involve a design approach that lets you go deep into the problem, and from there extract the mechanisms and the frontiers we have to face.

Daniele: Earlier you said you developed a machine-to-machine connection framework back in the early 2000s. What led you to create an IoT system before IoT even existed as a concept? Did you use the same approach you just described to get there?

Federico: I'd say yes. It was perhaps the moment when there was a change that was “not just technical”, but also a new way of making automation efficient and effective. The idea was this: if I have machines and these machines generate data, why should information reach the higher levels only through rigid tunnels between the levels, when we think of the CIM pyramid with its levels 0, 1, 2, MES, ERP, instead of making the machines autonomous, self-consistent, able to vertically govern their own production context while still being able to inform those downstream?

I imagined many work centers connected in cascade or in parallel, each able to cooperate with a network of agents capable of governing its own process, communicating with those downstream and upstream, and giving awareness to the person. It was 2007-2008 and we had to face a change, create something new. That's where Smart SCADA was born, which led to changing a philosophy: it's no longer about coding but about composing. Imagine Lego bricks that can be combined to create the system: a machine is a component made of many bricks that can be inserted, removed, moved within the ecosystem, and everything keeps working thanks to peer-to-peer communication mechanisms and the master system's ability to understand where it is, and why, and therefore to govern processes efficiently. Smart SCADA is the combination of Supervision, SCADA, MES, WMS and Business Intelligence.

Daniele: And in the short term, what value did this kind of integration bring to the people working on the machines, and to the company?

Federico: This idea certainly brought a very concrete result: a plant normally took nine months to develop, and we practically cut that in half. We no longer had to write code and rethink software modules from scratch, because we had created mechatronic modules, autonomous systems that could be plugged into the context and recognized automatically. I took low-value activities away from my designers so they could focus on real value creation. I knew I'd reached the goal when I was working with schools on work-study internships. We had just finished developing this framework and we gave the test to a kid fresh out of technical high school. After three weeks he had managed to set up the supervision of a machine, honestly without knowing why it worked, but it worked: composing the bricks made it possible to connect all the assets to the MES automatically without writing a single line of code, without worrying about where that tag or that variable was, because everything was consistently known across the systems and they communicated with each other. The only task was deciding whether to put the button on the right or on the left, or where to position that work center relative to the others or to other machines. Today we talk about software-defined automation, software-defined networks, software-defined processes: that was a beginning, done some time earlier.

The value of networking and writing as a tool for reflection

Daniele: I wanted to mention another aspect of your career that I really appreciated: you've written several books and you sit on various scientific committees, including SPS's. I'd like to understand two things: what value has the network of scientific committees brought you, where you can exchange ideas with people who have interesting and different stories to tell, and what led you to write a book, what value do you want to give the people who read it?

Federico: Interesting questions; the first is easier than the second. Taking part, having a network, is essential. I've noticed that innovation suffers a lot when we stay confined within our own industry. Meeting people from different worlds makes you discover that someone has already faced a case similar to yours, maybe contradictions similar to the ones you're thinking of resolving, and this exchange lets us grow. The scientific committees, SPS, keeping in touch with universities, meeting other companies and professionals have given me above all this: cross-pollination. I think people who do innovation need to stay with their own problems and their own skills, but also have peers who can be contributors, and create a network of exchange.

On the second question: maybe I wrote because I had realized I wasn't simply developing software, I was creating a new philosophy, and there was a model behind it. Smart SCADA came from the attempt to break the CIM pyramid, to change paradigm, to move from coding to composing, so not always building applications from scratch but making them collaborative and giving them an internal semantics. Writing forced me to do something useful for all technical people: turn an intuition into an experience and into a system of thought that helps you find other paths.

Daniele: So it's not just wanting to pass something on to others, but also a way to question yourself, think things through and maybe clarify some aspects that weren't entirely clear.

Federico: Definitely. I'll also borrow a line from a professor, Carlo Bagnoli, who says that whoever writes a book is engaging in self-celebration. There's probably some of that too.

Daniele: Fair enough, and it can also have a positive effect on the writer's career or status. After all, the book is based on lived experience, and telling those stories has great value for everyone, besides showcasing your own work. Earlier you told us about the difference between innovation and technology. Do you have a specific way of telling whether a project is truly innovative or just technological novelty? Can you give us a concrete example?

Federico: Let's start from a premise: technology can be interesting but it can also fail to produce innovation. For me, innovation happens when we significantly change the way we solve a problem, because our job is to solve problems, so we need to understand when technology is useful. Here I'm attached to people like Robert Gordon, Lewin, Bateson, Erik Brynjolfsson, the J-curve: they all tell us that technology without strategy is useless. Let's try to think about what innovation really is. Here I'm very much in Altshuller's camp: I look for a contradiction. If I don't clearly understand which contradiction a technology or a solution resolves, I remain in doubt; if it's clear to me, then I understand it.

I gave the example of Smart SCADA for an automation audience: something that aims to be standard but also flexible. If I resolve this contradiction, standard while remaining flexible, I've automatically innovated. But we can think about it in other fields too, including processes: I want to do the same thing in half the time; that doesn't simply mean applying technology, but breaking the problem apart, because it's probably the sequence in which we apply technologies that allows us to improve. We can also apply it at higher levels, because a company is made up of various processes, from sales to marketing, and the CFO can have contradictions too: how do I commit to creating a budget if I don't have one? Lots of paths open up here. My goal has always been not to be an obstacle, but to create pillars that all internal processes can benefit from. Not technology for its own sake, but a concept of strategy and technological construction: that's why we call it an ecosystem, supporting all business processes.

From vision to technology: the strategic framework, from vision and mission to KPIs

Daniele: How much of this innovation process is strategy, how much is process and how much is technology?

Federico: Now you've hit on something close to my heart. I always start from a vision. The vision creates a mission. The mission generates the value proposition. The value proposition creates the goals. The goals define the KPIs. The value proposition lets you build the strategic and tactical part that touches the technological part. But we always have to start from a vision and a mission: without them you can't define a value proposition that's useful for turning the ideas that come from brainstorming, from the business canvas, from a company's desire to keep doing better, into concrete actions. No part is more important than the others. Technology certainly comes after, because it has to apply a philosophy that comes from a concept of strategy.

Daniele: And how much is this tied to the business model? I imagine a good technology without a good business model remains a good technology that stays in the garage.

Federico: It's very much tied, and we're seeing it more and more. How often do we hear about services or servitization? They're not the same thing. Earlier I talked about building pillars that support the various processes without being an obstacle: the business model comes right into that concept of what we want to do. Today the market is very competitive and we need to change the way we go after it, building strategies and business plans that tell us how to act: do we want to sell a product? Do we want to sell a product and attach services to it? That's how IoT was born: we had a product, we attached a service to it, which requires another product able to communicate with a central base and provide data plus context and information. Today we can make good use of that information with machine learning and AI, to close the loop by going back to the customer with services and information. That's one strategy. Another strategy is to ask: why should I sell you a product and not the output it generates? Here we move from services to servitization: I no longer sell you the machine, I sell you what that machine does.

Servitization: selling value, not a kilogram of steel

Federico: There are lots of well-known examples, from printers with cost per copy to Rolls-Royce aircraft engines sold as flight hours. But let's try to bring this reasoning into an industrial process context, where civil works may also be needed: there you need a different strategy for servitization, supported by methodology and technology together.

Daniele: You brought up servitization. How have you tackled it in your career, and what real difficulties have you run into in this implementation process?

Federico: The first step is understanding the need: why can't I sell just a machine? The second is asking yourself whether I can add more value. A thought comes to mind, let's see if I can see it through: think of a mid-size car, how much does it cost? About 20 thousand euros. How much does it weigh? A ton. That's about 20 euros per kilo. And this (pointing to his smartphone), how much does it weigh? 200 grams. How much does it cost? A thousand euros.

Daniele: The value per kilo is completely different. It reminds me of another friend who often makes comparisons like this, Roberto Siagri, I don't know if you know him.

Federico: Yes, I've heard him too. These are ideas that were born many years ago, maybe in other settings, and that I've tried to bring home: how can I do the same thing with the machines we develop, Italian manufacturing companies, which in the end sell by the kilo? I come from the manufacturing world of the 2000s, where people were asking what software even is. Maybe that's why I try to shake certain things up. This touches on an interesting concept: productivity. We often confuse it with producing more in the same amount of time, but that's not it: productivity means taking an input and adding value to it, because that 200-gram object costs a thousand euros precisely because it contains service components that drive up its value, lots of intangible things.

Going back to machines, we need to understand what we can give the customer to increase their productivity, to let them produce physical objects that have much more value than before. This is a real strategic and market change. It all comes from a chain: we're machine builders, what does our customer need? We need to create partnerships, understand what we can give and what we can receive. That's what services are for, because we can provide help and start creating partnerships. When we manage to do servitization, we create cross-pollination and a connection between the machine builder's business and the business of the machine builder's customer. And we're back to vision, mission, value proposition.

Daniele: I'm taking notes because I'm seeing some very interesting ideas. Something that's emerging now is also an aspect of generosity: I create services because I want to help my customer achieve better results. In your case, how involved is the customer in designing these services?

Federico: The Romans said "do ut des", I give so that you may give. A noble selfishness, perhaps we can put it that way. Customers are part of the chain, they're stakeholders, the component whose needs manufacturers and machine builders have to analyze. Without that it's impossible to create a plan: we need to analyze the market, understand who we're dealing with and assess whether becoming partners makes sense, with all the pros and cons. You apply a mapping to identify the point where we can truly create a value proposition, because we don't assign the value ourselves, the market recognizes it.

Daniele: So it all goes through co-design with the end customer, who not only lays out their needs, but also explains how they'd like to see them met, and the process lies in turning that into something functional, the machine and the result.

Federico: Definitely, without generalizing too much; let's limit ourselves to fairly specific contexts: my experience is with builders of a certain type and complexity of plant, and it has to be analyzed case by case. Can we call it co-design? Yes; before that there are techniques like QFD, people who apply user experience have others, but they all start from a concept similar to lean: you have to go to the gemba, to your customer's production floor, and not only there. You have to climb all the floors, because the production floor is where the product is made, but then there are all the other offices. You have the factory director, the plant manager, the purchasing department, the engineering department, and all of them have needs, and then you have the administrative side. When we talk about servitization, we provide something that solves problems at all these levels, for all these stakeholders. It's easy to say, but hard to put together.

Daniele: I think it's also hard to get the design team to reason about all these stakeholders, because people often reason about a single stakeholder, forgetting that if you don't satisfy them all the product has no future. How important is the CFO in designing a service?

Federico: He may not know it, but he's extremely important. A service means structuring a way to have continuous income, the classic recurring fees. It means having the ability to develop a technology, maintain it and expose it to the customer, so guaranteeing a team able to follow it, improving it with continuous improvement logic, and making the numbers add up, because you need a team to support and a customer base large enough to balance that effort. If we take one more step toward servitization, we don't even sell the product anymore, the steel stays ours and we sell, for example, the output: you enter a financing mechanism that stays simple as long as the product is cheap and the payback time is short, but if we have machines that require civil works, the issue involves financial mechanisms that are no longer just the purview of the engineering department, but of the entire administrative environment. The CFO is a fundamental part of innovative growth toward these philosophies, because the plan has to be built and sustainable not just from a technological standpoint, but from the standpoint of the company ecosystem and the company's financial life.

Daniele: If only because the cash flows are very different compared to an upfront sale. As you said too, you need different financial instruments to meet the company's financial needs.

Building multidisciplinary teams and overcoming "we've always done it this way"

Daniele: You brought up the concept of the team needed for a servitization project. How should it be made up? Should it be an R&D team or a multidisciplinary team, with divergent views that lead to exploring different areas?

Federico: Doing innovation, for me, means being multidisciplinary. I've always been lucky enough to have multidisciplinary teams: not just people who develop software or firmware, but also people who do mechanical design, the structural engineer, the people who go and assemble the machine, the people who go to the customer to sell, the people who buy (supply chain). Today it's a mistake to create silos. To quote Gregory Bateson: the problem is that we try to solve our problems one at a time, without realizing that they're all connected.

If we're thinking about doing innovation for the company, then obviously each individual process has its own innovator, but by creating a structure that starts from a vision, which creates a mission, which generates the value proposition, we need to know all the voices, all the representatives of that business context. The team has to be multidisciplinary: today, even if we stay purely on the software level, you also need someone who handles cybersecurity, for example, considering the regulations already in force. I can't have a narrow team of vertical experts; I need experienced people who cover the entire surface of analysis. That's where the difficulty lies in putting these teams together: often, through inexperience, someone gets forgotten, maybe purchasing. We've done the most beautiful project in the world and then where do we get what we need? Just to give an example.

Daniele: And how do you fight inertia within a team? You fight it at the source, by choosing the right people, but what about a team that already exists, where maybe there's the classic "we've always done it this way"? How do you fight it, in your view?

Federico: I learned one thing, and I learned it by making mistakes. The first mistake is thinking that activities get carried forward by people's goodwill: it's a mistake because it means relying on the person without considering that they're an individual, with their own needs. Not everything can fall on the person, an individual with their own emotional intelligence, who brings interest and cognitive ability; it has to be the process that guides and leads to the goal. We need to change the way we think: we can't always rely on people's goodwill, we need to build processes that can bring people on board and give them the right context so they're able to complete the task they've been assigned or have taken on. It's a mix: people have goodwill, but first you need to structure a process. At the beginning I was talking about technology and machines, but in reality what I was optimizing were processes.

Daniele: So this has to come from the top and be shared with the team to succeed; you can't expect the team, so to speak, “to be enlightened” and spontaneously take the initiative to introduce a new process?

Federico: It needs to be framed properly, in the sense that one thing doesn't exclude the other. If I put myself in the shoes of the business owner or the manager, we need to build solutions that are as deterministic as possible: we have a mission, an objective, and we have to turn it into something concrete. I have to lead my team, and I do it through management frameworks, from project management to Agile to Scrum: these are methods that govern, through processes, the execution of each individual person on the team. It's a pact between the manager and the team, also a set of rules of engagement. When the rules of engagement are well defined and the team is brought into them, things work well. If they're not clear, that's where misunderstandings arise, which are nobody's fault, that's just how we are, and we have to learn to govern complexity because we ourselves are complex.

Measuring industrial innovation: KPIs and counter-KPIs

Daniele: And how do you think innovation projects should be measured? Are there KPIs or strategies you use?

Federico: Maybe I'm saying well-known things, but I always repeat it: value proposition, which gives the goals, and the goals translate into KPIs. When it comes to innovation, the time needed to turn an idea into an experiment can be a KPI. Adoption time — I have an idea, I run the experiment, I like it, let's try to adopt it — is a KPI too; we're talking about measurements. The number of processes actually changed, because I'm making improvements. What's maybe harder is measuring the reduction of complexity: I can create a measure of scalability, or of reuse, meaning how we've learned to reuse things, so we've created a method. We used to always write code from scratch; today we've created composable modules that remove low-value work and add value because I get to the solution faster by composing existing modules.

Staying close to the production level, you can measure real productivity, meaning what comes out in excess of what goes in, not just the tangible good but also all the intangible elements that increase the value of that artifact: think of the cell phone, 200 grams of metal and silicon that we pay a thousand euros for, plus all the subscriptions we have on it every month.

What is "Human at the Edge"? Federico Milan's vision of artificial intelligence

Daniele: Starting from this, I'd like to go deeper into two aspects: your position on artificial intelligence, what it is in your view, and the concept you coined, "Human at the Edge". Can you tell us about it?

Federico: Let's try. I don't much like the term "artificial intelligence", I'll say that right away, because words always carry a meaning and often take us off track. What we call AI is, for me, a very useful and accessible technology that, if used well, is rewarding, or rather helps by being woven into processes. Before even defining what AI is in industry, it's certainly not magic: it's a technology that helps extract meaning from the data that automation generates, if I'm talking about AI applied to automation, or from the data generated by industry, if I'm talking about AI applied to industry.

If we consider that informatics is automatic information, AI applied to informatics in the strict sense is an automation of how to exploit this data to close a control loop that optimizes processes. AI should be seen as the kick-off to start rethinking business processes. It's unthinkable to say "great, there's ChatGPT, let's put it in the office"; you can do that at home, but in a business context, and I'll repeat what I said earlier, we must never assume that an activity gets done through a person's goodwill, there has to be a process that guides it. We must never give people a technology without rules of engagement. When we bring AI into a company, we first have to build and review our processes, and understand where to introduce these new technologies.

And here we realize that AIs, today we talk about agents, are our colleagues: the company is no longer made up only of people, or soon won't be, but of people and of agents that aren't people. Borrowing a concept from Bruno Latour, Actor-Network Theory, we're all actors in an ecosystem of work, of industry, and we collaborate together: that's why we have to rebuild processes, start from them, understand where these actors are, what the communication points are, where the information loop closes, what the centers of power, knowledge and interaction are.

On this, we keep hearing about human in the loop, a term used more and more with Industry 5.0. I don't like it, because it means putting humans on a par with artificial intelligence, and I don't accept that: for me we have to keep humans inside the decision-making cycle, and I want to try to push the concept a bit further, adopting the idea of "Human at the Edge". People shouldn't be constantly inside automated micro-decisions; they should be on the edge, on the cognitive boundary of the system. The machine, the technology, the algorithms manage what they know, automate what's repeatable and propose what they can infer. The human steps in when the exception, the ambiguity, the new emerges. I don't use people to make worse what the machine already does well; I use people where their cognitive contribution adds the most value. The edge can be a physical boundary, lean tells us to go to the gemba to see what they're doing, kaizen, continuous improvement, but it can also be an abstract boundary, where the cognitive capacity that only humans can provide, fortunately still for a long time, brings improvement. That's where the idea comes from: human at the edge, not human in the loop. I don't want to be governed by a machine; I have to govern the machine, the process.

Daniele: I find this vision fascinating, and it's very different from the one being put forward today, where AI-based automation is sold as a replacement for people. Your way of seeing the situation seems much closer to reality, where people still provide something the machine can't, at least for now. I can't make predictions about the next five years, but today that's how it is. What's your view, on the other hand, on using generative AI as a conversational interface to the machine?

Why generative AI is the new interface between humans and machines

Federico: It's an aspect I find interesting and that we've already started using, because it represents an enormous transformation. It stems from an old paradigm: think of technology-centered design versus human-centered design. A few years ago we started from a concept where we technical people developed the project well, but it was siloed: think of a plant from the '90s, it worked, it had technology, it was made up of many machines, but each machine was siloed. You had to know the machine that deposited the material, move two meters and know the one that did the pressing, move again and know the next one. Think of the interfaces: you had to know lots of interfaces, lots of ways of operating, lots of ways of programming. People had to adapt to technology.

Then a series of paradigms emerged, think of UX, but even before that situation awareness, and Norman, first of all, said: no, people must be at the center, hence Human-centered design: technologies work well, but the interface toward the operator must be simple; it's technology that adapts to people, not the other way around. Interfaces changed, making information more and more central; think of the PC too: once there was DOS, a single line of code for every single thing you wanted to do, now there's an interface where you can do everything at once. Add one more bit, the ability to use natural language, and that's where generative AI in everyday applications becomes useful: I no longer have to learn the machine's language, I no longer have to remember to press that button, I talk just the way the two of us are talking. This helps close the distance, but it also adds other problems.

Daniele: What are those problems, in your view? And second, can generative AI also be a tool to surface correlations between data and information that today we're unable to identify? Does it make sense to use it in data analysis too?

Federico: When we talk about generative AI, we often focus on language models, like ChatGPT. The problem I see is that the machine gives us very convincing natural-language answers, and as human beings we're drawn to answers when they're well crafted and convince us. What happens? We no longer ask ourselves whether what it told us is correct, we don't question it. That's a big problem, and it's why I said that before adopting AI in a company we need to build processes. Not only because the AI Act says so, but because we need to keep our people attentive, so they don't blindly trust the output. Let me give you an example: a properly trained person, when they see a machine's graphical interface, understands whether it's working in the right operating curve, whether it's underutilized, because they have the ability to read charts and control charts and understand how the process is going, even make forecasts. If I overcomplicate those charts, making them prettier and more informative, they get harder to interpret, but it's still an active mental effort: I see, I translate what I see graphically into a concept, I apply an analysis. If instead the machine tells me directly "everything's fine", I'm happy, but I still have to ask myself "are you sure?". It gives me the answer I like, but if I'm an innovation person I don't want a nice answer, I want data that let me ask another question, not to you but to myself, to understand whether I can improve or whether what you're telling me is true only for a small part of the picture.

Here we come back to the concept of KPIs: if everything is based on a single KPI, that's a problem. To put it simply, if I take a production KPI, how many items I produced per hour, the setup is 10 per hour and I produce 15, the production director is thrilled. But what's the counter-KPI? You need a quality KPI, because if before we made 9 good-quality items out of 10 and now we make 7, is it good to have produced faster or not? Every KPI needs a counter-KPI, and every AI answer needs at least one counter-answer. We always come back to the concept of process.

On trust: the machine is better than we are at analyzing data, but should we trust it? In my opinion no, and I'll put it in a simple, basic way. When we take data and look for correlations, correlation only tells us how much two events are potentially linked, not that one causes the other. If I feed data to the machine, the classic example you find in every book is that in summer ice cream sales go up and so does the number of drownings: if I run a correlation, it looks like the more ice cream I sell the more drownings there are, but that's not true, it's just because in summer people go to the beach more often. The cause isn't ice cream sales, it's something else entirely. Bringing this example into a company, we understand that talking about correlation while forgetting causality risks leading us into a very big mistake. Generative AI, by putting together multiple contexts and activities, is more likely to give us a correlation than a causation. Today, causality is something we have to build ourselves, through a process that defines how a measurement, a piece of data, a report should be measured and evaluated.

Predictive maintenance: why context matters more than the model

Daniele: How does this fit with the concept of predictive maintenance?

Federico: Pretty well. First of all you need an infrastructure that turns events into usable data, to collect interesting information from the environment and turn it into useful information to pass on to whoever needs it. There's a lot of literature on predictive maintenance, often tied to rotating machines or well-known vibration processes, where there's a real benefit because a model was built that's useful enough to be analyzed.

When instead we have more complex systems, where the machine is subject not only to the operation it performs but also to the environment around it, this doesn't work as well. We can build a model that numerically predicts the trend very well, with accuracies of even 98-99%, but then, all things considered, it means nothing: if I have a process that works very well and produces little or no scrap, saying I have a 99% prediction, or that it almost never breaks, brings no value, because we still end up always working in "run to failure" mode. What did I learn? If it's a known technique, something well defined, going back to the machine example, things work well there. But if I have complex systems that change their position depending on environmental variables, then you need to use all the data, not only the machine's pressure, speed and vibration, but also temperature, humidity, whether it's Monday or Wednesday, whether it's winter or summer, whether it's raining or not. All this adds complexity and information to the model.

Daniele: So it's not wrong to do predictive AI, but the dataset used for the prediction needs to be considered carefully.

Federico: Exactly. The point is that when you do prediction it's not enough to add a technological component: you need to open a project to understand exactly which data, in what way and with what timing, are useful for extracting the information you need. The big mistake is thinking "I'll put in something smart that collects the data and gives me an answer". It doesn't work like that; it works when things are simple.

Daniele: How does predictive maintenance fit with the human side?

Federico: It comes into a maintenance context: it becomes an enabling factor that helps the operator not be stressed, not have to constantly watch the data, but see alerts that draw their attention only when something needs evaluating. My vision is that an increasingly collaborative environment will take shape, with specialized roles, because you act on multiple points: service people get an almost immediate benefit, they no longer just receive the phone call but already know what's going to happen soon, so they can organize and plan. And if I, as the manufacturer, can plan, I can purchase the consumables to provide to the customer at the right time, and the customer can in turn trigger their own purchasing process, finding optimizations. Soon we'll also have machines as customers.

Where to start with data-driven predictive maintenance

Daniele: If you had to advise a company on where to start to create a data-driven maintenance system, what would you tell them?

Federico: I'd do a due diligence process focused on the type of machine or product the company makes. Based on that, I'd look at the purchasing department or the maintenance process, what kind of calls it receives, focusing on the 20% of activities that deliver 80% of the value. From there I'd understand what to use: very often you discover you don't need to add sensors, but you can do simple planning, aided by the new AI tools, that already delivers a benefit.

With this analysis you can then structure data collection, because collecting data costs money: you need a sensor, a software application, an internet connection, a cloud, even a local one, something to hold that data, and you need to run inference. If we're a company, we need to optimize these costs and turn them into value, and that only happens if you start a serious analysis process: not grabbing the technology, but starting from the need. It's the hardest part, because it requires a lot of analysis, but you have to start from what already exists, make a hypothesis about what's worth using, what's worth touching and what benefit you get. Set yourself a clear goal: what we want to achieve.

Federico Milan's three pieces of advice for the young engineer

Daniele: Since we're wrapping up, I'd like to ask you one last question that we ask all our guests, probably one of the most important in the interview: if you could go back to the start of your career, what three pieces of advice would you give young Federico?

Federico: Given what I've learned, I'd say: study the fundamentals, not just the technologies, because technologies change quickly while principles last over time. Fall in love with philosophy; technology comes after.

The second: in innovation, look for contradictions. If everyone tells you that you have to choose between A and B, try asking yourself whether the real problem isn't precisely eliminating that choice. It's perhaps the most important lesson I carry with me, having read Altshuller and the idea that we must, in some way, resolve contradictions.

The third perhaps comes from the first: never fall in love with technology, but with the problem you want to solve. There's a joke that says engineers love solving problems so much that, when there aren't any, they invent one.

Daniele: That's a good one, I'm going to reuse it. Federico, thank you for the time you've given us, it's truly been a pleasure talking with you. I really appreciate the generosity with which you shared your experience, your journey, your way of tackling problems. For those listening who'd like to dig deeper, you'll find references to Federico's books in the episode notes, and you can subscribe to stay updated on upcoming videos. Give it a like if you enjoyed the video. Thanks again Federico, it was a pleasure.

Federico: Thank you, the pleasure is all mine. Take care, see you soon!

Daniele: Thanks, everyone, for listening, we'll talk again in the next episode of Expert Talks.