← Volver al listado de tecnologías ← Índice de TOGAF, Doble Diamante y Design Thinking

Capítulo 18 — Caso de estudio integral: de la empatía al roadmap

15 de octubre de 2026 Por: Artiko

togafdesign-thinkingdoble-diamantecaso-de-estudioadmroadmap

Caso de estudio integral: de la empatía al roadmap

Este capítulo recorre un caso de principio a fin aplicando lo visto en el capítulo 17. Los artefactos se presentan completos, no descritos, para que sirvan como plantilla. La empresa es ficticia; los números son verosímiles para una aseguradora de su tamaño, pero inventados.

18.1 Contexto y brief

Salud Austral es una aseguradora regional de salud con 180.000 asegurados, 420 prestadores en convenio y 60 personas en el back office de reembolsos. El reembolso de gastos médicos funciona así: el asegurado paga al prestador, reúne boleta, orden médica y formulario firmado, los entrega en una sucursal o los envía por correo postal, y recibe el dinero en su cuenta entre 18 y 35 días después.

La gerencia general pide “digitalizar el reembolso”. El brief inicial, tal como llegó, era una frase: “Que los asegurados puedan pedir el reembolso desde el celular”.

Elemento del brief	Contenido inicial	Estado
Problema	No explicitado; se asume que es el canal	Por descubrir
Usuarios	Asegurados	Incompleto: faltan prestadores y back office
Restricciones	Presupuesto anual aprobado, core de seguros heredado	Conocidas
Medida de éxito	No definida	Por definir
Plazo	18 meses	Fijo

El equipo decide no aceptar el brief como está y abrir el primer diamante.

flowchart LR
    B0["Brief inicial: app para pedir reembolso"] --> D1["Descubrir con Design Thinking"]
    D1 --> D2["Definir: POV, HMW, design brief"]
    D2 --> A1["Preliminar y Fase A"]
    A1 --> D3["Desarrollar: idear y prototipar"]
    D3 --> A2["Fases B, C, D"]
    A2 --> A3["Fases E y F: roadmap"]
    A3 --> A4["Fases G y H: entregar y medir"]

18.2 Descubrir con Design Thinking

Investigación

Segmento	Técnica	Cantidad	Duración
Asegurados que reembolsaron en los últimos 6 meses	Entrevista semiestructurada	14	45 min
Asegurados que abandonaron un reembolso	Entrevista telefónica	6	20 min
Prestadores en convenio (clínicas y consultas)	Entrevista en sitio	5	40 min
Analistas de back office	Observación de jornada completa	4	8 h
Ejecutivos de sucursal	Observación de atención	3	4 h

Mapa de empatía del asegurado

Dimensión	Hallazgos
Dice	”Nunca sé si me falta un papel hasta que me lo rechazan”. “Lo mando y desaparece”.
Piensa	Que el proceso está diseñado para que se rinda. Que el rechazo es arbitrario.
Hace	Fotografía las boletas por si las pierde. Pregunta en redes sociales a otros asegurados. Va a la sucursal para “asegurarse”.
Siente	Desconfianza, cansancio, vergüenza de preguntar lo mismo varias veces.
Dolores	Rechazos por documentos faltantes, silencio durante semanas, viajes a sucursal.
Ganancias esperadas	Saber de antemano qué necesita, saber en qué estado está, cobrar rápido.

Mapa de empatía del analista de back office

Dimensión	Hallazgos
Dice	”El 40 % de lo que llega viene incompleto”. “Tipeo lo mismo que ya está en la boleta”.
Piensa	Que el problema está en la entrada, no en su trabajo.
Hace	Revisa a ojo, tipea datos en el core, devuelve sobres con una nota manuscrita.
Siente	Frustración por el retrabajo y presión por el volumen.
Dolores	Documentos ilegibles, falta de datos del prestador, reglas de cobertura solo en su cabeza.
Ganancias esperadas	Recibir casos completos, no tipear, tener las reglas a mano.

