Common mistakes in automation projects (and how to avoid them from the design stage)

All too often, projects that start with enthusiasm end up as technology “islands”: underused equipment, interrupted flows, users going back to Excel and an ROI that stretches until it becomes hard to defend. And in most cases, the problem is not the technology. The problem is the order. What should have been designed first gets designed late.

The central idea is clear: the success or failure of an automation project is decided in the design phase. When the design is solid, implementation is execution. When the design is weak, implementation turns into a chain of patches, unplanned changes and hidden costs.

Below are the most common (and most expensive) mistakes in Mexico and Latin America, along with their typical impact and the practical approach to prevent them from the design stage.

The first mistake: automating chaos (digitizing a process that was already broken)

Many Mexican operations have an admirable ability to “get the day out” despite informality: undocumented rules, priorities that change with a phone call, decisions that live in WhatsApp and critical dependence on one or two people who “know the trick”. The problem appears when someone tries to automate that chaos without stabilizing it. The system will not magically put in order what is not in order: it will replicate it… only faster.

The result is predictable: automation amplifies the error. Rework appears, “special cases” multiply, IT or engineering end up putting out fires and the ROI starts to dissolve into operating costs nobody budgeted for.

The way out is not heroic, it is methodical. In design, you have to make an uncomfortable but healthy decision: design around the standard process, not around exceptions. Map the real flow, not the “ideal” procedure, and quantify the variations. If today a decision depends on a person and not on a rule, that is the first red flag.

The second mistake: designing for the average, not for the peaks (or for the real operation)

One of the fastest ways to undersize a system is to size it with averages. Average per hour, per shift, per day. But the warehouse doesn’t live on averages: it lives on peaks. Month-end closes, promotions, shipping windows, simultaneous arrivals, mix changes, rush orders, last-minute priorities. And in Mexico this is made worse by supplier variability, traffic, delays and on-the-fly operational adjustments.

The consequence? Saturation, queues, idle time and, sooner or later, the operation going back to manual mode “to get the day out”. For management, this looks like the worst outcome: capex invested to create a bottleneck. For the floor, it feels like pressure, stress and a loss of confidence in the system.

From the design side, the antidote is to think in scenarios: normal, peak, extreme peak and contingency. And to accept something that is sometimes hard to negotiate: intentional buffers (space, capacity, windows and rules). A robust system is not the one that “works on a nice day”; it is the one that doesn’t break when the day gets real.

The third mistake: buying equipment before defining the system (the “star solution” trap)

“We saw an incredible sorter”. “They offered us an AS/RS at a big discount”. “That AMR looks spectacular”. This is one of the most expensive mistakes because it usually comes from a good intention: moving fast. But choosing technology before closing the conceptual engineering (flows, rules, interfaces, layout, safety, maintenance, data governance) is betting the project on one piece without having the complete architecture.

Then come the surprises: costly integrations, layout changes, late re-engineering and the worst scenario of all: a single point of failure that conditions the entire operation. And then the ROI stops depending on the business… and becomes hostage to a piece of equipment that is poorly located or poorly integrated.

The right order is the one almost nobody wants to hear at the start: first the system, then the technology. Objectives, constraints, flows and architecture (WMS/WES/WCS + equipment). And only then select against requirements, with clear measurement criteria. Because if that equipment stops tomorrow, the question is not “if it happens” but how prepared your operation is to keep running.

The fourth mistake: underestimating the human side (adoption can’t be decreed)

Resistance to change is not eliminated with a kickoff. On the floor, if the system “gets in the way”, the operation works around it. And in many warehouses the knowledge lives in the people, not in the process. If the design does not build in usability, realistic training and clear roles, the project is born with friction.

That translates into low adoption, operational shortcuts, errors from confusion, dependence on “the ones who really know” and turnover. For the C-Level, it is a hidden cost: productivity that does not appear in the financial model. For Operations, it is frustration and burnout.

