Cronograma de implementación: dependencias que suelen quedar fuera del plan

Por qué los cronogramas fallan antes de empezar

Un plan que solo lista tareas con fechas invita a la sorpresa. Con frecuencia, los retrasos no vienen de la tarea principal (instalar lectores o etiquetas), sino de lo que debía estar listo antes: datos, accesos, permisos, red, decisiones. Por eso conviene construir el cronograma desde las dependencias: qué necesita cada etapa para empezar, quién lo entrega y cómo se sabe que está completo.

Este artículo no ofrece duraciones. Cualquier número genérico sería inventado, porque depende del alcance, de la cantidad de sitios, de la madurez de los datos y de la disponibilidad de terceros. Lo que sí ofrece es un mapa de etapas y las dependencias que suelen quedar fuera del plan.

Mapa de etapas

1. Definición: alcance, objetivo medible y criterios de aceptación escritos.
2. Datos y diseño: maestro de artículos, esquema de identificación, diseño de zonas o de cobertura.
3. Adquisición y logística: pedidos, importación, recepción y revisión de equipos.
4. Preparación del sitio: red, alimentación, soportes, permisos de acceso.
5. Configuración e integración: equipos, software, conexión con ERP, WMS o punto de venta.
6. Instalación y puesta en marcha.
7. Capacitación y operación asistida.
8. Pruebas de aceptación y cierre.

Las etapas pueden solaparse, pero cada solape debe estar justificado. Si la integración empieza antes de que los datos maestros estén listos, el riesgo debe estar anotado.

Dependencias que suelen olvidarse

Datos maestros. Las etiquetas RFID suelen contener un número que se consulta en una base de datos, como explica la RAIN RFID Alliance; si los datos del artículo están incompletos o duplicados, el sistema no mejora el proceso. Limpiar datos lleva tiempo y depende del cliente.

Red y energía. En ESL, la arquitectura puede exigir puntos de acceso compatibles, versiones de firmware, reglas de firewall y dominios de salida. La documentación de Cisco Meraki con Vusion lista modelos y requisitos de puerto, y advierte que algunas funciones IoT del punto de acceso son excluyentes entre sí. Averiguar esto después de comprar es un riesgo de calendario.

Aprobaciones internas. Seguridad informática, legal, compras y mantenimiento pueden tener ciclos propios. Si el sitio es de un tercero (un centro comercial, un cliente), agregue su proceso de permisos.

Trabajo en sitio fuera de horario. Si hay que instalar con la tienda abierta o la bodega operando, el acceso se limita a ventanas que hay que negociar.

Cumplimiento regulatorio. Los equipos con radio pueden requerir documentación; el tema se trata en el artículo sobre documentación de radiofrecuencia y debe resolverse con un especialista.

Plantilla de dependencias

Cómo estimar sin inventar

Pida a cada proveedor un cronograma por dependencias, no por fechas, con la lista de lo que necesita del cliente en cada etapa. Luego estime con su equipo la duración de lo que depende de ustedes. Etiquete cada estimación como «supuesto» y revíselas tras la prueba de concepto, que revelará lo que hay de real en ellas.

Considere holguras para los puntos con terceros (importación, permisos, ventanas de instalación) y deje una reserva explícita para pruebas fallidas: si la primera prueba de aceptación falla, ¿cuánto tiempo tomará corregir y repetir? Esa pregunta debería tener respuesta antes del inicio.

Ejemplo hipotético de una dependencia oculta

Supongamos que un proyecto de ESL para una tienda planea instalar etiquetas un fin de semana. Nadie había verificado que el equipo de red necesita aprobar el cambio de configuración en los puntos de acceso, y esa aprobación tiene su propio ciclo. La instalación física puede avanzar, pero las etiquetas no pueden vincularse al sistema hasta que la red esté lista. El plan no falló en la instalación, sino en una dependencia que no estaba escrita. Este escenario es ilustrativo y no representa a ningún cliente.

Control de cambios y señales de alerta

Todo cronograma cambia. Lo que distingue a un proyecto sano es que los cambios se registran y se discuten con su efecto: ¿qué etapa se mueve?, ¿qué dependencia arrastra?, ¿quién lo aprueba? Sin ese registro, los retrasos se acumulan sin que nadie los asuma.

Algunas señales tempranas de riesgo: entradas de una etapa que siguen en «pendiente» cuando la etapa debía comenzar, responsables que no responden a solicitudes de datos, cambios de alcance sin cambio de calendario y pruebas de aceptación sin criterios escritos. Si aparecen dos o más a la vez, conviene detener el avance y renegociar el plan en lugar de esperar que el tiempo lo resuelva. Un cronograma honesto es preferible a uno cómodo.

Siguiente paso

Tome la tabla anterior, adáptela a su caso y pida a cada responsable que confirme sus entradas y salidas por escrito. Revise el plan en una reunión corta cada semana, centrada en dependencias abiertas y no en el avance de tareas.

Si desea contrastar su caso con ARKCOM, puede escribir desde garkcom.com/contact.