La petición de un “sistema para todo” suele empezar con una frustración real: alguien copia información, persigue autorizaciones o intenta conciliar registros contradictorios. El problema es específico, pero la propuesta pronto crece hasta reemplazar toda la operación.
Antes de contratar ese reemplazo, define un piloto alrededor de un proceso completo. Su propósito es comprobar si el software mejora una tarea repetible lo suficiente para justificar construirlo y mantenerlo.
Observa el trabajo antes de listar funciones
Elige un proceso con inicio y final visibles, como recibir una solicitud de servicio y asignarla a la persona adecuada. Sigue varios ejemplos reales junto con quienes hacen el trabajo. Usa registros anónimos o sintéticos cuando compartas material fuera del equipo autorizado.
Anota quién recibe la información, dónde la guarda, quién decide el siguiente paso y qué excepciones requieren otra ruta. Incluye el trabajo fuera del sistema oficial: un mensaje de seguimiento, una fila copiada a una hoja o una aprobación verbal.
La guía de descubrimiento del Service Manual de GOV.UK es una referencia útil para investigar problema, necesidades y restricciones antes de comprometerse con una solución. Aquí se utiliza como método de diseño, no como obligación para una empresa privada.
Establece una medición inicial que puedas repetir
Mide el proceso actual antes de introducir una herramienta. Puedes observar tiempo transcurrido, tiempo de trabajo efectivo, captura repetida, registros incompletos y frecuencia de devoluciones para corregir.
Define con precisión cada medida. “Tiempo de procesamiento” puede significar minutos de esfuerzo o días esperando una autorización; cada uno revela un problema distinto. Separa los casos excepcionales y registra la carga de trabajo durante el periodo observado.
No elijas una meta de mejora sólo porque suena atractiva. Acuerda con el equipo qué resultado justificaría continuar el piloto y conserva el método original para comparar.
Compara cambiar el proceso, configurar una herramienta y desarrollar
Algunos problemas necesitan una persona responsable o menos pasos de autorización. Otros encajan en un producto existente con una configuración razonable. El desarrollo a la medida es candidato cuando los requisitos y el valor esperado justifican hacerse cargo del sistema resultante.
Compara las alternativas con las mismas necesidades: roles, integraciones, exportación de datos, costo recurrente, soporte y consecuencias de cambiar de proveedor. Incluye el tiempo del equipo para mantener información y resolver excepciones.
El piloto puede ser una herramienta configurada o un módulo pequeño a la medida. Su valor consiste en responder una pregunta sobre la operación, no en entregar la mayor cantidad posible de código.
Define la aceptación con situaciones reales
Describe el flujo completo más pequeño. Por ejemplo: llega una solicitud, se valida la información necesaria, alguien autorizado la asigna y la persona solicitante recibe un estado claro.
Después define las excepciones:
- Falta un dato obligatorio y alguien debe corregirlo.
- La misma solicitud llega dos veces.
- Una persona intenta abrir una tarea fuera de su rol.
- Una integración no está disponible.
- Hay que corregir un registro después de asignarlo.
- El equipo necesita exportar información para conciliarla o moverla.
Especifica el comportamiento esperado y quién lo aprueba en cada situación. “El tablero funciona” es difícil de comprobar. “Una persona coordinadora autorizada puede ver solicitudes pendientes y asignar una sin perder su historial” sí es un criterio verificable.
Prepara el regreso antes de iniciar el piloto
Mantén disponible el proceso anterior hasta aceptar el piloto. Acuerda cuál registro manda durante la prueba, cómo se concilian cambios y quién decide pausar. Evita dos fuentes que compitan entre sí sin alguien responsable de conciliarlas.
Documenta cómo exportar datos, qué implica una restauración probada y cómo retirar acceso cuando alguien cambia de funciones. Estas tareas pertenecen al alcance del piloto, no a una promesa de atender la operación después.
Evalúa resultados antes de agregar módulos
Compara la medición inicial con el piloto usando las mismas definiciones. Revisa errores, tareas incompletas, esfuerzo y capacidad del equipo para explicar en qué estado está el trabajo. Una pantalla más rápida no demuestra un proceso más rápido si las aprobaciones siguen esperando en una bandeja.
Continúa, ajusta o detén el piloto según los criterios acordados. Descartar una solución que no encaja también es un resultado válido. Si funciona, prioriza el siguiente proceso con evidencia del uso real.
Nuestros servicios de software a la medida pueden empezar con esa pregunta operativa delimitada, para que la primera entrega permita evaluar algo concreto.