Diagnóstico AS-IS Workmed_

Síntesis ejecutiva del levantamiento de los 7 procesos de negocio + 1 anexo de plataformas TI, con hallazgos transversales, reglas cross-proceso, KPIs consolidados, contradicciones documentadas y recomendación estratégica. Producto del trabajo de campo entre el 7 y el 23 de abril 2026 (11 sesiones, ~25 horas).

$ cat ./recomendacion-estrategica.md#tesis

TI Sovereignty abre el Bloque B: Workmed empodera a su equipo TI con control directo sobre su infraestructura cloud, su propia plataforma central y la gobernanza de los datos (cuenta AWS Workmed propia ya decidida, FlowMed 2.0, Identity Service, GitHub de Workmed) — dejando atrás la dependencia del partner Secall y los puntos únicos de falla. Esta sección consolida la tesis, el problema raíz y por qué la sovereignty habilita todo lo demás (saneamiento de procesos, BPO, Growth 7,5×, compliance Ley 21.719).

Tesis · TI Sovereignty

Síntesis ejecutiva de la posición que cierra la fase AS-IS y abre la fase de diseño TO-BE. La lectura cruzada de los 10 dolores cross-proceso, las 11 contradicciones y los puntos únicos de falla identificados en el diagnóstico no converge en una palanca de negocio: converge en una palanca arquitectónica. La tesis que se propone aquí no es un cambio de modelo comercial — es un cambio de quién controla el core.

Tesis · TI Sovereignty

Workmed empodera a su equipo TI (8-10 personas, área <3 años [EcosistemaTI-20260415 36:49]) con control directo sobre su infraestructura cloud, su propia plataforma central y la gobernanza de los datos que circulan por ella — FlowMed 2.0 sobre la cuenta AWS Workmed propia ya decidida [Plataformas-20260420 18:14, 42:10, 1:03:20] — que reemplaza al partner-as-bottleneck (Secall, hoy gatekeeper técnico de la BD productiva FlowMed en AWS RDS sin contrato formal de encargo verificable) y elimina los puntos críticos actuales: la cuenta genérica compartida sobre AWS RDS (Eduardo + Rodrigo + Ignacio + ¿otros?) sin trazabilidad por persona [Recaudacion-20260423 1:25:32, 1:38:42] y el script Python en GitHub personal de Rodrigo Llancao [Recaudacion-20260423 1:15:49, 1:30:35]. El equipo TI deja de ser cliente de partners externos y pasa a ser dueño de la plataforma y de los datos que la habitan; sólo así sanear los procesos, mitigar dolores y abrir la visión TO-BE (Agentes IA + Orquestador) tiene base estable.

Este diagnóstico nació como prerrequisito del proyecto Orquestador de Transformación Digital de Workmed — la visión TO-BE con agentes IA + orquestación de procesos. La conclusión central es que el Orquestador no puede arrancar sobre la operación actual: los dolores estructurales de TI son la frontera que primero hay que cruzar.

La tesis se sostiene en una sola idea fuerza: antes de cualquier salto a la visión TO-BE (Agentes IA + Orquestador), la prioridad es mitigar dolores en cada proceso ya identificados en el AS-IS. La TI Sovereignty es la base sobre la que todo lo demás se construye. El crecimiento volumétrico y los modelos contractuales avanzados (BPO outcome-based, planes anuales) emergen como consecuencia natural del saneamiento — no requieren ser tracks propios del roadmap; se activan cuando el comité comercial detecta apetito del mercado y la base técnica está lista.

Las dos caras de la TI Sovereignty: control técnico y gobernanza de datos

La sovereignty se descompone en dos capas inseparables. La primera es control técnico: cuenta AWS Workmed propia, FlowMed 2.0 estrangulando al legacy administrado por Secall, Identity Service como primer microservicio, GitHub de Workmed como repo canónico del script Python, accesos AWS RDS distribuidos. Es lo que el comité ejecutivo ya autorizó y lo que Carolina Araya describió como "acelerador máximo" [Plataformas-20260420 1:01:32, 1:04:16].

La segunda es gobernanza de datos: data stewards por dominio (identidad, pricing, catálogo, dashboards, datos clínicos), comité de cambios, política de versionado, inventario de tratamientos de datos personales, DPO designado y log auditable. Es la capa que el AS-IS revela como ausente — María Ignacia la nombra explícitamente desde Operaciones: "datos en silos: cada área inventó su propia captura, sin gobernanza" [Operaciones-20260407 51:32, 52:19]. El resto de los hallazgos transversales son síntomas de esta misma capa faltante: identidad fragmentada en 4 sistemas sin owner canónico [§hallazgo 1], catálogo de prestaciones que cambia silenciosamente y se detecta a 3-4 meses [§hallazgo 9], modelo de datos FlowMed no documentado [§hallazgo 10], cuentas Power BI compartidas sin auditoría, módulo de valorización abandonado "porque la persona que lo validaba rotó de cargo varias veces; nunca se llegó a validar si calculaba bien" [Recaudacion-20260423 38:29, 41:43, 42:13] — gobernanza pura, no técnica.

Por qué importa que sean inseparables: el control técnico sin gobernanza es vacío. Una plataforma propia sin comité de cambios, sin owners formales, sin políticas de versionado y sin DPO hereda los mismos dolores con stack nuevo. Los tres fracasos previos (NetSuite, HubSpot↔FlowMed 2024, módulo de valorización abandonado) tienen un denominador común no nombrado en su momento: gobernanza ausente sobre quién decide, quién valida, quién aprueba el cierre. Si FlowMed 2.0 sale al Mes 6 sin esa capa, el patrón se repite. Por eso la gobernanza de datos no es un pilar paralelo a la sovereignty: es la capa interna sin la cual la sovereignty se queda en cambio de stack.

La gobernanza es además lo que vuelve ejecutable el compliance regulatorio. La Ley 21.719 (vigencia 1 dic 2026) exige consentimiento granular, base legal explícita por tratamiento, inventario de tratamientos y un DPO formal — todo eso es gobernanza, no infraestructura. La triple norma ISO (junio 2026: 9001 + 14001 + 45001) exige control documental, trazabilidad y auditorías — todo eso es gobernanza, no infraestructura. Sin la capa de gobernanza, las dos auditorías se hacen sobre arena.

Problema raíz

El problema de Workmed no es operativo: es estructural y dependiente de terceros. Hoy la operación se sostiene sobre una arquitectura cuyo núcleo Workmed no controla y cuyos puntos críticos viven en personas individuales. La identidad del cliente vive fragmentada en 3-4 sistemas (FlowMed, HubSpot, Defontana, Power Platform) sin sincronización; el trabajador no tiene MPI; el mismo paciente se evalúa "como si fuera nuevo" 3-4 veces [§3 dolor 1 mapa-cruzado; Finanzas-20260416 11:13, 11:40; Agendamiento-20260413 11:48; Recaudacion-20260423 1:38:13]. La sección más larga del script Python de valorización no calcula descuentos: depura variantes del mismo RUT [§5.6 mapa-cruzado; Recaudacion-20260423 1:30:35].

A esto se suman dos puntos únicos de falla que ningún roadmap puede esquivar. Eduardo González es el único gatekeeper del acceso a la base AWS RDS sobre la que corre toda la valorización [§6.3 mapa-cruzado; Recaudacion-20260423 1:25:32, 1:38:42]; el script Python de pricing (~2.553 líneas) vivía en el GitHub personal de Rodrigo Llancao y aún está en migración a GitHub de Workmed [§5 08 riesgo 2; Recaudacion-20260423 1:15:49, 1:30:35; Finanzas-20260416 45:17]. Una caída de cualquiera de los dos detiene la cadena de cobro completa.

El partner del core es la otra pata estructural del problema. FlowMed no expone API genérica — sólo integraciones partner punto a punto [§5 08 dolor 6; Plataformas-20260420 35:00, 35:23] — y el soporte de Secall responde "2 semanas a 1 mes, a veces nunca" para incorporar formularios nuevos [Agendamiento-20260413 27:58, 44:28]. Workmed no tiene administración del software del core [EcosistemaTI-20260415 36:49, 38:38]. El FlowMed legacy ya muestra lentitud creciente — tiempos de procesamiento degradados a 20-25 min para nóminas grandes vs ~5 min normal [§6.7 mapa-cruzado; Agendamiento-20260413 41:08, 40:40] — y la regla "todo o nada" del agendamiento [§5.1 mapa-cruzado; Agendamiento-20260413 22:25] sólo se rompe modificando el módulo, lo que hoy depende exclusivamente de Patricia Maturana + soporte Secall errático.

El patrón histórico confirma el diagnóstico. Workmed ha intentado tres veces saltarse la sovereignty — NetSuite, intento HubSpot↔FlowMed 2024, módulo de valorización abandonado hace ~6 meses [Finanzas-20260416 37:26, 39:06; Agendamiento-20260413 47:19, 47:48; Recaudacion-20260423 38:29, 41:43]. Las tres iniciativas fracasaron como big-bangs. La iniciativa de valorización en FlowMed nunca se llegó a validar si calculaba bien por rotación del validador [§5 08 dolor 3; Recaudacion-20260423 38:58]. La sovereignty no es preferencia estética: es la lección destilada del propio AS-IS.

A esto se suma el deadline regulatorio. La Ley 21.719 entra en vigencia el 1 de diciembre de 2026 con 6 meses para cumplir [§5 08 riesgo 4; EcosistemaTI-20260415 43:39, 44:05] y la triple norma ISO tiene deadline junio 2026 [Flowmed-20260409 30:52; EcosistemaTI-20260415 42:40]. La réplica AWS RDS con datos clínicos asociables es vulnerabilidad bajo la nueva ley. Cada uno de los 10 puntos converge en la misma raíz: Workmed no controla su propio core. Sanear la operación sin antes resolver eso es construir sobre arena.

Por qué TI Sovereignty habilita todo lo demás

La sovereignty no es un fin en sí mismo; es la condición de posibilidad para los siguientes movimientos. Cada palanca que el comité ejecutivo tenga sobre la mesa — saneamiento de procesos, compliance regulatorio, agentes IA orquestados (visión TO-BE), crecimiento volumétrico, modelos contractuales avanzados como consecuencia natural — exige primero que Workmed controle la plataforma sobre la que esas palancas se apalancan.

Sanear procesos requiere control sobre la plataforma

Ejemplo concreto: la regla "todo o nada" en agendamiento [§5.1 mapa-cruzado; Agendamiento-20260413 22:25] sólo se rompe modificando el módulo de carga. Hoy esa modificación depende exclusivamente de Patricia Maturana + soporte Secall ("2 semanas a nunca" [Agendamiento-20260413 27:58]). Sin sovereignty no hay timeline ejecutable para este quick win, ni para ninguno de los otros que el AS-IS identifica. La promesa de "mitigar los 10 dolores cross-proceso" es vacía mientras el equipo TI Workmed siga siendo cliente del partner.

Crecimiento y modelos contractuales avanzados como consecuencia natural

Un eventual contrato "% aptitud vigente >95%" exige plataforma propia con alertas de vencimiento al trabajador y al cliente — alertas que hoy no existen en FlowMed [§5 08 dolores cross; Flowmed-20260409 45:44, 46:10]. Sobre el legacy administrado por Secall, el SLA es ficticio y el cliente lo descubre en el primer cierre. Igualmente, multiplicar volumen por 7,5× (de ~400/día a ~3000/día) sobre el legacy con "lentitud creciente" [§6.7 mapa-cruzado; Agendamiento-20260413 41:08] no tiene mecanismo de respuesta — Secall no escala con el cliente. Ambos movimientos surgen automáticamente cuando la sovereignty está en su lugar: con FlowMed 2.0 + Identity Service + gobernanza, cuando comercial detecte apetito del mercado para BPO outcome-based o un cliente top requiera capacidad volumétrica, la base técnica ya lo permite. Por eso no son tracks propios del roadmap: son consecuencia natural del saneamiento.

Compliance Ley 21.719 requiere control sobre el dato y gobernanza formal