Journey map del reembolso actual

journey
    title Reembolso actual desde la vista del asegurado
    section Atención médica
      Paga al prestador: 3: Asegurado
      Pide boleta y orden: 3: Asegurado
    section Preparación
      Busca el formulario: 2: Asegurado
      Completa y firma a mano: 2: Asegurado
    section Envío
      Viaja a sucursal o envía por correo: 1: Asegurado
      Entrega sin comprobante de recepción: 1: Asegurado
    section Espera
      No recibe noticias por semanas: 1: Asegurado
      Llama al call center: 1: Asegurado
    section Resultado
      Recibe rechazo por documento faltante: 1: Asegurado
      Reinicia el proceso: 1: Asegurado
      Recibe el depósito: 4: Asegurado

Etapa	Dolor principal	Dato cuantificado
Preparación	No sabe qué documentos exige su cobertura	41 % de solicitudes llegan incompletas
Envío	Viaje a sucursal	62 % de solicitudes se entregan presencialmente
Espera	Silencio	2,3 llamadas al call center por solicitud en promedio
Resultado	Rechazo tardío	23 % de rechazo en primera presentación; 11 días promedio hasta el rechazo
Resultado	Abandono	9 % de solicitudes rechazadas no se vuelven a presentar
Back office	Retrabajo	38 % del tiempo del analista es tipeo y revisión de completitud

18.3 Definir

Point of View

La asegurada que acaba de pagar una consulta necesita saber en el momento qué documentos exige su cobertura y en qué estado está su solicitud, porque hoy descubre lo que falta solo cuando la rechazan, semanas después, y eso la lleva a desconfiar y a abandonar.

Preguntas How Might We

¿Cómo podríamos validar la completitud de una solicitud antes de que el asegurado la envíe?
¿Cómo podríamos eliminar el tipeo del analista aprovechando que el asegurado ya tiene la boleta en la mano?
¿Cómo podríamos hacer visible el estado de la solicitud sin que el asegurado tenga que llamar?

Design brief

Campo	Contenido
Problema	El reembolso falla por entrada incompleta y falta de visibilidad, no por el canal.
Usuarios	Asegurados, analistas de back office, prestadores como fuente de datos.
Resultado esperado	Solicitudes completas al primer intento y estado visible en todo momento.
Principios de diseño	Validar antes de enviar. Capturar una sola vez. Mostrar el estado sin pedirlo. Mantener el canal presencial para quien lo necesite.
Métricas	Tasa de rechazo en primera presentación, tiempo total de reembolso, llamadas por solicitud, NPS del proceso.
Fuera de alcance	Cambiar las reglas de cobertura. Reemplazar el core de seguros.

18.4 Preliminar y Visión de la Arquitectura

Principios de arquitectura

Nombre	Enunciado	Justificación	Implicaciones
Captura única	Cada dato se ingresa una vez y se reutiliza	El tipeo duplicado es el 38 % del tiempo del back office	Integrar con prestadores; extracción automática de boletas
Estado visible	Todo proceso expone su estado a quien lo inició	El silencio genera 2,3 llamadas por solicitud	Eventos de estado publicados; canales de notificación
Reglas explícitas	Las reglas de cobertura viven en un motor, no en las personas	Los rechazos dependen del analista que toca el caso	Motor de reglas; catálogo de coberturas gobernado
Canal neutral	El asegurado elige el canal; el proceso es el mismo	62 % presencial hoy; no todos migrarán	Sucursal y app sobre el mismo backend

Stakeholders y concerns

Stakeholder	Concern	Vista que lo responde
Gerencia general	Reducir costo operativo y mejorar NPS	Roadmap y métricas
Gerencia de operaciones	Volumen del back office y retrabajo	Value stream y mapa de capacidades
Asegurados	Saber qué falta y en qué estado está	Journey objetivo
Prestadores	No agregar carga administrativa	Modelo de integración
Cumplimiento	Trazabilidad y protección de datos de salud	Arquitectura de datos y seguridad
TI	No tocar el core de seguros en este ciclo	Arquitectura de aplicaciones

