Why Digitalizing a Broken Process Just Gives You Faster Chaos

Every failed digitalization project I've seen had something in common: the failure was already there before anyone installed a single piece of software. The system wasn't the problem. What came before it was.

After years of implementing MES and industrial IT projects across manufacturing plants, the patterns repeat. And almost none of them are technical.

Digitalizing chaos gives you digital chaos

The most common mistake is also the most understandable one: companies jump into digitalization without cleaning up their own processes first.

Here's the uncomfortable truth. If your procedures are outdated, inconsistent, or simply bad, digitalizing them doesn't fix anything. It preserves the problem. A bad analog process becomes a bad digital process, except now it's encoded in software, and everyone assumes the software must be right.

If you start in the middle of chaos, you get chaos in the digital world. It's faster chaos, better documented, but it's still chaos.

The right sequence is to sit down first. Look at how information actually flows through your company, from one department to another, from the plant floor to the business systems. Modernize what's obsolete. Rewrite what no longer reflects reality. Then digitalize. The assessment phase isn't a delay before the real project starts. It is the project's foundation.

The silent project killer: a customer who disappears

The second pattern is harder to talk about, because it points at the customer.

An integrator can set up systems, configure interfaces, and do everything within its expertise. But the people who know the day-to-day work, the real procedures, the actual flow of data and materials, work at the plant, not at the integrator. If those people step away from the project, if there's no access to them and no feedback coming back, the project drifts in the wrong direction. Guaranteed.

It's rarely intentional. The customer has other priorities, a crisis on the line, an audit coming up. But feedback has to travel with the project, at least weekly in our experience. Without it, you don't find out you've been building the wrong thing until it's too late.

What a project actually needs: people first, then the plan

When plant managers ask me what they need to prepare before a digitalization project, they expect a technical answer. Infrastructure, budgets, licenses. My answer is different: first the people, then the plan.

On the customer's side, the project needs a team picked across departments (usually two or three) made up of the people who genuinely know the procedures, the production stages, the material and information handling. And it needs one project manager as the single point of contact for every question and every problem. That person will go hunting for answers across departments, but there has to be one person accountable.

Then comes the plan. Built together, integrator and customer, spanning months and sometimes years. With the customer's operational knowledge and the integrator's technical knowledge combined, you can keep adjusting toward the right direction. That's when projects succeed.

"We are not wizards"

What happens when a company skips the initial assessment? We've seen it. You work on a project for long months, and the final product matches maybe 5% of what the customer expected. Not because anyone did bad work, but because everybody had their own idea of the system and the outcome, and nobody put those expectations on the table.

I tell customers this directly: we are not wizards. We don't have a crystal ball that reveals what's in your head. Every company has its own procedures. Every plant is different, because its history is different: systems installed and shut off over the years, legacy platforms still running in parallel, all of it needing integration. We may know the systems, but in every plant they communicate a little differently. Everything must be discovered.

And discovery only works with the people who operate those systems every day. Which brings everything back to the same point: the technology is rarely the risk. The preparation is.

Where to start

If you're considering a digitalization project, don't start by comparing platforms. Start with three questions. Are our processes worth digitalizing as they are today? Do we have the right people available to support the project, with a single owner? Have we written down what we actually expect the outcome to be?

If any answer is no, that's your real first project. At Adasoft, that's exactly where we start every engagement: not with the system, but with an honest assessment of the processes and the people around it. It's the least glamorous phase of a digitalization project, and the one that decides whether it succeeds.