La Ley 21.719 entra en vigencia el 1 dic 2026 con 6 meses para cumplir [§5.3 mapa-cruzado; Flowmed-20260409 30:02; EcosistemaTI-20260415 42:12]. La réplica AWS RDS con datos clínicos asociables es vulnerabilidad bajo la nueva ley [§5 08 riesgo 4; EcosistemaTI-20260415 43:39, 44:05]. El Identity Service centraliza el consentimiento granular hoy disperso y permite anonimización selectiva [§Compromisos 5.8 mapa-cruzado; EcosistemaTI-20260415 41:46, 42:12]. Pero el Identity Service por sí solo no basta: la ley exige además DPO designado, inventario de tratamientos, base legal explícita y log auditable — todos elementos de la capa de gobernanza (B.6). Sin sovereignty + gobernanza, el deadline regulatorio sólo se cumple "a punta de papel" con parches por sistema y trazabilidad endeble. Con ambas, el cumplimiento se vuelve subproducto del roadmap.

Agentes IA orquestados requieren plataforma propia

Pre-informe IA con doble contraloría humana, agentes conversacionales sobre datos clínicos, orquestadores que coordinen el flujo agendamiento → contraloría → EDP — todos exigen acceso programático al núcleo. Hoy "no hay como una API de FlowMed" [§5 08 dolor 6; Plataformas-20260420 35:00] y los desarrollos internos se hacen contra la réplica AWS que el equipo TI ya consume con permiso explícito. Sin sovereignty, cualquier agente IA queda como anexo que vive afuera del core; con sovereignty, el agente es ciudadano de primera clase del stack.

Cierre. Antes de cualquier salto a la visión TO-BE (Agentes IA + Orquestador), la prioridad es mitigar dolores en cada proceso ya identificados en el AS-IS. La TI Sovereignty es la base sobre la que todo lo demás se construye. El crecimiento volumétrico y los modelos contractuales avanzados emergen como consecuencia natural del saneamiento, sin necesitar tracks propios del roadmap.

$ awk -F'|' '/recomendacion/' ./recomendacion-estrategica.md

La tesis baja a operación en esta matriz impacto vs esfuerzo con 18 recomendaciones organizadas en 4 cuadrantes — Quick wins (alto impacto, bajo esfuerzo) · Big bets (alto impacto, alto esfuerzo) · Fill-ins (bajo impacto, bajo esfuerzo) · Hard slogs (bajo impacto, alto esfuerzo). Cada recomendación aterriza los 10 dolores cross-proceso, las 11 contradicciones documentadas y los hallazgos por proceso 01-08.

Recomendaciones priorizadas · matriz impacto vs esfuerzo

La tesis TI Sovereignty (sección anterior) baja a operación en esta matriz. Cada recomendación es una acción concreta derivada del AS-IS, organizada en 4 cuadrantes según el binomio impacto operativo × esfuerzo de implementación. El propósito es mostrar el menú priorizado que aterriza los 10 dolores cross-proceso, las 11 contradicciones y los hallazgos por proceso identificados en el AS-IS — para que la sovereignty no quede como abstracción sino como lista ejecutable con propietarios sugeridos.

El eje impacto mide cuántos procesos toca cada acción, si bloquea decisiones aguas abajo y la magnitud económica declarada cuando existe. El eje esfuerzo mide CAPEX, dependencias técnicas, renegociación contractual y semanas de equipo. Los 4 cuadrantes ordenan ~18 acciones priorizadas (4 Quick Wins + 8 Big Bets + 3 Fill-ins + 3 Hard Slogs): Quick wins se ejecutan en Fase 1, Big bets arrancan en Fase 2, Fill-ins son mejoras puntuales con dueños cercanos, Hard slogs se descartan o se posponen indefinidamente.

Quick wins · alto impacto, bajo esfuerzo (Cuadrante A)

Acciones ejecutables en <90 días con recursos actuales. Cada una mitiga un dolor identificado en el AS-IS y abre espacio operativo para que las Big bets de Fase 2 arranquen.

Orden de ejecución sugerido: el roadmap arranca con la prioridad cero del Mes 1 (A.4 recuperación de soberanía sobre la BD clínica de FlowMed: contrato de encargo con Secall + acceso administrativo paralelo + individualizar credenciales) — sin esto, las demás corren sobre soberanía cedida. En paralelo: el ambiente de desarrollo ya en marcha (A.1, base de todas las demás), la palanca de mayor impacto upstream + diferenciador estratégico (A.2 Portal del Cliente fase 1, primer entregable del canal directo con la mandante), y la acción mediana que descarga operación diaria (A.3 pipeline). El bloqueo formal de doble contraloría que en versiones anteriores aparecía como Quick Win independiente queda subsumido en B.4 (Secall ya tiene compromiso de entrega).

A.1 Onboarding de EMERCOM + Ambiente de desarrollo Workmed-Tech (en marcha)

Workmed ya está construyendo el ambiente sobre el que se ejecuta toda la sovereignty: cuenta AWS Workmed propia operativa (decisión cerrada [Plataformas-20260420 18:14, 42:10, 1:03:20]); GitHub de Workmed como organización corporativa activa con la migración del script Python (~2.553 líneas) en proceso con Christian Urbina [Recaudacion-20260423 1:15:49, 1:30:35, 1:38:42]; Eduardo + Rodrigo con responsabilidad operativa compartida sobre el Identity Service (cierra §6.3 mapa-cruzado · Eduardo-SPOF) [Recaudacion-20260423 1:25:32, 1:38:42]; mail de acceso AWS RDS a Roberto y Barbarita pendiente de cerrar [Recaudacion-20260423 1:25:32, 1:40:40]; tooling AI-augmented (OpenCode + Claude) operativo para acelerar el desarrollo del equipo TI Workmed; Power Platform + Microsoft 365 ya en uso como capa colaborativa; EMERCOM onboarded como partner de transformación digital — equipo extendido sin contrato Secall-style.

Esta acción agrupa los hitos de continuidad y de infraestructura de desarrollo en un solo paquete, que en su mayor parte ya está ejecutado. Los pendientes (cerrar el mail de acceso AWS RDS, finalizar la migración del script al GitHub de Workmed) son trabajo administrativo en curso, no palancas estratégicas a planificar. La razón de listarla acá es que es la base sobre la que las otras 6 quick wins corren y conviene reconocerla explícitamente como hito Mes 1, no como esfuerzo a estimar. Esfuerzo: en marcha. No toca FlowMed. Owner: Carolina Araya + Eduardo + Rodrigo + Christian Urbina + EMERCOM.

A.2 Portal del Cliente — fase 1 (pre-agendamiento como servicio + plantillas canónicas)

Es el primer entregable del canal directo Workmed↔mandante (fase 1 de 2 · B.7 lo expande en Fase 2) y la palanca con mayor impacto upstream del Cuadrante A. Hoy FlowMed sí valida formato RUT (rechaza inválidos), pero el rechazo bloquea el agendamiento porque el operador no tiene herramienta para subsanar antes de cargar — los lunes "explosivos" se quedan hasta las 20:00 corrigiendo errores [Operaciones-20260407 21:23, 21:39, 44:03] y la regla "todo o nada" bota la nómina entera por un registro malo [Agendamiento-20260413 22:25]. En paralelo, el formulario Excel del cliente cambia silenciosamente y rompe la carga [§5.1 Agendamiento sub-flujo automático; §3 dolor 9 mapa-cruzado].

La solución no es duplicar validaciones dentro de FlowMed legacy (no se puede sin Secall) ni esperar al Identity Service: es construir un portal Workmed donde la empresa mandante (a) descarga la plantilla canónica versionada (sustituye la circulación informal de Excel), (b) sube su nómina y la herramienta valida en línea — RUT formato + dígito + cruce con Rectificador del Registro Civil (hoy workaround manual [01-agendamiento §6]), centros de costo, baterías existentes en catálogo, fechas, conformidad con la plantilla — y (c) corrige y reenvía hasta tener nómina limpia. Sólo entonces se carga a FlowMed.

Doble beneficio inmediato:

1. Saneamiento upstream sin tocar legacy ni esperar Identity Service — rompe el "todo o nada" en el momento de la carga, devuelve los lunes a su horario normal, desbloquea el flujo agendamiento → operaciones → contraloría → EDP de errores que hoy viajan aguas abajo.
2. Plantilla oficial versionada centralizada — fin de los cambios silenciosos en el formulario de carga.

Por qué prioridad alta: además de saneamiento upstream, A.2 es fase 1 del Portal del Cliente · B.7 lo expande en Fase 2 a a panel de deudas, costos, entrega de informes, trazabilidad y alertas de aptitud vigente. Esa expansión es el delivery channel natural de modelos contractuales avanzados activables post-sovereignty y foundation del compliance Ley 21.719. Arrancar A.2 en Fase 1 abre tracción comercial directa con la empresa mandante.

Esfuerzo: medio (1-2 meses). No toca FlowMed. Owner: Patricia Maturana + comercial + dev interno Workmed.

A.3 Módulo de Producción — fase 1

Es la fase 1 de un Módulo de Producción propio que vive sobre el ambiente Workmed-Tech (A.1) y no depende de FlowMed legacy para subsanar dolores estructurales en dos áreas: Comercial (valorización) y Contraloría (designación de médicos sobre exámenes entregados). Dos componentes:

A.3.1 Valorización automatizada de producción para Comercial. Hoy la "bajada de producción" es manual y dependiente de Ignacio: descarga la producción del día anterior, corre el script Python que normaliza y calcula sobre la "foto del día anterior", carga el resultado en Power BI [Finanzas-20260416 7:03, 43:32; Recaudacion-20260423 1:14:55; ComercialBI-20260422 1:25, 5:12]. Sobre ese dataset Comercial arma la proyección diaria vs presupuesto [Finanzas-20260416 42:39; HU-FIN-09]. Job programado nocturno que descarga producción + corre el script Python + carga el dataset al inicio de cada día hábil, sin intervención humana. Valor para Comercial: prepara la valorización automatizada durante la noche, lista al inicio del día hábil sin Ignacio manual. Hoy A.3.1 valoriza sólo la producción de los 6 centros propios con datos completos en FlowMed; los 6 acreditados quedan parcialmente cubiertos hasta que B.3 (pipeline de digitalización) carga sus exámenes estructurados a FlowMed — ahí A.3.1 valoriza los 12 con la misma lógica, sin código especial para acreditados (una sola fuente de verdad, un solo flujo de valorización). Deseable a futuro: valorización en tiempo real, lo que se materializa con B.2 FlowMed 2.0 (APIs + modelo queryable habilitan el servicio de datos operativos en tiempo real, sucesor de Power BI) — A.3.1 es el puente táctico mientras se construye el sucesor. Precondición: A.1 con migración del script al GitHub de Workmed cerrada.

A.3.2 Módulo de Contraloría — acceso unificado a exámenes y designación de médicos contralores. Hoy Vicente trabaja con dos orígenes según sucursal: SACMed/FlowMed para los 6 propios, SharePoint con digitación manual para los 6 acreditados [Contraloria-20260421 12:46, 14:58]. La designación de médicos contralores es conteo casuístico mental: "necesito que libere de cuatro, de cinco. Eso todavía no lo puedo ver" [Contraloria-20260421 25:43, 26:12]. Construir un módulo Workmed propio que acceda a ambos orígenes (FlowMed y SharePoint), unifique la vista de exámenes entregados por los centros, permita a Vicente designar a los médicos contralores disponibles y haga seguimiento de la emisión del informe final. Incluye la segmentación de pendientes por tipo de espera (cultivos 3-4 días hábiles, metales 15 días hábiles, resto bajo SLA 8h interno / 24h contractual [Contraloria-20260421 23:25, 24:15; RN-12 17:13, 17:38]). Valor para Contraloría: genera el prerequisito directo de B.4 (cola dirigida automática + pre-informe IA con doble contraloría humana). Sin un módulo unificado que vea ambas fuentes y permita designación, B.4 no tiene sustrato sobre el que operar.

A.3 no resuelve producción intra-día — A.3.1 sigue siendo foto del día anterior. Eso queda para el servicio de datos operativos sobre FlowMed 2.0 (B.2, sucesor de Power BI). La auditoría de cuentas paralelas Power BI (hoy todos entran con la misma cuenta, dashboards "dando vuelta", workaround renombrar v2.1, v3.1 [Flowmed-20260409 1:04:16, 1:06:32, 1:08:39]) no es problema técnico de A.3: se resuelve con B.6 marco de gobernanza de datos (data steward por vista + log auditable). Esfuerzo: 1-2 sprints (A.3.1) + 1-2 meses (A.3.2). No toca FlowMed. Owner: Rodrigo Llancao + Ignacio Ahumada + Vicente Rivano + dev interno Workmed.

A.4 Recuperación de soberanía sobre la BD clínica de FlowMed (Mes 1 · prioridad cero)

La acción crítica del Mes 1 con tres componentes simultáneos:

