Una prueba de concepto demuestra que una idea puede funcionar en condiciones favorables. Un sistema en producción debe funcionar todos los días, con usuarios reales, con datos reales y junto a sistemas que nunca se diseñaron pensando en él. Muchas organizaciones descubren la diferencia solo cuando a una demo exitosa le siguen meses de silencio. Este artículo describe por qué ocurre y cómo se puede organizar un proyecto por etapas para que la demo tenga un camino realista hacia producción.

Por qué se estancan las pruebas de concepto

La mayoría de las pruebas de concepto estancadas comparten un conjunto reducido de causas. Ninguna es técnica en sentido estricto y todas pueden identificarse en las primeras semanas del proyecto.

  • Ausencia de un responsable de negocio. El trabajo lo patrocina un equipo de innovación o de TI, y nadie en el área operativa ha aceptado cambiar un proceso a raíz de él.
  • Acceso a los datos dado por hecho. La demo usó una exportación preparada a mano, mientras que los datos reales están en sistemas con sus propios responsables, permisos y problemas de calidad.
  • Falta de integración con los sistemas existentes. El prototipo funciona de forma aislada, por lo que nunca se ha estimado el costo de conectarlo con el ERP, el CRM o los sistemas de planta.
  • Criterios de aceptación inexistentes. Sin un objetivo definido, el éxito es cuestión de opinión, y un proyecto que no puede declararse exitoso rara vez recibe más financiamiento.

Qué necesita un sistema en producción más allá de la demo

Una demo cubre el camino principal. Un sistema en producción debe cubrir además todo lo que lo rodea. La siguiente lista recoge lo que esperaríamos ver antes de que un sistema empresarial entre en servicio.

  • Autenticación y autorización conectadas al proveedor de identidad corporativo, con roles que correspondan a funciones laborales reales.
  • Registro de eventos y monitoreo que permitan a un operador ver errores, solicitudes lentas y tareas fallidas antes de que los usuarios las reporten.
  • Contratos de datos que definan campos, formatos, frecuencia de actualización y qué ocurre cuando un sistema de origen envía algo inesperado.
  • Procedimientos de despliegue y reversión automatizados y ensayados, de modo que una versión defectuosa pueda revertirse en minutos.
  • Documentación sobre arquitectura, interfaces, configuración y procedimientos de operación.
  • Un responsable designado y disponible para guardias, con el acceso y el conocimiento necesarios para resolver incidentes.

Cómo se organiza un proyecto por etapas

Un enfoque por etapas mantiene cada inversión en proporción a lo aprendido hasta ese momento. Primero viene el descubrimiento, que aclara el problema de negocio, las personas afectadas, los sistemas involucrados y los datos disponibles. El resultado es un documento breve y una decisión sobre si continuar.

Después viene la prueba de concepto, con un criterio de aceptación medible acordado de antemano. En un sistema de clasificación de documentos puede ser una exactitud mínima sobre una muestra reservada. En un modelo de pronóstico puede ser un umbral de error frente al método manual actual. El propósito es obtener un sí o un no claro.

A continuación se ejecuta un piloto con datos reales y un grupo limitado de usuarios reales. Es en esta fase donde aparecen los problemas de integración, de calidad de datos y de proceso. Sigue la preparación para producción: revisión de seguridad, pruebas de rendimiento, monitoreo, respaldo y recuperación, y el flujo de despliegue. La etapa final es la entrega, con capacitación, documentación y un acuerdo de soporte que establezca quién responde a qué y en cuánto tiempo.

Preguntas para un proveedor antes de firmar

Unas pocas preguntas directas aportan mucha información al comprador. Qué personas del proveedor permanecen en el proyecto desde el descubrimiento hasta la entrega. Cuáles son los criterios de aceptación de cada etapa y quién decide si se cumplieron. Cómo se monitoreará el sistema después de la puesta en marcha y a quién se avisa cuando falle. Quién es el titular del código fuente, de los modelos entrenados y de la documentación. Cómo se desplegará el sistema y cómo se revierte una versión fallida.

También es razonable preguntar qué partes del trabajo dependen del cliente, como el acceso a los datos, los entornos de pruebas y los expertos de la materia, y en qué fechas se necesitan. Los retrasos del lado del cliente son una causa frecuente de desvíos en el cronograma, y nombrarlos desde el inicio facilita gestionarlos.

Conclusión

Pasar de la prueba de concepto a la producción depende sobre todo de la responsabilidad sobre el sistema, los datos, la integración y la operación, y solo en parte de la tecnología que se mostró en la demo. Las organizaciones que resuelven esos puntos desde el principio y organizan el trabajo por etapas con criterios claros dedican menos tiempo a pilotos que nunca terminan y más tiempo a operar sistemas en los que la gente confía.