Proyecto piloto de control de activos: probar antes

Ya eligió el sistema. Planificó el despliegue. El próximo lunes activa todo para todos: cinco sedes, 500 personas.

No lo haga.

Construí UNIO24 porque vi esta misma escena repetirse una y otra vez. Los equipos eligen una herramienta, planifican el despliegue y se saltan el piloto porque "no hay tiempo". Después pasan los siguientes seis meses parchando el sistema en producción mientras los usuarios, en silencio, regresan a las tablillas. Los equipos que corren un piloto de dos semanas casi siempre despliegan limpio. El patrón es brutalmente consistente.

Le voy a mostrar cómo correr un piloto que detecte los problemas de verdad: el wifi que no llega hasta donde en realidad vive el equipo, las etiquetas que se desgastan en dos semanas, el flujo que toma 5 minutos cuando debería tomar 30 segundos. Pruebe en pequeño, encuéntrelos mientras son baratos, y después despliegue con el sistema ya sin ese riesgo.

Por qué el piloto no es opcional

Los pilotos se sienten como burocracia. Son mitigación de riesgo disfrazada de proceso.

Un buen piloto cumple cinco funciones. Saca a la luz problemas técnicos antes de que se conviertan en desastres: si el wifi del almacén de verdad llega hasta el fondo, si el servidor aguanta 50 lecturas simultáneas, si sus etiquetas sobreviven al ambiente real. Revela problemas de flujo que no anticipó, los que solo aparecen con alguien escaneando con guantes puestos, o cuando hay que rastrear laptops mientras están conectadas a su base. Le da un ciclo de retroalimentación mientras todavía puede cambiar de sistema, ajustar su estrategia de etiquetado o rehacer la estructura de datos, algo que ya no puede hacer después del despliegue general. Crea impulsores, porque los usuarios que ayudaron a dar forma al proceso son quienes lo defienden después. Y demuestra el ROI antes de firmar el cheque grande, justo lo que una dirección escéptica necesita ver.

El riesgo de implementar el control de activos no desaparece si lo ignora; solo aparece después, en una forma peor, con más testigos. Entender el costo total de propiedad significa contar ese riesgo desde el principio.

Cómo elegir su piloto: ¿área, sede o ambas?

No se puede pilotar "un poco de todo". Eso es un despliegue general a medias, no un piloto. Para probar bien el software, necesita un alcance lo bastante representativo para validar sus hipótesis, pero lo bastante pequeño para manejarlo.

Hay tres formatos posibles.

Un área, todas las sedes. Rastree todo el equipo de TI de la empresa, y nada más. Funciona cuando sus procesos están estandarizados entre sedes y una categoría de activos tiene requisitos propios (TI, vehículos). El límite: no prueba cómo maneja el sistema la variedad de activos. El mobiliario de oficina se comporta distinto de las herramientas eléctricas.

Una sede, todos los tipos de activo. Despliegue todo en la sede principal, en ningún otro lugar. Funciona cuando las sedes difieren mucho entre sí (oficina contra almacén contra obra) y quiere probar el espectro completo. El límite: se pierde los problemas propios de cada ubicación, como la zona muerta de wifi del almacén.

Híbrido. Elija una sede representativa más dos o tres categorías de activos que cubran usos distintos. Ejemplo: sede principal + equipo de TI + mobiliario de oficina + herramientas. Gana variedad en los tipos de activo (caro contra barato, móvil contra fijo, lo que se traslada seguido contra lo que casi nunca se mueve) sin desbordar el alcance. Es el formato que elegiría para la mayoría de las organizaciones, ya sea que gestione activos de una iglesia u ONG o equipo de mantenimiento de edificios.

Qué hace buena a una sede piloto

Elija una sede representativa de su organización en general (ni la más fácil ni la más difícil), accesible para resolver problemas de forma presencial, de tamaño medio (lo bastante grande para sacar a la luz problemas, lo bastante pequeña para manejarla), y dispuesta a participar. Los usuarios piloto resistentes condenan el proyecto.