1. Contrato de encargo de tratamiento de datos con Secall — cláusulas mínimas exigibles bajo Ley 19.628 vigente y Ley 21.719 (vigencia 1-dic-2026): finalidades autorizadas, medidas de seguridad, prohibición de subencargados, plazo de conservación, devolución/destrucción al término, derecho de auditoría por Workmed.
2. Acceso administrativo paralelo Workmed sobre AWS RDS — Workmed deja de depender de Secall para cualquier cambio de IAM, configuración de red o auditoría sobre la BD productiva.
3. Individualizar credenciales con MFA + cerrar la cuenta genérica compartida (Eduardo + Rodrigo + Ignacio + ¿otros? + posiblemente personal de Secall) — cada persona con cuenta nominativa y log auditable.

Cierra simultáneamente: S1 (BD clon expuesta a internet), S2 (conexiones MySQL/Postgres sin cifrado), S4 (cuenta única compartida en RDS), I1 (Secall gatekeeper técnico real), C3 (réplica caliente con detalle clínico) y C4 (Secall procesa datos sensibles sin contrato formal de encargo).

Sin esto, A.1, B.1 y B.2 corren sobre soberanía cedida — son aspiracionales. Esfuerzo: medio-alto (30 días, paralelo entre tracks técnico y contractual). Owner: Juan Pablo Coustasse (CFO · contractual) + Eduardo González (técnico) + Christian Urbina + Asesoría Legal + DPO por designar.

Nota — el bloqueo formal de doble contraloría en FlowMed que en versiones anteriores aparecía como A.4 queda subsumido en B.4 (cola dirigida + pre-informe IA · doble contraloría humana). Secall ya tiene fecha de entrega comprometida [Contraloria-20260421 16:44]; no requiere track propio.

Big bets · alto impacto, alto esfuerzo (Cuadrante B)

Palancas estratégicas que arrancan en Fase 2 y materializan la TI Sovereignty. No son rapidez; son magnitud y profundidad. Cada una cierra simultáneamente varios dolores del Top 10 y abre las opciones de monetización post-sovereignty.

B.1 Workmed Identity Service como primer microservicio de FlowMed 2.0

Microservicio acotado (worker + client + APIs de lectura) sobre la cuenta AWS Workmed propia ya decidida [§Decisiones 08-plataformas-ti; Plataformas-20260420 18:14, 42:10, 1:03:20]. Elimina la necesidad del script Python de depuración de RUTs (~50% del script de Rodrigo) [Recaudacion-20260423 1:30:35, 1:31:02]: Workmed Identity Service + FlowMed 2.0 subsanan la problemática en origen — la identidad se valida y normaliza al ingreso, no se depura aguas abajo. Cierra simultáneamente: identidad fragmentada en 4 sistemas [§3 dolor 1 mapa-cruzado], lunes correctivos [§3 dolor 6 mapa-cruzado], frontera de la nueva Ley 21.719 [§5.3 mapa-cruzado; Flowmed-20260409 30:02; EcosistemaTI-20260415 42:12]. Es el primer entregable concreto de la TI Sovereignty. Owners: Eduardo González (líder técnico) + Rodrigo Llancao · responsabilidad operativa compartida.

B.2 FlowMed 2.0 sobre AWS Workmed propia, control end-to-end del equipo TI

Reemplazo del FlowMed legacy administrado por Secall (sin API genérica [§5 08 dolor 6; Plataformas-20260420 35:00, 35:23], "lentitud creciente" [Agendamiento-20260413 41:08, 40:40], soporte errático "2 semanas a nunca" [Agendamiento-20260413 27:58]). Decisión arquitectónica ya tomada por Carolina Araya ("acelerador máximo" [Plataformas-20260420 1:01:32, 1:04:16]). El equipo TI Workmed (8-10 personas, área <3 años [EcosistemaTI-20260415 36:49]) deja de ser cliente de Secall y pasa a ser dueño de la plataforma. Permite mitigar el "todo o nada" de carga de nómina [Agendamiento-20260413 22:25] modificando el módulo sin pasar por el partner.

Deliverable derivado: servicio de datos operativos en tiempo real (sucesor de Power BI). APIs propias + modelo de datos queryable habilitan consultas en línea sobre producción, valorización, aptitud vigente y trazabilidad — sin depender del job nocturno de Ignacio (A.3.1) ni de Power BI con cuentas paralelas. Es input directo de A.3.1 (valorización en tiempo real), B.7 (panel deudas/costos/informes/trazabilidad/alertas) y B.8 (visibilidad real-time del cierre vs presupuesto). La gobernanza sobre este servicio (data steward, log auditable, política de versionado) la entrega B.6.

Owners: Carolina Araya (líder del programa) con Eduardo González + Rodrigo Llancao · responsabilidad operativa compartida.

B.3 Pipeline de digitalización y procesamiento automatizado de exámenes acreditados en la frontera Workmed

Hoy 40% de las atenciones provienen de 6 centros acreditados operativamente independientes (BestMed y otros [Operaciones-20260407 56:32, 1:02:08]) — no usan Megafy ni SACMed porque son operaciones autónomas con sus propios sistemas; cada uno entrega resultados vía OneDrive/SharePoint con sus propios formatos [§3 dolor 7 mapa-cruzado; Contraloria-20260421 12:46, 14:58]. Imponerles Megafy o SACMed no es viable: Workmed no controla su flujo interno. La promesa "FlowMed = 100%" se rompe acá [§5 08 dolor 5; EcosistemaTI-20260415 23:55, 24:25], pero el bottleneck no está en el acreditado: está en la frontera Workmed, donde los administrativos transcriben manualmente al FlowMed lo que llega de SharePoint.

Solución: pipeline de ingestión + extracción estructurada (OCR + parsing) del lado Workmed → carga a FlowMed/SACMed como única fuente de verdad, validando contra Identity Service (B.1) y catálogo. El acreditado sigue operando como hasta hoy; Workmed absorbe la variabilidad en su propia frontera digital y elimina la digitación manual interna sin bifurcar el dato. La regla arquitectónica es estricta: B.3 es ingestión, no analítica — entrega a FlowMed (legacy primero, luego 2.0) y cada downstream consume desde ahí con su lógica. Bifurcar (canal directo B.3 → finanzas, B.3 → portal) reproduciría el patrón "anexo que vive afuera" de NetSuite, módulo valorización y HubSpot↔FlowMed 2024 [Recaudacion-20260423 38:29, 41:43; Finanzas-20260416 37:26].

B.3 es palanca multi-proceso, no integración punto-a-punto. Los 4 downstream que se desbloquean simultáneamente cuando los exámenes acreditados llegan estructurados a FlowMed:

1. Contraloría → B.4 (cola dirigida + pre-informe IA): captura ya estructurada elimina la digitación masiva ("los chiquillos se vuelven locos digitando" [Contraloria-20260421 14:58, 15:27]) y habilita el routing automático por peso de batería + pre-recomendación apto/no apto sobre el 100% del volumen, no sólo el 60% propio.
2. Finanzas / EDP → A.3.1 + B.8: producción acreditados aparece en FlowMed con la misma estructura que centros propios → A.3.1 valoriza nocturno los 12 sin lógica especial → B.8 cierre contractual del mes deja de esperar transcripción manual ("atenciones de marzo aparecen en abril" [§3 dolor 5; Finanzas-20260416 7:34, 8:27]) y la fecha de corte dura (día 5 hábil) se vuelve viable. El flujo es B.3 → FlowMed → A.3.1 → cierre, no B.3 → finanzas directo: una sola fuente de verdad, A.3.1 reutiliza el flujo existente.
3. Comercial / Portal Cliente → B.7: aptitud vigente del 100% (no sólo del 60% propio) en el panel del cliente → trazabilidad end-to-end + alertas de aptitud por vencer + cumplimiento granular Ley 21.719.
4. Agendamiento → A.2: historial canónico del trabajador completo (incluye atenciones acreditados) → menos re-agendamientos redundantes y mejor experiencia upstream.

PoC en Fase 2 con 1-2 acreditados (los que entreguen formato más estable — partir por BestMed); expansión gradual en Fase 3 según calidad de la fuente. No los desafilia (alto CAPEX, baja recompensa — ver Cuadrante D); les construye una pasarela digital del lado Workmed.

Meta: 0% digitación manual en Workmed sobre exámenes acreditados — el administrativo deja de transcribir, el médico contralor recibe la captura ya estructurada, finanzas valoriza on-time, el cliente ve aptitud completa. Owner: Pablo Martínez + dev interno Workmed.

B.4 Sistema interno de cola dirigida + pre-informe IA con doble contraloría humana sostenida

Productividad médico contralor: meta declarada 6 informes/hora [§2.4 RN-10 03-contraloria-salud; Contraloria-20260421 10:47, 24:45] hoy bloqueada por dos cuellos: (a) digitación manual masiva previa al médico (40% del volumen llega de acreditados independientes vía SharePoint sin pipeline de digitalización Workmed-side [§3 dolor 7 mapa-cruzado; Contraloria-20260421 12:46, 14:58]) y (b) ausencia de distribución dirigida — Vicente lleva conteo casuístico mental porque el dashboard FlowMed no distingue peso por batería y "necesito que libere de cuatro, de cinco. Eso todavía no lo puedo ver" [Contraloria-20260421 25:43, 26:12]. Vicente declara explícitamente KPIs deseados pero no implementados: peso específico por batería, asignación de cartera por médico tipo "ejecutivo comercial", distribución dirigida tipo cola/queue [Contraloria-20260421 26:12, 30:54, 31:11, 32:10].

Solución integrada en tres componentes:

1. Sistema de tickets internos que rutea automáticamente cada caso al médico contralor disponible según peso de batería — baterías de alta complejidad (altura física + evaluación psicológica + drogas) a médicos senior, baterías más simples a médicos con disponibilidad inmediata. Reemplaza el conteo mental casuístico de Vicente por una cola/queue dirigida.
2. Sistema de apoyo al diagnóstico que pre-revisa la captura digital ya saneada por el Identity Service y FlowMed 2.0, y pre-recomienda la categoría del informe (apto / no apto / no apto transitorio) con su justificación.
3. Doble contraloría humana sostenida como invariante — el administrativo del paso 1 sigue preparando preinforme; la firma médica sigue siendo única autoridad legal para liberar [§2.4 RN-02 03-contraloria-salud; Top 10 RN-4]. El sistema asiste, no reemplaza.

PoC en Fase 2 con 100 informes y métricas rigurosas: tasa de aceptación del pre-informe IA sin cambios, tasa de errores, tiempo medio de revisión por peso de batería antes vs después, % de informes que requieren reasignación manual de Vicente. Productividad proyectada 12-15 inf/h post-PoC exitoso (combinando captura saneada + cola dirigida + pre-revisión asistida). Precondición: A.3.2 Módulo de Contraloría operando — sin acceso unificado a exámenes y designación humana sostenida, B.4 no tiene sustrato sobre el que automatizar el routing ni la pre-revisión. Owner: Vicente Rivano + Pablo Martínez.

B.5 Integración FlowMed↔HubSpot retomada sobre plataforma propia

El intento 2024 fracasó como big-bang [§3 dolor 4 mapa-cruzado; Agendamiento-20260413 47:19, 47:48]. Sobre FlowMed 2.0 con APIs propias, la integración deja de ser "anexo que vive afuera" y pasa a ser flujo nativo: el cliente que firma convenio en HubSpot existe en el Identity Service desde el día 1, y todo downstream lo consume. Owners: Eduardo + Rodrigo · responsabilidad operativa compartida + comercial.

B.6 Marco de gobernanza de datos como capa interna de la TI Sovereignty

Cierra el hallazgo transversal 11 (gobernanza ausente) y la cita explícita "datos en silos: cada área inventó su propia captura, sin gobernanza" [Operaciones-20260407 51:32, 52:19]. Sin esta capa, FlowMed 2.0 hereda los dolores con stack nuevo: la pregunta "¿quién decide cuándo cambia el catálogo? ¿quién aprueba un cambio en la regla de descuento? ¿quién cierra el mes?" sigue sin respuesta y los tres patrones de fracaso previo (NetSuite, HubSpot↔FlowMed 2024, módulo valorización abandonado por rotación del validador [Recaudacion-20260423 38:29, 41:43, 42:13]) se repiten.

Cinco entregables formalmente declarados:

1. DPO (Data Protection Officer) designado, con asesoría legal externa para Ley 21.719 (vigencia 1 dic 2026) y triple norma ISO (junio 2026). Owner del inventario de tratamientos, base legal por tratamiento, política de consentimiento granular, anonimización selectiva [§5.3 mapa-cruzado; EcosistemaTI-20260415 41:46, 42:12, 43:39, 44:05].
2. Data stewards por dominio con rol explícito (no full-time): identidad cliente/trabajador → Eduardo + Rodrigo (responsables operativos del Identity Service); pricing y reglas de descuento → Rodrigo + Ignacio + Coustasse; catálogo de prestaciones → comercial + Eduardo; modelo de datos FlowMed → Eduardo + Rodrigo; servicio de datos operativos sobre FlowMed 2.0 (sucesor de Power BI) → Rodrigo + dueño asignado por vista (auditoría de cuentas paralelas que hoy existen en Power BI, fin del "todos entran con la misma cuenta", versionado público de vistas y consultas, alimenta B.7 panel cliente); datos clínicos → DPO + Pablo Martínez (jefe médico).
3. Comité de cambios de datos con cadencia mensual mínima (o trigger-based para cambios de catálogo, regla de descuento, modelo de datos): aprueba modificaciones, deja registro, notifica a downstream. Mónica Pérez (PMO) actúa como secretaría técnica del comité — convoca sesiones, lleva la bitácora, monitorea hitos. Cierra los "cambios silenciosos" detectados a 3-4 meses [§hallazgo 9; Comercial-20260420 44:01] y el patrón de "abandonado porque rotó el validador" [Recaudacion-20260423 38:29, 41:43].
4. Políticas de versionado explícitas para catálogo de prestaciones, vistas/consultas del servicio de datos operativos (mientras Power BI sigue vigente en transición + sucesor sobre FlowMed 2.0), scripts canónicos (script Python en GitHub de Workmed por A.1), modelo de datos FlowMed. Versionado público auditable, no workarounds tipo "v2.1, v3.1" [Flowmed-20260409 1:08:39].
5. Log auditable de accesos a datos sensibles: cierra el "todos entran con la misma cuenta" de Power BI y la falta de auditoría sobre la réplica AWS RDS. Exigible por Ley 21.719 + ISO.

Por qué es Big Bet, no Quick Win: no es CAPEX alto, es ciclo organizacional. Requiere designación formal de roles, asesoría legal, redacción de políticas, instalación del comité — eso no se hace en 90 días por capacidad disponible, pero entrega antes que FlowMed 2.0 release 1 si arranca con el diseño en Fase 1. Esfuerzo: medio-alto (organizacional, no técnico). Owners: Carolina Araya (líder del programa) + Juan Pablo Coustasse (CFO, owner de compliance y contratos) + Eduardo González (líder técnico) + Mónica Pérez (PMO, secretaría técnica del comité) + asesoría legal externa para DPO.

B.7 Portal del Cliente — fase 2 (panel deudas, costos, informes, trazabilidad, alertas)

Es la expansión natural de A.2 sobre la sovereignty completa. Mientras A.2 entrega la fase 1 como Quick Win (pre-agendamiento + plantillas), B.7 lo crece en Fase 2 sobre Identity Service (B.1, consentimiento granular y identidad canónica del trabajador y mandante), FlowMed 2.0 release 1 (B.2, modelo de datos propio + servicio de datos operativos sucesor de Power BI) y marco de gobernanza (B.6, stewardship sobre los datos expuestos al cliente). Cinco capas de funcionalidad sobre el mismo portal:

1. Panel de deudas y compromisos del cliente: estado de cuenta en línea, EDPs pendientes, facturas emitidas, plazos contractuales, vencimientos. Hoy esto vive en mails y Excel manual de la Supervisora de Facturación [§5.6 mapa-cruzado; Recaudacion-20260423 11:52, 37:59] — el portal lo expone directo.
2. Visibilidad de costos: producción mensual valorizada, descuentos aplicados, mix por batería, evolución vs presupuesto. Reduce las iteraciones del ciclo EDP de 5 días [§5.2 mapa-cruzado; Recaudacion-20260423 6:06] porque el cliente ve el dato antes del envío del EDP.
3. Entrega de informes con descarga de PDF firmados: aptitud vigente por trabajador, batería, fecha de vencimiento. Foundation técnica del SLA "% aptitud vigente >95%" activable cuando comercial detecte apetito [§5.4 mapa-cruzado; Flowmed-20260409 47:11].
4. Trazabilidad end-to-end de cada examen: agendado → atendido → contraloría → informe disponible. Reduce las consultas operativas que hoy llegan a Patricia y Vicente.
5. Alertas al cliente y al trabajador de aptitud por vencer (hoy no existen en FlowMed [§5 08 dolores cross; Flowmed-20260409 45:44, 46:10]). Foundation del SLA T1 + cumplimiento granular de Ley 21.719 (consentimiento por finalidad y notificación documentada).

Subsume el ítem antes en bitácora "Portal real-time del EDP construido fuera de FlowMed 2.0 = repetiría el patrón anexo que vive afuera". La diferencia clave: B.7 está dentro de la sovereignty (sobre AWS Workmed propia + Identity Service + FlowMed 2.0 con servicio de datos operativos + B.6 gobernanza), no afuera. Por eso ya no es anexo, es ciudadano de primera clase del stack y delivery channel natural de modelos contractuales avanzados activables post-sovereignty.

Esfuerzo: medio-alto (paralelo a FlowMed 2.0 release 1; depende de B.1 Identity Service para identidad canónica y B.2 FlowMed 2.0 + servicio de datos operativos para visibilidad). Owner: dev interno Workmed + comercial + DPO (datos clínicos en informes).

B.8 Cierre contractual del mes con clientes top + alineación operativa

El cierre de mes hoy es "blando": producción se mueve retroactivamente, atenciones de marzo aparecen en abril, último EDP sale recién el día 9 [§3 dolor 5 mapa-cruzado; Finanzas-20260416 7:34, 8:27]. Esta capa no es Quick Win — es trabajo estratégico que requiere renegociación contractual con el 60% del top que ya tiene convenio firmado [Comercial-20260420 12:43] y alineación operativa que sólo es viable cuando los hitos de Fase 2 cierren los upstream que mueven la fecha (cultivos 3-4 días hábiles + metales 15 días hábiles + acreditados con digitación manual).

Cuatro componentes:

1. Renegociación de la fecha de corte dura (ej. día 5 hábil) con el cliente top, cliente por cliente. Trabajo contractual de comercial + Coustasse, sostenido sobre meses, no sprints.
2. Alineación operativa con los upstream que hoy mueven la fecha: pipeline de digitalización acreditados (B.3) carga exámenes estructurados a FlowMed → A.3.1 valoriza los 12 sin lógica especial → finanzas deja de esperar transcripción manual de SharePoint (el flujo es B.3 → FlowMed → A.3.1 → cierre, no canal directo B.3 → finanzas, para preservar una sola fuente de verdad); cola dirigida + pre-informe IA (B.4) acelera la liberación de informes de baterías complejas; servicio de datos operativos sobre FlowMed 2.0 (B.2) da visibilidad real-time del cierre vs presupuesto, con stewardship de B.6. B.8 sólo es ejecutable cuando estos están al menos en PoC avanzado.
3. Política formal de cierre dentro del marco de gobernanza de datos (B.6): el comité de cambios aprueba la fecha de corte como dato canónico, no negociable mes a mes.
4. Prerequisito de cualquier modelo contractual avanzado activable post-sovereignty: sin cierre formal, el SLA "% aptitud vigente >95%" no es medible en una ventana acotada.

Beneficio standalone (sin T1): recupera 2-3 días de ventaja para facturar cada mes [Recaudacion-20260423 36:33, 1:33:37, 1:35:04]; cierra el gatillante directo del riesgo "factura sale el 9 + cliente la rechaza el 17 = sin ventana de respuesta" frente al plazo legal de 8 días corridos. Esfuerzo: medio-alto (renegociación contractual + alineación operativa con B.3, B.4, B.6 simultáneamente). Owner: Juan Pablo Coustasse + comercial.

Fill-ins · bajo impacto, bajo esfuerzo (Cuadrante C)

Mejoras puntuales con dueños cercanos. No mueven la aguja estructural pero descargan trabajo cotidiano y eliminan fricción visible.

C.1 Documentación del modelo de datos de FlowMed

FlowMed legacy nunca fue documentado [§3 dolor 10 mapa-cruzado; Recaudacion-20260423 1:23:16]: qué tablas existen, cómo se relacionan, qué columna almacena qué dato y cuál es sensible. El conocimiento vive en la cabeza de Eduardo González — refuerzo del riesgo SPOF que C3 ya señala. La documentación se construye en 1-2 sprints inspeccionando la réplica AWS RDS, con entregable concreto: diagrama Entity-Relationship + diccionario de datos por tabla + clasificación de datos sensibles (PII clínico, operacional, comercial).

Es prerrequisito invisible de B.2 FlowMed 2.0 — sin modelo documentado, la migración por estrangulamiento se construye a ciegas — y prerrequisito de compliance Ley 21.719: el inventario de tratamientos exigido por la ley (qué dato vive dónde, con qué finalidad, qué base legal) es imposible sin esta documentación. Por eso aparece en Cuadrante C: bajo CAPEX pero alto valor invisible que destraba dos Big Bets.

Esfuerzo: bajo (1-2 sprints). No toca FlowMed. Owners: Eduardo González (líder técnico) + Rodrigo Llancao.

C.2 Versionado de catálogo de prestaciones con alertas de cambio

Marcela reportó un incidente concreto en sesión [§3 dolor 9 mapa-cruzado; Comercial-20260420 44:01]: un proveedor renombró una prestación y la valorizó al doble sin avisar; toda la producción salió mal por 3-4 meses hasta que se detectó. Hoy el catálogo se modifica sin trazabilidad ni notificación a downstream — cero gobernanza sobre un activo crítico que toca pricing, valorización y cobranza.

La solución técnica complementa la pieza organizacional: trigger automático en la base de datos que envía email a comercial + Eduardo cada vez que alguien modifica un ID, precio o descripción de prestación, con bitácora versionada y auditable. Complementa el comité de cambios de B.6 marco de gobernanza: la gobernanza decide qué cambios se permiten; C.2 alerta cuando ocurren.

Esfuerzo: bajo (1-2 días). No toca FlowMed. Owner: comercial + Eduardo González.

C.3 Bodegas satélite como modelo de descentralización logística

Hoy el abastecimiento de insumos está centralizado en la bodega de Santiago [§5.7 mapa-cruzado; Abastecimiento-20260423 10:02]: las sedes regionales (Calama, Antofagasta y futuras) dependen de despachos cotidianos desde el centro, con SLA estándar de 1-1.5 días [Abastecimiento-20260423 23:49]. Eso introduce dependencia logística, costo de transporte recurrente y riesgo de stockout cuando el despacho se atrasa o el insumo escasea.

Pamela Lastra ya tiene un piloto de bodega satélite operativo en Antofagasta que descentraliza stock crítico hacia el norte: insumos cotidianos disponibles regionalmente, sin esperar despacho central. La acción consiste en documentar el modelo del piloto (qué stock se desplaza, qué SLA interno aplica, qué KPIs de rotación medir) y replicarlo a otras sedes con presión similar de transporte o stockout. No requiere intervención TI; es un patrón operativo-logístico que ya funciona en producción.

Esfuerzo: bajo (replicar patrón ya validado). No toca FlowMed. Owner: Pamela Lastra.

C.4 Visibilidad del no-show por cliente con umbral recomendado

Workmed históricamente absorbe las inasistencias como parte de la propuesta de valor con sus clientes top [Top 10 RN-6; Comercial-20260420 6:25, 6:51] — práctica que la diferencia de otros prestadores y forma parte de la relación cultural con la cartera mayor. El dolor real no es la absorción sino que nadie lo mide ni lo hace visible: 15-17% de no-show sobre 700 agendas/día [Plataformas-20260420 53:39] equivale a 100-120 atenciones diarias regaladas, pero ese costo queda invisible tanto para Workmed como para el cliente. Workmed reservó la hora, asignó box, pagó al equipo médico — y nadie nota el servicio extra entregado.

La acción tiene dos piezas que respetan el modelo histórico sin imponer cláusulas contractuales:

1. Instrumentar y reportar el no-show por cliente. Medición mensual + reporte al cliente con cifras y valorización ("este mes Workmed absorbió X atenciones por no-show de tu equipo, valorizadas en $Y"). Hace visible el servicio extra → fortalece la relación con clientes top y genera data accionable para futuras conversaciones contractuales.
2. Umbral recomendado de no-show por cliente (ej. 10-12% mensual, a calibrar contra baseline por industria). No es cláusula contractual — es una norma cultural compartida con el cliente: si un cliente se pasa del umbral, comercial abre conversación operativa (sin cobro, sin penalidad), busca causas de raíz, propone re-agendamiento sistemático.

Esto preserva la absorción como diferenciador, pero rompe la invisibilidad del costo. El cobro formal del no-show queda como opción contractual avanzada dentro de B.8 (cierre contractual del mes con clientes top), donde la conversación tarifa-volumen ya está abierta y es el momento natural para discutir tiers (premium / outcomes) si el cliente lo pide.

Esfuerzo: bajo (instrumentar + diseñar reporte mensual). No toca FlowMed. Owner: comercial + Juan Pablo Coustasse + Mónica Pérez (PMO para cadencia del reporte).

Hard slogs · bajo impacto, alto esfuerzo (Cuadrante D)

Acciones que se descartan o se posponen indefinidamente. Quedan en bitácora por si el contexto cambia, pero no compiten con Fase 1, 2 o 3.

D.1 Desafiliación de los 6 centros acreditados

CAPEX alto (policlínicos modulares, carros de paro) + renegociación con clientes top que valoran cobertura nacional + recompensa baja vs pipeline de digitalización acreditados Workmed-side (B.3, que no requiere control sobre los acreditados independientes). Posponer indefinidamente; revisar sólo si SLA aptitud vigente es inalcanzable con red mixta saneada.

D.2 Producto de datos B2B en Fase 1-2

Requiere modelo FlowMed documentado, anonimización legal sólida y perfil comercial nuevo. Esperar a Fase 3 con activo ya saneado por Identity Service + plataforma propia + gobernanza B.6. Vendido como producto independiente sobre los 31 GB de log + 2.2 GB de atenciones [§5.3 mapa-cruzado; Recaudacion-20260423 1:26:56].

D.3 Reemplazo big-bang de Defontana o HubSpot

Patrón histórico Workmed: NetSuite y HubSpot↔FlowMed 2024 fracasaron como big-bangs [Finanzas-20260416 37:26; Agendamiento-20260413 47:19; Recaudacion-20260423 38:29]. Migración por estrangulamiento desde la plataforma propia, no reemplazo. Ningún proyecto monolítico independiente entra en horizonte 365 días.

Cómo esta matriz se ejecuta en el roadmap

La matriz no es una lista de deseos; es el menú ordenado que se ejecuta en las tres fases del roadmap (09-recomendacion-roadmap.md):

• Fase 1 (días 1-90) = Quick wins del Cuadrante A. Las 4 acciones se ejecutan en paralelo con el diseño arquitectónico de FlowMed 2.0; A.1 (Onboarding + Ambiente Workmed-Tech) ya está en marcha y es la base de todas las demás. A.2 (Portal del Cliente fase 1) es la palanca con mayor impacto upstream y el primer entregable del canal directo cliente · B.7 lo expande en Fase 2. Resultado: dolores cotidianos saldados sin esperar a la nueva plataforma.
• Fase 2 (días 91-180) = Big bets del Cuadrante B arrancan. Identity Service como primer microservicio, FlowMed 2.0 release 1, PoC pre-informe IA con métrica rigurosa, PoC pipeline digitalización acreditados con 1-2 acreditados, marco de gobernanza de datos (B.6), expansión del Portal del Cliente a panel completo (B.7), cierre contractual del mes con clientes top + alineación operativa (B.8) apalancado en B.3, B.4 y B.6. Cuadrante C en paralelo según capacidad.
• Fase 3 (días 181-365) = visión TO-BE post-sovereignty. Expansión de B.3, B.4, B.7 y B.8 + T1 Agentes IA + Orquestador de Transformación Digital (visión TO-BE original del proyecto Workmed) condicionado al éxito del PoC pre-informe IA (B.4). El crecimiento volumétrico y los modelos contractuales avanzados emergen como consecuencia natural del saneamiento.
• Cuadrante D = bitácora. Ningún hard slog compite con la Fase 1, 2 o 3. Quedan documentados como descartes con criterio de retorno explícito.

$ cat ./recomendacion-estrategica.md#roadmap

Roadmap en 3 fases con carta Gantt de 13 acciones × 12 meses: Fase 1 (días 1-90) Saneamiento + sovereignty foundations · Fase 2 (días 91-180) Plataforma propia + integraciones críticas · Fase 3 (días 181-365) Expansión B.3/B.4/B.7/B.8 + visión TO-BE T1 Agentes IA + Orquestador de Transformación Digital. El crecimiento volumétrico y los modelos contractuales avanzados emergen como consecuencia natural del saneamiento. Stakeholders: Carolina Araya (líder del programa), Eduardo González + Rodrigo Llancao (responsabilidad operativa compartida sobre Identity Service), Mónica Pérez (PMO), Coustasse (CFO), Vicente+Pablo, Christian Urbina (infraestructura), DPO por designar.

Mecanismo y roadmap 90 / 180 / 365 días

Cómo baja la tesis TI Sovereignty a operación: una decisión arquitectónica que ancla todo, tres fases secuenciales (no paralelas) y un mapa explícito de stakeholders y de lo que no se hace en este horizonte. La Fase 3 (visión TO-BE: Agentes IA + Orquestador) sólo arranca cuando las fases 1 y 2 cierran sus hitos. La estructura 90/180/365 reemplaza al 30/90/365 anterior para reflejar que la sovereignty no es ejecutable en 30 días.

Carta Gantt · 14 acciones priorizadas en 12 meses

Cómo leer la Gantt. Cada fila es una recomendación priorizada (13-recomendaciones-priorizadas.md). Las acciones del Cuadrante A (Quick Wins) viven íntegras en Fase 1; las del Cuadrante B (Big Bets) arrancan con diseño en Fase 1 (cuando aplica) y entregan en Fase 2. La Fase 3 contiene la expansión de B.3, B.4, B.7, B.8 + T1 Agentes IA + Orquestador, la visión TO-BE original del proyecto Workmed que la sovereignty habilita (Orquestador de Transformación Digital). El crecimiento volumétrico y los modelos contractuales avanzados (BPO outcome-based, planes anuales) emergen como consecuencia natural del saneamiento — no requieren track propio.

Decisión arquitectónica clave

El Identity Service y el primer release de FlowMed 2.0 viven en la cuenta AWS Workmed propia ya decidida [§Decisiones 08; Plataformas-20260420 18:14, 42:10, 1:03:20]. La regla operativa es migración por estrangulamiento, no big bang — cada hito tiene que ser entregable de forma autónoma y consumible por un sistema downstream.

El equipo TI Workmed (8-10 personas, área <3 años [EcosistemaTI-20260415 36:49]) deja de ser cliente del partner y pasa a ser dueño de la plataforma. Cada modificación al módulo de agendamiento, a la lógica de bloqueo en contraloría o al motor de alertas se hace sin pasar por Secall. Ése es el cambio operativo que permite mitigar dolores en plazos ejecutables; sin él, el AS-IS sigue siendo un mapa de dolores sin timeline.

Fase 1 · Saneamiento + sovereignty foundations (días 1-90)

Quick wins ejecutados sobre el stack actual + arquitectura de la plataforma propia diseñada en paralelo. Esta fase no espera a tener la nueva plataforma para empezar a saldar dolores; los 4 quick wins del Cuadrante A se ejecutan en simultáneo con el diseño de FlowMed 2.0.

• Quick wins ejecutados en orden de prioridad (A.4 prioridad cero del Mes 1, las demás en paralelo):

1. A.4 Recuperación de soberanía sobre la BD clínica de FlowMed (Mes 1 · prioridad cero): contrato de encargo de tratamiento de datos con Secall (cláusulas Ley 19.628 + 21.719) + acceso administrativo paralelo Workmed sobre AWS RDS + individualizar credenciales y cerrar la cuenta genérica compartida. Cierra simultáneamente S1 + S2 + S4 + I1 + C3 + C4 del mapa de incidencias. Sin esto, A.1, B.1 y B.2 corren sobre soberanía cedida — son aspiracionales. 2. A.1 Onboarding de EMERCOM + Ambiente de desarrollo Workmed-Tech (ya en marcha): cuenta AWS Workmed propia operativa, GitHub de Workmed activo con migración del script Python en proceso [Recaudacion-20260423 1:15:49, 1:25:32, 1:30:35, 1:40:40; Plataformas-20260420 18:14, 42:10], tooling AI-augmented (OpenCode + Claude), Power Platform + Microsoft 365, EMERCOM onboarded como partner. Base de A.2, A.3 y de toda la sovereignty. 3. A.2 Portal del Cliente fase 1 — pre-agendamiento como servicio + plantillas canónicas. La mandante descarga la plantilla canónica, sube nómina al portal Workmed, valida en línea, corrige y reenvía hasta limpia [Agendamiento-20260413 22:25; Operaciones-20260407 21:23, 44:03; §5.1 Agendamiento sub-flujo automático]. Fase 1 del canal directo · B.7 lo expande en Fase 2 (panel completo, delivery channel de modelos contractuales avanzados activables post-sovereignty). 4. A.3 Módulo de Producción fase 1 sobre ambiente Workmed-Tech, sin depender de FlowMed legacy: (A.3.1) valorización automatizada nocturna para Comercial (sin Ignacio manual) [Finanzas-20260416 7:03; ComercialBI-20260422 1:25]; (A.3.2) módulo Contraloría con acceso unificado a exámenes (FlowMed + SharePoint) + designación de médicos contralores + seguimiento del informe final [Contraloria-20260421 12:46, 25:43, 26:12] — prerequisito directo de B.4 (cola dirigida + pre-informe IA). La auditoría de cuentas Power BI se resuelve en B.6 gobernanza, no acá.

Nota — el bloqueo formal de doble contraloría en FlowMed que en versiones anteriores aparecía como A.4 Quick Win independiente queda subsumido en B.4 (Secall ya tiene compromiso de entrega, no requiere track propio).

• Arquitectura FlowMed 2.0 diseñada. Documento técnico cerrado con Carolina Araya + Eduardo González + Rodrigo Llancao: stack, modelo de datos, plan de migración por estrangulamiento. Ése es el ancla del Mes 6.
• Identity Service definido y responsabilidad operativa compartida formalizada. Eduardo González (líder técnico) + Rodrigo Llancao comparten la responsabilidad operativa del Identity Service — cierra §6.3 mapa-cruzado (soberanía sobre BD productiva FlowMed cedida a Secall + cuenta genérica compartida + sin contrato encargo, mitigado por A.4 en Mes 1). Alcance acotado: tablas raíz worker + client con APIs de lectura. Elimina la necesidad del script Python de depuración de RUTs porque la identidad se valida y normaliza al ingreso, no se depura aguas abajo [Recaudacion-20260423 1:30:35, 1:31:02].
• Documentación inicial del modelo de datos de FlowMed [§3 dolor 10 mapa-cruzado; Recaudacion-20260423 1:23:16]. Insumo de FlowMed 2.0 y de cualquier producto de datos posterior.

Fase 2 · Plataforma propia + integraciones críticas (días 91-180)

Primer release de FlowMed 2.0 sobre AWS Workmed propia, cubriendo los módulos donde la "todo o nada" y la lentitud creciente más duelen. La regla del Mes 6: cada Big Bet del Cuadrante B con un PoC concreto y métrica rigurosa.