The big difference comes from one design decision: designing the future operation together with the users (supervision, maintenance, safety, planning), simulating real tasks and building simple SOPs. The uncomfortable question that saves projects is: “what does a shift look like when the expert isn’t there?” If the answer is “it falls apart”, you still have time to correct course.

The fifth mistake: “we’ll see later” about maintenance and spare parts

The machine can be excellent, but if there is no serious preventive maintenance plan, no defined critical spare parts and no trained in-house capabilities, the system becomes fragile. And in Mexico, very concrete issues weigh in as well: imports, customs, lead times, the real availability of support.

When this is ignored, recurring stoppages, emergency costs and lower-than-expected availability appear. The ROI erodes through OPEX and, worse, through lost service.

Here, once again, design is the insurance: maintenance from the conceptual engineering stage (preventive, predictive, corrective, SLA, critical stock), design of access and safety for maintenance, and a clear plan for operating when a critical component fails. Automation is not about “never failing”; it is about not letting a failure destroy you.

The sixth mistake: ignoring master data and information governance (the invisible root of chaos)

Automation without reliable data is like sailing without a map. Poorly defined locations, inconsistent units, SKUs with incorrect dimensions, slotting “from memory”, inventories out of sync. And then comes the typical phrase: “the system is failing”. No: the system executes what you give it. If the data is wrong, the execution will be a very efficient error.

The effect is devastating: picking errors, blockages, rework, discrepancies and loss of confidence. Management sees it as a direct impact on service and cost. The floor experiences it as exasperation: “it always fails”.

The antidote is clear and non-negotiable: a data cleanup and governance plan before go-live, with data owners in the business (not “IT” as a catch-all). The critical question is: “which data must be perfect for this to work?” If you don’t know today, you will pay for it tomorrow.

The seventh mistake: designing without scalability (born at the limit)

Tight budgets and pressure for a quick return: completely understandable. The problem is designing at 95-100% utilization from day one. That leaves zero margin for growth, variability or new business. In volatile markets, that is a financial risk.

The consequence arrives quickly: within 12-18 months the system is too small and the era of patches begins: extra shifts, improvised routes, unplanned purchases or a second project… a more expensive one.

From the design side, the way out is modularity: expansion in stages, scalable capacity and a layout prepared for it. And something very executive: define the “growth path” as part of the business case (planned future capex). It is not overspending; it is protecting the investment.

The eighth mistake: leaving integration and cybersecurity “for the end”

Modern automation is not a piece of equipment: it is an ecosystem. WMS/WES/WCS, PLCs, industrial networks, sensors, APIs, ERP and dashboards. When integration and security are dealt with at the end, the project becomes an endless negotiation between suppliers and operational risk grows silently.

That ends in delays, cost overruns, failed start-ups and vulnerabilities. And when an incident occurs, diagnosis is slow for a simple reason: nobody knows where the fault is, or who is responsible.

Robust design defines the integration architecture, the responsible parties, FAT/SAT testing and validation criteria from the RFP onward. It also builds in observability: alarms, logs, dashboards and escalation. The question that changes the game is: “who integrates what, and how is it validated end to end?” If it isn’t written down, you are gambling.

Design is not an expense; it is the insurance policy for your ROI

In automation, what is expensive is not investing; what is expensive is investing without design. Meticulous design reduces financial risk, speeds up the return, avoids single points of failure and builds an operation that actually gets adopted. It also protects an internal asset that is rarely quantified: the project’s reputation. When automation works, confidence is earned and doors open to scale.

That is why at DEVA, we make sure that our business partners, before committing capital, carry out a preliminary design evaluation: process diagnosis, data cleanup, peak analysis, layout, technology architecture, maintenance and scalability. It is the shortest step to avoid the most expensive path.

If your automation fails for a week, does your operation have a designed plan to keep running… or will it depend on heroes, patches and overtime?