Pongamos las cosas claras: las demos de WMS son teatro. Teatro ensayado, guionizado y coreografiado. Y la mayoría de los compradores salen del teatro, firman un contrato y luego pasan el año siguiente preguntándose por qué el software que se veía tan fácil en la pantalla del proyector se desmorona en su almacén.
Lo vi pasar en 2019 con un distribuidor de artículos para el hogar en las afueras de Los Angeles. La demo fue impecable: escaneas un código de barras, las olas de preparación se liberan al instante, las rutas de picking optimizadas como el diagrama de un libro de texto. El dueño firmó en el acto. Nueve meses después, en la semana del go-live, el almacén acumulaba 6,000 pedidos atrasados y el dueño me gritaba desde el andén: "¡En la demo funcionaba bien!"
Claro que sí. Esa era la idea.
Tres trucos de las demos a tener en cuenta
Primero, datos sanitizados. La base de datos de la demo tiene quizá 500 SKU perfectos: cada artículo con código de barras, cada lote limpio, cada ubicación asignada. Tu almacén tiene 20,000 SKU, incluidos los que tienen códigos de barras faltantes, cajas aplastadas y tres lotes mezclados en un mismo pallet. El software parece rápido porque nunca ha conocido datos sucios.
Segundo, el camino feliz. Las demos de ventas siempre recorren el camino dorado: recepción, almacenamiento, picking, embalaje, envío. Preguntas por el procesamiento de devoluciones y escuchas "es configurable". Preguntas por la trazabilidad por número de serie y escuchas "lo soportamos". Esas dos palabras — configurable, soportado — suelen traducirse en una segunda factura por desarrollo a medida durante la implementación. Pídeles que ejecuten tu flujo real de devoluciones en vivo, en el momento. La mayoría no lo hará.
Tercero, el operador equivocado. Quien hace la demo suele ser un ingeniero de preventa o un consultor senior de implementación que podría operar el sistema con los ojos cerrados. El equipo que implemente tu proyecto será otro: posiblemente consultores con tres meses de formación. Lo fluida que se siente la demo no tiene casi nada que ver con lo buena que será tu implementación.
Quítales el guion al proveedor
Una POC real tiene un solo principio: el guion lo escribe el comprador.
Escribe el tuyo antes de que el proveedor toque nada. Limítalo a unos diez escenarios, todos sacados de pedidos que tu almacén procesó realmente en los últimos tres meses. Mi lista recomendada: recepción y almacenamiento estándar, recepción de pallet completo con daños, inserción de pedido urgente en una ola, reasignación por picking corto, devoluciones de artículos con número de serie, reposición desde pallet roto, ajuste por variación de conteo cíclico, reetiquetado. Adjunta datos reales: al menos 2,000 de tus SKU reales, incluidos los feos, más una semana real de volumen de pedidos.
Luego fija las reglas: nada de datos precargados del proveedor; importan los tuyos en el momento; el operador debe ser tu supervisor de almacén, no su consultor manejando el ratón; cada escenario se cronometra.
Esa regla de "sin ayuda" es la que más importa. He presenciado POCs donde el consultor del proveedor se plantaba detrás del operador narrando cada clic, prácticamente moviendo el ratón por él. Eso evalúa al consultor, no al software. Sienta a tu supervisor menos técnico. Si lo aprende durante la sesión, el sistema es usable.
Cuantifica la línea de aprobación o no te molestes
Cuando termine la POC, nunca preguntes a la sala "¿qué les pareció?". Los sentimientos son el peor criterio de aceptación jamás inventado.
Escribe los criterios de aceptación en la primera página de tu guion de POC y haz que el proveedor los firme. Por ejemplo: al menos siete de ocho escenarios completados de principio a fin sin ayuda del proveedor; la liberación de una ola de 500 pedidos se completa en menos de dos minutos; un ajuste de conteo cíclico no toma más de cinco clics; tu supervisor opera de forma independiente durante dos horas sin errores.
¿No se cumple la línea? Dos opciones: el proveedor admite que necesita desarrollo a medida y pone el alcance y el precio por escrito, o queda fuera. La frase que hay que temer es "lo vamos a revisar": significa "hoy no funciona".
Hay una trampa que debo señalar específicamente: el tour guiado. Algunos proveedores ejecutarán tus escenarios por ti — su consultor conduce, tu gente mira — y lo llamarán POC. Eso es una demo con tu logo encima, no una prueba de concepto. Si las manos del proveedor están en el teclado más que las de tu equipo, detén la sesión y restablece las reglas. Una POC en la que el comprador nunca toca el software no demuestra nada, salvo que el proveedor sabe operar su propio producto, lo cual nunca estuvo en duda.
Un movimiento más: trae a tu líder de TI a la POC y que evalúe la capa de integración. Tu WMS va a hablar con tu ERP, tu TMS, tus plataformas de comercio electrónico. Medio día basta para saber si la documentación de la API es real y si existe un entorno de pruebas. Pide también los límites de tasa de la API: un sistema que te limita a unos pocos cientos de llamadas por hora se va a ahogar en cuanto tu volumen de pedidos se dispare. Un sistema con interfaces podridas va a arrastrar tu implementación al fondo.
Tres preguntas antes de firmar
La POC salió bien. Antes del contrato, consigue por escrito estas tres respuestas como anexo del contrato.
Uno: por cada escenario que pasó la POC, ¿quién paga el desarrollo a medida si no funciona en el go-live? Muchos contratos cotizan la implementación como una "estimación" con los sobrecostos facturados por separado. Anexa la lista de escenarios aprobados como criterios de aceptación: si no funciona, es problema del proveedor.
Dos: ¿quién está exactamente en el equipo de implementación? Consigue los nombres de los consultores líderes en el contrato, con una cláusula de que los reemplazos requieren tu aprobación. Las promesas verbales de "nuestro mejor equipo" no valen nada.
Tres: tiempos de respuesta durante los primeros 90 días tras el go-live. Algo se va a romper; la pregunta es qué tan rápido aparecen. Escríbelo: atención remota en cuatro horas para problemas críticos, en sitio en 24.
¿Ese cliente de artículos para el hogar? Cambiaron de sistema. En la segunda ronda de selección, los hice correr una POC de tres semanas con datos reales y más de 200 pedidos reales. El día del go-live en el nuevo sistema, el almacén cerró con dos horas de horas extra. El dueño me dijo después que ojalá lo hubieran hecho así la primera vez.
Una POC es el único momento antes de firmar en que puedes hacer que el proveedor haga trabajo real. No lo desperdicies.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