• Primer release FlowMed 2.0 cubriendo agendamiento + intake. Estrangulamiento progresivo del legacy.
• Identity Service consumido por al menos 1 sistema downstream — test del Mes 6. Si al cabo de la primera fase ningún sistema downstream consume el servicio, se está repitiendo el patrón "core monolítico que tarda años" (NetSuite, intento HubSpot↔FlowMed 2024, módulo valorización [Finanzas-20260416 37:26; Agendamiento-20260413 47:19; Recaudacion-20260423 38:29]).
• Marco de gobernanza de datos instalado (B.6). DPO designado, data stewards por dominio formalmente nombrados, primer comité de cambios sesionado, políticas de versionado de catálogo + dashboards + scripts canónicos vigentes, log auditable de accesos a datos sensibles activo. Sin esta capa, FlowMed 2.0 hereda los dolores con stack nuevo [§hallazgo 11; Operaciones-20260407 51:32, 52:19].
• Portal del Cliente fase 2 (B.7) en construcción. Crece sobre A.2 con panel de deudas, costos, entrega de informes, trazabilidad y alertas de aptitud por vencer — base técnica del SLA "% aptitud >95%" activable cuando comercial detecte apetito y foundation del compliance Ley 21.719.
• Cierre contractual del mes con clientes top + alineación operativa (B.8) en negociación. Renegociación cliente por cliente de la fecha de corte dura, apalancada en B.3 (pipeline de digitalización Workmed-side elimina digitación manual de acreditados independientes), B.4 (cola dirigida acelera baterías complejas) y B.2 (FlowMed 2.0 da visibilidad real-time de los datos operativos, con stewardship de B.6). Recupera 2-3 días de ventaja para facturar y vuelve medible el SLA "% aptitud vigente >95%" en ventana acotada.
• PoC sistema interno de cola dirigida + pre-informe IA con 100 informes en contraloría: routing automático de casos a médicos contralores disponibles según peso de batería (alta complejidad ↔ médicos senior); pre-revisión y pre-recomendación de apto/no apto/no apto transitorio; doble contraloría humana sostenida (firma médica = única autoridad legal [Top 10 RN-4]). Métricas rigurosas: tasa de aceptación sin cambios, tasa de errores, tiempo de revisión por peso de batería antes vs después, % de reasignaciones manuales de Vicente. Reemplaza el conteo casuístico mental de Vicente por cola dirigida [Contraloria-20260421 26:12, 30:54, 31:11].
• PoC pipeline de digitalización acreditados con 1-2 acreditados (partir por BestMed). Pasarela digital Workmed-side, no Megafy impuesto sobre operaciones independientes.
• Benchmark de carga FlowMed 2.0 — input crítico para decidir T2 en Fase 3.

Fase 3 · Visión TO-BE post-sovereignty (días 181-365)

Sobre la base saneada en Fases 1-2, Workmed arranca la visión TO-BE original que motivó este diagnóstico (proyecto Orquestador de Transformación Digital). El crecimiento volumétrico y las opciones de monetización contractual avanzada (BPO outcome-based, planes anuales) emergen como consecuencia natural de Fases 1-2 — no requieren un track propio en el roadmap; cuando la sovereignty está en su lugar, el comité comercial las activa cuando hay apetito del mercado. Lo que sí requiere un track explícito de Fase 3 es el único movimiento que no surge automáticamente del saneamiento:

• T1 — Agentes IA + Orquestador de Transformación Digital. La visión TO-BE original del proyecto Workmed. Sobre sovereignty + saneamiento, el Orquestador coordina end-to-end los procesos agendamiento → operaciones → contraloría → EDP con agentes IA especializados por proceso. B.4 pre-informe IA en contraloría con doble contraloría humana es el primer agente del ecosistema, ya en Fase 2 con PoC de 100 informes; T1 expande la capacidad agéntica a los demás procesos (agente de pre-agendamiento que valida nóminas en B.7, agente de operaciones que coordina sucursales, agente conversacional sobre datos clínicos para mandantes en el portal). El Orquestador es la capa integradora: en lugar de cada proceso ejecutándose como silo con su agente, los agentes se coordinan vía un orquestador central que conoce el estado del trabajador, del cliente y de la batería en curso. Sin sovereignty (FlowMed 2.0 con APIs, Identity Service, gobernanza), cualquier agente IA queda como "anexo que vive afuera" reproduciendo el patrón fracasado.

T1 está condicionado al éxito de B.4 (PoC pre-informe IA con 100 informes y métricas rigurosas de aceptación, error y reasignación). Si B.4 valida la doble contraloría humana sostenida con productividad clínica medible, T1 se ejecuta; si B.4 no escala, T1 se posterga hasta resolver la brecha de calidad.

Compromisos y stakeholders

• Carolina Araya (CTO Workmed) · líder del programa. Primer release FlowMed 2.0 declarado en sesión como "acelerador máximo" [Plataformas-20260420 1:01:32, 1:04:16]. Accountable del resultado completo del programa de sovereignty.
• Eduardo González · líder técnico + Rodrigo Llancao · especialista en BI/datos: responsabilidad operativa compartida sobre el Identity Service. Cierran el riesgo de punto único de falla en el acceso AWS RDS [§6.3 mapa-cruzado].
• Mónica Pérez · Oficina de Proyectos (PMO). Cadencia, hitos, riesgos y secretaría técnica del comité de gobernanza de datos (B.6). Sin PMO, los hitos son aspiracionales.
• Juan Pablo Coustasse (CFO): owner del marco de gobernanza de datos (B.6) + designación de DPO + asesoría legal Ley 21.719 + triple norma ISO [Flowmed-20260409 30:52; EcosistemaTI-20260415 41:46, 42:40, 43:39, 44:05]; owner del contrato BPO si se elige T1 en Fase 3.
• Vicente Rivano + Pablo Martínez: owners del SLA aptitud vigente (T1) o de la calidad clínica del pre-informe IA en PoC Fase 2 [Contraloria-20260421 10:47, 24:45].
• Christian Urbina (infraestructura): GitHub de Workmed + scheduler del pipeline de producción diaria + on-prem Manuel Montt durante la transición.
• DPO · por designar (Mes 2): owner formal del compliance Ley 21.719 + custodios del dato.

Fuera de alcance Fases 1-3

La tesis es deliberadamente una sola (TI Sovereignty + saneamiento + visión TO-BE T1). Lo siguiente queda explícitamente fuera del horizonte 365 días por si retorna en horizonte mayor:

• Desafiliación de centros acreditados (Cuadrante D hard slogs). CAPEX alto + recompensa baja vs pipeline de digitalización Workmed-side (B.3, no requiere control sobre los acreditados). Posponer indefinidamente; revisar sólo si el SLA aptitud vigente es inalcanzable con red mixta saneada.
• Producto B2B de datos clínicos. Requiere modelo FlowMed documentado, anonimización legal sólida y perfil comercial nuevo. Esperar a que el activo esté saneado por Identity Service + plataforma propia.
• Modelos contractuales avanzados (BPO outcome-based, suscripción anual flat). Emergen como consecuencia natural del saneamiento + sovereignty si el comité comercial detecta apetito del cliente top — no requieren track propio en el roadmap; se activan cuando la base técnica está lista.

La regla es estricta: ningún descarte compite con la Fase 1. Cada uno tiene su ventana de retorno (Fase 2/3 o más allá), pero no se mezclan en el horizonte de saneamiento + sovereignty.

$ diff ./as-is/kpis ./to-be/kpis

Tabla de ~20 KPIs con cifra actual vs cifra esperada bajo TI Sovereignty + opciones de monetización. Incluye 14 KPIs originales + 6 nuevos (volumen 400→3000/día, productividad contralor 6→12-15 inf/h, % acreditados manuales 100→0%, diversificación 100% minería → 70/30, Manuel Montt 45→30%, capacity headroom FlowMed 5×). Las cifras "estimación" se validan en piloto Mes 6.

Impacto esperado en KPIs

Las 23 cifras que siguen toman los KPIs declarados en el AS-IS (ver 06-kpis-consolidados.md y §5 del resumen ejecutivo) y los proyectan contra la cifra esperada bajo la tesis TI Sovereignty + saneamiento + visión TO-BE (T1 Agentes IA + Orquestador). Cada fila tiene cuatro columnas: cifra actual, cifra esperada, mecanismo y fuente AS-IS. Las cifras esperadas no son metas comerciales: son consecuencias mecánicas de la sovereignty + saneamiento aplicados en conjunto. El crecimiento volumétrico y los modelos contractuales avanzados (BPO outcome-based, planes anuales) emergen como consecuencia natural del saneamiento, sin requerir tracks propios. Las 9 filas marcadas en negrita son nuevas en v3.0: reflejan KPIs de capacidad volumétrica, productividad clínica con IA, diversificación industrial y gobernanza de datos (capa interna de la TI Sovereignty) que la versión anterior no exponía.

Tabla de impacto

Nota sobre estimaciones y validación

Las cifras esperadas son estimaciones y se calculan sobre el supuesto de que la TI Sovereignty se ejecuta según roadmap 90/180/365 — Identity Service, primer release FlowMed 2.0, gobernanza B.6, pipeline digitalización B.3 y cierre contractual B.8 cierran sus hitos. Las cifras de capacidad volumétrica + diversificación industrial dependen además de las validaciones del Mes 6 detalladas en 12-recomendacion-riesgos-validaciones.md.

El criterio de validación operativo es el siguiente: si al Mes 6 del piloto la reducción de errores upstream no se materializa al menos al 50% de la meta proyectada (errores que llegan a EDP <0.1%, lunes correctivos −80%, captura manual de 6+ estaciones a 1), el supuesto de Identity Service como frontera está mal y la inversión técnica no se justifica con la lógica de saneamiento únicamente. Hay que revisar la arquitectura antes de seguir, no comprometer Fase 2 ni Fase 3.

Las 6 filas nuevas marcadas en v3.0 son las que llevan mayor incertidumbre — dependen del cierre de hitos arquitectónicos (FlowMed 2.0 release 1 con benchmark de carga, pipeline digitalización acreditados (B.3), PoC pre-informe IA con métrica rigurosa). No son promesas: son techos alcanzables si la sovereignty se ejecuta y la opción de monetización elegida arranca según calendario. La utilidad de esta tabla no es predictiva sino contractual: cuando un stakeholder pregunta "qué cambia exactamente con esto", la respuesta no es una promesa cualitativa sino 20 cifras concretas con su mecanismo y su fuente AS-IS.

$ cat ./recomendacion-estrategica.md#riesgos

Riesgos R1-R7 con contraargumento + mitigación + early warning (Identity Service patterns, soberanía sobre BD productiva cedida a Secall, Ley 21.719, FlowMed legacy capacidad volumétrica, pre-informe IA calidad/regulatorio, capacidad canal propio+acreditados, degradación legacy durante 6 meses). 7 validaciones pendientes con stakeholder ejecutivo. Exposición regulatoria vigente hoy: Ley 19.628 + Ley 16.744/DS 109 (régimen ocupacional) + futura Ley 21.719 (1 dic 2026) + triple norma ISO (junio 2026) — TI Sovereignty + Identity Service + gobernanza B.6 + contrato de encargo con Secall habilitan compliance por arquitectura.

Riesgos · validaciones · regulatorio

La tesis TI Sovereignty + saneamiento + visión TO-BE (T1 Agentes IA + Orquestador) es radical y por eso lleva 7 riesgos R1-R7 con contraargumento, mitigación y early warning explícitos. Lleva además 7 validaciones pendientes con stakeholder ejecutivo que deben cerrarse antes de comprometer cada palanca — sin esos "sí" iniciales, los hitos no arrancan. Y lleva un mapa de exposición regulatoria sobre dos deadlines reales y simultáneos: la Ley 21.719 (vigencia 1 dic 2026, 6 meses para cumplir) y la triple norma ISO (deadline junio 2026).

Los riesgos cubren las objeciones estructurales al Identity Service + plataforma propia + pipeline de digitalización acreditados + pre-informe IA + continuidad operacional del legacy durante los 6 meses hasta FlowMed 2.0 release 1. Las validaciones refieren a hitos del Mes 1-6 que condicionan el avance.

Riesgos R1-R7

R1 — "El Identity Service es otra FlowMed 2.0 que tarda años; el patrón se repite"

Contraargumento: el Identity Service no es FlowMed 2.0 completo. Es un microservicio acotado (worker + client con APIs de lectura) sobre AWS Workmed propia [Plataformas-20260420 18:14], independiente del calendario Secall. Workmed ha fracasado antes con reemplazos monolíticos — NetSuite, intento HubSpot↔FlowMed 2024, módulo de valorización abandonado [Finanzas-20260416 37:26; Agendamiento-20260413 47:19; Recaudacion-20260423 38:29]; este movimiento es deliberadamente acotado.

Mitigación: alcance Mes 1 limitado a worker + client con APIs de lectura. Migración por estrangulamiento, no big bang.

Early warning: si al Mes 6 ningún sistema downstream consume el servicio, el patrón se está repitiendo y hay que parar antes de comprometer Fase 3.

R2 — Eduardo González sigue siendo punto único de falla (§6.3 mapa-cruzado)

Contraargumento: Eduardo + Rodrigo Llancao con responsabilidad operativa compartida sobre el Identity Service es la respuesta explícita.

Mitigación: mail sobre acceso AWS RDS para Roberto / Barbarita [Recaudacion-20260423 1:25:32, 1:40:40] queda como hito Mes 1, antes de cualquier otro entregable.