Descarte su sede más pequeña y simple: no va a revelar la complejidad real. Descarte también la más caótica: solo va a generar frustración. Evite sedes remotas donde no pueda involucrarse presencialmente. Y no pilote en ningún lugar que esté pasando por una disrupción grande: mudanzas, reorganizaciones, cambios de liderazgo.

Cuántos activos incluir

Mi regla general:

Piso: al menos 50 activos y 5 usuarios activos. Con menos, no se genera suficiente actividad para probar flujos reales. Techo: no más del 10% de su total de activos. Más allá de eso, está haciendo un despliegue general con otro nombre.

Cómo definir el alcance de su piloto

"Vamos a probarlo y a ver qué pasa" no es un plan. Los alcances vagos producen resultados vagos. Defina cuatro cosas explícitamente.

Qué está probando. Categorías de activos incluidas (laptops, monitores, escritorios, sillas de oficina). Categorías excluidas. Enumérelas explícitamente para que nadie asuma. Límites de ubicación (Edificio A, pisos 1 a 3, incluyendo el almacén pero no el centro de datos). Grupos de usuarios (gerentes de oficina, TI, mantenimiento, pero no el personal en general).

Qué está midiendo. Defina los criterios de éxito antes de empezar: tiempo para localizar activos, tasa de responsabilización de activos, adopción de usuarios, tasa de error en el registro de datos, tiempo dedicado a tareas relacionadas con activos. Más sobre las cifras en la sección de indicadores más abajo.

Qué procesos está probando. No solo el software, el flujo completo. Alta de activos nuevos, etiquetado, entrega y devolución, traslados, baja, y sí, también los procesos de auditoría durante el propio piloto.

Qué NO está probando todavía. Integración con otros sistemas (para el despliegue general). Reportes complejos (concéntrese en lo esencial). Funciones avanzadas que no va a usar de inmediato. Personalizaciones de las que no está seguro. Este último punto es donde el alcance se desborda y mata los pilotos: "ya que estamos, aprovechemos y también...". Si está empezando desde cero y hoy usa hojas de cálculo, vea cómo pasar de hojas de cálculo a un software de control de activos.

Cronograma: ¿cuánto debería durar un piloto?

Con menos de dos semanas, detecta los problemas técnicos obvios pero se pierde los problemas de flujo que aparecen con el tiempo, y los usuarios no llegan a formar hábitos reales. Con más de tres meses, el impulso muere; la gente olvida que es un piloto y lo trata como algo permanente pero roto.

El punto óptimo para la mayoría de las organizaciones: de cuatro a ocho semanas.

Las semanas 1-2 son configuración y uso inicial: configurar el sistema, etiquetar los activos piloto, importar o cargar el dato inicial, capacitar a los usuarios, ponerlos a usarlo para trabajo real. Está vigilando problemas técnicos, dificultades básicas de uso, retroalimentación del tipo "este botón no funciona".

Las semanas 3-5 son pruebas del mundo real. El sistema está en uso diario, los usuarios corren flujos reales, empiezan a aparecer los primeros problemas de proceso, y empieza a ver qué funciones se usan y cuáles se ignoran. Está vigilando fricción de flujo, funciones faltantes, brechas de capacitación, problemas de calidad de dato.

Las semanas 6-8 son evaluación. Recoja retroalimentación formal, analice los datos de uso, pruebe los ajustes que hizo, corra una mini-auditoría para verificar la calidad del dato, tome la decisión de escalar o no. Está vigilando si las mejoras se sostuvieron y si el sistema resuelve el problema real.

Cuándo necesita comprimirlo

A veces el calendario no respeta los plazos ideales: auditoría anual en seis semanas, presión regulatoria, impaciencia de la dirección. Un piloto comprimido de dos a tres semanas puede funcionar, pero solo con recursos dedicados, un líder de implementación con experiencia y requisitos simples:

• Semana 1: configuración intensiva, capacitación y pruebas iniciales.
• Semana 2: uso operativo completo con seguimiento diario.
• Semana 3: recolección rápida de retroalimentación y decisión.

No comprima en entornos complejos. El trabajo del piloto es encontrar problemas. Recortar tiempo significa encontrar menos.

Indicadores de éxito: medir lo que de verdad importa

"¿Funcionó el piloto?" es una pregunta inútil. Necesita criterios específicos y medibles, definidos antes de que empiece el piloto. Esto es lo que hay que rastrear y cómo deberían verse las cifras.

Desempeño técnico

El sistema necesita ser confiable. Apunte a 99%+ de disponibilidad durante el piloto. Si los usuarios no pueden acceder con regularidad, ya perdió. La lectura móvil debería completarse en menos de tres segundos, del código QR a los detalles del activo. Más lento que eso, y la gente va a encontrar excusas para no escanear. La confiabilidad de la sincronización es el asesino silencioso: rastree si las lecturas offline en realidad sincronizan cuando el usuario vuelve a estar en línea. Lecturas perdidas significan dato perdido, y el dato perdido significa confianza perdida. La confianza no vuelve fácil.

Adopción de usuarios

Quiere que 80%+ de los usuarios piloto estén usando el sistema activamente cada semana. Rastree inicios de sesión y movimientos por usuario. Si la mitad de sus usuarios piloto no está participando, su despliegue general va a chocar contra personas normales.

El cumplimiento del proceso le dice si el sistema encaja con el flujo de trabajo. Compare lo que pasa físicamente contra lo que queda registrado en el sistema. Si el 90%+ de los traslados de activos no se están registrando, la gente está trabajando alrededor de la herramienta. Su proceso está roto, corríjalo ahora.

El tiempo hasta la competencia es el indicador de aceptación que más me importa. Los usuarios deberían poder realizar tareas básicas de forma independiente en dos días. Si todavía necesitan acompañamiento después de la primera semana, algo anda mal con la interfaz o con la capacitación.

Impacto en el negocio

El tiempo para localizar activos debería bajar al menos 50%. Pida a los usuarios que estimen el antes y el después. Si el sistema no hace más rápido encontrar las cosas, ¿cuál es el punto?

Responsabilización de activos: 95%+ de los activos piloto deberían tener ubicación y responsable conocidos. Corra una auditoría al final del piloto para verificarlo. Si no puede dar cuenta de los activos después del piloto, tampoco va a poder después del despliegue general.

