The ERP is often described as a "monster": a rigid entity, at times cumbersome, that seems to impose severe rules, stifling the natural vitality of everyday work. It is a widespread perception, a sentiment that drifts through the corridors of many companies. And yet, to believe that flexibility lies in the absence of constraints is an error of perspective: what at first glance looks like a rigidity of rules is in truth what allows an organization to keep from squandering its own energy.
I often read of systems described as "silo-breakers," or promises of instant agility. They are seductive narratives, selling technology as a magic wand able to dissolve deep-rooted human resistance in a single click. Anyone who wrestles daily with the complexity of processes knows that reality is less poetic and far more demanding. The system is not the demolisher; it is, if anything, the witness.
The anatomy, not the cage
Picture the company as a body in motion. Without a solid bone structure there is no agility, only a shapeless form that, at the first attempt to lift a serious load — an expansion, a new market, a digital transition — is bound to collapse under its own weight. That system is not a cage. It is, rather, the anatomy. It is the scaffolding that turns intention into execution and lets the corporate "muscle" exert force without tearing.
The true value of an integrated architecture does not lie in forcing a cultural change that belongs to people, but in its capacity to make inefficiencies transparent. That capacity springs from the very way a system like SAP is conceived: a piece of information enters it only once and, from that moment on, no longer belongs to a single office but to the whole company. Recorded in orderly fashion within the master data — the structured registries in which every customer, every material, every supplier exists once and in a single form — it becomes the datum upon which, in the very same instant, administration invoices, production plans, and logistics ships. There are no longer many parallel copies of the same reality, each kept by one department and slightly different from the others, but a single version of the facts running through the organization from end to end. It is precisely this integration that makes inefficiencies visible: when a process crosses sales, administration, production, and logistics along a single thread, the "wall" that once separated the functions ceases to be a convenient alibi and becomes, at last, an obstacle plain to everyone. It is not a magical transformation, but an awareness that imposes itself. This is where the system stops being felt as an operational burden and becomes an instrument of clarity: the moment it forces us to look at what, until now, we had preferred to ignore.
Freedom needs a perimeter
Flexibility — real flexibility — is not the freedom to change course every day to indulge every operational whim. It is, rather, the ability to reconfigure processes on top of a solid base, without having to rewrite the company's fundamental grammar each time. This grammar is no abstraction: it is the narrow set of shared rules on which everything else rests — a single way of naming customers and products, one chart of accounts valid for every company in the group, a bill of materials, that is, the list of the components that make up a product. These are the common foundations on which sales, purchasing, and production read the same numbers.
Some look to software for total freedom, without boundaries. Those who have learned to design the architecture of systems — or even merely to inhabit it — know one thing.
"A clear perimeter is not the opposite of freedom: it is the very condition for freedom to produce something, instead of scattering into nothing."
Twenty years on, the same question
Looking to the near future, I am preparing to begin a new migration project to SAP S/4HANA alongside the group's central team. It is a moment I approach with a curiosity that reaches beyond mere technological fascination with the new system's features. My real question, this time, concerns people.
I wonder whether the organization will meet this step with a mature awareness of the strengths of a solid ERP, welcoming the change as an opportunity to evolve, or whether that natural resistance will resurface — the one I saw, twenty years ago, in the passage from the mainframe to SAP. In 2006, distrust of the "new" was almost a form of defense; today, the times have changed profoundly. Yet what weighed most heavily back then was not the fear of losing control: it was the refusal to open one's mind to a well-conceived structure, made of integrated processes and of data set in order within dedicated master-data records. Many, out of sheer prejudice, judged that design wrong without so much as trying to understand it: at all costs they wanted to find in the new system the old master data exactly as it had been structured in the mainframe, and the old processes carried out just as before. The real mistake, in the end, was the inability to read — the unwillingness to read — its philosophy; and it was only when they were forced to grasp it that they realized how much better it was than what they were leaving behind.
It is a lesson I carry with me: faced with a system so important and so widespread, adopted by a great many companies around the world, the first thing to do is to recognize the skeleton that someone has already designed — the very scaffolding I spoke of — and to build around it the functionalities that are our own. The skeleton remains; the tailored functionalities, and even the shortcuts with which we speed up our own processes, are the part that gets added on — and that SAP handles superbly.
The confidence with which I approach this step is not a trait of my character: by nature I give credit to what I have verified, rather than to what I am promised. But that is exactly why my optimism, this time, carries weight. It is born of twenty years of observation, from 2006 to today, in which people have proved able to overcome the prejudices that every great innovation brings with it, and to recognize value when it is offered not as an imposition, but as a supporting pillar. For this reason mine is not an inclination but a conclusion: I ground my expectation on evidence, not on temperament. And it is on this evidence that I place my trust in a new kind of alliance: the one between IT — no longer merely a supplier of tools, but a companion on the journey — and a systemic philosophy that, once understood, ceases to be a "monster" and becomes, at last, a common language.
It is not merely a matter of migrating data or upgrading modules. It is a matter of seeing whether, after two decades, we have become capable of looking at the system no longer as a cage, but as that invisible anatomy able to sustain, at last, our growth.