Business Scenario

Elemento	Contenido
Problema	Rechazos tardíos por completitud y falta de visibilidad del estado
Entorno	Core de seguros heredado, 420 prestadores con sistemas heterogéneos, regulación de datos de salud
Actores humanos	Asegurado, analista, ejecutivo de sucursal, contacto administrativo del prestador
Actores de cómputo	Core de seguros, motor de reglas, servicio de extracción de documentos, canal digital, sucursal
Resultado deseado	Solicitud completa al primer intento en el 90 % de los casos; reembolso en menos de 7 días

Capability Assessment

Capacidad	Madurez actual	Madurez objetivo	Brecha
Recepción de solicitudes	Manual, presencial y postal	Digital con validación previa	Alta
Validación de completitud	En la cabeza del analista	Automática con motor de reglas	Alta
Extracción de datos de documentos	Tipeo manual	Extracción automática con revisión por excepción	Alta
Seguimiento de estado	Solo por call center	Eventos y notificaciones proactivas	Media
Integración con prestadores	Inexistente	Recepción de boletas electrónicas de prestadores grandes	Media
Pago	Transferencia por lote semanal	Transferencia diaria	Baja

18.5 Desarrollar: idear y prototipar

Conceptos generados

Concepto	Responde a HMW	Esfuerzo estimado	Valor estimado
Checklist dinámico por cobertura antes de enviar	1	Bajo	Alto
Reembolso por foto con extracción automática	2	Alto	Alto
Integración directa con prestadores grandes	2	Alto	Medio
Línea de tiempo del estado en la app y por mensaje	3	Medio	Alto
Prevalidación en sucursal con tablet	1	Bajo	Medio
Chat de dudas con el analista	3	Medio	Bajo

quadrantChart
    title Priorización de conceptos
    x-axis Bajo esfuerzo --> Alto esfuerzo
    y-axis Bajo valor --> Alto valor
    quadrant-1 Planificar
    quadrant-2 Hacer primero
    quadrant-3 Descartar
    quadrant-4 Reconsiderar
    Checklist dinamico: [0.2, 0.85]
    Reembolso por foto: [0.8, 0.9]
    Integracion prestadores: [0.85, 0.55]
    Linea de tiempo del estado: [0.45, 0.8]
    Prevalidacion en sucursal: [0.25, 0.5]
    Chat con analista: [0.5, 0.25]

Prototipo Wizard of Oz: reembolso por foto

Antes de invertir en extracción automática, el equipo probó la experiencia con un prototipo donde la “automatización” era una persona detrás.

Elemento	Implementación del prototipo
Interfaz	Formulario web con carga de fotos y checklist por cobertura
Extracción	Un analista tipeaba los datos en menos de 10 minutos y los devolvía a la pantalla
Validación	Motor de reglas simulado con una planilla
Estado	Mensajes enviados a mano siguiendo un guion
Participantes	5 asegurados con un reembolso real pendiente

Resultados del test

Participante	Completó sin ayuda	Tiempo	Observación clave
1	Sí	6 min	Preguntó si la foto “servía” como original
2	Sí	4 min	Valoró el checklist; no leyó el mensaje de estado
3	No	11 min	Foto borrosa; el sistema no avisó hasta el final
4	Sí	5 min	Pidió guardar a medias para terminar después
5	Sí	7 min	Desconfió de que el depósito fuera real sin un comprobante

Requisitos derivados del test y registrados en Gestión de Requisitos:

Validar calidad de la foto en el momento de la captura.
Permitir guardar una solicitud incompleta.
Emitir comprobante de recepción con número de solicitud.
Confirmar explícitamente que la foto reemplaza al documento físico.

18.6 Arquitecturas de negocio, sistemas de información y tecnología

