Aplicación operativa a medida

Construye una aplicación operativa para un proceso que no encaja en una plataforma estándar.

Cuándo tiene sentido desarrollar

La decisión empieza por el proceso, no por una pantalla. Una aplicación a medida puede ser pertinente cuando existen estados, excepciones o permisos que una plataforma estándar no representa sin trabajo paralelo. Primero se compara configurar un producto existente, integrar sus datos o modernizar una pieza con desarrollar. Configurar suele reducir superficie técnica, pero puede forzar el proceso a sus módulos y reglas. Desarrollar permite expresar el modelo propio, aunque añade decisiones de datos, seguridad, soporte y mantenimiento. Esta comparación no garantiza ahorro, velocidad ni compatibilidad; se decide después de revisar evidencia.

Modelo de dominio y datos maestros

El diseño debe nombrar objetos, relaciones y estados con el lenguaje del equipo. En una operación hipotética de solicitudes internas, el modelo podría distinguir solicitud, persona responsable, unidad, prioridad, evidencia y decisión; no se debe asumir que esas entidades existen hasta observar el proceso. Los datos maestros —catálogos de unidades, tipos, estados y responsables— necesitan dueño, definición de vigencia y regla para corregir duplicados. Así se evita que cada formulario invente valores distintos. También se documenta qué fuente prevalece cuando dos sistemas discrepan y qué dato puede quedar vacío.

Permisos y validaciones

Los permisos se definen por acción y contexto: quién puede crear, asignar, aprobar, consultar o corregir, y qué ocurre cuando cambia el responsable. El sistema debe registrar intentos rechazados sin exponer información innecesaria. Las validaciones combinan formato, obligatoriedad y reglas del proceso; por ejemplo, una aprobación hipotética podría exigir una justificación y evidencia antes de cambiar el estado. Conviene validar en servidor y mostrar mensajes comprensibles en la interfaz. Las excepciones no se ocultan: quedan como estados revisables, con responsable y motivo, en lugar de convertirse en ediciones manuales sin trazabilidad.

Prueba de aceptación

La aceptación traduce el alcance en escenarios observables. Un caso hipotético puede describir una solicitud nueva, asignarla a un rol autorizado, rechazar un campo incompleto, aprobarla y comprobar el historial resultante. Cada escenario identifica datos de prueba, actor, precondición, acción, resultado esperado y evidencia que se conserva. Usuarios representativos revisan tanto el camino normal como duplicados, cambios concurrentes y datos ausentes. Si un escenario falla, se registra si el problema es de regla, dato, permiso o interfaz; no se presenta una demostración parcial como validación completa.

Observabilidad y mantenimiento

Una aplicación operativa necesita explicar qué ocurrió. Se acuerdan eventos relevantes, errores, cambios de permisos y fallos de integración, cuidando que los registros no contengan secretos ni datos que no sean necesarios. Un tablero hipotético podría mostrar solicitudes bloqueadas por estado o validación, pero no implica que ese tablero exista hoy ni que mida resultados de negocio. El mantenimiento requiere responsable de reglas, procedimiento para cambios de esquema, respaldo, revisión de accesos y una forma de retirar una función. Sin esa capacidad operativa, el desarrollo crea dependencia difícil de evaluar.

Decisión y límites

El diagnóstico debe dejar una comparación legible entre configurar, integrar, modernizar y desarrollar. Se documentan alcance, fuentes, permisos, supuestos, dependencias y criterio para detenerse. El alcance, la inversión, los tiempos y las condiciones de soporte se acuerdan después de contrastar los requisitos y las dependencias; la compatibilidad se comprueba por integración. Tampoco se asume acceso administrativo o una integración concreta sin revisión. El siguiente paso puede ser un mapa de proceso, una prueba acotada, una recomendación de configuración o descartar la aplicación propia. La elección queda condicionada a datos y responsables reales; la recomendación requiere validación técnica, contractual y de seguridad.

En una revisión final, el equipo debe poder repetir una prueba y explicar el resultado sin depender de una persona que conozca decisiones implícitas. Se separan hechos observados, reglas aprobadas e hipótesis de diseño. Si una fuente cambia, se revisan el modelo de dominio, los permisos y las validaciones antes de ampliar el flujo. La continuidad también exige identificar qué hacer cuando no hay datos, cuando una persona deja el rol o cuando una integración queda temporalmente fuera de servicio. Estas preguntas no son adornos de documentación: determinan si configurar sigue siendo suficiente o si desarrollar agrega control justificable.