Early warning: si al final del Mes 1 sólo Eduardo tiene acceso, el riesgo bloquea el piloto.

R3 — "La Ley 21.719 (1 dic 2026, 6 meses) hace inviable agregar nuevos sistemas con clínicos"

Contraargumento: la Ley exige consentimiento explícito y anonimización; no prohíbe sistemas. El Identity Service habilita el compliance porque centraliza el consentimiento granular hoy disperso. La triple norma ISO con deadline junio 2026 [Flowmed-20260409 30:52] es el envoltorio.

Mitigación: primer entregable incluye registro de consentimiento por trabajador y finalidad, validado con asesoría legal antes del despliegue.

Early warning: si la asesoría legal rechaza el modelo de consentimiento al Mes 2, revisar arquitectura.

R4 — FlowMed legacy no aguanta el volumen del crecimiento esperado

Contraargumento: "Lentitud creciente" ya documentada [§6.7 mapa-cruzado; Agendamiento-20260413 41:08, 40:40] — tiempos de procesamiento se degradaron a 20-25 min para nóminas grandes vs ~5 min normal. Cualquier crecimiento volumétrico significativo sobre el legacy es inviable.

Mitigación: la capacidad volumétrica está condicionada a FlowMed 2.0 release 1; hito Mes 6 = benchmark de carga del primer release sobre AWS Workmed propia. La decisión de escalar volumen depende del comportamiento real del nuevo stack bajo prueba, no de un compromiso comercial anticipado.

Early warning: Mes 9 sin diseño FlowMed 2.0 cerrado = capacidad volumétrica se pausa. El crecimiento como consecuencia natural del saneamiento queda diferido hasta tener benchmark.

R5 — Pre-informe IA puede comprometer calidad clínica o exposición regulatoria

Contraargumento: la doble contraloría humana se mantiene; la firma médica sigue siendo única autoridad legal [Top 10 RN-4; Contraloria-20260421 3:25, 15:27]. La IA sólo prepara borrador estructurado a partir de la captura digital. B.4 es además el primer agente del ecosistema T1 Agentes IA + Orquestador: si B.4 no escala con calidad, T1 entero queda en bitácora.

Mitigación: PoC Mes 6 con 100 informes y métrica rigurosa: tasa "edita el borrador" vs "acepta sin cambios" + tasa de errores. Productividad médico contralor proyectada de 6 → 12-15 inf/h sólo se valida si la métrica de calidad se sostiene.

Early warning: PoC con <70% aceptación o ≥1% errores = no escala. La productividad proyectada no se materializa, el pre-informe IA queda en bitácora, y T1 (Agentes IA + Orquestador) se posterga hasta resolver la brecha de calidad.

R6 — Capacidad de canal propio + acreditados insuficiente

Contraargumento: el pipeline de digitalización Workmed-side (B.3) opera con los 6 acreditados independientes absorbiendo la variabilidad de cada operación autónoma sin imponerles sistemas Workmed. Manuel Montt concentra 45% de la actividad nacional [§5.2 mapa-cruzado; Operaciones-20260407 4:08] — la descongestión geográfica con 1-2 sucursales nuevas en zonas saturadas es parte del mecanismo.

Mitigación: PoC pipeline funcionando con al menos 1-2 acreditados (partir por BestMed) como hito Mes 6 — descomprime la frontera Workmed eliminando la digitación masiva del 40% de atenciones acreditadas. Nota: la descentralización de bodegas (C.3) ataca un problema logístico distinto (despacho de insumos a sedes regionales), no la capacidad clínica.

Early warning: Mes 6 sin PoC pipeline funcionando con al menos 1 acreditado = la frontera digital no se materializa. La capacidad de absorber crecimiento volumétrico queda comprometida.

R7 — FlowMed legacy puede degradarse más durante los 6 meses hasta FlowMed 2.0 release 1

Contraargumento: la "lentitud creciente" del legacy ya está documentada — tiempos de procesamiento degradados a 20-25 min para nóminas grandes vs ~5 min normal [§6.7 mapa-cruzado; Agendamiento-20260413 41:08, 40:40] — y el soporte Secall responde "2 semanas a 1 mes, a veces nunca" para incorporar formularios nuevos [Agendamiento-20260413 27:58, 44:28]. La sovereignty no congela el legacy durante el saneamiento: la degradación puede continuar y llegar a paro operacional parcial antes de que FlowMed 2.0 release 1 esté en producción al Mes 6. Workmed tendría que mitigar con Secall en condiciones de poder negociador débil (la decisión de salir ya está tomada).

Mitigación: dos palancas que descargan operaciones críticas del legacy sin requerir su modificación: (1) A.2 Portal del Cliente fase 1 mueve la validación de nóminas upstream del legacy y rompe el "todo o nada" sin tocarlo; (2) A.3 Módulo de Producción fase 1 desacopla la valorización (A.3.1) y la designación de médicos contralores (A.3.2) del legacy, haciendo observable la degradación sin depender de FlowMed. Observación informal del equipo TI Workmed sobre tiempos de procesamiento + errores reportados por área (sin instrumentar FlowMed) sirve como early warning intermedio. Benchmark de carga FlowMed 2.0 al Mes 6 (V5) cierra el horizonte. Plan de contingencia con Secall acordado en Mes 1: si los tiempos legacy pasan ciertos umbrales, intervención técnica obligada bajo cláusula contractual existente.

Early warning: si los tiempos de procesamiento de nóminas grandes pasan de 25 min a 35+ min antes del Mes 4 (observación del equipo TI), o si se registra paro operacional ≥4 horas por degradación del legacy, escalar inmediatamente: negociar intervención de emergencia con Secall y acelerar el release FlowMed 2.0 (priorizar el módulo más afectado, no esperar al release completo). Mes 6 sin FlowMed 2.0 release 1 + tiempos legacy >40 min = riesgo de paro operacional total durante Fase 2.

Validaciones pendientes con stakeholder ejecutivo

Conversaciones que deben cerrarse antes de comprometer cada palanca. Sin estos "sí" iniciales, los hitos correspondientes no arrancan.

1. V1 — Capacidad TI real para FlowMed 2.0 (Carolina Araya): ¿el primer release sobre AWS Workmed propia es compatible con el roadmap 90/180? Hoy "FlowMed 2.0" no tiene diseño público [Plataformas-20260420 55:32]. El equipo TI de 8-10 personas, área de <3 años, debe asumir el servicio como entregable independiente.

1. V2 — Cobertura ISO + Ley 21.719 (asesoría legal externa + compliance Workmed): ¿el Identity Service como frontera de consentimiento granular es defensible frente al deadline junio 2026 de la triple norma ISO y la vigencia 1 dic 2026 de la Ley 21.719?

1. V3 — Acceso AWS RDS distribuido (Eduardo González): mail sobre acceso para Roberto / Barbarita ejecutado antes del Mes 1 [Recaudacion-20260423 1:25:32, 1:40:40].

1. V4 — Política comercial renegociada (Coustasse + comercial): ¿se acepta suspensión de SLA como palanca contractual de cobranza? Hoy "no hay palanca" [Recaudacion-20260423 29:16] y "le vende al que no le paga" [Recaudacion-20260423 32:26].

1. V5 — Capacidad sostenible FlowMed 2.0 con benchmark de carga (Carolina Araya): benchmark de carga del primer release como prerrequisito de cualquier compromiso volumétrico. Sin benchmark concreto, la capacidad sobre el nuevo stack es aspiracional.

1. V6 — Apetito IA pre-informe en contraloría (Vicente Rivano): ¿Vicente acepta el PoC con 100 informes y la métrica rigurosa? La productividad proyectada de 12-15 inf/h y la viabilidad de T1 Agentes IA + Orquestador dependen de este sí — B.4 es el primer agente del ecosistema; sin B.4 escalando con calidad, T1 entero se posterga.

1. V7 — PoC pipeline de digitalización acreditados funcionando (Carolina + Pablo Martínez + dev interno): pipeline operando con al menos 1-2 acreditados (partir por BestMed) antes del Mes 6. Sin pipeline absorbiendo la variabilidad de los acreditados independientes, la promesa "0% digitación manual en frontera Workmed" no se materializa y la capacidad volumétrica esperada queda comprometida.

Exposición regulatoria

Ley 21.719 — Datos Personales

Vigencia: 1 de diciembre de 2026. Plazo de cumplimiento: 6 meses desde vigencia. Alcance Workmed: datos personales del trabajador (RUT, biométricos, estado clínico, vínculo con empleador) y datos personales sensibles (información de salud bajo Ley 16.744). La réplica caliente AWS RDS con datos clínicos es hoy una vulnerabilidad de compliance [§5 08 riesgo 4; EcosistemaTI-20260415 43:39, 44:05].

Cómo TI Sovereignty + Identity Service habilitan el compliance:

• La plataforma propia sobre AWS Workmed elimina la dependencia del modelo de datos de Secall y permite versionar el consentimiento dentro del perímetro Workmed.
• El Identity Service centraliza el registro de consentimiento granular por trabajador y finalidad (clínica / producto / operativa), hoy disperso en 4 sistemas [§3 dolor 1 mapa-cruzado].
• Permite anonimización selectiva [§Compromisos 5.8 mapa-cruzado; EcosistemaTI-20260415 41:46, 42:12] sobre la réplica para usos no clínicos.
• Documenta la frontera de qué dato sale del perímetro clínico y bajo qué consentimiento.

Sin sovereignty, Workmed cumple la Ley con parches por sistema y trazabilidad endeble. Con sovereignty + Identity Service + gobernanza B.6, cumple por arquitectura.

Triple norma ISO

Deadline: junio 2026. Alcance: certificación en curso (referenciada en sesión como "triple norma ISO" con ISO 27001 entre las componentes [Flowmed-20260409 30:52; EcosistemaTI-20260415 42:40]).

Cómo TI Sovereignty habilita la certificación:

• La plataforma propia permite documentar el modelo de datos de FlowMed (hoy sin documentación [§3 dolor 10 mapa-cruzado; Recaudacion-20260423 1:23:16]) — prerrequisito de la certificación.
• Eduardo + Rodrigo con responsabilidad operativa compartida + acceso AWS RDS distribuido eliminan el SPOF que la certificación marcaría como hallazgo crítico.
• El marco de gobernanza de datos (B.6) — DPO, comité de cambios, log auditable, políticas de versionado — entrega los controles documentales y de trazabilidad exigidos por las tres normas.

Concurrencia de los dos deadlines

Junio 2026 (ISO) y 1 dic 2026 + 6 meses (Ley 21.719) caen sobre la misma ventana en que se ejecutaría la Fase 1 + Fase 2 de la recomendación. Si Workmed alinea los tres calendarios (ISO + Ley + sovereignty), el cumplimiento se vuelve subproducto del roadmap estratégico, no carga adicional. Si no los alinea, los tres compiten por el mismo equipo TI de 8-10 personas y ninguno cierra a tiempo.

$ cat ./recomendacion-estrategica.shortlist.md

Anexo de referencia. Bitácora del proceso de exploración previo a cerrar la tesis: 6 candidatos evaluados (C-1 a C-6) con tesis, descarte/integración y criterio de retorno. La recomendación final converge en TI Sovereignty + saneamiento + visión TO-BE (T1 Agentes IA + Orquestador), pero el shortlist queda documentado por si los candidatos descartados o postergados retornan al menú en horizonte mayor.

Anexo · Shortlist de candidatos considerados (referencia futura)

Este anexo cierra el Bloque B como bitácora de referencia. La recomendación final del diagnóstico ya quedó establecida en las secciones anteriores (TI Sovereignty + saneamiento + visión TO-BE: T1 Agentes IA + Orquestador), pero antes de cerrar la tesis se evaluaron 6 candidatos macro comparables — cada uno construido sobre la inversión de un supuesto operativo distinto del AS-IS.

Se documentan acá por si el contexto de Workmed cambia en horizonte mayor a 365 días y alguno de los candidatos descartados o postergados retorna al menú: el cliente puede consultar el razonamiento original, los criterios de descarte y la ventana de retorno explícita de cada uno.

La pregunta original "¿cuál de los 6 es el ganador?" se reformuló al constatar que ninguno es viable mientras Workmed no controle su propia plataforma. De ahí emergió la tesis TI Sovereignty (sección 9 del Bloque B). Este shortlist registra para cada candidato qué proponía, por qué fue descartado/integrado/postergado, cuándo regresa al roadmap (si regresa) y cómo se relaciona con la recomendación final.

