# Hallazgos — 5ta Sesión Proceso Finanzas / Comercial
## Sesión
- **Fecha:** 2026-04-16
- **Tema:** Proceso Finanzas (con cruce hacia Comercial y Agendamiento)
- **Archivo fuente:** `diagnostico/transcripts/Diagnostico-20260416-Proceso-Finanzas.final.md`
- **Duración aproximada:** 50 min 51 s (último timestamp 50:51)
- **Hablantes detectados:**
- Juan Pablo Coustasse — CFO Workmed (líder del área Finanzas; expone los dolores principales)
- Roberto Carvajal — CTO Emercom (lleva las preguntas)
- Barbarita Lara — CEO Emercom (interviene cierre y agenda)
- Data Specialist — Analista de Datos Emercom (consulta sobre HubSpot y panel de eventos)
- Mónica Pérez — PMO Workmed (coordina próximas entrevistas)
- Ignacio Ahumada — Analista, valoriza producción (interviene tarde, ~43:00 explicando el script Python)
- Desconocido-A — voz que comenta "Ricardo siempre habla de la gestión de la demanda" [28:07] (posiblemente integrante interno Workmed; no se identifica explícitamente)
## Procesos
### Proceso 1 — Ciclo Estado de Pago (EDP) → Factura
- **Gatillante:** cierre de mes (o fechas de corte por cliente); existe una atención de paciente ya finalizada en el ciclo. [4:22]
- **Pasos:**
1. Se descarga la producción del mes (todas las atenciones) desde FlowMed/Secall. — Ignacio Ahumada [4:22, 43:32]
2. Un script en Python aplica precios por tramo, precios de lista, precio unitario y validaciones varias sobre la producción. — Ignacio Ahumada [43:32, 44:08]
3. Se cruza con correos de SAC (cambios), correos de agendamiento, correos de ejecutivos comerciales, acuerdos comerciales y contratos para validar descuentos. — Ignacio Ahumada [44:27, 44:53]
4. Un área dependiente del CFO valoriza las atenciones a precio real (no de lista). [4:22]
5. Una persona del equipo de facturación revisa caso a caso (precios aplicados, centros de costo correctos) antes de entregar la producción final. — Juan Pablo Coustasse [41:44]
6. Se arman los Estados de Pago a partir de la planilla valorizada. [4:50]
7. Se cargan los EDP en HubSpot (seguimiento) y en Defontana (reconocimiento de ingresos como nota de venta). [4:50, 23:01]
8. Se envía al cliente la carátula con todas las adhesiones por sucursal + detalle por persona + código y fecha de la solicitud de agendamiento. [17:51]
9. Inicia ciclo de "peloteo" con el cliente: el cliente devuelve observaciones (centro de costo equivocado, tipo de cobro mal asignado, etc.). [5:16]
10. Una vez aceptado el EDP, el cliente envía la Orden de Compra (OC). [5:16]
11. Con la OC en mano, Workmed factura. [5:16]
- **Dueño:** Juan Pablo Coustasse (CFO) y su equipo de Finanzas (~22-23 personas)
- **Salida:** Factura emitida + ingreso reconocido en Defontana
```mermaid
flowchart TD
prod["Producción mensual
(FlowMed/Secall)"] -->|"dump base de datos"| python["Script Python
(Ignacio Ahumada)"]
python -->|"valorización + validaciones"| revfact["Revisión equipo facturación"]
revfact -->|"planilla valorizada"| edp["Estado de Pago"]
edp -->|"carga"| hubspot["HubSpot
(seguimiento)"]
edp -->|"carga nota de venta"| defontana["Defontana
(ingreso reconocido)"]
edp -->|"envío"| cliente["Cliente"]
cliente -->|"observaciones / peloteo"| edp
cliente -->|"OC aprobada"| factura["Factura emitida"]
```
**Fuentes:** [4:22, 4:50, 5:16, 23:01, 41:44, 43:32, 44:27]
### Proceso 2 — Reconocimiento contable de ingresos (Defontana)
- **Gatillante:** existencia de producción mensual valorizada (independiente de la facturación). [23:57]
- **Pasos:**
1. Se ingresa la producción como ingreso en Defontana (ej.: si producción es 1.500 millones, ingresos son 1.500 millones). [23:57]
2. Contra-cuenta de activo "Estados de pago por facturar". [23:57]
3. A medida que se factura, se mueven montos desde "Estados de pago por facturar" hacia "Deudores comerciales". [24:27]
- **Dueño:** Contabilidad (jefatura + 3 analistas, bajo Subgerencia de Finanzas) [45:47]
- **Salida:** estados financieros con ingresos reconocidos sobre base devengada de producción
### Proceso 3 — Seguimiento de cobranza en HubSpot
- **Gatillante:** EDP cargado en HubSpot como "negocio". [32:35]
- **Pasos:**
1. Cada EDP se modela como un "negocio" con 4-5 estados. [32:35]
2. Estado 1: cargado. Estado 2: enviado al cliente. Estado 3: OC recibida. Estado 4: facturado. [32:35, 33:02]
3. Una vez facturado, pasa a un flujo paralelo de cobranza tradicional. [33:02]
4. La ejecutiva de cobranza registra cada gestión (correo, llamada) en el "negocio" correspondiente. [33:02]
5. Se comparte la información con el área comercial para que los ejecutivos comerciales pidan la OC al cliente. [33:33]
- **Dueño:** Ejecutiva de cobranza (Finanzas) + ejecutivos comerciales como apoyo
- **Salida:** OC obtenida del cliente → habilita facturación
## Roles y responsabilidades
- **Juan Pablo Coustasse (CFO)** → lidera Finanzas, Contabilidad, Abastecimiento y (desde fines de 2023, "endosado" temporalmente) el área de Personas. [45:47, 46:44]
- **Subgerencia de Finanzas** → tiene a cargo Contabilidad (1 jefatura + 3 analistas), Facturación (1 jefatura + ~4 personas) y Tesorería. [45:47]
- **Ignacio Ahumada** → corre el script Python que valoriza la producción; arma proyecciones comerciales día a día y dashboards en Power BI. [7:03, 43:32, 44:08]
- **Juan Pablo Herrera** → trabaja con Ignacio Ahumada en valorización/análisis de producción. [7:03]
- **Pamela Lastra (Pame)** → jefa de Abastecimiento; administra el contrato del policlínico Codelco Ventanas (heredado porque requería un ingeniero a cargo). [46:16, 48:06, 48:37]
- **Equipo Abastecimiento** → 1 analista de inventario + 2 bodegueros; insumos clínicos (tubos orina, insumos exámenes). [46:16]
- **Subgerencia de Personas (área endosada al CFO)** → 2 subgerencias internas: Desarrollo Profesional y Calidad de Vida (vacante, en búsqueda) + Personas (remuneraciones + licencias médicas + fundación). [46:44]
- **Ejecutivos comerciales** → ahora participan en gestión de OC (antes "no estaban ayudando", hoy entienden que es parte de su trabajo). [33:33]
- **Carolina (fundación)** → maneja licencias médicas con 2 personas + Predecesorita. [46:44]
## Sistemas y herramientas
### FlowMed (vía Secall)
- **Descripción:** SaaS legacy donde se registra agendamiento, admisión y atención; fuente primaria de la producción mensual. [22:33, 23:01]
- **Usuarios:** Operaciones (agendamiento + admisión) y, downstream, Finanzas (extrae producción).
- **Entradas:** datos de agendamiento, atenciones realizadas en centros propios. [22:33]
- **Salidas:** producción mensual (no tiene cierres de mes — la producción se mueve retroactivamente). [7:34]
- **Integraciones:** Workmed mantiene una copia/espejo de la base de datos vía Secall, con desfase de ~5-10 minutos respecto a producción. [35:15, 40:27, 40:52]
### Secall
- **Descripción:** proveedor del SaaS FlowMed; provee acceso a copia de base de datos en línea (espejo de producción). [35:15, 40:52]
- **Usuarios:** equipo de datos Workmed (Ignacio, Juan Pablo Herrera).
- **Entradas:** réplica continua desde la base de FlowMed.
- **Salidas:** base poco estructurada, "un millón de tablas", consultable. [35:40]
- **Integraciones:** alimenta el script Python de Ignacio Ahumada para valorización.
### Script Python (Ignacio Ahumada)
- **Descripción:** código Python local que descarga producción desde Secall, aplica reglas de pricing y validaciones, y entrega un archivo final. [43:32, 44:08]
- **Usuarios:** Ignacio Ahumada (único operador).
- **Entradas:** dump de producción desde Secall.
- **Salidas:** archivo final valorizado en ~18 segundos de procesamiento. [43:32]
- **Integraciones:** alimenta Power BI; código vive en la computadora de Ignacio + GitHub (en su cuenta personal "por si tengo que unificar algunos"). [45:17]
### Defontana (ERP)
- **Descripción:** ERP chileno que reemplazó al fallido proyecto NetSuite; gestiona facturación, contabilidad, centros de costo, inventario y órdenes de compra. [31:39, 32:07, 48:06]
- **Usuarios:** Contabilidad, Facturación, Abastecimiento.
- **Entradas:** notas de venta (resumen del EDP), órdenes de compra de Abastecimiento, inventario, transacciones contables. [23:28, 48:06]
- **Salidas:** facturas emitidas, estados financieros, gestión de inventario. [32:07]
- **Integraciones:** recibe nota de venta desde el flujo de EDP; centralización con Buk **pendiente** (hoy se hace manual). [25:23]
- **Estado:** implementado en enero 2025; "no es un gran dolor hoy día" — temas menores de reportes e integraciones. [32:07, 32:35]
### HubSpot
- **Descripción:** CRM usado por Finanzas para seguimiento de EDP y cobranza (modelado como "negocios" con estados). [4:50, 32:35]
- **Usuarios:** Ejecutiva de cobranza, área comercial. [33:02]
- **Entradas:** EDP cargado como negocio; registro de gestiones (correos, llamadas). [33:02]
- **Salidas:** trazabilidad del ciclo EDP → factura. [33:02]
- **Integraciones:** comparte alguna data con la cuenta de HubSpot de Comercial (cuentas separadas, configuraciones distintas). [34:00, 34:30]
### Power BI
- **Descripción:** herramienta de visualización donde Ignacio Ahumada arma dashboards diarios de producción valorizada (precio de lista). [7:03, 24:56]
- **Usuarios:** Finanzas, gerencia. [7:03]
- **Entradas:** archivo final valorizado del script Python. [42:39]
- **Salidas:** paneles de avance comercial diario, balance, proyecciones, comparación con presupuesto, consideración de días hábiles. [42:39, 24:56]
- **Limitación:** "tenemos que salir del Power BI" (ver §16, meta B2B). [38:18]
### Buk
- **Descripción:** SaaS de RR.HH. y nómina; usado por área de Personas. [25:23]
- **Usuarios:** área de Personas (subgerencias de Personas y Calidad de Vida). [46:44]
- **Entradas:** datos de empleados, remuneraciones.
- **Salidas:** nómina, gestión de personas.
- **Integraciones:** centralización con Defontana **pendiente** (proyecto en curso, hoy manual). [25:23]
### Tivendo (módulo de caja, parte ecosistema Defontana)
- **Descripción:** POS / módulo de caja. [25:23]
- **Estado:** "hoy día nos sirve, pero probablemente nos va a quedar chico una vez que nos metamos en el negocio laboratorio de ensayos comunes". [25:23, 24:56]
### Power Platform (mencionado en el contexto de creación de clientes)
- **Descripción:** uno de los lugares donde se crea el cliente (junto con CRM, FlowMed y Defontana). [11:13]
- **Limitación:** contribuye a la duplicación de creación del cliente en 3+ lugares. [11:13]
### NetSuite (contexto histórico)
- **Descripción:** ERP Oracle; proyecto de implementación que **fracasó** entre 2022-2024. [31:39]
- **Estado:** abandonado a fines de 2024; reemplazado por Defontana en enero 2025. [31:39, 32:07]
```mermaid
flowchart LR
subgraph Internos
flowmed["FlowMed"]
secall["Secall
(copia DB)"]
pyscript["Script Python
(Ignacio)"]
pbi["Power BI"]
defontana["Defontana ERP"]
hubspot["HubSpot
(cobranza)"]
buk["Buk
(personas)"]
tivendo["Tivendo
(caja)"]
end
subgraph Externos
cliente["Cliente"]
end
flowmed -->|"replica continua 5-10 min"| secall
secall -->|"dump producción"| pyscript
pyscript -->|"archivo valorizado"| pbi
pyscript -->|"EDP"| defontana
pyscript -->|"EDP como negocio"| hubspot
hubspot -->|"envío EDP / cobranza"| cliente
cliente -->|"OC"| defontana
defontana -->|"factura emitida"| cliente
buk -.->|"centralización pendiente / manual"| defontana
```
**Fuentes:** [4:50, 7:03, 23:01, 23:28, 25:23, 32:35, 33:02, 35:15, 40:52, 43:32]
## Flujos de datos
- **FlowMed → Secall (copia DB):** réplica continua, desfase 5-10 minutos, "prácticamente un espejo de producción". [40:27, 40:52]
- **Secall → Script Python:** dump de producción mensual, alimentado por cron. [43:32, 40:52]
- **Script Python → Power BI:** archivo final valorizado (~18 s de procesamiento). [43:32]
- **EDP → HubSpot:** carga como "negocio" para seguimiento de cobranza. [4:50, 32:35]
- **EDP → Defontana:** transformado a nota de venta para reconocimiento de ingreso. [23:01, 23:28]
- **Workmed → Cliente:** carátula con adhesiones por sucursal + detalle por persona + código de solicitud de agendamiento + fecha. [17:51]
- **Cliente → Workmed:** Excel masivo de agendamiento (vía correo) o subido vía integración. [12:09, 12:39]
- **Buk ↔ Defontana:** centralización **manual** hoy; proyecto pendiente para automatizar. [25:23]
## KPIs
- **Producción valorizada diaria** (proyección comercial)
- Cálculo: producción FlowMed × precios de lista (no precios reales)
- Dueño: Ignacio Ahumada
- Frecuencia: día a día (a veces semanal)
- Limitación: difiere de la facturación final por descuentos por volumen y reglas especiales por cliente. [7:03, 7:34]
- **Avance vs presupuesto / días hábiles**
- Cálculo: comparación de producción acumulada con presupuesto, ajustada por días hábiles transcurridos
- Dueño: Ignacio Ahumada (Power BI)
- Frecuencia: actualización diaria con cada nueva carga de producción [42:39]
- **Estado de EDP en pipeline** (carga → envío → OC → facturación)
- Cálculo: conteo de EDP en cada uno de los 4-5 estados del "negocio" en HubSpot
- Dueño: Ejecutiva de cobranza
- Frecuencia: continuo [32:35, 33:02]
## Datos cuantitativos
- **El 90% del negocio de Workmed es preocupacional** con un flujo definido. [1:10, 1:40]
- **El equipo de Finanzas (incluyendo Abastecimiento + Personas endosado): ~22-23 personas.** [45:47, 46:16]
- **Composición Finanzas pura:** 1 subgerente + Contabilidad (1 jefatura + 3 analistas) + Facturación (~5 personas, 4 en lista) + Tesorería. [45:47]
- **Abastecimiento:** Pamela + 1 analista de inventario + 2 bodegueros. [46:16]
- **Producción mensual referenciada como ejemplo:** "fueron mil quinientos millones" (ejemplo ilustrativo del CFO sobre reconocimiento de ingresos). [23:57]
- **Desfase de la copia de base de datos Secall vs producción:** 5-10 minutos. [40:52]
- **Procesamiento del script Python:** ~18 segundos para procesar la producción una vez cargada. [43:32]
- **Tiempo de cierre de mes (producción final):** 1 a 1,5 días. [41:22, 44:27]
- **Tiempo de procesamiento diario rutinario de Ignacio:** "máximo 1 hora en la mañana o media hora". [42:13]
- **Plantillas Excel del cliente requieren ajustes manuales en el 98% de los casos** (según mención cruzada del proceso Agendamiento referida en esta sesión). [30:13]
- **Defontana implementado en enero 2025;** decisión de cambio tomada en 2024 tras fracaso de NetSuite. [31:39, 32:07]
## Mención regulatoria
- No se mencionaron leyes, decretos ni normas específicas en esta sesión.
## Stakeholders mencionados
### Internos (Workmed)
- CFO (Juan Pablo Coustasse), CTO (no nombrada explícitamente — "los gerentes de tecnología que han pasado") [39:35, 89]
- Subgerencia de Finanzas, Contabilidad, Facturación, Tesorería, Abastecimiento, Personas [45:47, 46:44]
- Equipo de datos: Ignacio Ahumada, Juan Pablo Herrera [7:03, 43:32]
- Carolina + Predecesorita (fundación / licencias médicas) [46:44]
- Pamela Lastra (Abastecimiento) [46:16]
- Max Dollmann + Ricardo Jorquera (citados como referentes en la pregunta sobre "gestión de la demanda") [28:07, 47:43]
### Clientes
- Fluor (mencionada como ejemplo: "le hicimos a la empresa Fluor por inventar el nombre"). [17:51]
- Codelco Ventanas (policlínico administrado por Workmed bajo contrato heredado por Pamela). [48:37]
- Cliente "ASAP-style" con baterías acotadas no mencionado explícitamente en esta sesión, pero el patrón de "el cliente llama a una batería 'bat 010' y nosotros le llamamos 'altura geográfica'" sí. [10:16]
### Proveedores / sistemas externos
- Secall (proveedor del SaaS FlowMed) [35:15]
- Defontana (ERP) [4:50]
- HubSpot (CRM) [4:50]
- Buk (RR.HH.) [25:23]
- Tivendo (POS, parte de Defontana) [25:23]
- Power BI (Microsoft) [7:03]
- Laboratorios externos no integrados a FlowMed (caso "Violera" o similar — nombre dudoso, ver §17). [8:04]
## Dolores / fricción
### D1 — No hay un "dueño del cliente" único antes del agendamiento
- **El dolor:** «hay errores que hoy día no tenemos claro quién crea, quién es el dueño del cliente». — Juan Pablo Coustasse [2:09]
- **A quién afecta:** Todo el ciclo aguas abajo, especialmente Finanzas al final cuando intenta cobrar.
- **Impacto:** llegan al final del proceso "sin saber cómo cobrarle al cliente". — Roberto [5:45]
- **[2:09, 2:40, 5:45]**
### D2 — Cliente creado en 3+ sistemas distintos, ninguno completo
- **El dolor:** «el cliente hay que crearlo, no sé, con el CRM, después en el Flow, en Defontana, en el Power Platform. Estamos creando un cliente como en tres lugares».
- **A quién afecta:** todas las áreas; genera inconsistencias y trabajo duplicado.
- «Estamos repitiendo esa pega y en ninguna está completo». [11:13]
- **[11:13, 11:40]**
### D3 — Ciclo largo de "peloteo" del EDP con el cliente
- **El dolor:** todos los errores acumulados aguas arriba (centro de costo mal asignado, tipo de cobro mal categorizado, batería con nombre distinto al que usa el cliente) se manifiestan al enviar el EDP, alargando el ciclo hasta obtener la OC.
- **A quién afecta:** Equipo de Finanzas (cobranza) + ejecutivos comerciales.
- «Entonces ahí nos pelotean, nos pelotean y una vez que tenemos la orden de compra nosotros en función podemos ya facturar». [5:16]
- **[5:16, 18:42]**
### D4 — FlowMed no tiene cierre de mes; producción se mueve retroactivamente
- **El dolor:** atenciones de marzo aparecen agregadas posteriormente (cuando un proveedor externo finalmente carga los datos), pero ya no quedan en el mes en que se cerró ni en el siguiente.
- **A quién afecta:** Finanzas (valorización), Contabilidad (reconocimiento de ingresos).
- «Cuando yo saco la producción a fin de mes, me quedan 10 personas que no están en ningún lado, que no puedes cobrar». [8:27]
- «Quedan obsoletas en cierto sentido, quedan en la línea de producción». [9:22]
- **[7:34, 8:04, 8:27, 8:56, 9:22]**
### D5 — Línea de crédito por cliente no está registrada ni se consume
- **El dolor:** no hay sistema que registre la línea de crédito asignada al cliente ni que descuente a medida que el cliente agenda.
- **A quién afecta:** Comercial + Finanzas (riesgo de morosidad).
- «Esa línea de crédito no está registrada en ninguna parte ni tampoco se va consumiendo en ningún lado». [6:15]
- **Estado deseado:** alerta automática cuando queda poco saldo o se sobrepasa.
- **[6:15, 6:36]**
### D6 — Diferencias entre proyección diaria (precio lista) y facturación real (precios negociados)
- **El dolor:** Power BI muestra producción a precio de lista, pero la facturación final aplica reglas especiales (descuentos por volumen, descuentos por cliente).
- **A quién afecta:** gerencia y Comercial (visión de avance distorsionada).
- **[7:03, 7:34]**
### D7 — Esfuerzo manual masivo en cierre de mes
- **El dolor:** la valorización mensual exige cruzar producción con correos de SAC, agendamiento y comerciales; revisión caso a caso de descuentos.
- **A quién afecta:** Ignacio Ahumada (~1.5 días) + 1 persona del equipo de facturación.
- **[18:42, 41:44, 44:27, 44:53]**
### D8 — Cliente entrega plantillas Excel mal formateadas (proceso aguas arriba)
- **El dolor:** el 98% de las veces requiere ajustes manuales antes de procesarse.
- **A quién afecta:** Agendamiento (mencionado de cruce); cascada de errores aguas abajo hacia Finanzas.
- **[30:13]**
### D9 — Sistema legacy (FlowMed) es difícil de modificar
- **El dolor:** «hay un sistema legacy que no es muy fácil de modificar. Se le piden cambios o cosas así o hay integraciones que se intentaron hacer que no eran».
- «Están un poco amarrados a cómo funciona este software que es bastante legacy». — Roberto [16:27]
- «Está empezando a dar muestras de que les está quedando chico». [16:56]
- **[16:27, 16:56]**
### D10 — Centralización Buk-Defontana es manual
- **El dolor:** la integración entre nómina (Buk) y ERP (Defontana) se hace manualmente.
- **A quién afecta:** Contabilidad.
- «Tenemos pendiente iría a la centralización, la estamos haciendo manual, pero tenemos un proyecto pendiente». [25:23]
- **[25:23]**
### D11 — Cultura de flexibilidad genera deuda de calidad de datos
- **El dolor:** «todos tienen la misma percepción de "lo que el cliente quiera, resolver lo que el cliente necesita lo más rápido posible". Y ahí es donde se pueden saltar un poco estas restricciones». — Roberto [19:09]
- «Nadie quiere ser el que pare la máquina». [19:09]
- **[19:09, 19:39]**
### D12 — Picos de demanda no anticipados desbordan capacidad operativa
- **El dolor:** cliente avisa "mañana llegan 200 personas"; faltan sillas, equipo médico, insumos (hasta el yogur y el juguito).
- **A quién afecta:** Operaciones, pero el dolor lo levanta el área comercial/finanzas porque "Ricardo siempre habla de la gestión de la demanda".
- **[28:07, 28:35, 29:01, 29:23, 29:48]**
### D13 — No existe RP secundario en infraestructura
- **El dolor:** «en tu diagnóstico aparezca que no tenemos RP secundario». [50:26]
- **A quién afecta:** continuidad operacional, infraestructura/redes.
- **[50:26]**
### D14 — Rotación alta de gerentes de tecnología
- **El dolor:** «hemos tenido una rotación súper grande de las cabezas que podrían guiar estos proyectos». [37:26]
- **Impacto:** muchas iniciativas pasadas quedaron como deudas técnicas.
- **[37:26, 39:06]**
## Workarounds
### W1 — Script Python local para valorización
- **Qué hacen:** Ignacio Ahumada corre un script Python en su máquina que descarga la producción desde Secall, aplica reglas de pricing y entrega el archivo final.
- **Manual o automatizado:** semi-automatizado (corre vía cron/automatización con código en GitHub personal).
- **Fragilidad:** el código vive en la máquina personal de Ignacio + su cuenta personal de GitHub ("en mi guiza lo tengo en caso de algún puche que tenga que unificar algunos"). Knowledge concentrado en una persona. [45:17]
- **[43:32, 44:08, 45:17]**
### W2 — Manejar descuentos vía cruce manual de correos
- **Qué hacen:** Ignacio cruza producción con correos de SAC, agendamiento y comerciales para validar que se apliquen los descuentos correctamente.
- **Manual o automatizado:** manual.
- **Fragilidad:** cualquier correo no recibido o no cruzado genera error en la facturación → cliente reclama → atrasa cobranza. [44:53, 45:17]
- **[44:27, 44:53]**
### W3 — HubSpot torcido para gestión de cobranza
- **Qué hacen:** modelan cada EDP como un "negocio" con 4-5 estados, fuera del uso típico de HubSpot.
- «Es un poco torcer el paquete de HubSpot». — Juan Pablo Coustasse [32:35]
- **Fragilidad:** requiere mantener configuración custom, dos cuentas separadas (Finanzas y Comercial) que no hablan entre sí. [34:00, 34:30]
- **[32:35, 34:00, 34:30]**
### W4 — Personas llegan al centro sin estar agendadas → agendamiento "express"
- **Qué hacen:** el centro inscribe a la persona en el sistema rápidamente para que pueda atenderse.
- **Manual o automatizado:** manual, sin las validaciones del flujo normal.
- **Fragilidad:** ingresa data incompleta al sistema (RUT no validado, sin centro de costo confirmado, etc.). [21:05, 21:35, 22:03]
- **[21:05, 21:35]**
### W5 — RUT inválido se ingresa como pasaporte
- **Qué hacen:** «si le falla un rut, lo ponen como pasaporte para que la persona igual no más pase, haga, haga, haga el [proceso]». — Roberto [22:03]
- **Manual o automatizado:** manual.
- **Fragilidad:** la persona queda registrada con identificador no validado → puede generar duplicados / errores de cobro. [22:03]
- **[22:03]**
### W6 — Recurrir a personal externo para absorber picos de demanda
- **Qué hacen:** los jefes de centro, al saber con un día de anticipación, recurren a "centrales que tenemos de personal externo".
- **Manual o automatizado:** manual, depende de aviso previo del cliente.
- **Fragilidad:** «la petición es de un día hacia otro»; no siempre llega el aviso. [29:01, 29:23]
- **[28:35, 29:01]**
## Excepciones y edge cases
### E1 — Atención en laboratorio externo NO integrado con FlowMed
- **Caso:** Workmed agenda al paciente en FlowMed, pero la atención se realiza en un laboratorio tercero ("Violera" o similar — confirmar nombre) que no usa FlowMed. La admisión, recepción y finalización no quedan registradas. [8:04, 8:27]
- **Consecuencia:** la atención no aparece en la producción del mes; el laboratorio tercero le cobra a Workmed pero Workmed no puede cobrar al cliente final. [8:27]
- **[8:04, 8:27, 8:56]**
### E2 — Producción retroactiva descalza meses ya cerrados
- **Caso:** atenciones de marzo se incorporan en abril cuando el laboratorio externo finalmente las reporta; ya no caben en marzo (cerrado) ni en abril (no son del mes). [8:56, 9:22]
- **[8:56, 9:22]**
### E3 — Cliente con nomenclatura propia de baterías
- **Caso:** Workmed llama "altura geográfica" a una batería; el cliente la conoce como "bat 010". Hay que mantener un traductor por cliente para los EDP. [10:16]
- **[10:16]**
### E4 — Centro de costo malformado por errores históricos
- **Caso:** «llegamos al extremo de que antiguamente, viendo que eso cambió, tal centro costo 100A, 100 espacio A, 1000A. O sea, al momento de nosotros después hacerlo estado de pago, eso nos genera altos problemas». — Juan Pablo Coustasse [3:35]
- **[3:35]**
### E5 — Negociación comercial verbal sin contrato formal
- **Caso:** «como contratos o convenios de palabra, de acuerdo como comercial, y empieza a obligar a la empresa». [3:35]
- «Está en el recuento en fronteras. No es tan claro... en el ERP cuando ya tengo una negociación en contrato, no existe». [3:08]
- **[3:08, 3:35, 15:01]**
### E6 — Venta spot vs proyecto continuo
- **Caso:** existen al menos dos modalidades de servicio (proyecto con OC previa + acumulación a fin de mes vs venta spot puntual) que requieren tratamiento distinto desde el agendamiento. [3:58]
- **[3:58]**
### E7 — Heredamiento del contrato Codelco Ventanas
- **Caso:** Pamela (Abastecimiento) "heredó" la administración del policlínico Codelco Ventanas porque el contrato exigía que un ingeniero estuviera a cargo y no podían devolverlo a otra área. [48:37]
- **[48:06, 48:37]**
## Compromisos y entregables
- **Entrevistar a Pablo (Operaciones / Subgerencia)** para perspectiva adicional. — Mónica + Roberto [49:28]
- **Entrevista con Max Dollmann y Ricardo Jorquera** agendada (originalmente para "el lunes"; reprogramada). [47:43, 49:28]
- **Entrevista con Comercial (Juan Pablo)** pendiente. [47:15]
- **Entrevista con Contraloría (Juan Pablo Vicente Rivano)** pendiente. [47:15]
- **Entrevista con Abastecimiento (Pamela)** pendiente. [47:43, 48:06]
- **Sesión adicional sobre infraestructura/redes** con "la señorita por redes" para revisar enlaces, copia de contundencia y RP secundario. — Juan Pablo Coustasse [50:26]
- **Recapitulación de iniciativas pasadas que fracasaron**, por área. — Roberto [36:35, 37:03]
## Decisiones tomadas en la reunión
- **Confirmación:** el dolor más profundo de Finanzas no es Finanzas en sí (Defontana funciona bien), sino los errores que se acarrean desde Comercial / Agendamiento hasta el EDP. [25:53, 58]
- **Agregar al diagnóstico la falta de RP secundario** en infraestructura. — Juan Pablo Coustasse [50:26]
- **Confirmación de que las cuentas HubSpot de Comercial y Finanzas están separadas** y no se comunican entre sí. [34:00, 34:30]
## Preguntas abiertas / desconocidos
- **Nombre exacto del laboratorio externo "Violera"** — Juan Pablo dice "no se me olvida" pero no lo recuerda. [8:04]
- **Tiempo exacto de la copia de base de datos:** 5 o 10 minutos (Juan Pablo no estaba seguro, ofrece confirmar). [40:52]
- **Estado/destino final de las múltiples iniciativas TI que fracasaron** en distintas áreas (NetSuite confirmado fracasado; otras pendientes de levantar). [36:35, 37:03, 37:26]
- **¿Quién va a llenar la subgerencia vacante de Calidad de Vida en el área de Personas?** — vacante en búsqueda. [46:44]
## Metas / estado deseado
### M1 — Cliente único, fuente de verdad consolidada
- «La fuente de verdad tiene que ser una sola. No pueden haber copias de clientes repartidas por distintos sistemas». — Roberto [17:25]
- Cliente, proyectos, centros de costo, responsables, modalidad de cobro, descuentos, líneas de crédito → todo registrado **antes** de que opere agendamiento. [3:58, 11:40]
### M2 — Agendamiento como compromiso pre-OC
- «Que el documento de agendamiento sea lo más formal posible para que sea casi como un compromiso a un orden de compra de parte del cliente». — Juan Pablo Coustasse [12:09]
- El cliente sube nómina vía autoservicio; el sistema valida (RUT, batería, precio) y entrega un compromiso "precocinado" al cliente. [12:39, 13:35, 14:04]
### M3 — Panel de eventos cliente-céntrico
- Trazabilidad de eventos del cliente sobre la prestación (descargó el informe → reconoce que el caso es suyo). — Data Specialist [27:36, 27:09]
- Análogo a "campaña de correo" donde uno ve si abrieron, si vieron el contenido. [27:36]
- **[15:01, 15:29, 27:09, 27:36]**
### M4 — Línea de crédito automática por cliente
- Sistema que registre y decremente automáticamente la línea de crédito a medida que el cliente agenda; alertas de saldo. [6:15, 6:36]
### M5 — B2B propio para reemplazar dependencia de Power BI
- «El B2B es súper necesario. Tenemos que salir del Power BI, tenemos que lograr que podamos crear un B2B en el que él se logee y pueda ver toda la gama de información... dependiendo de las autorizaciones o negociaciones comerciales». — Mónica Pérez [38:18, 38:40]
- **[38:18, 38:40]**
### M6 — Reformular agendamiento completo
- «El tema del agendamiento es que hay que reformularlo completo. Ese proceso hay mucho que hacer ahí». — Mónica Pérez [38:40]
### M7 — Data lake / consolidación informacional
- «Hay un proyecto que en algún minuto se quiere crear un data lake o alguna cosa para tener ya toda la información nuestra de gestión». **Estado:** "está en la idea por ahora". — Juan Pablo Coustasse [35:40]
### M8 — Centralización automática Buk ↔ Defontana
- Proyecto pendiente (hoy manual). [25:23]
### M9 — Sistema con bloqueos y alertas según criticidad del dato faltante
- Distinción entre datos "pendientes" (no bloqueantes, visibles en dashboard rojo) y datos "bloqueantes" (paran el flujo). [19:39, 20:09, 20:38]
- Permitir flexibilidad operativa sin perder trazabilidad. [21:05, 22:33]
- **[19:39, 20:09, 20:38, 21:05]**
### M10 — Reducir fricción de validación del cliente del EDP
- Que el cliente pueda revisar y aprobar rápido el EDP por solicitante o como prefiera. [10:43, 31:09]
- «Eliminar la excusa del cliente para no pagar». — Roberto [30:41]
- **[10:43, 30:41, 31:09]**
## Sorpresas / anomalías
### S1 — Reconocimiento de ingresos contra producción, no contra facturación
- Workmed reconoce ingresos sobre la base de la producción del mes (devengado), no sobre la facturación. Cuenta de activo "Estados de Pago por Facturar" se mueve contra "Deudores Comerciales" cuando se factura.
- Juan Pablo lo califica de **"particularidad que no tienen otros negocios"**. [23:57, 24:27]
- Implicación: cualquier movimiento retroactivo de la producción (ver D4, E2) impacta directamente los estados financieros ya cerrados.
- **[23:57, 24:27]**
### S2 — Conciencia explícita de que Finanzas NO es la prioridad
- Juan Pablo Coustasse explícitamente: «toda esta parte mía es la menos prioritaria para esta compañía hoy. Le metería todos los esfuerzos a la producción, al agendamiento, antes de llegar al estado de pago». [25:23, 25:53]
- Anomalía organizacional: el CFO empuja para que se invierta primero en otras áreas, no en la suya. [25:53]
- **[25:23, 25:53]**
### S3 — Confianza expresada en el proceso de transformación actual
- «Yo siento que es primera vez que esto va en serio y no tengo ninguna duda de que se va a hacer». — Juan Pablo Coustasse [40:02]
- Contrasta con el contexto histórico de iniciativas fallidas (NetSuite, intentos varios). [37:03, 39:06]
- **[39:35, 40:02]**
### S4 — Patrón cultural cross-área: "lo que el cliente quiera"
- Roberto identifica que es un **patrón cultural en TODAS las áreas entrevistadas**, no solo en una.
- «Es parte, es culturalmente lo veo en todas las áreas, eh, pero sí les trae problemas». [22:33]
- Implica que cualquier solución técnica que agregue fricción enfrentará resistencia cultural; la respuesta debe ser un sistema flexible con "alertas en rojo" más que con bloqueos duros. [19:09, 22:33]
- **[19:09, 22:33]**
### S5 — Subgerencia de Personas "endosada" temporalmente al CFO
- A fines de 2023 le pasaron Personas al CFO «por 1 ratito y que no van a ser que nunca van». — Juan Pablo Coustasse [46:44]
- Sugiere desorden organizacional histórico que está en proceso de reordenamiento.
- **[46:44]**
### S6 — Iniciativas TI fallidas son señal diagnóstica clave
- Roberto explícita el principio: «esas iniciativas son señales de por qué las necesitan, están tratando de solucionar algo». [36:35]
- Propone hacer recapitulación con cada área de qué se intentó y por qué no resultó. [37:03]
- **[36:35, 37:03, 37:26]**
### S7 — Código de valorización en GitHub personal de Ignacio
- El script Python de valorización vive en la cuenta personal ("mi guiza") de Ignacio, no en un repositorio corporativo. [45:17]
- Riesgo de continuidad alto, no comentado como dolor por los participantes (anomalía implícita).
- **[45:17]**
### S8 — Defontana se evalúa positivamente; "no es un gran dolor hoy día"
- Contraste fuerte con la mayoría de las áreas que sí reportan dolor en sus sistemas core. Implementación rápida ("en enero ya estábamos facturando"). [32:07, 32:35]
- **[32:07]**