Los riesgos de un proyecto de automatización son conocidos: dimensionar con datos de un mes atípico, no contemplar el crecimiento, integrar mal el software de gestión y dejar al equipo sin capacitación. Se acotan con relevamiento medido, alcance escrito, pruebas con carga real antes de la puesta en marcha y un plan de contingencia operativo.
Dimensionar con el mes equivocado, y cómo se evita
Es el riesgo que más silenciosamente sale mal, porque no se nota hasta que el sistema ya está funcionando.
Un sistema automático se dimensiona sobre dos cosas: cuántas ubicaciones hace falta tener y cuántos movimientos por hora hay que sostener. Los dos números salen de los datos históricos de la operación, y de qué período se tomen cambia el resultado por completo.
El error típico tiene dos versiones opuestas y las dos cuestan. Si se dimensiona con el mes pico, el sistema queda sobredimensionado: se paga capacidad entera que se usa unas pocas semanas al año. Si se dimensiona con un mes tranquilo, el sistema se satura en la primera temporada alta y la operación vuelve a tener el problema que fue a resolver, ahora con la inversión hecha.
Hay una tercera versión más difícil de ver: dimensionar con un período que fue atípico por otra razón. Un año con un cliente grande que después se perdió, o con un desabastecimiento que infló el stock, produce números que parecen normales y no lo son.
Cómo se acota. Se trabaja con doce meses completos, se identifica el pico por separado en lugar de promediarlo con el resto, y se pregunta explícitamente si algo del período fue excepcional. En el almacén, depósito o bodega que se está relevando, ese dato lo tiene operaciones y no está en ningún sistema: hay que preguntarlo.
Y se deja escrito con qué período se dimensionó. Un sistema tiene siempre un supuesto de volumen detrás; cuando está escrito, se puede revisar.
Qué pasa cuando el crecimiento no entró en el cálculo
Es una variante del riesgo anterior, pero merece su propio tratamiento porque se resuelve distinto.
Un sistema automático se dimensiona una vez, se fabrica y se monta. No es como sumar una estantería: la capacidad de almacenamiento y el movimiento por hora quedan definidos por el diseño. Si la operación crece más de lo previsto, el sistema no se estira.
El error más común no es olvidarse del crecimiento: es aplicarle un porcentaje al volumen actual y darlo por resuelto. Crecer no siempre significa mover más de lo mismo. Una operación puede duplicar la facturación con el mismo movimiento, o mantener la facturación y duplicar las líneas de pedido porque los pedidos se hicieron más chicos y más frecuentes. Para un sistema automático son escenarios completamente distintos: el primero casi no lo afecta y el segundo lo satura.
Cómo se acota. Se define el crecimiento en las variables que el sistema siente —ubicaciones necesarias, movimientos por hora, líneas de pedido por día— y no en facturación. Se declara el horizonte del dimensionamiento, que es el tiempo durante el cual el sistema tiene que alcanzar.
Y se elige el tipo de sistema pensando en cuánto puede cambiar la operación. Un sistema dimensionado rinde mejor cuando el volumen es estable; uno basado en robots móviles autónomos —AMR, unidades que se desplazan solas por el piso llevando la carga hasta el puesto— se amplía agregando unidades. La pregunta no es cuál es mejor, sino cuánta variación tiene por delante.
Por qué la integración con el software es el riesgo más caro
No es el riesgo más probable, pero es el que más cuesta cuando ocurre, y por una razón de calendario: aparece al final, cuando el equipamiento ya está comprado y montado.
Un almacén automático necesita dos capas de software. El WMS es el que dice dónde está cada cosa y en qué orden se prepara cada pedido. El WCS es el que traduce esas decisiones en órdenes de movimiento para las máquinas. Y las dos tienen que conversar con el sistema administrativo que la empresa ya usa.
Lo que sale mal casi nunca es la máquina: es el dato. Códigos de producto que existen en un sistema y no en el otro, unidades de medida que no coinciden, un maestro de productos que nadie definió quién actualiza, o un stock que en el papel está y en la posición no. Un operario corrige esa diferencia a ojo sin darse cuenta; un sistema automático se detiene.
Cómo se acota. Primero, entrando temprano: el área de sistemas de la empresa tiene que estar desde el relevamiento, no desde el montaje. Segundo, definiendo por escrito de dónde a dónde viaja cada dato y quién es el dueño de cada maestro. Tercero, midiendo la exactitud de inventario antes de empezar, porque ese número es el que anticipa cuánto trabajo va a costar la integración.
Y cuarto, probando la integración con datos reales antes de la puesta en marcha, no con datos de prueba. Un juego de datos limpio no encuentra los casos que rompen.
Qué plan de contingencia necesita una operación que se automatiza
Un almacén manual degrada: si falla algo, se trabaja más lento. Un almacén automático se detiene. Esa diferencia es la que obliga a escribir un plan de contingencia antes de arrancar, y no después del primer incidente.
El plan tiene que contestar cinco preguntas concretas.
Cómo se despacha lo urgente con el sistema detenido. En la mayoría de los diseños hay una forma de extracción manual o de acceso de emergencia a una parte del stock, pero hay que definirla en el diseño y probarla, no descubrirla el día que hace falta.
Qué stock conviene tener accesible fuera del sistema automático. Muchas operaciones dejan los productos de mayor rotación o los de compromiso crítico en una zona convencional, justamente por esto.
Quién hace el primer diagnóstico y a quién llama. La diferencia entre una detención de dos horas y una de dos días suele estar en quién mira primero y con qué instrucción.
Qué repuestos críticos están en el almacén y quién define esa lista.
Y cómo se registra lo que se movió mientras el sistema estuvo caído, para que al volver el inventario coincida. Esta es la que más se olvida y la que deja la peor secuela.
El plan de contingencia se define dentro del proyecto, junto con la capacitación, y se prueba durante la puesta en marcha, que en un proyecto de automatización lleva de 3 a 4 meses desde la firma.
Qué se prueba antes de la puesta en marcha, y con qué carga
La prueba es el último punto donde un error todavía es barato, y por eso conviene que sea incómoda.
Se prueba con carga real, no con carga de muestra. La diferencia importa porque los problemas aparecen justamente en lo que no es estándar: el pallet que viene mal armado, la caja que excede el alto por dos centímetros, el film que quedó suelto, la unidad de carga que en el papel es una y en la práctica son tres formatos distintos. Un sistema probado sólo con carga perfecta funciona hasta que entra la primera real.
Se prueba el pico, no el promedio. Sostener el movimiento medio es fácil; lo que define si el sistema alcanza es si sostiene la hora de mayor demanda del día de mayor demanda.
Se prueban los casos de excepción: el pedido que se cancela a mitad de preparación, la devolución que vuelve al sistema, el producto que hay que bloquear por calidad, el conteo mientras el sistema opera. Son los que más trabajo dan después y los que menos se prueban antes.
Se prueba la integración con el software de gestión de punta a punta, con datos reales, incluyendo qué pasa cuando se cae la comunicación y vuelve.
Y se prueba con el equipo que va a operar, no sólo con los técnicos de montaje. Esa es la parte de la capacitación que no se puede hacer en un aula, y es la que evita que la curva de aprendizaje se pague con pedidos atrasados durante el primer mes.
Ninguno de los cuatro es imprevisible
Los cuatro riesgos tienen algo en común: no aparecen por mala suerte, aparecen por una decisión que no se tomó a tiempo. El período de datos con que se dimensiona, el horizonte de crecimiento que se declara, el momento en que entra el área de sistemas y lo que se prueba antes de arrancar son cuatro decisiones que se toman al principio y cuestan poco, o se pagan al final y cuestan mucho. Si está evaluando un proyecto, lo más útil que puede pedir no es una garantía: es ver escrito con qué supuestos se dimensionó y qué se va a probar antes de la puesta en marcha.
Frequently asked questions
Con doce meses completos, identificando el pico por separado en lugar de promediarlo, y preguntando explícitamente si algo de ese período fue excepcional: un cliente grande que después se perdió o un desabastecimiento que infló el stock producen números que parecen normales y no lo son. Además conviene que quede escrito con qué período se dimensionó, para poder revisarlo más adelante.
Definiéndolo en las variables que el sistema siente —ubicaciones necesarias, movimientos por hora y líneas de pedido por día— y no en facturación. Una operación puede duplicar la facturación sin mover más, o mantenerla y duplicar las líneas porque los pedidos se hicieron más chicos y frecuentes. Para un sistema automático son escenarios opuestos: el primero casi no lo afecta y el segundo lo satura.
Por cuándo aparece. Se manifiesta al final, cuando el equipamiento ya está comprado y montado, así que no hay margen para cambiar el alcance. Y lo que falla casi nunca es la máquina sino el dato: códigos que existen en un sistema y no en el otro, unidades que no coinciden, o un stock que en el papel está y en la posición no. Un operario corrige eso a ojo; un sistema automático se detiene.
Con carga real y no de muestra, porque los problemas aparecen en lo que no es estándar: el pallet mal armado, la caja que excede el alto, el film suelto. Se prueba la hora pico y no el promedio, los casos de excepción —cancelaciones, devoluciones, bloqueos por calidad, conteo en operación—, la integración de punta a punta con datos reales, y se prueba con el equipo que va a operar, no sólo con los técnicos de montaje.
Un almacén manual degrada y uno automático se detiene, y por eso el plan de contingencia se escribe antes de arrancar. Tiene que definir cómo se despacha lo urgente con el sistema parado, qué stock conviene dejar accesible fuera del sistema, quién hace el primer diagnóstico, qué repuestos críticos están en el almacén, y cómo se registra lo que se movió mientras estuvo caído para que al volver el inventario coincida.