Nota sobre la nomenclatura "T1". En esta bitácora histórica, el track de monetización BPO outcome-based (candidato C-5) aparece referenciado como "T1 BPO" — era la nomenclatura usada durante la fase de evaluación. En la recomendación final, ese track se demotó a consecuencia natural del saneamiento (no es un track con nombre propio en el roadmap), y la sigla T1 se reasignó a "Agentes IA + Orquestador de Transformación Digital" — la visión TO-BE original del proyecto. Este anexo preserva la nomenclatura histórica para no falsear el razonamiento del momento.

C-1 · Compliance-as-a-product (suscripción anual sobre dotación)

Tesis (1 línea): el cliente compra cumplimiento anual prorrateado por headcount × industria × matriz de riesgo, con exámenes incluidos hasta el cap del plan; cobro adelantado, no por evento.

Decisión: descartado, subsumido por C-5. C-1 vende un plan; C-5 vende un outcome. El BPO outcome-based es C-1 + delegación funcional + integración HRIS + SLA contractual sobre el indicador final. Lanzar C-1 sin el outcome contractual deja la cuota fija sin el SLA que la justifica frente a las mineras.

Vuelta al shortlist: como tier inferior si un cliente top quiere cobro adelantado pero rechaza el outcome contractual. En ese caso C-1 funciona como puente comercial hacia C-5; el catálogo base SUSESO/ACHS/Mutual sigue siendo el contrato técnico del plan.

Relación con la recomendación final: C-1 es la versión "soft" del cambio comercial; C-5 es la versión "hard". El score ponderado (REC-2) los puso en 3.75 vs 4.50 sobre 5: C-1 pierde principalmente en radicalidad (vende un plan, no invierte el supuesto operativo más profundo) y en narrativa.

C-2 · Identity-First Operating System (sobrevive integrado)

Tesis (1 línea): el trabajador y el cliente son el contrato de datos primario del stack; antes que cualquier proceso, un servicio canónico (Workmed Identity Service) que toda integración consume.

Decisión: sobrevive integrado en la tesis TI Sovereignty. Es la primera capa técnica concreta de la sovereignty; sin él, mitigar dolores de identidad fragmentada [§3 dolor 1 mapa-cruzado] queda como aspiración. C-2 deja de ser candidato independiente y pasa a ser el primer entregable de la fase de saneamiento + sovereignty foundations (Fase 1, días 1-90).

Vuelta al shortlist: N/A — C-2 entra desde la Fase 1 como primer microservicio de FlowMed 2.0. Es la decisión arquitectónica que ancla el roadmap completo.

Relación con la tesis TI Sovereignty: C-2 es la manifestación técnica concreta de la sovereignty. Sin Identity Service, el equipo TI Workmed sigue siendo cliente del modelo de datos de Secall; con Identity Service sobre AWS Workmed propia, el equipo TI es dueño de la frontera de identidad y del consentimiento granular requerido por Ley 21.719. El score (REC-2) de C-2 fue 3.75/5, pero C-2 no compite con la tesis: la habilita.

C-3 · Desintegración de centros acreditados

Tesis (1 línea): los 6 acreditados se convierten o se desafilian; la cobertura nacional se reconstruye con sucursales propias modulares o policlínicos móviles bajo modelo white-label invertido.

Decisión: descartado de Fase 1. Alta radicalidad pero baja factibilidad de corto plazo: CAPEX de policlínicos modulares + renegociación con clientes top que valoran la cobertura nacional + riesgo real de perder cuentas si el cliente prefiere acreditado local. Score (REC-2): 3.50/5, principalmente por factibilidad 2/5.

Vuelta al shortlist: Fase 2 (12-18 meses) sólo si el SLA del BPO es inalcanzable con la red mixta actual (6 propios + 6 acreditados). C-3 pasa de movimiento estratégico independiente a consecuencia operativa de C-5.

Relación con la recomendación final: C-3 ataca el dolor 7 (40% de atenciones digitadas a mano desde acreditados) que también afecta el SLA del BPO. La validación pendiente "costo del SLA aptitud vigente >95% sobre red mixta" (Vicente + Pablo) es la métrica que decide si C-3 se adelanta. Si supera el costo de tarifa BPO razonable, C-3 entra antes de Fase 2.

C-4 · Datos clínicos como producto B2B

Tesis (1 línea): monetizar los 31 GB de log + 2.2 GB de atenciones como dashboards de inteligencia ocupacional anónima vendidos por suscripción a las mismas mineras top — y eventualmente a aseguradoras, mutuales y reguladores.

Decisión: descartado de Fase 1. Score (REC-2): 3.25/5. Línea nueva 5-10% de ingresos en 18 meses no mueve la aguja contra los dolores estructurales 1, 2, 8 y 10 que dominan el AS-IS. Requiere modelo FlowMed documentado [§3 dolor 10 mapa-cruzado; Recaudacion-20260423 1:23:16] y anonimización legal sólida antes de vender. Depende de C-2 implementado primero.

Vuelta al shortlist: Fase 3 (12-18 meses), sobre el activo ya saneado por el Identity Service, vendido como upsell a clientes BPO ya conectados. La línea de datos no compite con la línea clínica: la complementa.

Relación con la recomendación final: C-4 fue el candidato con mayor score narrativo (5/5 — "monetizamos lo que ya tenemos" es la pieza más fácil de vender al comité), pero la facilidad narrativa no compensa la baja ejecutabilidad ni la dependencia de C-2. Queda como ganancia secundaria sobre un activo que C-2 sanea antes.

C-5 · BPO end-to-end de cumplimiento ocupacional minero

Tesis (1 línea): la minera delega la función completa de cumplimiento ocupacional a Workmed (preocupacional, periódico, reincorporación, alertas, auditoría); Workmed factura tarifa fija mensual por trabajador-cubierto contra un SLA "% aptitud vigente >95%". Análogo a cómo las empresas externalizan la nómina a Buk.

Decisión inicial (durante la fase de evaluación): sobrevive como opción de monetización post-sovereignty etiquetada como "T1 BPO". Score (REC-2): 4.50/5, fue el candidato con mayor impacto + radicalidad + narrativa entre los 6, pero factibilidad 3/5 y dependencia crítica de plataforma propia con alertas automáticas lo descalifican como tesis principal en horizonte 1-180 días.

Decisión final (en la recomendación cerrada): demotado a consecuencia natural del saneamiento, no track con nombre propio en el roadmap. La sigla "T1" se reasignó a Agentes IA + Orquestador (visión TO-BE original del proyecto Workmed). El BPO outcome-based emerge como movimiento contractual disponible cuando el comité comercial detecte apetito del cliente top y la base técnica esté lista — la sovereignty + B.7 (Portal del Cliente) + B.8 (Cierre contractual) + alertas de aptitud ya entregan la infraestructura para activarlo, sin requerir un track explícito en el roadmap.

Por qué quedó como consecuencia y no como track:

• El SLA "% aptitud vigente >95%" sólo es medible automáticamente sobre plataforma propia con alertas, alertas que hoy no existen en FlowMed [Flowmed-20260409 45:44, 46:10] y que el legacy administrado por Secall no permite construir en plazos ejecutables ("2 semanas a 1 mes, a veces nunca" [Agendamiento-20260413 27:58]).
• Lanzar el BPO sobre el legacy daría un SLA ficticio que el cliente descubre en el primer cierre — repetir el patrón Workmed de "compromiso comercial sin base técnica".
• Una vez la sovereignty está en su lugar, el BPO no requiere un calendario propio: el comité comercial puede activarlo cuando detecte apetito en una negociación específica.

Relación con la tesis TI Sovereignty: C-5 no es la tesis; es una opción de monetización que la sovereignty habilita. Sin sovereignty, no es viable; con sovereignty, está disponible como cláusula contractual activable cuando comercial detecte apetito.

C-6 · EDP como objeto continuo

Tesis (1 línea): reemplazar el cierre de mes "detectivesco" por flujo continuo: el EDP es un objeto vivo que se construye día a día, visible para el cliente desde el día 1, y se "cierra" sólo cuando el cliente da approval continuo o cuando legalmente no se puede atrasar más.

Decisión: descartado, parcialmente subsumido por C-5. Score (REC-2): 3.25/5. Es optimización del ciclo financiero, no inversión del supuesto operativo profundo: bajo BPO el EDP deja de ser el objeto central, lo que hace que C-6 pierda relevancia.

Vuelta al shortlist: subsumido como capacidad de C-5. La visibilidad continua del cliente sobre su % de aptitud vigente es exactamente lo que C-6 propone, pero sobre dotación cubierta en lugar de EDP por evento. El portal cliente del Mes 3 reemplaza al portal real-time del EDP.

Relación con la recomendación final: C-6 era el candidato con menor radicalidad (3/5) pero mayor implementabilidad. Bajo C-5, su pieza más útil (visibilidad continua) sobrevive con otro sujeto de medición; el resto (script Python en corrida diaria, EDP como objeto CRUD versionado) se vuelve innecesario al desaparecer el EDP por evento como concepto.

Recapitulación · de los 6 candidatos a la recomendación final

La pregunta original "¿cuál de los 6 candidatos es el ganador?" se reformuló al constatar que ninguno de los 6 es viable mientras Workmed no controle su propia plataforma. La recomendación final que cierra el Bloque B no es uno de los 6 candidatos sino la combinación TI Sovereignty + saneamiento + visión TO-BE (T1 Agentes IA + Orquestador), que reorganiza los candidatos así:

• C-2 (Identity-First) sobrevive integrado en la tesis. Es la primera capa técnica concreta de la sovereignty (B.1 Identity Service), primer microservicio de FlowMed 2.0 en Fase 1.
• C-5 (BPO outcome-based) demotado a consecuencia natural del saneamiento. Durante la evaluación se etiquetó como "T1 BPO" pero la recomendación final lo demotó: no requiere un track con nombre propio porque la sovereignty + B.7 (Portal del Cliente) + B.8 (Cierre contractual) + alertas ya entregan la infraestructura. Activable cuando el comité comercial detecte apetito del cliente top.
• C-1 (Compliance-as-a-product) queda en bitácora. Subsumido por el modelo BPO si se activa, o como tier inferior si un cliente acepta cobro adelantado pero rechaza el outcome contractual.
• C-3 (Desafiliación de acreditados) queda en bitácora. Cuadrante D hard slogs — CAPEX alto + recompensa baja vs pipeline de digitalización Workmed-side (B.3, frontera digital que absorbe variabilidad de los acreditados independientes sin requerir control sobre ellos), que entra como Big Bet del Cuadrante B en Fase 2.
• C-4 (Datos B2B) queda en bitácora. Espera a Fase 3 sobre activo ya saneado por Identity Service + plataforma propia + gobernanza B.6; vendido como producto independiente o upsell.
• C-6 (EDP continuo) queda en bitácora. Subsumido por la visibilidad continua que la plataforma propia con alertas habilita naturalmente (B.7 Portal del Cliente fase 2); no regresa como movimiento independiente.

Lo que NO estaba en los 6 candidatos y se incorporó en la recomendación final:

La visión TO-BE original del proyecto Workmed — Agentes IA + Orquestador de Transformación Digital — no figuraba como uno de los 6 candidatos porque era el motivador del diagnóstico, no una opción a evaluar. Al cerrar la recomendación, esta visión se incorporó como T1 (Fase 3), condicionada al éxito del PoC pre-informe IA en B.4 (primer agente del ecosistema). El crecimiento volumétrico (lo que la fase de evaluación llamó "T2 Growth") también dejó de ser un track con nombre propio: emerge como consecuencia natural del saneamiento.

Secuencia ejecutable final:

• Fase 1 (días 1-90): saneamiento + sovereignty foundations. Identity Service como primer microservicio, FlowMed 2.0 diseñado, responsabilidad operativa compartida Eduardo + Rodrigo formalizada sobre el Identity Service, mail acceso AWS distribuido, script Python migrado al GitHub de Workmed.
• Fase 2 (días 91-180): primer release FlowMed 2.0, Identity Service consumido por al menos 1 sistema downstream, PoC pre-informe IA con 100 informes (primer agente del ecosistema TO-BE), PoC pipeline digitalización acreditados con 1-2 acreditados (partir por BestMed), gobernanza B.6 instalada.
• Fase 3 (días 181-365): T1 Agentes IA + Orquestador (visión TO-BE) condicionado al éxito de B.4. Crecimiento volumétrico y modelos contractuales avanzados (incluido el BPO heredero de C-5) emergen como consecuencia natural del saneamiento, sin tracks propios.