Ejemplo de UNIO24, un registro piloto con prefijos de identificador por clase (TI- para equipo de cómputo, TN- para transporte, MB- para mobiliario), cada renglón con un responsable (una ubicación como Almacén #2, un proveedor de servicio como Servicio Universal de TI, o una persona con su área), y estados repartidos entre inactivo, activo y en mantenimiento. Esto es lo que se ve un 95%+ de responsabilización: las celdas de Responsable vacías, los prefijos faltantes o las fechas de Actualizado desactualizadas son donde hay que buscar al final del piloto.

Exactitud del dato: 95%+. Ubicación, estado y asignación coinciden con la realidad al verificar físicamente. El dato basura en el piloto se convierte en dato basura en producción. Rastree también los activos encontrados durante el piloto. Descubrir artículos "perdidos" paga el piloto y vende el despliegue general.

Satisfacción de los usuarios

70%+ de los usuarios piloto deberían recomendar el despliegue general. Si sus adoptantes entusiastas tempranos no lo recomiendan, algo está genuinamente roto. La facilidad de uso percibida debería promediar 4+ de 5 en las encuestas. Y lo que más importa es el valor percibido: escuche frases como "esto me ayuda a hacer mejor mi trabajo". Si ven el sistema como trabajo adicional, ninguna cantidad de capacitación lo arregla. Es un problema de gestión del cambio.

Cómo recoger retroalimentación en el momento correcto

No espere hasta el final para preguntar "¿cómo va todo?". Para entonces, los usuarios frustrados ya se desconectaron mentalmente.

En la primera semana, tenga conversaciones diarias de cinco minutos o mensajes de seguimiento. Pregunte qué genera confusión, dónde se traban las personas, qué toma más tiempo del que debería, si ven errores. La retroalimentación diaria es esencial aquí: un botón confuso que desperdicia 30 segundos por lectura desperdicia 500 minutos a lo largo del piloto. Arréglelo ahora.

En las semanas 2-3, cambie a encuestas semanales cortas: cinco preguntas máximo, dos minutos para completar. Facilidad de uso de 1 a 5, qué tarea tomó más tiempo esta semana, qué cambiarían, qué función desearían que existiera, más un espacio abierto para lo que no se le ocurrió preguntar. Las encuestas semanales dejan emerger tendencias: si tres personas piden lo mismo de forma independiente, importa.

En las semanas 4-6, corra entrevistas individuales de 15 a 30 minutos con usuarios representativos. Recorra su flujo típico: dónde ayuda el sistema, dónde estorba, si son más o menos productivos, qué haría que pasara de "bien" a "excelente". Las encuestas dan datos; las entrevistas dan entendimiento, el por qué algo es un problema, no solo que lo es.

Al final, corra una encuesta final más una sesión de cierre en grupo. La encuesta cubre satisfacción general (1-10), recomendación de despliegue sí/no, las tres cosas que funcionan, las tres que necesitan mejorar, preocupaciones sobre el despliegue más amplio. La sesión de cierre es donde vive el valor real: reúna a los usuarios piloto y déjelos hablar entre sí, no con usted. Las conversaciones que tienen revelan cosas que las encuestas nunca captan.

Una pregunta para agregar a todo piloto: "si desplegáramos esto en toda la empresa mañana, ¿estaría emocionado o preocupado?". Corta a través de la cortesía y revela el sentimiento real. Si sus adoptantes tempranos, la audiencia más favorable que jamás va a tener, están preocupados, no está listo.

Problemas comunes que va a encontrar

Todo piloto que he observado saca a la luz alguna versión del mismo puñado de problemas. Conocerlos de antemano no los evita, pero acorta el tiempo que pasa confundido.

El wifi no llega hasta donde viven los activos. Los usuarios no pueden escanear en ciertas áreas porque no hay red. Si el escaneo no funciona donde está el equipo, el sistema es inútil. La solución es el modo offline (las aplicaciones modernas lo tienen), puntos de acceso adicionales, o dispositivos con datos móviles para los rincones realmente remotos. Pruebe en el entorno físico real, no en la oficina: los mapas de calor de wifi mienten.

Registrar un traslado toma demasiado tiempo. Cuando el flujo digital es más lento que el método anterior, la adopción fracasa. Identifique qué pasos son lentos, no lo asuma. Recorte campos innecesarios (¿de verdad necesita los 15 para un traslado?). Habilite acciones masivas para trasladar diez artículos a la vez en lugar de uno por uno. Use escaneo en lugar de tipeo siempre que pueda. Cronometre cada flujo de rutina; si toma más de tres clics y 30 segundos, simplifíquelo.

Las etiquetas se despegan, se decoloran o dejan de leerse. No sobreviven a su entorno. Si no puede escanear la etiqueta, no puede rastrear el activo, y el esfuerzo de etiquetado se desperdició. Pruebe la durabilidad en condiciones reales durante el piloto: pegue una etiqueta y vea cómo se ve en dos semanas. Cambie a poliéster en lugar de papel, etiquetas metálicas para ambientes agresivos, laminado protector para artículos de exterior o alto tráfico. NFC vale la pena para superficies metálicas o exposición química. La guía de buenas prácticas de etiquetado cubre esto a fondo.

Los usuarios no logran definir la categoría. "¿Un teclado inalámbrico es Equipo de TI o Suministros de Oficina?" La categorización inconsistente destruye los reportes y la búsqueda. Cree un árbol de decisión simple ("si se conecta a la corriente → TI; si te sientas en él → mobiliario; si tiene motor → equipo"). Reduzca la cantidad de categorías: diez es mejor que cuarenta y siete. Dé ejemplos y deje que los usuarios marquen "no estoy seguro" en lugar de obligarlos a adivinar mal.

Los usuarios piloto no se dan cuenta de que se supone que deben usarlo de verdad. La participación pasiva no prueba nada. Establezca expectativas explícitas desde el arranque, haga del piloto parte del trabajo real de los usuarios, designe un coordinador que dé seguimiento con regularidad, y celebre la participación, no solo los resultados.

El dato estaba mal desde el día uno. Importar registros sin limpiarlos primero hace que el piloto arranque con basura, y los usuarios pierden la confianza de inmediato. Limpie su dato antes de que arranque el piloto; la guía de migración y limpieza de datos recorre esto a detalle. Verifique una muestra antes de importar todo y corra una mini-auditoría en la primera semana. Sea transparente: "sabemos que algunos registros están mal, ayúdennos a encontrarlos" genera colaboración donde "este es el sistema oficial" genera frustración.

Lo que funciona a escala piloto se rompe a escala completa

Esta es la trampa que he visto arruinar pilotos exitosos: 20 usuarios comprometidos con excelente calidad de dato y comentarios positivos, y después llegan 500 usuarios en el despliegue y todo se desmorona. La escala pequeña y la escala grande no son el mismo juego.

En el piloto, cuando alguien tiene una duda, le pregunta al líder de implementación. Con 500 usuarios, ese líder se ahoga: los tiempos de respuesta pasan de cinco minutos a cinco días, los usuarios se frustran, se rinden. La solución es soporte de autoservicio construido antes del despliegue: documentación consultable con capturas de pantalla, un FAQ basado en las preguntas reales del piloto, videos tutoriales (la gente ve videos cuando no lee manuales), impulsores capacitados en cada área, y una ruta de escalamiento clara.

Los usuarios piloto se ofrecieron como voluntarios o fueron elegidos. Están motivados, perdonan problemas pequeños, dan retroalimentación sin que se les pida. Los usuarios del despliegue general no pidieron esto: tienen su propio trabajo, no van a perdonar la fricción, simplemente van a dejar de usar el sistema. Resuelva cada problema significativo antes de escalar, comunique el por qué repetidamente, reduzca la fricción que pueda y reconozca públicamente la buena adopción.

Con 50 activos piloto puede verificar la calidad del dato manualmente cada semana. Con 5 000, la verificación manual es imposible: los errores se acumulan y la calidad decae. Construya verificaciones automáticas antes del despliegue: activos sin ubicación, números de serie duplicados, fechas de "visto por última vez" sospechosamente antiguas. Implemente una estrategia de auditoría sostenible con conteo cíclico en lugar de esperar que la auditoría anual lo detecte todo, y haga de la calidad del dato la responsabilidad específica de alguien.

El líder de implementación hace todo a escala piloto: configura, capacita, importa, corrige, responde preguntas. A escala, se forman cuellos de botella por todos lados. Documente lo que sabe antes del despliegue, capacite administradores adicionales para que el conocimiento no se concentre en una persona, y delegue roles claros: capacitación, calidad del dato, soporte técnico.

Agregar un activo nuevo toma cinco minutos en el piloto. A escala completa son 50 activos nuevos por semana, cuatro horas de trabajo. Simplifique el registro con menos campos obligatorios y valores predeterminados inteligentes, habilite la importación masiva y, si puede, intégrese con compras para crear activos desde las órdenes de compra.

Regla general: multiplique el esfuerzo del piloto por su factor de escala. Si algo toma una hora por semana en el piloto, va a tomar 25 horas a 25 veces la escala.

La decisión de escalar o no

Su piloto terminó. Tiene datos, retroalimentación y experiencia. Ahora decide. Esto debería ser evidencia, no política ni costos hundidos.

Escale automáticamente si todo esto es cierto: desempeño técnico dentro de los objetivos (>99% de disponibilidad, lectura rápida), adopción sobre 80%, exactitud del dato sobre 95%, al menos 70% de los usuarios recomienda el despliegue, sin problemas graves, y ROI demostrable en tiempo ahorrado, activos encontrados o eficiencia ganada. Con estas cifras, avance y use a los usuarios piloto como impulsores.

No escale si cualquiera de esto es cierto: el sistema no está disponible con regularidad, los usuarios lo resisten o lo evaden, los flujos críticos están rotos, la calidad del dato empeoró respecto al piloto, el respaldo de la dirección o el presupuesto se evaporaron, o el proveedor no corrige problemas críticos. Ante estas señales, deténgase: corrija lo fundamental, elija un sistema distinto, o replantee el enfoque.

Escalar con modificaciones es donde termina la mayoría de los pilotos. Las cosas funcionan en general, pero hay problemas importantes. Desempeño técnico aceptable pero no excelente, adopción de 60-75% (buena pero no excelente), algunos puntos de fricción en el flujo, los usuarios ven valor pero tienen reservas, calidad del dato mejorando pero todavía no llega.

Hágase cuatro preguntas. ¿Los problemas se pueden corregir? (Los problemas técnicos por lo general sí; los desajustes de flujo fundamentales muchas veces no.) ¿Cuánto van a tomar las correcciones? (Dos semanas es razonable; seis meses significa que no está listo.) ¿Las correcciones van a resolver las preocupaciones de los usuarios? (Pregúnteles, no asuma.) ¿Puede darse el lujo de esperar? (A veces la presión externa fuerza un momento subóptimo.) Después corrija los tres a cinco problemas principales, corra un mini-piloto de dos semanas para probar las correcciones, y tome la decisión final.

Un marcador, si quiere usar uno

Algunos equipos prefieren cuantificar la decisión:

8.0 o más: avance. 6.0-7.9: resuelva los problemas y avance. Menos de 6.0: retrabajo importante por delante. Ajuste los pesos a su organización. Si la satisfacción de los usuarios es crítica en su cultura, asígnele 30%.

Cómo comunicar los resultados del piloto

Su piloto terminó, ya decidió. Ahora se lo cuenta a la gente.

Para la dirección

Una página. Los directivos no leen reportes de cuarenta páginas.

Incluya: descripción general (qué, cuándo, con quién), indicadores clave en números (adopción, exactitud, ahorro de tiempo), uno o dos casos de éxito concretos, problemas encontrados y cómo los resolvió, riesgos restantes (sea honesto), la recomendación y los próximos pasos con cronograma y recursos. Empiece con los resultados, no con el proceso: "los usuarios del piloto redujeron el tiempo de búsqueda en 60%" gana a "completamos todas las actividades según lo programado".

Para el equipo de implementación

Este es su conocimiento institucional. Documente todo: alcance y cronograma completos, listado de usuarios y tasas de participación, toda la retroalimentación organizada por tema, problemas técnicos y sus resoluciones, cambios de proceso hechos durante el piloto, comparaciones antes/después con datos, lecciones aprendidas (qué funcionó, qué no), recomendaciones para el despliegue, y anexos con encuestas, notas de entrevistas y datos de indicadores.

Dentro de seis meses, cuando esté resolviendo un problema del despliegue, este documento vale oro. Dentro de un año, cuando pilotee un sistema distinto, este es su manual de referencia.

Para los futuros usuarios

Si va a avanzar, el anuncio establece expectativas y genera entusiasmo. Comparta los resultados del piloto de forma concreta. Destaque lo que funcionó. Muestre que escuchó la retroalimentación ("con base en lo que aprendimos, simplificamos el proceso de traslado y agregamos el modo offline"). Establezca expectativas claras ("va a recibir capacitación dos semanas antes de que su área entre en vivo"). Conecte con los beneficios que les importan ("menos tiempo buscando, más tiempo en el trabajo real").

Tono: confiado pero sin descartar las preocupaciones. "Sabemos que el cambio es difícil. Lo probamos a fondo y funciona" gana a "¡esto va a ser genial!".

Los usuarios piloto como impulsores

Sus usuarios piloto son su activo más valioso para el despliegue. Ya usaron el sistema, saben que funciona, pueden responder preguntas de sus compañeros con credibilidad. Destaque sus comentarios en los anuncios. Que co-lideren la capacitación en sus áreas. La capacitación entre compañeros es más creíble que la instrucción de arriba hacia abajo. Conviértalos en el punto de referencia para preguntas en su zona. Reconozca su contribución públicamente.

Su checklist del piloto

4-6 semanas antes

• Definir el alcance del piloto (áreas, sedes, categorías de activos)
• Elegir a los usuarios piloto (dispuestos, representativos, accesibles)
• Establecer criterios de éxito e indicadores
• Programar el cronograma del piloto (inicio, fin, evaluación)
• Comunicar el plan a la dirección y a los usuarios piloto

2-3 semanas antes

• Configurar el sistema para el entorno del piloto
• Preparar etiquetas
• Limpiar y preparar el dato para importar
• Crear materiales de capacitación
• Configurar canales de retroalimentación (encuestas, agenda de entrevistas)

La semana anterior

• Etiquetar los activos piloto
• Importar el dato inicial y verificar su exactitud
• Capacitar a los usuarios piloto (práctica, interactiva)
• Distribuir guías rápidas de referencia
• Configurar canales de soporte (Slack, correo, etc.)

Durante el piloto

• Seguimiento diario la primera semana
• Encuestas semanales de ahí en adelante
• Resolver problemas técnicos de inmediato
• Documentar toda la retroalimentación y los problemas
• Hacer ajustes rápidos sobre la marcha
• Rastrear los indicadores de uso continuamente

Fin del piloto

• Encuesta final de usuarios
• Entrevistas o sesión de cierre en grupo
• Auditoría física para verificar la exactitud del dato
• Calcular todos los indicadores de éxito
• Analizar qué funcionó y qué no

Después del piloto

• Resumen ejecutivo
• Reporte detallado del piloto
• Decisión de escalar o no, con el marcador
• Si escala: plan de despliegue con base en las lecciones aprendidas
• Si no escala o escala con modificaciones: correcciones necesarias documentadas
• Comunicar los resultados a los interesados
• Agradecer y reconocer a los usuarios piloto

Por qué esto me importa

Convertí estos patrones en las restricciones de diseño de UNIO24.

Móvil sin conexión por defecto, porque vi a demasiados equipos rendirse ante un sistema la primera vez que el wifi del almacén falló en medio de una lectura. Los primeros 50 activos son gratis, sin tarjeta y sin vencimiento de la prueba, porque quiero que de verdad pueda correr un piloto, no negociar con compras antes de saber si la herramienta encaja. Importación y traslado masivos, porque la diferencia entre cinco minutos y treinta segundos por acción es lo que decide la adopción entre el piloto y la escala. Una estructura de categorías inicial intencionalmente corta, porque ver a los usuarios adivinar categorías es un problema de flujo disfrazado de problema de interfaz.

Nada de eso está en este playbook por accidente. Está porque vi a los mismos problemas romper los mismos tipos de despliegues, y después construí un producto que no facilita cometerlos.

Corra el piloto. Encuentre los problemas mientras son pequeños. Si UNIO24 le ayuda a lograrlo, bien, empiece su piloto gratuito. Si algo más encaja mejor, úselo. Solo no se salte el piloto.