Calidad de Software · UADE
Diagnóstico y Propuesta de Mejora para Sanatorio Bernal
Cómo pasar de una operación reactiva y riesgosa a un sistema de calidad gradual, medible y sostenible.
- Ezequiel Banchio
- Francisco Gonzalez
- Luka Cerrutti
Contexto de la organización
Un sanatorio mediano con alta demanda operativa
Sanatorio Bernal es una institución privada de salud en zona sur, con procesos asistenciales intensivos y un área de IT reducida.
Escala sanitaria
~130 camas, 800-1000 consultas ambulatorias diarias y guardia 24 horas.
Equipo IT pequeño
5 personas: jefe de sistemas, 2 técnicos de infraestructura y 2 analistas funcionales.
Ecosistema híbrido
Herramientas in-house conviven con HCE, turnos y portal del paciente tercerizados.
Modelo actual
El área de Sistemas trabaja en modo ad-hoc
El ciclo de vida del software carece de prácticas formales de ingeniería, trazabilidad y validación previa.
Gestión informal
Trello con checklists, pedidos verbales y sin métricas de flujo ni criterios de aceptación.
Código en main
GitHub funciona como repositorio simple, sin branching ni revisiones cruzadas.
Despliegue manual
El pase a producción depende del jefe de sistemas y de configuraciones WAMPP locales.
Terceros reactivos
Las caídas o bugs del proveedor se gestionan recién cuando impactan en la operación.
Calidad percibida y técnica
Las fallas ya afectan pacientes y operación clínica
Las reseñas y situaciones reportadas muestran una brecha crítica entre lo que el sistema debería garantizar y lo que realmente entrega.
Crítico
Seguridad de datos
Resultados de laboratorio visibles en perfiles incorrectos y pérdida de registros digitales.
Disponibilidad
Portal con pantallas en blanco, timeouts y fallas en recuperación de contraseña.
Interoperabilidad
Órdenes quirúrgicas perdidas, turnos mal asignados y errores de facturación.
UX operativa
WhatsApp en bucle, triage desincronizado y problemas de compatibilidad.
Diagnóstico crítico
El iceberg: síntomas visibles, causas estructurales
La crisis no está en una pantalla o un módulo puntual, sino en una cultura reactiva que desplaza la calidad al final.
Lo que se ve
Quejas, caídas del portal, cruces de datos y turnos inconsistentes.
La raíz
Testing tardío, despliegues manuales, sin staging, sin rollback y deuda técnica acumulada.
Estrategia de mejora
Kaizen + PDCA: mejorar sin paralizar al sanatorio
Se descartan cambios rígidos o radicales. La mejora debe ser pequeña, continua y compatible con un equipo saturado.
- 1 Planificar la demanda
- 2 Hacer cambios pequeños
- 3 Verificar con usuarios
- 4 Actuar y estandarizar
Plan de acción
Dos frentes para atacar las causas raíz
Primero se ordena la entrada de trabajo; después se evita que el software llegue tarde y sin validación real.
Frente 1
5S Digitales
Clasificar, ordenar, limpiar, estandarizar y sostener la disciplina sobre tickets y pedidos.
Menos interrupciones
Reducir llamados informales y cambios de contexto que rompen el flujo de los analistas.
Frente 2
Planificación temprana
No codificar inmediatamente: entender el problema y definir criterios antes de implementar.
Entregas cortas
Validar incrementos funcionales con usuarios reales para evitar testing tardío.
Shift-left quality
Construir calidad desde el origen
La calidad deja de inspeccionarse al final y se incorpora desde la primera decisión técnica.
- 1 Ticket priorizado
- 2 Rama separada
- 3 Pull Request
- 4 Staging
- 5 Producción
Prácticas técnicas
Alto impacto, bajo costo de mantenimiento
Por tailoring, se eligen prácticas realistas para cinco personas y no una infraestructura corporativa imposible de sostener.
CI/CD simplificado
Automatizar empaquetado y despliegue a staging para reducir copia manual y error humano.
Testing estratégico
Automatizar solo flujos críticos: login, turnos, órdenes, estudios y datos sensibles.
Trazabilidad
Cada cambio debe vincularse a un ticket para saber qué se cambió, por qué y cómo revertirlo.
Configuration Management
Documentar versiones, puertos, librerías y datos de entorno para evitar 'en mi máquina funciona'.
Enfoque ágil en calidad
Kanban con WIP limits para recuperar el flujo
El tablero deja de ser una lista pasiva y se convierte en una herramienta para visualizar carga, priorizar y limitar trabajo en curso.
Visualizar el trabajo
Separar lo pendiente, en curso, en validación y terminado para transparentar bloqueos.
Limitar WIP
Evitar que los analistas atiendan demasiadas tareas a la vez y acumulen trabajo sin terminar.
Modelo de calidad y cambio
Normas como guía, no como burocracia
ISO 9001 e ISO/IEC 25010 se usan de forma adaptada, priorizando procesos claros y software confiable.
ISO 9001
Enfoque basado en procesos para ordenar demanda, soporte y priorización.
ISO/IEC 25010
Foco en funcionalidad, fiabilidad y seguridad por la criticidad de los datos médicos.
Everett Rogers
Empezar con innovadores y adoptadores tempranos para demostrar valor antes de escalar.
Curva de compromiso
Acompañar la resistencia inicial hasta exploración, aceptación y adopción sostenida.
Métricas de calidad
OKR para medir impacto, no actividad
El éxito se mide por resultados operativos: menos defectos críticos, menor tiempo de ciclo y mejor cumplimiento de soporte.
Calidad
KR 1 — Defectos críticos
Reducir defectos críticos en producción de 5 por mes a 0.
Flujo
KR 2 — Cycle Time
Bajar desarrollos simples de 14 días a menos de 5 días.
Servicio
KR 3 — SLA soporte
Subir el cumplimiento del SLA de soporte del 40% al 85% al finalizar el trimestre.
Conclusión
La ingeniería no elimina la incertidumbre, la gestiona
La propuesta permite que Sanatorio Bernal deje de correr detrás de urgencias y construya software confiable para médicos, administrativos y pacientes.
Kaizen + calidad desde el origen mejoras pequeñas, medibles y sostenibles en un entorno crítico