Some of you may remember that just over a year ago we launched MICROlab, a department created to bring together three strategic areas of MICROingranaggi—Operations & IT, Quality & Certifications, and Marketing—to work collaboratively on the same business challenges.
The goal of this initiative was, and still is, to centralize our innovation and optimization strategies by analyzing and monitoring data from across the company in an integrated way.
Working on MICROlab has reminded us, once again, of the significant difference between deciding to do something and actually putting it into practice.
From the very beginning, we had a clear vision of what we wanted to achieve. As is often the case, however, the practical implementation required continuous refinement as we worked alongside colleagues from the various departments.
Let me explain.
From day one, MICROlab has been organized around a sprint-based approach. We identify a specific operational area, determine where improvement is possible, concentrate the necessary expertise on that area, and move forward in a coordinated manner.
Initially, the structure, priorities, and direction were defined centrally. Over time, however, the model evolved.
The methodology itself has not changed. What has changed is the way responsibilities are distributed. Today, senior management still sets the overall direction, but once those objectives are clear, each person involved contributes independently according to their own expertise and skills.
Today, MICROlab focuses on areas where structure is missing. It develops tools, defines processes, and introduces key performance indicators (KPIs). Once the system is in place, responsibility is handed over to the department, enabling it to manage the process independently.
A good example is our Purchasing Department.
The challenge was immediately apparent: there were no meaningful KPIs, no measurement tools, and no effective interface that allowed buyers to monitor and evaluate their activities consistently.
Take supplier delivery delays—a problem familiar to virtually every manufacturing company.
Supplier performance had largely been assessed through long-established perceptions rather than objective data.
We isolated the department, analyzed where information was being lost throughout the process and why, and concentrated our expertise on building the tools needed to capture that information accurately.
As we progressed, we realized that properly analyzing supplier delays required changes to our ERP system.
Not because the ERP itself was inadequate, but because its standard configuration did not provide all the fields our purchasing team needed to accurately describe what was actually happening. As a result, users were forced to fit real-world situations into generic data fields.
The consequence is predictable: if the system is not fed with accurate and up-to-date information, it continues planning based on incorrect assumptions, generating a cascade of errors—often without anyone noticing.
Our solution was to modify parts of the ERP directly, adding fields and business logic that were not included in the standard software.
Again, this wasn’t because the ERP was poorly designed. It was simply too generic to reflect the specific needs of that department.
This is a step that many companies underestimate. Rather than adapting the software to their processes, they often adapt their processes to the software without fully understanding what information they actually need.
In our case, customizing the ERP was not the starting point.
It emerged naturally as a direct consequence of the work carried out on KPIs and the continuous dialogue with the Purchasing Department.
Without that preliminary analysis, we would most likely have modified the wrong part of the system—and solved the wrong problem.
Ultimately, however, the objective was never just to solve a technical issue.
The real goal was to ensure that, once the project was completed, the department could manage the system independently: reading the data, interpreting the KPIs, and making informed decisions based on them.
That is exactly what MICROlab is designed to achieve.