Mapa de capacidades

flowchart TD
    subgraph Cliente["Gestión del asegurado"]
        C1["Gestión de coberturas"]
        C2["Comunicación con el asegurado"]
    end
    subgraph Reembolso["Gestión de reembolsos"]
        R1["Recepción de solicitudes"]
        R2["Validación de completitud"]
        R3["Extracción de datos"]
        R4["Evaluación de cobertura"]
        R5["Liquidación y pago"]
        R6["Seguimiento de estado"]
    end
    subgraph Red["Gestión de prestadores"]
        P1["Convenios"]
        P2["Integración de boletas"]
    end
    subgraph Soporte["Soporte"]
        S1["Gestión documental"]
        S2["Cumplimiento y auditoría"]
    end

Value stream: del gasto al reembolso

Etapa	Stakeholder	Valor entregado	Capacidades habilitantes
Registrar el gasto	Asegurado	Solicitud iniciada con datos del prestador	Recepción, integración de boletas
Completar la solicitud	Asegurado	Certeza de que está completa	Validación de completitud, gestión de coberturas
Evaluar	Analista	Decisión fundada en reglas explícitas	Extracción de datos, evaluación de cobertura
Pagar	Asegurado	Dinero en cuenta	Liquidación y pago
Informar	Asegurado	Estado conocido en cada paso	Seguimiento de estado, comunicación

Brechas por dominio

Dominio	Línea base	Objetivo	Brecha
Datos	Boletas en papel; catálogo de coberturas en documentos Word	Boleta como dato estructurado; catálogo de coberturas gobernado en el motor de reglas	Modelo de boleta; migración del catálogo
Datos	Sin registro de eventos de estado	Registro de eventos por solicitud	Diseñar el flujo de eventos
Aplicaciones	Core de seguros con liquidación; sin front digital	Canal digital, servicio de extracción, motor de reglas, servicio de notificaciones; core sin cambios	Cuatro componentes nuevos; integración por API con el core
Aplicaciones	Sucursal usa el core directamente	Sucursal usa el mismo canal que el asegurado	Reemplazar pantalla de sucursal
Tecnología	Servidores propios; sin plataforma de integración	Plataforma de integración y almacenamiento de documentos con cifrado	Adoptar plataforma de integración; almacenamiento conforme a datos de salud
Tecnología	Sin observabilidad de procesos	Tablero de estado del proceso	Instrumentar eventos

flowchart LR
    App["Canal digital y sucursal"] --> API["Plataforma de integración"]
    API --> Ext["Servicio de extracción de documentos"]
    API --> Reglas["Motor de reglas de cobertura"]
    API --> Estado["Servicio de eventos y notificaciones"]
    API --> Core["Core de seguros"]
    Prest["Prestadores grandes"] --> API
    Ext --> Doc[("Almacén de documentos cifrado")]
    Estado --> Asegurado["Asegurado"]

18.7 Oportunidades, soluciones y roadmap

Work packages

Work package	Brechas que cierra	Depende de	Prototipo que lo respalda
WP1 Checklist dinámico y recepción digital	Recepción, validación básica	Ninguno	Checklist del prototipo
WP2 Motor de reglas y catálogo gobernado	Evaluación de cobertura, catálogo	WP1	Planilla simulada del prototipo
WP3 Eventos de estado y notificaciones	Seguimiento, comunicación	WP1	Guion de mensajes del prototipo
WP4 Extracción de documentos	Tipeo del analista	WP1, almacén de documentos	Wizard of Oz
WP5 Plataforma de integración y almacén cifrado	Tecnología	Ninguno	No aplica
WP6 Integración con prestadores grandes	Captura única	WP5, WP4	No validado aún
WP7 Sucursal sobre el canal común	Canal neutral	WP1	No aplica

Arquitecturas de transición

Transición	Contenido	Resultado visible
T1	WP5, WP1, WP7	Solicitud digital y en sucursal con checklist; analista sigue tipeando
T2	WP2, WP3	Rechazos por reglas explícitas; estado visible sin llamar
T3	WP4, WP6	Sin tipeo; boletas de prestadores grandes llegan solas

gantt
    title Roadmap de 18 meses
    dateFormat YYYY-MM
    axisFormat %b %Y
    section Transición 1
    WP5 Plataforma e integración   :w5, 2026-11, 3M
    WP1 Checklist y recepción      :w1, 2026-12, 3M
    WP7 Sucursal canal común       :w7, 2027-02, 2M
    T1 en producción               :milestone, t1, 2027-04, 0d
    section Transición 2
    WP2 Motor de reglas            :w2, 2027-03, 4M
    WP3 Eventos y notificaciones   :w3, 2027-04, 3M
    T2 en producción               :milestone, t2, 2027-07, 0d
    section Transición 3
    WP4 Extracción de documentos   :w4, 2027-06, 5M
    WP6 Integración prestadores    :w6, 2027-09, 5M
    T3 en producción               :milestone, t3, 2028-02, 0d

18.8 Gobernanza de implementación y gestión del cambio

Architecture Contract de la transición 1

Criterio	Tipo	Verificación
El canal digital y la sucursal usan la misma API de recepción	Técnico	Revisión de diseño
Ninguna solicitud se envía sin pasar el checklist de su cobertura	Experiencia	Test de usabilidad con 5 asegurados
El asegurado recibe comprobante con número de solicitud	Experiencia	Prueba de aceptación
Los documentos se almacenan cifrados y con trazabilidad de acceso	Cumplimiento	Auditoría interna
Una solicitud incompleta se puede guardar y retomar	Experiencia	Prueba de aceptación
Existe plan de adopción para ejecutivos de sucursal	Cambio	Entregable revisado por operaciones

Revisión de conformidad

Punto de control	Momento	Resultado esperado
Revisión de diseño	Antes de desarrollar	Diseño alineado con el contrato
Revisión previa a producción	Antes del despliegue	Criterios de experiencia y cumplimiento verificados
Revisión posterior	60 días en producción	Métricas comparadas con la línea base

Métricas de impacto

Métrica	Línea base	Meta T1	Meta T2	Meta T3
Tiempo total de reembolso (días)	18 a 35	14	9	5
Rechazo en primera presentación	23 %	12 %	7 %	5 %
Solicitudes incompletas al llegar	41 %	15 %	8 %	5 %
Llamadas al call center por solicitud	2,3	1,5	0,5	0,3
Tiempo del analista en tipeo y completitud	38 %	30 %	25 %	8 %
NPS del proceso de reembolso	12	25	40	50

La fase H usa estas métricas para decidir si el siguiente ciclo del ADM se abre con un nuevo diamante del problema (por ejemplo, si la integración con prestadores no reduce el tipeo como se esperaba) o con ajustes dentro del segundo diamante.

18.9 Lecciones aprendidas

El brief inicial pedía un canal; la investigación mostró que el problema era la entrada incompleta y la falta de visibilidad. Sin el primer diamante, el proyecto habría construido una app que reproducía los rechazos.
El prototipo Wizard of Oz permitió comprometer el WP4, el más costoso, con evidencia de que la experiencia funcionaba antes de evaluar proveedores de extracción.
Los principios de arquitectura se redactaron después de la investigación y por eso tienen justificaciones cuantificadas.
La restricción de no tocar el core de seguros, declarada desde el brief, orientó la arquitectura de aplicaciones hacia componentes periféricos integrados por API.
La Gestión de Requisitos recibió requisitos del test de usuarios en la misma semana en que el equipo de arquitectura trabajaba la fase C, sin esperar a cerrar ninguna fase.

18.10 Plantilla reutilizable

Orden de artefactos para replicar el caso en otra organización:

Brief inicial tal como llega, con sus vacíos marcados.
Plan de investigación por segmento.
Mapas de empatía por actor humano.
Journey map actual con dolores cuantificados.
Point of View.
Preguntas How Might We.
Design brief con principios de diseño y métricas.
Principios de arquitectura con justificación e implicaciones.
Stakeholders y concerns.
Business Scenario.
Capability Assessment.
Conceptos priorizados en una matriz esfuerzo y valor.
Prototipo y resultados del test con requisitos derivados.
Mapa de capacidades y value stream.
Brechas por dominio de datos, aplicaciones y tecnología.
Work packages con dependencias y prototipo que los respalda.
Arquitecturas de transición y roadmap.
Architecture Contract con criterios técnicos, de experiencia, de cumplimiento y de cambio.
Plan de revisiones de conformidad.
Métricas de impacto con línea base y metas por transición.

Ejercicio práctico

Elige un proceso de tu organización que hoy tenga rechazos, retrabajo o esperas sin información. Escribe el brief tal como lo pediría la gerencia, en una frase.
Diseña un plan de investigación con al menos tres segmentos de personas y una técnica por segmento.
Construye el journey map actual y cuantifica al menos tres dolores con datos que puedas obtener en una semana.
Redacta el POV, tres HMW y el design brief con principios de diseño y métricas.
Escribe cuatro principios de arquitectura con justificación tomada de la investigación.
Propón seis conceptos, ubícalos en la matriz esfuerzo y valor y define un prototipo de baja fidelidad para el de mayor valor.
Lista las brechas por dominio, agrúpalas en work packages y dibuja un roadmap con al menos dos transiciones.
Redacta un Architecture Contract con un criterio de cada tipo y una tabla de métricas con línea base y metas.

Autoevaluación

¿Qué reveló el primer diamante respecto del brief inicial de Salud Austral?
- A. Que el canal móvil era la causa principal de los rechazos
- B. Que el problema estaba en la entrada incompleta y la falta de visibilidad, no en el canal
- C. Que el core de seguros debía reemplazarse
- D. Que los prestadores no querían participar
¿Para qué sirvió el prototipo Wizard of Oz en este caso?
- A. Para medir el rendimiento del servicio de extracción automática
- B. Para entrenar a los analistas en el nuevo sistema
- C. Para seleccionar al proveedor de la plataforma de integración
- D. Para validar la experiencia del reembolso por foto antes de comprometer el work package más costoso
¿Qué principio de arquitectura se derivó del dato de que el 38 % del tiempo del analista era tipeo y revisión de completitud?
- A. Captura única
- B. Canal neutral
- C. Estado visible
- D. Reglas explícitas
¿Qué entrega la transición T2 en el roadmap?
- A. Solicitud digital con checklist y analista que sigue tipeando
- B. Boletas de prestadores grandes que llegan sin intervención
- C. Rechazos basados en reglas explícitas y estado visible sin llamar
- D. Reemplazo del core de seguros

Respuestas

B. La investigación cuantificó que el 41 % de las solicitudes llegaban incompletas y que el silencio generaba 2,3 llamadas por solicitud; el canal era un síntoma.
D. El prototipo con una persona detrás permitió observar a cinco asegurados usando la experiencia y derivar requisitos antes de invertir en extracción automática.
A. El principio de captura única se justifica directamente con el dato del tipeo duplicado y lleva a la extracción automática y la integración con prestadores.
C. T2 agrupa el motor de reglas (WP2) y los eventos de estado con notificaciones (WP3).

Checklist

Reconozco los vacíos de un brief inicial antes de aceptarlo.
Puedo construir un journey map con dolores cuantificados.
Sé derivar principios de arquitectura con justificación desde la investigación.
Puedo diseñar un prototipo Wizard of Oz y convertir sus resultados en requisitos.
Sé agrupar brechas en work packages y transiciones con un roadmap.
Puedo redactar un Architecture Contract con criterios de experiencia y métricas con línea base.