La reunión ha ido bien.

El cliente reconoce el problema, hace preguntas concretas y parece entender el valor de la solución.

Incluso pronuncia una de esas frases que permiten cerrar la conversación con optimismo:

Envíame la propuesta y lo comento internamente.

Preparas el documento, ajustas el precio y resumes lo hablado.

Después lo envías.

Pasan unos días.

Preguntas si han podido revisarlo y recibes una respuesta amable:

Todavía estamos valorándolo.

No ha aparecido necesariamente una oferta mejor.

Puede que tu propuesta haya encontrado un competidor mucho más difícil de ver: el esfuerzo que necesita el cliente para conseguir que su propia empresa la apruebe.

Fijate lo que ocurre:

→ Tu contacto debe explicar el problema a quien no estuvo en la reunión.

→ Finanzas ve un coste, pero desconoce el impacto de esperar.

→ Tecnología descubre una posible integración.

→ Compras pregunta qué otras alternativas se han valorado.

→ Dirección quiere saber por qué debe hacerse ahora.

→ El equipo que utilizará la solución teme recibir más trabajo.

→ Cada participante observa una parte diferente de la decisión.

Y tú ya no estás en la sala.

Una propuesta tiene que hacer dos trabajos

El primero es evidente: convencer a la persona con la que estás hablando.

El segundo recibe menos atención: ayudar a esa persona a convencer a los demás.

Una propuesta puede ser clara para quien conoce el problema y resultar insuficiente para quien la recibe reenviada sin contexto.

→ El responsable financiero quizá solo vea una cifra.

→ Tecnología puede encontrar una promesa que implica trabajo para su equipo.

→ Compras puede interpretar que no se han comparado alternativas.

→ La dirección puede entender el beneficio, pero no la urgencia.

→ El usuario final puede temer que la mejora complique una forma de trabajar que, con todas sus limitaciones, al menos conoce.

Cuando esto ocurre, tu contacto se convierte en traductor, defensor y coordinador de una decisión que tú diseñaste.

Si necesita reconstruir tu argumento para venderlo internamente, todavía no le has entregado una propuesta completa.

El recorrido comienza después de enviarla

Desde fuera, la venta parece seguir una secuencia sencilla:

reunión → propuesta → decisión

Dentro de la empresa compradora puede suceder algo muy diferente:

propuesta → responsable del área → dirección → finanzas → tecnología → compras → usuarios → nuevas preguntas → revisión → decisión

No todas las personas participan en una reunión conjunta.

Algunas solo reciben el documento.

Otras escuchan un resumen improvisado.

Algunas aparecen al final, cuando modificar una condición obliga a revisar todo el acuerdo.

Cada traspaso puede eliminar contexto y aumentar la incertidumbre.

Por eso una propuesta no debe evaluarse únicamente por lo bien que presenta la solución.

También debe evaluarse por lo fácil que resulta trasladarla.

Comprender la propuesta también tiene un coste

Las empresas no valoran únicamente cuánto deben pagar.

También consideran, aunque no siempre lo expresen:

• cuánto trabajo exige evaluar la propuesta.

• cuántas personas deben participar.

• qué riesgos tendrán que asumir.

• cuánto esfuerzo requerirá la implantación.

• qué preguntas quedarán sin respuesta.

• quién tendrá que defender la decisión.

• qué ocurrirá si el resultado no es el esperado.

Una propuesta económicamente atractiva puede resultar cara de aprobar.

Otra con un precio superior puede avanzar mejor porque reduce la incertidumbre y facilita la decisión.

Esto no significa llenar el documento de explicaciones.

Una propuesta extensa también puede aumentar el esfuerzo si obliga a cada lector a encontrar por sí mismo la información que necesita.

El objetivo no es entregar más información.

Es entregar la información necesaria para que cada participante pueda tomar su parte de la decisión.

Deja un comentario

Las cinco preguntas que tu contacto tendrá que responder

Antes de enviar una propuesta conviene comprobar si quien la recibe podrá responder estas preguntas sin reconstruir toda la conversación.

1. ¿Qué problema estamos resolviendo?

La propuesta debe describir una situación reconocible para el cliente.

Necesita concretar:

• qué sucede actualmente.

• a quién afecta.

• qué evidencia lo demuestra.

• qué consecuencias produce.

• qué parte del problema queda dentro de la propuesta.

Si el problema aparece únicamente con el lenguaje del proveedor, será difícil que viaje por la organización.

2. ¿Por qué debemos actuar ahora?

Reconocer un problema no significa asignarle prioridad.

La propuesta debe explicar qué sucede si la empresa espera.

Puede tratarse de trabajo acumulado, oportunidades perdidas, exposición a errores, crecimiento previsto o dependencia de una solución temporal.

El coste de no actuar debe apoyarse en datos o supuestos visibles.

Inventar urgencia destruye confianza.

No explicar las consecuencias de esperar favorece la inacción.

3. ¿Por qué esta alternativa?

El cliente comparará la propuesta con otras opciones, aunque ninguna proceda de un competidor.

También puede:

• seguir como hasta ahora.

• resolverlo internamente.

• reducir el alcance.

• utilizar otra herramienta.

• posponer la decisión.

• no hacer nada.

Una propuesta gana credibilidad cuando reconoce esas alternativas y explica en qué condiciones encaja mejor la recomendación.

4. ¿Qué riesgo asumimos?

Toda decisión introduce riesgos.

Ocultarlos no los elimina. Solo obliga al comprador a descubrirlos y valorarlos sin ayuda.

Una propuesta útil debería explicar:

• qué debe aportar el cliente.

• qué dependencias existen.

• qué podría retrasar el proyecto.

• qué datos o accesos serán necesarios.

• qué resultados no pueden garantizarse.

• cómo se comprobarán los avances.

• qué ocurrirá si algo falla.

La claridad sobre los riesgos no debilita necesariamente la propuesta.

Puede demostrar que la solución ha sido pensada más allá de la venta.

5. ¿Qué tenemos que aprobar?

Muchas propuestas terminan con una descripción general, un precio y una invitación a continuar.

Pero la organización necesita saber qué decisión debe tomar ahora.

Puede ser:

• aprobar un diagnóstico.

• elegir una alternativa.

• autorizar un presupuesto.

• validar un alcance.

• nombrar un responsable.

• iniciar una prueba limitada.

Cuanto más ambigua sea la decisión, más fácil será aplazarla.

Deja un comentario

¿Quién tiene que sentirse seguro?

Antes de redactar la propuesta conviene identificar las funciones que pueden intervenir.

El impulsor interno

Es la persona que reconoce el problema y quiere que la iniciativa avance.

Necesita un argumento transferible y respuestas para las objeciones previsibles.

No debería asumir en solitario todo el trabajo de coordinación.

Quien autoriza la inversión

Necesita comprender el resultado empresarial, el coste, los supuestos y las consecuencias de esperar.

Probablemente no necesita conocer cada característica de la solución.

Quien utilizará el resultado

Necesita saber qué cambiará en su trabajo, qué esfuerzo requerirá y cómo se evitarán nuevas cargas.

Quien controla el riesgo

Tecnología, Seguridad, Legal, Compras o Cumplimiento pueden necesitar revisar aspectos específicos.

Si aparecen al final, sus preguntas parecerán obstáculos inesperados.

Si se identifican antes, forman parte del diseño de la decisión.

La pregunta práctica es:

Además de ti, ¿quién necesita sentirse suficientemente seguro para que esto avance?

El kit de aprobación interna

Además de la propuesta completa, tu contacto necesita un material que pueda circular sin perder su significado.

Un buen kit de aprobación puede contener:

1. La decisión solicitada

Una frase concreta:

Se propone aprobar una fase de diagnóstico de cuatro semanas para validar X antes de decidir la implantación completa.

El lector sabe desde el principio qué se espera de él.

2. La situación actual

Una descripción del problema utilizando el lenguaje y la evidencia del cliente.

No debería parecer una introducción genérica reutilizable para cualquier empresa.

3. Las consecuencias de esperar

El coste, riesgo, demora u oportunidad que continuará si no se actúa.

Los datos conocidos deben aparecer separados de las estimaciones.

4. El resultado esperado

Una definición observable de lo que cambiará.

«Mejorar la eficiencia» resulta demasiado amplio.

«Reducir el tiempo necesario para preparar cada expediente y disminuir las devoluciones por información incompleta» permite discutir alcance y medición.

5. La recomendación

Cada componente de la solución debería responder a una necesidad o reducir un riesgo.

Una lista de funcionalidades obliga al cliente a construir esa relación por sí mismo.

6. La implantación

Fases, responsabilidades, dedicación necesaria, información requerida y primeros hitos.

Una propuesta pierde credibilidad cuando promete un resultado sin mostrar el trabajo necesario para alcanzarlo.

7. Los riesgos y controles

Los principales riesgos, sus responsables y las medidas previstas para limitarlos.

Este apartado prepara las conversaciones con quienes deben proteger a la empresa.

8. El próximo paso

Una decisión concreta, una persona responsable y una fecha propuesta.

«Quedamos a vuestra disposición» es educado, pero no ayuda a mover la decisión.

Cómo puede ayudar la IA

La IA puede actuar como un equipo de revisión antes de enviar la propuesta.

Puede leerla desde distintas perspectivas:

• Dirección General.

• Finanzas.

• Tecnología.

• Compras.

• usuario final.

• asesoría jurídica o cumplimiento.

Desde cada perspectiva puede localizar:

• afirmaciones sin evidencia.

• conceptos ambiguos.

• supuestos no declarados.

• dependencias ocultas.

• riesgos no tratados.

• preguntas que impedirían aprobar.

• decisiones que no tienen responsable.

También puede transformar una propuesta validada en versiones más breves para cada participante.

Por ejemplo:

Revisa esta propuesta desde la perspectiva de Dirección Financiera. Identifica qué decisión se solicita, qué evidencia respalda el impacto, qué supuestos no están declarados y qué preguntas impedirían aprobarla. No completes la información ausente: señálala.

Esta última instrucción es importante.

La IA puede simular objeciones y reorganizar argumentos.

No debe inventar cifras, testimonios, urgencias ni riesgos que el cliente no haya confirmado.

Compartir IA aplicada: potencia tu carrera o negocio.

Dos SKILLS para que la propuesta pueda viajar

Para convertir este enfoque en una herramienta aplicable, la campaña incluye dos SKILLS compatibles con ChatGPT Work y Claude.

1. Auditar propuesta B2B

La primera SKILL analiza la propuesta y el contexto disponible.

Comprueba:

• si el problema está demostrado.

• si la decisión solicitada es clara.

• si se distingue entre datos y estimaciones.

• si aparece el coste de esperar.

• si se han considerado alternativas.

• si los riesgos están explicados.

• si cada participante encuentra la información que necesita.

• si existe un siguiente paso concreto.

El resultado no trata de corregir el estilo: es un diagnóstico de todo aquello que puede impedir que la propuesta avance internamente.

2. Crear kit de aprobación interna

La segunda SKILL parte de una propuesta ya revisada.

Genera:

• el resumen ejecutivo de una página.

• una versión para Dirección.

• una lectura económica para Finanzas.

• preguntas y respuestas para Tecnología, Compras o Legal.

• el impacto sobre los usuarios.

• riesgos, controles y dependencias.

• la decisión solicitada y el siguiente paso.

La secuencia es la siguiente:

SKILL 1 audita → SKILL 2 prepara la venta interna → las personas validan

La IA no sustituye la conversación comercial ni decide por el cliente. Lo que permite es ayudar a que el valor, la evidencia y los límites sobrevivan cuando la propuesta empieza a circular.

El test de transferencia

Antes de enviar tu próxima propuesta, entrégasela a una persona que no haya participado en la oportunidad.

Dale diez minutos y pídele que responda:

1. ¿Qué problema tiene el cliente?

2. ¿Qué ocurre si no actúa?

3. ¿Qué estamos proponiendo?

4. ¿Por qué esta alternativa?

5. ¿Qué debe aportar el cliente?

6. ¿Qué riesgos existen?

7. ¿Qué resultado se espera?

8. ¿Qué decisión debe tomar ahora?

9. ¿Quiénes podrían intervenir?

10. ¿Cuál es el siguiente paso?

Las respuestas incompletas muestran dónde se perderá el argumento cuando el documento empiece a circular.

No es una prueba de estilo.

Es una simulación del trabajo que tendrá que hacer tu contacto.

La propuesta debe funcionar cuando tú no estás

Una buena propuesta no sustituye una buena conversación.

La prolonga.

Conserva el problema, la evidencia, la lógica de la recomendación y los límites cuando pasa de una persona a otra.

Reduce el esfuerzo necesario para comprender, comparar y aprobar.

Y ayuda al cliente a realizar una parte del trabajo que normalmente permanece invisible: construir acuerdo dentro de su propia organización.

Tu propuesta seguirá compitiendo contra otras ofertas.

Pero, muchas veces, su rival más fuerte será la opción de no decidir.

La mejor defensa frente a ella no es añadir más argumentos comerciales.

Es facilitar una decisión que el cliente pueda explicar, contrastar y aprobar incluso cuando tú ya no estés en la sala.

Si estás interesad@ en estos temas dímelo y te envio los dos SKILL.
Francisco Javier López Martín - perfil de Linkedin
jlopez@tallerformacion.com

Una factura llega sin número de pedido.

En teoría, el proceso está claro: el sistema recibe el documento, comprueba los datos, lo relaciona con una orden y lo envía a aprobación.

Pero esta factura pertenece a un proveedor habitual. El servicio ya se ha prestado. El responsable que debería autorizar la excepción está de vacaciones y retrasar el pago puede afectar a una operación importante.

El sistema no puede continuar.

Una persona sí.

Busca correos anteriores, confirma quién solicitó el servicio, consulta un acuerdo que no figura en la aplicación y decide qué vía utilizar.

El caso queda resuelto. Probablemente, también queda fuera del procedimiento.

Semanas después, la empresa estudia automatizar la gestión de facturas. El proyecto se diseña a partir del flujo documentado y el caso normal funciona perfectamente.

Entonces aparecen las facturas reales.

Unas no incluyen pedido. Otras utilizan referencias antiguas. Algunas agrupan varios servicios. Ciertos proveedores tienen condiciones particulares. Los importes no siempre coinciden y las aprobaciones cambian según el centro de coste.

La automatización no ha creado las excepciones.

Solo ha dejado de ocultarlas.

El recorrido previsto no es todo el proceso

Cuando se describe un proceso, suele representarse su recorrido principal:

1. Se recibe una entrada.

2. Se comprueban unos datos.

3. Se aplican unas reglas.

4. Se obtiene una aprobación.

5. Se registra o entrega un resultado.

Este recorrido resulta útil para explicar cómo debería funcionar el trabajo. El problema aparece cuando se trata como si describiera todos los casos.

En la práctica, una parte importante del esfuerzo se concentra en situaciones como estas:

• falta un dato necesario.

• dos fuentes contienen información distinta.

• el caso no encaja en ninguna categoría.

• una regla entra en conflicto con un compromiso comercial.

• no está claro quién puede decidir.

• el sistema no permite ejecutar la solución acordada.

• existe un plazo que obliga a abandonar el recorrido habitual.

Estas situaciones - y otras - también forman parte del proceso.

Si se ignoran durante el diseño, no desaparecen después de automatizar. Se convierten en rechazos, colas, correcciones manuales, incidencias o decisiones que siguen dependiendo de unas pocas personas.

Deja un comentario

Una excepción no siempre es un error

Las excepciones contienen información sobre el diseño real del trabajo. Algunas deberían desaparecer; otras reflejan una necesidad legítima.

Conviene distinguir cinco tipos.

1. Excepciones evitables

Nacen de información incompleta, formatos incorrectos, duplicidades o incumplimientos repetidos.

La mejor respuesta suele encontrarse antes del proceso: mejorar la captura, validar la entrada o corregir la causa que genera el error. Automatizar su tratamiento puede hacer más eficiente un problema que no debería existir.

2. Excepciones legítimas

Existen porque la realidad empresarial contiene variedad. Un cliente estratégico, un país con requisitos diferentes o un producto especial pueden necesitar otro recorrido.

Aquí la pregunta no es cómo eliminar la excepción, sino si debe convertirse en una variante explícita del proceso.

3. Excepciones de criterio

Las reglas disponibles no bastan para decidir. Alguien debe interpretar el contexto, valorar consecuencias o comparar alternativas.

Estas excepciones permiten descubrir dónde reside realmente el conocimiento experto.

4. Excepciones de autoridad

La solución puede ser conocida, pero no está claro quién tiene capacidad para aprobarla.

El trabajo se detiene, escala innecesariamente o espera a la persona que suele asumir la responsabilidad. La dificultad no es tecnológica: es de gobierno y atribución de decisiones.

5. Excepciones técnicas

Un sistema, una integración o una fuente de datos no permiten continuar.

Pueden necesitar una solución técnica, pero también una vía de recuperación, un responsable y un plazo máximo tolerable.

El procedimiento muestra la intención; los casos muestran la ejecución

Para conocer un proceso real no basta con leer su documentación.

Una revisión útil puede comenzar con una muestra reciente de expedientes, solicitudes, pedidos, facturas, contrataciones o incidencias. Para cada caso conviene preguntar:

• ¿Siguió el recorrido previsto?

• ¿En qué punto se desvió?

• ¿Qué provocó la desviación?

• ¿Quién intervino?

• ¿Qué información consultó?

• ¿Qué decisión tomó?

• ¿Dónde quedó registrada?

• ¿Cuánto tiempo añadió?

• ¿Qué habría ocurrido si nadie hubiera intervenido?

El objetivo no es encontrar culpables. Es comprender qué necesita realmente el proceso para producir un resultado correcto.

Cómo construir un mapa de excepciones

El análisis puede organizarse en cinco movimientos.

Definir un resultado concreto

«Analizar Administración» es demasiado amplio.

«Conseguir que una factura válida quede registrada y aprobada dentro del plazo acordado» permite observar entradas, decisiones y consecuencias.

Compartir IA aplicada: potencia tu carrera o negocio.

Revisar casos reales

Conviene combinar casos habituales, incidencias, reclamaciones y expedientes que tardaron más de lo previsto.

Las entrevistas aportan contexto, pero la memoria selecciona. Los casos permiten contrastar lo que se explica con lo que ocurrió.

Registrar cada desviación

Para cada excepción deberían anotarse, como mínimo:

• el punto donde aparece.

• su desencadenante.

• su frecuencia aproximada.

• quién la resuelve.

• el criterio utilizado.

• el tiempo añadido.

• la consecuencia de una decisión incorrecta.

• la evidencia disponible.

Elegir un tratamiento

No todas las excepciones necesitan automatización. Las respuestas posibles incluyen:

• Eliminar: retirar una causa, actividad o requisito innecesario.

• Prevenir: mejorar la entrada para evitar que el problema llegue al proceso.

• Estandarizar: convertir una respuesta repetida en una variante o regla explícita.

• Automatizar: ejecutar una decisión estable y verificable.

• Asistir: ayudar a una persona a localizar información o comparar opciones.

• Escalar: dirigir el caso a quien posee la autoridad adecuada.

• Mantener bajo decisión humana: conservar deliberadamente el juicio cuando el contexto y las consecuencias lo justifican.

• Aceptar y vigilar: reconocer una excepción cuyo tratamiento no resulta proporcionado.

Diseñar la prueba

Una solución no está terminada porque el flujo haya sido configurado.

Debe probarse con casos normales, casos límite y excepciones conocidas. También hay que observar qué sucede cuando falta un dato, un sistema no responde o la confianza de la solución es insuficiente.

La prueba debería responder:

• ¿El caso se detecta correctamente?

• ¿Llega a la persona adecuada?

• ¿Recibe la información necesaria?

• ¿La decisión queda registrada?

• ¿Puede recuperarse el proceso si algo falla?

• ¿El tiempo total realmente mejora?

Cuándo está preparado un proceso para automatizarse

Un proceso no necesita ser perfecto. Sí necesita ser suficientemente conocido.

Antes de automatizar conviene comprobar que:

• el resultado esperado está definido;

• las entradas necesarias pueden identificarse;

• las reglas principales son comprensibles;

• las excepciones frecuentes están registradas;

• se sabe quién decide cuando una regla no basta;

• las consecuencias de los errores son conocidas;

• existe una vía de recuperación;

• puede comprobarse si el resultado es correcto.

Si varias de estas condiciones no se cumplen, la primera fase del proyecto no debería ser configurar una herramienta. Debería ser descubrir y rediseñar el proceso.

Deja un comentario

Dónde encaja la IA

La IA puede aportar valor cuando las excepciones contienen información no estructurada.

Puede ayudar a clasificar solicitudes, resumir antecedentes, localizar casos similares, detectar datos ausentes o preparar la información que necesita quien toma una decisión.

Pero existe una diferencia importante entre asistir y decidir.

Cuando las reglas son ambiguas, las consecuencias son elevadas o la evidencia es insuficiente, presentar una recomendación puede ser razonable. Ejecutar automáticamente la decisión puede no serlo.

Por eso un componente de IA debería tener fuentes autorizadas, límites de actuación, criterios de confianza, casos que obligan a escalar, registro de decisiones y una alternativa cuando no esté disponible.

La pregunta no es solo si la IA puede gestionar una excepción. También debemos preguntar quién responde por el resultado y cómo se detectará una decisión incorrecta.

Automatizar el trabajo o desplazarlo

Una automatización puede mostrar buenos resultados y, al mismo tiempo, trasladar esfuerzo a otra parte.

La entrada se procesa más rápido, pero aumentan los rechazos. El equipo original ahorra tiempo, pero otra unidad debe corregir los casos incompletos. El sistema resuelve el recorrido habitual, pero las personas expertas reciben más excepciones y con menos contexto.

Por eso la evaluación debe observar el proceso de principio a fin.

No basta con medir cuántos casos ejecuta la herramienta. También hay que medir cuántos necesitan intervención, cuánto tardan en resolverse, dónde se concentra el trabajo manual y qué errores llegan al cliente o al resultado final.

Dos SKILLS para trabajar antes de automatizar

Para convertir este análisis en algo utilizable he preparado dos SKILLS compatibles con ChatGPT Work y Claude.

1. Mapear excepciones operativas

La primera trabaja con procedimientos, casos, incidencias y notas de entrevistas.

Distingue hechos, declaraciones e hipótesis; identifica las desviaciones; clasifica las excepciones y construye un mapa priorizado con evidencia, impacto y confianza.

2. Decidir tratamiento de excepciones

La segunda recibe las excepciones priorizadas y compara posibles respuestas.

Ayuda a decidir cuáles eliminar, prevenir, estandarizar, automatizar, asistir, escalar, mantener bajo decisión humana o aceptar y vigilar. Después define controles, retorno seguro y casos de prueba.

La secuencia es deliberada:

SKILL 1 descubre y prioriza → SKILL 2 decide y diseña → las personas validan y prueban

Las SKILLS no ejecutan cambios en sistemas reales ni convierten una hipótesis en una regla automática. Ordenan el análisis, exigen evidencia y producen una base contrastable para decidir.

La pregunta anterior a la herramienta

Una herramienta puede acelerar un proceso conocido.

No puede aclarar por sí sola qué debería ocurrir cuando las reglas, los datos o las responsabilidades no están definidos.

Antes de preguntar qué automatizar, conviene preguntar:

¿Qué casos impiden que este proceso termine correctamente y cómo los resolvemos hoy?

La respuesta permite separar el trabajo repetitivo de las decisiones importantes. También permite elegir con más precisión qué eliminar, qué simplificar, qué automatizar, qué apoyar con IA y qué mantener bajo responsabilidad humana.

Si estás interesad@ en estos temas dímelo y te envio los dos SKILL.
Francisco Javier López Martín - perfil de Linkedin
jlopez@tallerformacion.com

Hay empresas que parecen ordenadas hasta que alguien se va de vacaciones.

El lunes a primera hora todo sigue en su sitio. Los puestos están cubiertos, los procedimientos existen y los sistemas funcionan. Y entonces aparece una incidencia que no encaja en el caso normal.

La persona que suele resolverla no está. Su sustituto tiene acceso a la aplicación, pero no sabe qué criterio aplicar.

El responsable formal puede firmar la decisión y desconoce por qué esa excepción afecta al cierre o al cliente. Empieza la cadena conocida: mensajes, llamadas, correos antiguos y preguntas que terminan siempre en el mismo nombre.

El organigrama no estaba equivocado. Estaba respondiendo a otra pregunta.

Un organigrama explica quién depende de quién y dónde se sitúa la responsabilidad formal. No muestra de qué personas, criterios, accesos y relaciones depende un resultado para producirse a tiempo.

Esa segunda estructura, la menos visible, es la que decide si la empresa aguanta una ausencia, una salida inesperada o un fallo de sistema.

La diferencia entre una persona valiosa y un punto único de fallo

Una persona puede ser muy valiosa sin ser un “punto único de fallo”.

En continuidad de negocio se usa esa expresión, adaptada del inglés single point of failure, para un elemento cuya ausencia interrumpe un resultado porque no hay alternativa preparada y probada.

Lo que convierte a alguien en punto único de fallo es el tiempo que tarda la organización en sustituir o verificar su trabajo, no el volumen de lo que sabe.

Dos responsables con el mismo conocimiento pueden dejar a su empresa en situaciones opuestas.

En la primera, otra persona asume el trabajo durante dos semanas.

Los criterios difíciles están explicados con casos reales, los accesos existen, los clientes importantes conocen a un segundo interlocutor y la sustitución se ha probado al menos una vez.

En la segunda, el sustituto figura en el organigrama pero nunca ha resuelto un caso completo.

La documentación describe el flujo habitual y no las excepciones. Una hoja crítica vive en una carpeta personal y el proveedor principal solo responde cuando llama la persona de siempre.

Las dos dependen de profesionales valiosos. Solo una ha convertido ese valor en una capacidad compartida.

La fragilidad no acusa a nadie. Es una característica del sistema de trabajo y de las coberturas que se diseñaron alrededor de las personas, o que nadie llegó a diseñar.

Muchas fragilidades nacen de soluciones que funcionaron

La dependencia rara vez aparece porque alguien decidiera crear un problema.

Alguien resolvió una urgencia, montó una hoja de cálculo, aprendió a tratar con un proveedor difícil o acumuló criterio después de años viendo casos. La solución dio resultado, se repitió y acabó siendo imprescindible.

Por eso estas dependencias conviven con buenos resultados. Mientras la persona, el sistema o la relación están disponibles, el trabajo funciona, y a veces funciona muy bien.

La fragilidad se hace visible cuando cambia una condición: una ausencia, un pico de volumen, una integración que falla, alguien nuevo que entra.

El rendimiento de hoy no dice nada sobre la capacidad de recuperación de mañana. Un proceso puede ser eficiente y no resistir dos semanas sin su responsable.

Deja un comentario

La prueba de los 5, 15 y 30 días

Elige un proceso concreto y plantea tres horizontes. Funciona mejor en un ámbito manejable: el cierre mensual, la elaboración de ofertas, las altas de proveedores, la nómina.

Analizar «toda la empresa» de una vez produce respuestas genéricas y ninguna acción.

5 días

¿Qué se retrasaría si la persona, el sistema o el proveedor habitual no estuvieran disponibles?

¿Qué podría asumir otra persona sin pedir instrucciones adicionales?

¿Qué accesos, datos o autorizaciones faltarían?

15 días

¿Empezarían a acumularse excepciones?

¿Qué decisiones volverían al mismo experto?

¿Qué cliente, proveedor o área interna notaría primero la ausencia?

¿Aparecerían correcciones manuales que nadie puede demostrar?

30 días

¿Qué compromisos quedarían expuestos?

¿Qué conocimiento sería difícil de reconstruir?

¿Qué parte del servicio habría que rediseñar?

¿Cuánto costaría recuperar el funcionamiento habitual si el recurso no volviera?

El ejercicio separa una incomodidad tolerable de una dependencia con consecuencias reales.

Cinco lugares donde suele esconderse la fragilidad

1. Personas

La señal evidente es la concentración del trabajo o de las decisiones en una persona.

Hay otras menos obvias: vacaciones que condicionan el calendario, autorizaciones sin respaldo, clientes que solo reconocen a un interlocutor, sustitutos que nunca han gestionado un caso completo.

La pregunta de contraste: ¿esa persona podría ejecutar el trabajo mañana, sin preguntar?

2. Conocimiento

Un procedimiento explica el caso normal.

La dependencia está en los matices: cómo se reconoce una excepción, qué dato despierta una sospecha, por qué se descartó una opción, cuándo hay que escalar.

Acumular documentos no garantiza que el conocimiento se transfiera. La prueba es más exigente: entregar un caso real a otra persona y comprobar si puede decidir, ejecutar y explicar por qué actuó así.

3. Procesos

Hay procesos bien definidos que dependen de traspasos informales, de urgencias que abandonan el flujo previsto o de controles que no dejan evidencia.

Sigue un caso de principio a fin, sobre todo cuando cambia de persona, de departamento o de sistema. Ahí aparecen las esperas, la información que falta y las decisiones sin dueño.

4. Datos y sistemas

La herramienta más crítica no suele ser la más sofisticada. Una hoja de cálculo o una integración secundaria pueden condicionar un resultado de negocio importante.

Revisa quién responde de cada herramienta, de dónde vienen los datos, cómo se controlan las versiones y cuánto se tarda en recuperar el trabajo. Tener una copia no demuestra que pueda restaurarse e interpretarse dentro del plazo.

Deja un comentario

5. Proveedores y relaciones

Parte del funcionamiento puede depender de un proveedor sin alternativa viable, de una ruta de escalado guardada en el correo de alguien o de una relación personal que nunca llegó a ser de la empresa.

Si el interlocutor habitual no respondiera durante dos semanas, ¿quién sabría qué se acordó, a quién llamar y qué alternativa activar?

Qué cambia para RRHH y Operaciones

La planificación de sucesiones mira puestos y posibles reemplazos. La continuidad del trabajo obliga a mirar capacidades concretas:

• Quién puede ejecutar un cierre.

• Quién sabe interpretar una excepción.

• Quién puede recuperar un acceso.

• Quién mantiene una relación importante.

• Quién puede explicar una decisión difícil.

Con eso, Recursos Humanos y Operaciones trabajan sobre evidencia y no sobre una matriz genérica de competencias.

Una sustitución real enseña si lo que falta es conocimiento, autoridad, práctica o acceso. Un caso mal resuelto puede indicar una necesidad de formación, y también un proceso confuso o una responsabilidad mal repartida.

No todo se arregla contratando a alguien o pagando un curso.

También cambia la incorporación.

Entrar en un puesto no es recibir documentación y una explicación del funcionamiento habitual: es exponerse de forma progresiva a casos representativos y excepciones, y comprobar qué se resuelve sin recurrir al experto de siempre.

La misma lógica sirve para una salida planificada.

En lugar de preguntar solo qué documentos deja la persona, se acuerda qué casos transfiere, qué relaciones necesitan un segundo interlocutor y qué pruebas van a demostrar que la empresa conserva esa capacidad.

Así la gestión del conocimiento deja de ser un archivo y pasa a ser algo que se puede observar.

Puntuar ayuda, pero la evidencia importa más

Un diagnóstico puede convertir estas observaciones en una escala sencilla:

• 0: no se observa fragilidad relevante, o existe una cobertura probada.

• 1: la dependencia es limitada y está razonablemente controlada.

• 2: hay una fragilidad relevante con controles insuficientes o sin probar.

• 3: una ausencia o un fallo pueden interrumpir el resultado.

La cifra obliga a tomar posición y no convierte una opinión en evidencia. Por eso conviene registrar aparte el grado de confianza de cada valoración.

Un 3 respaldado por incidentes, tiempos de espera o una prueba fallida pide una respuesta distinta de un 3 basado en una impresión aislada. En el segundo caso, la primera acción es verificar.

La conversación cambia mucho cuando se pide un caso reciente. «¿Cómo se hace?» produce la descripción ideal. «Enséñame el último caso» enseña el trabajo tal como sucede.

Deja un comentario

No toda fragilidad se resuelve documentando

Documentar puede ser útil y no es una respuesta universal. Según la causa, puede tener más sentido:

• Eliminar una actividad o dependencia que ya no aporta valor suficiente.

• Simplificar un flujo que genera excepciones y conocimiento innecesario.

• Transferir criterio mediante casos reales y práctica supervisada.

• Duplicar un acceso, un sistema, un proveedor o un interlocutor.

• Estandarizar un trabajo estable que exige consistencia y evidencia.

• Automatizar cuando hay volumen, reglas claras y datos fiables.

• Aceptar y vigilar cuando el coste de la cobertura supera el riesgo que evita.

La acción elegida necesita una prueba de cierre.

«Documentar el proceso» no demuestra que el riesgo haya bajado; «otra persona completa el cierre en el plazo previsto», sí.

«Crear una copia» tampoco basta; «restaurar una versión utilizable en dos horas» es una comprobación.

La fragilidad está resuelta el día que la cobertura funciona en una prueba real.

Dónde encajan la tecnología y la IA

La tecnología ayuda a hacer visible el conocimiento, a repartir accesos, a comparar versiones y a acelerar una recuperación.

La IA ayuda a buscar criterios y casos, a clasificar incidencias, a localizar contradicciones y a asistir a quien asume un trabajo que no es el suyo.

Para llevar eso a algo utilizable he preparado el “Radar de Fragilidad Operativa”:

• un Excel con 30 señales

• y dos SKILLs de IA que funcionan encadenadas.

Las SKILLS son paquetes de instrucciones y plantillas que se cargan en el modelo (ChatGPT Work o Claude) para que trabaje con un método fijo.

Ninguna de las dos sustituye el criterio de quien conoce la empresa. Ordenan el análisis, exigen evidencias y convierten el diagnóstico en decisiones que se pueden probar.

Dos skills para dos momentos distintos

1. Diagnosticar fragilidad operativa

Trabaja con documentos, incidencias y notas de entrevistas. Separa hechos, declaraciones e hipótesis, recorre las 30 señales del Radar, identifica dependencias y propone qué hay que verificar antes de asignar una prioridad.

Sirve para que una percepción no acabe tratada como si fuera evidencia.

2. Diseñar coberturas operativas

Parte de las fragilidades ya priorizadas y plantea alternativas proporcionadas:

• Transferencia de conocimiento mediante casos reales.

• Personas de respaldo.

• Accesos alternativos.

• Documentación útil.

• Componentes de IA cuando aporten valor.

• Medidas de control.

• Un plan de 90 días.

• Guiones para comprobar que la solución funciona.

El criterio es reducir el riesgo de interrupción con el mínimo de procedimiento nuevo.

Cada SKILL se entrega en su propio archivo ZIP, y el mismo paquete funciona en ChatGPT Work y en Claude, así que no hay que mantener dos versiones del método.

La combinación tiene una lógica.

La primera SKILL descubre y estructura las dependencias. El Excel conserva las evidencias y dibuja el Radar.

La segunda diseña alternativas. Después, las personas contrastan, deciden y prueban.

La IA acelera el trabajo que rodea al diagnóstico y deja trazabilidad; la decisión sigue siendo de quien responde del resultado.

El orden importa.

Primero hay que definir qué resultado debe mantenerse, dónde está la dependencia, qué consecuencias tendría un fallo y cómo se demostraría la recuperación. Después se elige la herramienta.

Si una solución reduce la dependencia de una persona y crea una dependencia opaca de un proveedor, de un modelo de IA o de una integración que nadie sabe supervisar, el riesgo ha cambiado de sitio.

La tecnología es una buena capa de cobertura y un mal parche para una pregunta de negocio que nadie ha formulado.

Del diagnóstico a un plan de 90 días

El resultado de este análisis no debería ser una lista interminable. Selecciona entre 3 y 5 dependencias importantes y trabaja en tres etapas.

Días 1 a 30: contener y aclarar

Confirmar accesos, reunir evidencias, nombrar responsables, explicar las consecuencias posibles y definir alternativas.

Días 31 a 60: transferir y preparar

Formar a las personas de respaldo, actualizar criterios, configurar alternativas, acordar vías de escalado y preparar casos de prueba.

Días 61 a 90: probar y corregir

Ejecutar sustituciones, restauraciones, casos difíciles o simulaciones. Registrar qué ha fallado y ajustar la cobertura.

Esta última fase es la que separa una intención de una capacidad disponible.

La pregunta que el organigrama no puede responder

El organigrama seguirá siendo necesario: ordena responsabilidades, autoridad y estructura. Lo que no puede responder por sí solo es esto.

¿Puede la empresa mantener o recuperar un resultado importante sin depender de una única persona, un único criterio, una única herramienta o una única relación?

El “Radar de Fragilidad Operativa” está pensado para contestarla con evidencia.

El KIT incluye:

• Una guía de aplicación.

• Un Excel editable con 30 señales.

• Cálculo automático en cinco dimensiones.

• Un ejemplo cumplimentado.

• Dos skills de IA compatibles con ChatGPT Work y Claude.

• Un método para priorizar las dependencias encontradas.

• Un plan de actuación de 90 días.

No es una auditoría ni una evaluación del desempeño de las personas. Convierte dependencias difusas en hipótesis verificables y en acciones con una prueba de cierre.

Si estás interesad@ en estos temas dímelo y te envio el KIT completo.

Compartir IA aplicada: potencia tu carrera o negocio.

Francisco Javier López Martín - perfil de Linkedin

Una reunión de procesos suele empezar de forma ordenada. Alguien proyecta el procedimiento vigente, se repasan sus etapas y, durante unos minutos, todo parece más o menos claro.

La claridad dura hasta que una persona dice: “Eso ya no se hace así”. Otra añade que depende del cliente. Una tercera explica que, cuando falta un dato, utiliza una hoja de cálculo que no aparece en el documento.

Poco después se descubre que una aprobación que era obligatoria se resuelve por correo y que el control final ocurre cuando ya es demasiado tarde para evitar el error.

No es que haya mala fe ni desorden extremo. Lo que aparece es la distancia normal entre el trabajo diseñado y el trabajo ejecutado.

El problema comienza cuando una empresa intenta mejorar, formar o automatizar tomando como referencia únicamente la primera versión.

El proceso no es el procedimiento

Un proceso es el trabajo que se repite desde un disparador reconocible hasta un resultado que alguien recibe. El procedimiento es uno de los documentos que intenta describir cómo debe realizarse ese trabajo.

La diferencia parece terminológica, pero tiene consecuencias prácticas.

Un proceso puede funcionar aunque nunca se haya documentado. También puede existir un procedimiento impecable que describa una forma de trabajar abandonada hace años.

Documentar y diseñar tampoco son la misma actividad. Pasar a limpio lo que aparece en un documento antiguo no mejora el proceso. A veces solo hace más legible una ficción organizativa.

Por eso conviene distinguir tres versiones que suelen convivir.

El proceso documentado

Es el que aparece en procedimientos, mapas, políticas e instrucciones. Suele describir el caso normal, utiliza nombres y sistemas oficiales y evita los detalles que parecían demasiado obvios cuando se redactó.

Tiene valor: permite conocer la intención de diseño, los controles previstos y las responsabilidades formales. Pero no demuestra que el trabajo ocurra así.

El proceso percibido

Es el que las personas cuentan cuando se les pregunta cómo trabajan.

No tiene por qué ser falso. Quien repite una actividad todos los días deja de percibir muchos pasos rutinarios. También tiende a describir una versión limpia: la secuencia habitual, sin interrupciones, urgencias ni casos difíciles.

Una entrevista aporta contexto, lenguaje y criterios. Por sí sola no permite reconstruir el proceso real.

El proceso real

Es lo que aparece al cruzar las explicaciones con casos, registros, observación y datos del sistema.

Incluye los atajos, las comprobaciones informales, las esperas entre áreas, los ficheros paralelos y las llamadas que desbloquean situaciones no previstas.

Es también el lugar donde se concentra buena parte del tiempo consumido y del riesgo operativo.

El objetivo de un buen levantamiento no consiste en elegir cuál de las tres versiones “tiene razón”. Consiste en explicar sus diferencias y decidir qué debe cambiar: el trabajo, el documento, el control o los tres.

Deja un comentario

Por qué preguntar no basta

“Cuéntame cómo lo haces” es una buena pregunta para empezar. Es insuficiente para verificar.

La conversación cambia cuando se pide: “Enséñame el último caso”. Entonces aparecen fechas, pantallas, correos, documentos, decisiones y ausencias de evidencia. El proceso deja de ser una descripción y se convierte en algo que puede seguirse.

Hay tres preguntas especialmente útiles:

1. ¿Cómo sabrías que este paso se realizó?

2. ¿Qué ocurre cuando no puede hacerse de la forma prevista?

3. ¿Quién recibe el resultado y cómo confirma que está completo?

La primera descubre controles que existen en el papel pero no dejan rastro. La segunda saca a la luz las excepciones. La tercera permite detectar dónde termina realmente el proceso, que rara vez coincide con el borde de un departamento.

Un método práctico para encontrar el proceso real

1. Definir el principio y el final

Todo levantamiento necesita un disparador y un resultado observable.

“Gestión de compras” es demasiado amplio. “Desde que un área solicita una compra hasta que el pago queda conciliado” establece un recorrido que puede seguirse.

Si el análisis empieza cuando el trabajo llega a una mesa y termina cuando sale de ella, probablemente estamos estudiando una función, no el proceso completo.

Los problemas importantes suelen vivir en los traspasos: la información que falta, el trabajo que espera y los casos que nadie confirma haber recibido.

2. Leer la documentación antes de entrevistar

El procedimiento vigente no debe aceptarse como descripción de la realidad, pero proporciona una hipótesis inicial.

Conviene identificar:

• Los pasos que deberían dejar evidencia.

• Los controles previstos.

• Los responsables formales.

• Las excepciones descritas.

• Los puntos en los que el trabajo cambia de área o sistema.

Esta lectura permite preparar preguntas concretas y evita dedicar la entrevista a información que ya estaba disponible.

3. Entrevistar roles por separado

Una reunión conjunta produce acuerdos demasiado rápidos. Cuando varias áreas describen el mismo traspaso por separado, las diferencias aportan información.

Quien entrega puede pensar que el paquete está completo. Quien recibe puede dedicar cada mañana media hora a corregirlo. Ambas personas pueden estar actuando de buena fe y, al mismo tiempo, describir dos realidades incompatibles.

La entrevista debe pedir ejemplos recientes, casos difíciles y decisiones que requieren experiencia.

Los nombres propios importan menos que los roles, salvo cuando aparece una dependencia: “esto solo sabe hacerlo Marta” es un hallazgo de continuidad, no un detalle del mapa.

4. Seguir una muestra de casos hacia delante y hacia atrás

El rastreo hacia delante comienza con una entrada y acompaña el caso hasta su resultado. Permite ver pasos omitidos, demoras y evidencias que faltan.

El rastreo hacia atrás parte de un resultado y pregunta de dónde salió. Por ejemplo: este pago se emitió; ¿dónde están la factura, el albarán, el pedido y la aprobación?

Las dos miradas son necesarias. Si solo elegimos casos desde el inicio, veremos los que entraron por la puerta prevista. No encontraremos aquello que llegó al final por una vía alternativa.

La muestra no necesita ser enorme para una primera revisión, pero sí intencionada. Debe incluir periodos de carga, personas distintas, importes altos y bajos, alguna excepción y casos seleccionados desde el resultado final.

5. Separar declaración y evidencia

Un registro del sistema con fecha y usuario es evidencia. Y puede serlo, tamhién, un documento firmado, un acuse o una observación directa registrada correctamente.

“Me han dicho que se hace” no demuestra la ejecución de un control que debería dejar rastro. Tampoco la ausencia de reclamaciones demuestra que el proceso funcione.

Esta distinción evita dos errores opuestos: acusar de incumplimiento sin base y dar por bueno un control porque todo el mundo afirma conocerlo.

Supongamos que un procedimiento exige verificar los datos bancarios de cada proveedor y registrar la comprobación. En una muestra de quince altas, nueve no contienen esa nota.

La conclusión rigurosa no es “nadie verifica los datos”. Lo que puede afirmarse es que el control no deja evidencia de haberse ejecutado en el 60 % de la muestra y, por tanto, no es posible determinar si se realizó.

La precisión mejora el diagnóstico y permite discutir una acción concreta.

6. Registrar las excepciones como parte del diseño

Un diagrama del flujo normal enseña poco sobre la capacidad real del proceso. Las preguntas más útiles aparecen cuando algo no encaja:

• ¿Quién puede autorizar una excepción?

• ¿Qué información necesita para decidir?

• ¿Dónde queda registrada?

• ¿Cómo vuelve el caso al flujo normal?

• ¿Se revisan después las excepciones repetidas?

Si una excepción ocurre todas las semanas, quizá ya no sea una excepción. Puede ser una variante legítima que el diseño nunca incorporó.

Deja un comentario

Distinguir un problema documental de un problema operativo

La distancia entre el procedimiento y la realidad no siempre significa que las personas trabajen mal.

Hay, al menos, cuatro diagnósticos posibles:

1. El proceso funciona y el documento está desactualizado. Hay que corregir el documento.

2. El documento es válido, pero resulta impracticable. Hay que revisar el diseño y sus recursos.

3. El proceso y el documento son razonables, pero un control no se ejecuta. Hace falta analizar la causa antes de recurrir automáticamente a más formación.

4. La realidad contiene una solución mejor que la formal. Conviene validarla, controlar sus riesgos e incorporarla al estándar.

Confundir estos diagnósticos produce respuestas pobres. Actualizar el procedimiento no arregla una falta de capacidad. Formar de nuevo no corrige un sistema que obliga a trabajar fuera de él. Automatizar no resuelve una responsabilidad ambigua.

Dónde puede ayudar la IA

La IA resulta útil cuando hay que trabajar con un volumen grande de material: comparar versiones de procedimientos, organizar entrevistas, localizar contradicciones, clasificar excepciones o preparar una primera tabla de hallazgos.

También puede ayudar a formular preguntas de contraste o a detectar que dos áreas utilizan términos distintos para el mismo dato.

Su límite está en la evidencia.

Si una decisión se toma por teléfono y nunca se registra, ningún modelo podrá reconstruirla con fiabilidad. Si una persona pulsa “aceptar” sin aplicar un criterio real, el texto del procedimiento no permitirá evaluar el control.

Y si nadie responde del resultado de un agente, el problema es de gobierno, no de capacidad tecnológica.

La IA puede acelerar el análisis de lo que la organización conserva. Descubrir lo que no deja rastro sigue exigiendo observar, preguntar y verificar.

Una revisión ligera para empezar

Antes de lanzar un proyecto amplio, puede hacerse una primera comprobación:

1. Elegir un proceso con impacto, volumen o dependencia de personas.

2. Definir su disparador y su resultado final.

3. Leer el procedimiento vigente y marcar entre ocho y quince puntos críticos.

4. Entrevistar por separado a los roles que entregan y reciben trabajo.

5. Seguir varios casos hacia delante y algunos resultados hacia atrás.

6. Registrar excepciones, ficheros paralelos y decisiones sin evidencia.

7. Contrastar los hallazgos con las personas afectadas.

8. Separar cambios del proceso, cambios documentales y cambios de control.

El resultado no necesita ser un informe de cincuenta páginas. Una matriz con requisito, evidencia, diferencia, impacto y acción puede ser mucho más útil.

La mejora empieza antes de diseñar la solución

Una empresa puede dedicar semanas a dibujar un proceso que nadie reconoce. Puede crear un procedimiento impecable que no ayuda a resolver el primer caso difícil.

También puede automatizar una secuencia ideal y descubrir después que la mayor parte del esfuerzo estaba en las excepciones.

Evitarlo requiere una disciplina sencilla: contrastar lo que está escrito, lo que las personas explican y lo que muestran los casos.

El procedimiento cuenta cómo debería funcionar el trabajo. Las entrevistas explican cómo se entiende. La evidencia muestra cómo funciona.

Y es esa tercera versión la que merece ser mejorada.

Tengo una SKILL de IA (funciona en Claude y ChatGPT Work) que levanta estos hallazgos en una matriz de requisito, evidencia, diferencia, impacto y acción (Gap Analysis). Si estás interesad@ en estos temas pídemela.

Compartir IA aplicada: potencia tu carrera o negocio.

Francisco Javier López Martín - perfil de Linkedin

Pega los datos de un proyecto en Claude o ChatGPT y pregunta cómo va.

Puede devolverte un porcentaje de avance, una estimación del coste final y un diagnóstico en tres líneas.

La respuesta suena razonable.

Los números parecen coherentes.

Y puede estar contándote la película equivocada.

No necesariamente porque haya calculado mal, aunque también puede hacerlo, sino porque faltaba información y el modelo ha completado los huecos con supuestos que no ha mostrado.

En determinados proyectos hay varias decisiones que cambian por completo el diagnóstico:

→ Cómo se ha medido el avance.

→ Cómo se ha distribuido el presupuesto en el tiempo.

→ Qué hipótesis se utiliza para estimar el coste final.

→ Cómo se relacionan el coste, el margen y la caja.

Este artículo explica cómo detectar esas decisiones y auditarlas.

Con un caso que puedes seguir con una calculadora.

El caso

Un contrato para instalar 100 paneles solares por 108.000 euros.

El coste presupuestado es de 100.000 euros: un coste equivalente medio de 1.000 euros por panel.

El plazo es de diez meses.

Estás en el mes cinco. Sales a la instalación y cuentas 40 paneles terminados.

Con ese único dato, ¿puedes saber si el proyecto va bien?

Aquí puedes hacer la primera prueba.

Proporciona esos datos a un modelo y pídele un diagnóstico.

Si responde sin advertir que falta información, anótalo.

Todavía no sabemos:

→ Cuántos paneles deberían estar terminados según el plan. → Cuánto ha costado completar los 40 actuales. → Cómo se ha medido y acreditado el avance. → Cómo está previsto ejecutar el trabajo pendiente.

Sin esos datos no existe un diagnóstico completo.

Solo una respuesta plausible.

Lo que los 40 paneles sí nos dicen

El presupuesto asignaba un coste equivalente de 1.000 euros a cada panel.

Por tanto, haber instalado 40 significa que se ha completado trabajo con un valor presupuestado de 40.000 euros.

Eso es el valor ganado.

No son ingresos.

No es beneficio.

No es dinero cobrado.

Es el valor, medido según el presupuesto, del trabajo realmente completado.

Para calcularlo no hemos mirado las facturas.

Es deliberado.

Si midiéramos el avance utilizando el coste incurrido, nunca podríamos detectar un sobrecoste. El coste sería, al mismo tiempo, el termómetro y lo que pretendemos medir.

Aquí aparece una primera limitación de la IA.

El modelo no puede verificar el avance físico si no recibe una fuente que lo acredite: unidades terminadas, hitos aceptados, mediciones, informes, fotografías o datos procedentes de los sistemas del proyecto.

Puede analizar esa información.

No puede inventarla ni verificar por sí solo lo que ocurre en la instalación.

El primer riesgo aparece cuando acepta un porcentaje de avance sin preguntar cómo se ha medido.

Contar paneles terminados no es lo mismo que estimar el avance a ojo.

Primera pregunta: ¿cuántos debería llevar?

Aquí aparece la curva.

Podríamos pensar que en el mes cinco de diez deberían estar instalados 50 paneles.

La mitad del plazo, la mitad del trabajo.

En la línea base de este caso, el resultado también es 50, pero no porque todos los proyectos avancen linealmente.

Durante los primeros meses se trabaja en estructura, acometidas, permisos y preparación.

Después, el equipo alcanza su mayor ritmo de instalación.

Al final, la actividad vuelve a moderarse por el conexionado, las pruebas y el cierre.

Si representamos la actividad de cada periodo, obtenemos un perfil parecido a una campana.

Si representamos esa actividad de forma acumulada, aparece una curva S.

La curva S muestra la evolución acumulada de una actividad que no se desarrolla a un ritmo constante.

En nuestro ejemplo hemos elegido una curva simétrica. Por eso coincide con el reparto lineal en el punto medio.

En otros periodos, las referencias son diferentes.

En el mes tres, por ejemplo, el reparto lineal indica 30 paneles, mientras que la línea base de este caso contempla 22.

Un proyecto con 25 paneles terminados parecería retrasado frente a una referencia y adelantado frente a la otra.

El problema no está en la curva S ni en la línea recta.

El problema está en utilizar una referencia que no representa cómo se ha planificado realmente el trabajo.

Si no defines la distribución temporal, un modelo puede asumir un reparto lineal sin justificarlo.

Por eso conviene pedirle que muestre el plan periodo a periodo y explique qué hipótesis ha utilizado para construirlo.

Segunda pregunta: ¿cuánto ha costado?

El sistema de control del proyecto muestra 46.000 euros de coste incurrido.

En España se habla habitualmente de coste real. En buena parte de Latinoamérica se utiliza costo real. El concepto es el mismo: los recursos consumidos y registrados para ejecutar el trabajo hasta la fecha.

No equivale necesariamente al dinero pagado.

Puede incluir ajustes o estimaciones de costes correspondientes a trabajo ya realizado cuyas facturas todavía no han llegado.

Ahora tenemos dos magnitudes independientes:

→ Trabajo completado con un valor presupuestado de 40.000 euros. → Coste incurrido para completarlo: 46.000 euros.

En este caso simplificado, hemos requerido un coste equivalente medio de 1.150 euros por panel terminado, frente a los 1.000 presupuestados.

No significa que cada panel tenga literalmente ese coste.

El presupuesto también incluye estructura, permisos, conexiones y otras actividades. La división sirve para traducir el desempeño total a una unidad operativa fácil de entender.

El proyecto está ejecutando el trabajo con menor eficiencia de coste que la prevista.

Y lo sabemos en el mes cinco, no cuando termina.

Las dos distancias

Representa tres líneas sobre los mismos ejes:

→ Valor planificado: lo que debería haberse completado. → Valor ganado: el trabajo realmente completado, medido según el presupuesto. → Coste real: lo que ha costado completar ese trabajo.

La distancia entre el valor planificado y el valor ganado indica una desviación respecto al cronograma.

La distancia entre el valor ganado y el coste real indica una desviación de coste.

Necesitamos las tres curvas porque ir más lento e incurrir en sobrecostes son problemas diferentes, con causas y respuestas distintas.

Hay un matiz importante.

La desviación del cronograma en el análisis tradicional del valor ganado se expresa en unidades monetarias.

Indica que el proyecto está por detrás del plan, pero no dice por sí sola cuántos días o meses de retraso existen.

Para medir el retraso en tiempo necesitamos analizar el cronograma o utilizar técnicas como Earned Schedule.

Aquí es donde la IA empieza a aportar valor

Faltan 60 paneles.

¿Cuánto costará terminar el proyecto?

Si hacemos esa pregunta sin más contexto, un modelo puede devolver una única cifra sin explicar qué supuesto ha utilizado.

Pero existen diferentes formas de estimar el coste final.

No son respuestas intercambiables.

Son escenarios construidos sobre hipótesis distintas.

Comparemos dos.

Escenario 1: el sobrecoste fue puntual

Este escenario supone que la desviación observada no se repetirá y que el trabajo pendiente podrá ejecutarse según el presupuesto original.

El trabajo restante tiene un presupuesto de 60.000 euros.

Sumado a los 46.000 ya incurridos, el coste final estimado sería de 106.000 euros.

El contrato conservaría 2.000 euros de margen.

Escenario 2: la eficiencia actual continúa

Este escenario supone que el trabajo pendiente mantendrá el coste equivalente observado hasta ahora.

Los 60 paneles restantes requerirían 69.000 euros.

Sumados a los 46.000 ya incurridos, el coste final ascendería a 115.000 euros.

El proyecto perdería 7.000 euros.

Mismo mes.

Mismos 40 paneles.

Mismos 46.000 euros incurridos.

Dos conclusiones opuestas.

La diferencia no está en la aritmética.

Está en el supuesto.

Los manuales y sistemas de valor ganado utilizan varias estimaciones independientes del coste final. En mi modelo comparo cuatro escenarios habituales, pero no porque exista una lista universal y cerrada de cuatro respuestas.

Cada escenario intenta contestar una pregunta distinta:

→ ¿La desviación fue excepcional?

→ ¿Se mantendrá la eficiencia actual?

→ ¿El retraso también afectará al coste pendiente?

→ ¿Debemos reestimar desde cero el trabajo que falta?

El trabajo útil de la IA consiste en mantener abiertos esos escenarios, calcularlos con los mismos datos y explicar qué tendría que ser cierto para que cada uno se cumpliera.

Pedirle “dame el coste final” puede esconder la decisión.

Pedirle “compara varios escenarios, muestra el supuesto de cada uno y dime qué información permitiría descartarlo” convierte la respuesta en algo auditable.

La aritmética es parecida.

Lo que cambia es la calidad de la decisión.

Compartir

Traducir el margen a una unidad operativa

El contrato se firmó por 108.000 euros y tenía un coste presupuestado de 100.000.

El margen inicial era de 8.000 euros.

Podemos traducirlo a una medida operativa dividiendo ese margen entre los 100 paneles.

El resultado es un colchón medio equivalente de 80 euros por panel.

No es el margen literal de cada unidad. Es una forma simplificada de expresar cuánto sobrecoste medio puede absorber el contrato antes de perder todo su margen.

El proyecto podía soportar un coste medio equivalente de hasta 1.080 euros por panel.

El observado hasta ahora es de 1.150.

El colchón se ha consumido y el coste equivalente está 70 euros por encima del límite.

Otra forma de verlo:

→ El presupuesto total podía absorber un sobrecoste del 8 %.

→ La eficiencia observada refleja un sobrecoste equivalente del 15 %.

Esta conversión no sustituye la estimación detallada.

Sirve para hacer visible cuánto margen existe realmente para absorber desviaciones.

Para calcularlo tampoco necesitamos IA.

Es una división.

La consecuencia financiera que no aparece si nadie la pregunta

Cuando el coste estimado comienza a superar los ingresos contractuales, Finanzas recibe una señal que no puede ignorar.

Pero la conclusión no es automática.

Un contrato es oneroso cuando los costes inevitables de cumplir sus obligaciones exceden los beneficios económicos que se espera recibir.

La evaluación debe considerar los costes directamente relacionados con el contrato, los beneficios esperados y el menor coste neto entre cumplirlo o salir de él.

Por tanto, que una estimación alcance los 115.000 euros frente a un precio de 108.000 es una alerta clara para iniciar el análisis.

No basta, por sí sola, para determinar sin más el importe de una provisión.

Si el análisis confirma que el contrato es oneroso, la obligación correspondiente debe reconocerse y valorarse como una provisión en la fecha de información aplicable.

Esto convierte una estimación operativa en una cuestión financiera.

Y aquí la IA puede ayudar, pero no decidir.

Puede cruzar los diferentes escenarios con el precio contractual, identificar cuáles generan una señal de pérdida y preparar la información necesaria para revisar el contrato oneroso.

La conclusión y el tratamiento corresponden a Finanzas y deben validarse con la normativa aplicable.

Los cinco riesgos

Ninguno depende exclusivamente del cálculo.

Todos aparecen cuando el modelo completa información que no se le ha proporcionado.

1. Puede devolver una sola cifra de coste final.

La respuesta puede ocultar qué fórmula o supuesto ha utilizado.

2. Puede aceptar el porcentaje de avance sin preguntar cómo se ha medido.

Unidades terminadas, hitos aceptados y porcentajes subjetivos no producen necesariamente el mismo resultado.

3. Puede asumir una distribución lineal.

Si no recibe una línea base temporal, puede utilizar el reparto más sencillo aunque no represente el proyecto.

4. Puede analizar la rentabilidad sin disponer de la caja.

El coste incurrido no equivale al pago. El ingreso reconocido tampoco equivale al cobro. Sin anticipos, retenciones y plazos de pago no puede evaluar la tesorería.

5. Puede proporcionar una referencia normativa incorrecta o desactualizada.

Con normativa financiera, contable o fiscal no basta con una cita convincente. La referencia debe comprobarse siempre en una fuente oficial.

Estos no son fallos inevitables de todos los modelos.

Son riesgos que un buen proceso de trabajo debe controlar.

Con lo que debes de quedarte

El dato que determina el margen suele generarse fuera de Finanzas.

El escandallo lo prepara Producción y condiciona el margen bruto.

El plan de mantenimiento nace en Ingeniería y condiciona la amortización.

La política de existencias se define en Operaciones o Logística y condiciona el capital circulante.

El avance del proyecto lo informa el equipo responsable de ejecutarlo.

La IA no cambia ese origen.

Lo que cambia es la velocidad con la que podemos cuestionar el supuesto, comparar escenarios y documentar el razonamiento.

Auditar el supuesto es trabajo de Finanzas.

Recalcular manualmente cada escenario no tiene por qué serlo.

La aritmética casi nunca es la parte más difícil.

Lo difícil es descubrir qué se dio por sentado antes de empezar a calcular.

Tres preguntas para el equipo y para la IA

¿Qué supuesto sostiene la estimación del coste final?

No basta con conocer la fórmula. Hay que explicar por qué representa razonablemente el trabajo pendiente.

¿Cómo se ha medido el avance?

Contar unidades, verificar hitos y estimar un porcentaje subjetivo pueden producir resultados diferentes.

¿Cuál es el retraso expresado en tiempo?

Un índice de desempeño del cronograma no equivale directamente a meses de retraso. Para responder necesitamos el cronograma o una medida basada en tiempo.

He construido un caso completo con Claude

→ sobre un contrato de 8,4 millones de euros

→ un modelo recalculable de 21 hojas,

→ un manual para construirlo desde cero

→ y tres prompts que permiten comparar escenarios sin que el modelo elija por ti.

Si te interesa, pídemelo

Referencias técnicas

→ Definiciones oficiales de gestión del valor ganado

→ NIC 37: provisiones y contratos onerosos

→ NIIF 15: ingresos procedentes de contratos con clientes

IA Aplicada · Claude para Finanzas · jlopez@tallerformacion.com · +34 606 94 95 66 · claudefinanzaspro.netlify.app

Francisco Javier López Martín · Perfil de Linkedin

Deja un comentario

El informe llegó impecable. Tres secciones, tono sobrio, recomendaciones numeradas y un dato de mercado que sostenía la segunda.

Pedí la fuente de ese dato y no existía. El modelo no había mentido exactamente: había construido una cifra con la forma que suelen tener esas cifras, y la había puesto donde hacía falta.

Detectarlo me costó tres minutos porque sabía dónde mirar. A quien no lo sabe le cuesta veinte, o no lo detecta, porque nada en el texto invitaba a sospechar de esa frase y no de las otras cuarenta.

Ahí está toda la diferencia, y no tiene que ver con el modelo que uses.

Los fallos no son aleatorios

Un modelo de lenguaje predice qué texto encaja mejor a continuación. Encajar bien y ser cierto coinciden casi siempre.

Cuando no coinciden, gana encajar bien. El error no aparece entonces en forma de disparate: aparece en forma de frase perfectamente construida, ocupando el hueco donde debería ir un dato.

De ahí sale una consecuencia práctica: si el mecanismo es sistemático, los errores también lo son. Y lo que es sistemático se puede nombrar.

En dos años revisando entregables hechos con IA, míos, de alumnos y de clientes, he acabado con doce patrones. No son doce ideas. Son doce sitios donde mirar, cada uno con su propia comprobación.

Nombrarlos sirve para algo muy concreto. Revisar sin taxonomía es leer entero y confiar en que algo chirríe. Revisar con taxonomía es hacer doce preguntas, y doce preguntas se hacen en cinco minutos.

Bloque 1. Lo que dice y es falso

Los cuatro fallos que producen una afirmación incorrecta. Son los más fáciles de cazar y los que más gente se salta.

1. Dato inventado. Una cifra, una cita o una referencia normativa que no existe. Suena bien porque está construida con el patrón correcto.

Comprobación: pide la fuente y ábrela. Una fuente inventada no sobrevive a un clic.

2. Dato caducado. El dato existió y era correcto. Ya no lo es. Este pasa desapercibido porque la fuente sí abre.

Comprobación: no preguntes por la fuente, pregunta por la fecha del dato. Y compárala con la fecha de la decisión que vas a tomar.

3. Causa atribuida sin evidencia. El fallo más caro en trabajo de gestión. Le das una variación y te devuelve una explicación. La explicación es razonable y no está sostenida por nada.

Comprobación: hazlo tú, no se lo pidas a él. Subraya cada frase que explique un porqué y escribe al lado el dato que la sostiene. Las que se queden en blanco son hipótesis. Y son justo las que ibas a firmar como causas.

4. Cálculo encadenado. El paso uno está bien, el dos está bien, el cuatro arrastra un error del tres y el resultado final es coherente consigo mismo.

Comprobación: recalcula el resultado final por una vía distinta, no revises los pasos. Revisar los pasos uno a uno es exactamente lo que el error aprovecha.

Bloque 2. Lo que no dice

Estos cuatro no dejan huella en el texto. Por eso son los peligrosos: no hay nada que leer, hay algo que falta.

5. Omisión del punto que más importa. Todo lo que aparece es correcto. Lo que decidía el asunto no aparece.

Comprobación: antes de leer la respuesta, escribe en un papel las tres cosas que esperas encontrar. Luego compara. Sin esa lista previa no tienes forma de notar una ausencia.

6. Contexto ignorado. Le entregas veinte páginas de información del cliente y usa tres frases, casi siempre las del principio.

Comprobación: el test del nombre tachado. Tapa el nombre de la empresa. Si el documento sigue valiendo igual, no ha analizado a esa empresa, ha rellenado una plantilla.

7. Sin caso extremo. Solo contempla el escenario normal. Cero ventas, mes sin actividad, valor negativo, duplicado: nada de eso está.

Comprobación: fuerza los límites tú. Mete un cero, un valor negativo y un registro repetido, y mira qué se rompe.

8. Convergencia prematura. Le pides opciones y te da seis, todas razonables, ninguna incómoda. Parece amplitud y es lo contrario.

Comprobación: antes de leer su lista, escribe tú dos opciones: la que crees que va a proponer y una que te parezca mala. Si su lista no contiene ninguna que no se te hubiera ocurrido, no ha ampliado tu criterio. Te lo ha devuelto ordenado.

Bloque 3. Cómo llega a ti

Los ocho anteriores están dentro del texto. Estos aparecen alrededor: en la conversación que tuviste para producirlo y en la forma en que acaba entregado.

9. Capitulación bajo presión. Le discutes una cifra y la cambia. No porque hayas aportado un dato nuevo, sino porque has dudado. Aparece en el trabajo de ida y vuelta, que es como se trabaja de verdad. Casi nunca en la primera respuesta.

Comprobación: pon en duda algo que sabes que está bien. Si lo defiende, puedes darle algún crédito al resto. Si se pliega ante algo correcto, no tienes forma de saber qué de lo anterior era convicción y qué era complacencia.

10. Contradicción interna. El resumen ejecutivo dice una cosa y el detalle de la página seis dice otra. En documentos largos aparece casi siempre.

Comprobación: lee el resumen y, a continuación, solo la última frase de cada sección, seguidas. Ignora el desarrollo. Las contradicciones se ven al juntar los remates; leídas en su sitio, cada una parece razonable.

11. Salida no accionable. Describe, compara, concluye, y nadie sabe qué hacer el lunes por la mañana.

Comprobación: tres preguntas. Quién hace qué. Para cuándo. Cómo sabremos dentro de tres meses si funcionó. Si el documento no responde a las tres, no es una recomendación.

12. Incumplimiento del formato pedido. Pediste cinco secciones y trae siete. Pediste una tabla y trae prosa. Empieza cumpliendo y se olvida a la mitad.

Comprobación: cuenta. Literalmente. Es la comprobación más tonta de las doce y la que más veces salta.

El orden importa

Las doce en cinco minutos solo funcionan si las haces en este orden:

1. Cuenta el formato (fallo 12). Diez segundos y te dice si hay que devolverlo antes de leer nada.

2. Lee el resumen y luego el remate de cada sección, seguidos (fallo 10).

3. Pide fuentes y fechas de los tres datos que sostienen el argumento (fallos 1 y 2).

4. Recalcula el resultado final por otra vía (fallo 4).

5. Compara con tu lista previa de lo que esperabas (fallo 5).

6. Tapa el nombre (fallo 6).

7. Subraya las causas y busca el dato de cada una (fallo 3).

8. Fuerza los límites y contrasta su lista con la tuya (fallos 7 y 8).

9. Discute algo que sabes que está bien y mira si lo defiende (fallo 9).

10. Busca el quién, el cuándo y el cómo lo mediremos (fallo 11).

Empezar por el formato y terminar por la acción tiene una razón: los dos extremos son los que más rápido descartan un documento entero, y el trabajo caro está en el medio.

Si no trabajas en finanzas

Los doce son los mismos en cualquier función. Lo que cambia es por dónde empiezas.

• Consultoría → el 6. La respuesta que valdría para cualquier cliente del sector.

• Operaciones → el 7. El procedimiento que solo cubre el día en que todo va bien.

• RRHH → el 3. Una explicación segura de por qué se va la gente, sin un dato detrás.

• Finanzas → el 4. Los cálculos van encadenados y el error viaja hasta el final sin dejar rastro.

• Dirección → el 11. Seis páginas de análisis y ninguna decisión.

La taxonomía es una. El orden de sospecha lo pone tu oficio.

La regla

Ningún entregable sale de tus manos si no puedes decir de dónde viene cada afirmación relevante. No cada frase: cada afirmación relevante.

Suelen ser cinco o seis. Comprobarlas cuesta menos que explicar en una reunión por qué la número tres no era cierta.

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

Deja un comentario

Por qué el modelo te contesta con seguridad sobre datos que nunca le llegaron, y cómo comprobarlo desde el propio chat.

Te ha pasado esto.

Abres un informe en PDF, seleccionas la tabla que te interesa, la copias y la pegas en el chat. Preguntas por la evolución de una partida. La respuesta llega bien redactada, con su porcentaje y su explicación.

Y algo no encaja. El número que menciona no es el que tú ves en el documento. O sí lo es, pero pertenece al otro año.

Lo primero que piensas es que el modelo ha alucinado. Casi nunca es eso.

El dato llegó mal. Y llegó mal por un paso que hiciste tú sin considerarlo un paso: seleccionar y pegar.

Ese Ctrl+C es una extracción

Copiar texto de un PDF no copia lo que ves. Ejecuta un algoritmo de extracción, el que trae incorporado tu visor.

Un PDF no guarda “aquí hay una tabla de dos columnas”. Guarda instrucciones de dibujo: coloca este carácter en esta coordenada de la página.

Cuando seleccionas y copias, alguien tiene que decidir en qué orden salen esos caracteres. Ese alguien es el visor, y toma la decisión sin consultarte.

Pega en un editor de texto plano el contenido de una tabla de un PDF. Vas a ver lo que copiaste en realidad:

Inmovilizado material 84.200,00 79.410,00 Existencias 18.340,50
21.905,20 Deudores comerciales 25.909,50 23.110,80

Esa es la tabla. Sin columnas, sin cabeceras, sin la línea de arriba que decía en qué unidad están las cifras.

Eso es lo que le llega al modelo cuando pegas.

Los tres síntomas que ya has visto

Cada uno tiene una causa concreta y todas ocurren antes de que el modelo lea nada.

El año cambiado

Es el más frecuente con tablas comparativas. Pegas dos columnas, 2025 y 2024, y las cifras salen entrelazadas en una sola tirada.

El modelo recibe una lista de números sin marca de a qué columna pertenece cada uno. Los reparte con la lógica que puede, que suele ser alternar, y acierta más o menos según cómo se maquetara la tabla.

Cuando falla, no falla del todo. Acierta unas filas y otras no, que es lo que hace difícil detectarlo revisando por encima.

El resumen fluido de un documento que dice otra cosa

Este aparece con memorias, informes y papers maquetados a dos columnas.

Copiar recorre la página de izquierda a derecha, así que la primera línea de la columna izquierda se pega con la primera de la derecha. El texto queda partido a mitad de frase, una y otra vez.

Aquí pasa algo que conviene entender bien, porque explica por qué el problema pasa desapercibido: el modelo repara ese texto mientras lo lee.

Tiene toda la capacidad del mundo para reconstruir sentido a partir de fragmentos, así que te devuelve un resumen coherente y bien escrito. De un documento que decía otra cosa.

El texto de entrada estaba roto. La salida no lo parece.

La unidad desaparecida

“Cifras expresadas en miles de euros” está una vez, arriba, en una línea suelta encima de la tabla.

Si seleccionaste solo la tabla, esa línea se quedó fuera. Y el modelo no tiene forma de saber si 4.218 son cuatro mil euros o cuatro millones doscientos mil.

Va a elegir una. Y si eliges mal, todo lo que salga de ahí está mal por un factor de mil, con todas las sumas cuadrando.

Por qué te contesta con tanta seguridad

Esta es la parte que desconcierta más, y tiene explicación.

El modelo no recibe una señal de que falte algo. Recibe una lista de números y una pregunta.

No hay excepción, no hay hueco, no hay celda vacía. La entrada está completa desde su punto de vista, porque no conoce el documento original.

Compara esto con cualquier otro fallo que te encuentres en el trabajo. Una fórmula rota en Excel devuelve #¡REF!. Un enlace muerto devuelve un 404.

Una extracción rota devuelve texto que se lee sin problema.

El error no viaja como error. Viaja como dato.

Compartir IA aplicada: potencia tu carrera o negocio.

Lo que cambia si subes el fichero

Aquí está la parte que le da la vuelta al consejo que circula por ahí.

Según la documentación de Anthropic, cuando adjuntas un PDF a Claude el texto de cada página se envía acompañado de la imagen de esa página, y el modelo analiza las dos cosas.

Eso significa que la maqueta original sigue disponible. Si la extracción de texto entrelaza dos columnas, la imagen de la página sigue ahí para desmentirlo.

Cuando copias y pegas, esa segunda vía desaparece. Le entregas el resultado de una extracción, ya cocinado, sin nada que lo compense.

De ahí sale la regla práctica: si el documento cabe, adjúntalo en vez de pegarlo.

Con matices, para no venderlo de más. Depende de la vía por la que trabajes y del tamaño del documento.

Cada página cuesta entre 1.500 y 3.000 tokens solo de texto, más lo que ocupa la imagen. Con documentos de cientos de páginas la aritmética cambia.

Y ojo con generalizar el consejo a cualquier formato. Un Excel, un Word o un CSV se suben y funcionan, porque llevan la estructura guardada dentro del archivo. El caso difícil es el PDF, junto con el escaneado.

¿Y si uso una herramienta en condiciones?

Es la reacción normal al llegar aquí. Si el problema es que copiar y pegar extrae mal, se coge un convertidor serio y listo.

MarkItDown es el más conocido ahora mismo. Le das el PDF y te devuelve Markdown. Docling, de IBM, tarda más y respeta mejor las tablas.

Son mejores que el Ctrl+C de tu visor. En algunos casos, mucho mejores.

Pero hacen la misma operación: inferir estructura a partir de coordenadas. Los mismos tres síntomas de arriba siguen sobre la mesa, con menos frecuencia.

Y aparece uno nuevo, que es el que más me preocupa de los dos.

El resultado limpio inspira más confianza

El PDF original está sucio. Membretes, números de página, notas al pie en cuerpo seis, tablas descuadradas.

El Markdown que sale del convertidor está impecable. Encabezados, listas, tablas alineadas, todo en su sitio.

Así que te fías más del segundo. Lo abres, lo ves ordenado y das por hecho que ha ido bien.

Cuando pegas a mano, el churro de números sin columnas te avisa de que algo se ha perdido. El Markdown limpio no avisa de nada.

El documento con menos información de los dos es el que inspira más confianza. Parte de lo que se perdió por el camino era el desorden.

Y encima quitas la imagen

Aquí es donde el consejo de convertir se vuelve contraproducente.

Si adjuntas el PDF, va el texto extraído más la imagen de cada página. Si conviertes primero y entregas el Markdown, solo va el Markdown.

Le has quitado la vía que compensaba los fallos de la otra.

Convertir tiene sentido con volumen, en procesos automáticos, o cuando el documento no cabe. Como paso de higiene por delante de todo, resta.

Tres comprobaciones que caben en un prompt

Valen para los dos casos, pegado a mano o convertido con herramienta. Ninguna necesita instalar nada.

1. Pide la tabla antes que el análisis

Antes de preguntar nada sustantivo, pide que te devuelva la tabla tal como la ha entendido, con sus cabeceras y todas sus filas.

Suena a paso perdido. Es el que más pronto detecta el desastre, porque el problema se ve al instante: cifras en la columna que no toca, filas de menos, cabeceras repetidas.

Comparar esa tabla con el documento lleva veinte segundos, y es una comparación visual, no un ejercicio de fe.

2. Pregunta por la unidad

“¿En qué unidad están estas cifras y de dónde sacas esa información?”

La respuesta interesante no es la unidad. Es la segunda parte.

Si te dice que lo deduce por la magnitud de los números, no lo sabe. Está estimando, y ese es el momento de darle la línea que se quedó fuera de la selección.

3. Haz que sume

Cualquier documento con totales trae su propio control incorporado. Las partidas suman el subtotal, y los subtotales suman el total.

Pídele que sume las partidas y compare el resultado con el total que aparece en el documento.

Si no cuadra, la extracción se rompió, y lo sabes sin volver al original. Un descuadre caza tres fallos de golpe: columnas entrelazadas, signos perdidos y separadores decimales mal leídos.

Un detalle que ayuda a diagnosticar. Si el descuadre dividido entre dos coincide con una partida del documento, el fallo es de signo y no de columna.

Una cifra negativa sumada en positivo desplaza el total en el doble de su valor.

Lo que ninguna de las tres detecta

Conviene saberlo, porque si no las comprobaciones dan una tranquilidad que no corresponde.

Un error uniforme de escala pasa el cuadre sin despeinarse. Si todo está multiplicado por mil, las sumas siguen dando.

Una nota al pie que se quedó fuera de la selección tampoco altera ninguna suma. La cifra llega sola, sin el dato de que incluye un ajuste extraordinario, y el análisis que salga de ahí será coherente y falso.

Y un dígito mal leído en un escaneo solo aparece si esa cifra participa en algún total que estés comprobando.

Por eso las tres comprobaciones no se sustituyen entre sí. Cada una cubre un trozo distinto.

El tercer camino

Hay una opción intermedia que se usa poco y resuelve buena parte de los casos.

En vez de leer el documento, el modelo puede abrirlo con código y enseñarte lo que ha sacado. Anthropic trae skills de serie para eso, una por formato: pdf, docx, xlsx y pptx.

La diferencia no está en quién hace la extracción. Está en que puedes verla.

Cuando copias y pegas, el resultado te llega ya hecho y sin manera de saber qué se quedó por el camino.

Cuando la extracción ocurre dentro de la conversación, puedes pedir la tabla, pedir la suma, pedir que contraste el total.

Deja de ser un paso a ciegas y pasa a ser un paso con respuesta.

Necesita entorno de ejecución, así que no está en todas partes ni en todos los planes.

Prueba esto con un documento tuyo

Nada de lo anterior hay que creérselo. Coge un informe tuyo que tenga una tabla con dos columnas de datos.

Adjunta el fichero y pide la tabla completa, con cabeceras y unidades. Guarda el resultado.

Ahora abre el PDF, copia esa misma tabla, pégala en un chat nuevo y pide lo mismo.

Compara. Mira tres cosas: si las cifras están en la columna correcta, si sobrevive la línea de la unidad, y si aparecen las notas al pie.

Con una tabla sencilla saldrán iguales. En cuanto la tabla se complica, dejan de salir iguales.

Dónde acaba esto

La costumbre de pegar texto, y la de convertirlo antes, vienen de cuando los modelos solo leían texto plano. Era lo único que había.

Eso cambió y los dos gestos se quedaron. Y ahora restan, porque tiran información que el modelo podría haber usado.

Antes de pegar o de convertir, tres preguntas.

¿Existe el documento en un formato que ya lleve la estructura dentro? ¿Cabe el fichero entero?

¿Y si necesito extraer datos concretos, puede hacerlo dentro de la conversación, donde lo veo?

Las comprobaciones de este artículo, junto con el catálogo completo de lo que se rompe al convertir, están empaquetadas en un skill: preflight-documental. Si lo necesitas pidemelo

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para financieros?

👉 Enlace Formación Claude para Financieros

Deja un comentario

Acceso a Manual, de más de 300 paginas, para profesionales no técnicos. En este post de Linkedin verás cómo lo puedes conseguir.

Hay una carpeta en tu ordenador que contiene esto:

Informe_Q3_v2.docx
Informe_Q3_v2_REVISADO.docx
Informe_Q3_v2_REVISADO_JM.docx
Informe_Q3_final.docx
Informe_Q3_final_ok.docx
Informe_Q3_final_ok (1).docx
Informe_Q3_ESTE_SI.docx

Sabes cuál es el bueno porque te acuerdas. Dentro de siete meses no te vas a acordar, y la persona que ocupe tu puesto tampoco.

Ese es el problema, y no es de orden ni de disciplina. Tu sistema de archivos guarda fotos sueltas de un documento en momentos distintos, sin fecha fiable, sin autor y sin ninguna explicación de por qué cambió lo que cambió.

Cuando alguien pregunta “¿por qué bajamos la tasa de descuento en septiembre?”, la respuesta está en la memoria de quien estuviera ese día en la reunión.

Los programadores tuvieron este problema antes que nadie, porque escriben miles de archivos de texto que se pisan entre sí. Lo resolvieron en 2005 y llevan desde entonces usando la solución todos los días.

Se llama control de versiones. La implementación que ganó se llama Git, y GitHub es la web donde vive.

La confusión habitual es pensar que eso es para código. No lo es. Sirve para cualquier cosa que sea texto y cambie con el tiempo, y eso incluye casi todo tu trabajo:

• Metodologías y criterios de valoración.

• Políticas internas y procedimientos.

• Actas y registros de decisión.

• Prompts que ya te funcionan.

Qué hace exactamente

Cada vez que terminas un cambio con sentido, lo confirmas y escribes una nota. Eso genera un punto en la historia del proyecto, con seis datos: qué había, qué hay ahora, qué línea cambió, quién lo hizo, cuándo y por qué.

La parte que importa no es la técnica. Es que el sistema te obliga a escribir el porqué y luego lo conserva para siempre pegado al cambio que explica.

Un ejemplo real de cómo se ve eso:

Actualizo la tasa de descuento del 8% al 9,5%

El comité de inversiones del 12 de septiembre aprobó revisar la
prima de riesgo tras la subida de tipos del BCE de julio. El cambio
reduce la valoración de Acme en un 14%, de 42 a 36 millones.

Fuente: acta del comité, disponible en 01-contexto.

Dentro de dos años, cuando un auditor pregunte de dónde sale ese 9,5%, la respuesta ya está escrita. No hay que reconstruirla, ni buscar en el correo, ni llamar a alguien que ya no trabaja allí.

Compáralo con lo que tienes ahora: un archivo llamado Valoracion_Acme_v4.xlsx cuya fecha de modificación es el 12 de septiembre. El cuándo sí lo tienes. El por qué no lo tuviste nunca.

Dónde falla, para que no te lo vendan mal

Esto no sirve igual para todo, y conviene saberlo antes de empezar y no después.

Con archivos de texto plano, y eso incluye Markdown y CSV, ves la diferencia exacta entre dos versiones: la línea vieja en rojo, la nueva en verde, el resto en gris.

Con un .docx o un .xlsx, no. Se guardan bien y puedes recuperar cualquier versión anterior completa.

Lo que no vas a ver es qué párrafo cambió, porque por dentro no son texto.

Esto tiene dos consecuencias prácticas.

La primera es que el material que quieres poder comparar conviene escribirlo en Markdown. Es texto normal con unas pocas marcas: dos asteriscos alrededor de una palabra la ponen en negrita, una almohadilla al principio de una línea la convierte en título.

Se aprende en veinte minutos, se abre en el Bloc de notas y se leerá dentro de veinte años.

La versión maquetada en Word se genera al final, cuando el documento sale hacia fuera.

La segunda es que Excel merece un tratamiento aparte. Un modelo financiero no se puede pasar a texto, así que se guarda tal cual y se le añaden dos exportaciones:

• La hoja de datos, a CSV.

• El volcado de fórmulas, a un archivo de texto.

Cuestan un minuto por cierre y convierten un binario opaco en algo que un auditor puede revisar línea a línea.

Tampoco sirve para tres casos:

• Archivos grandes que cambian a diario.

• Dos personas escribiendo a la vez en el mismo párrafo.

• Cualquier cosa que contenga datos personales.

El tercero no es una recomendación blanda. El historial es inmutable, y eso choca de frente con el derecho de supresión del RGPD.

Los datos de personas se quedan en el sistema de gestión de la empresa.

Un caso completo

Una revisión de la política de teletrabajo. Existe una versión de 2024 en Word, dirección pide adaptarla a la normativa nueva, participan Legal y un responsable de área.

El montaje son cinco carpetas:

politica-teletrabajo/
├── 01-contexto/          el encargo, las actas
├── 02-version-anterior/  la política de 2024, intacta
├── 03-trabajo/           la redacción en curso
├── 04-entregable/        la versión final para firmar
└── 05-archivo/           lo descartado

Lo primero que se hace, antes de tocar nada, es subir el Word de 2024 a 02-version-anterior. Ese punto es lo que permite responder dentro de dos años a “¿qué decía exactamente antes?”.

Después se pasa el contenido a Markdown en 03-trabajo, que es donde se puede comparar.

Los cambios se hacen uno a uno. Tres cambios, tres confirmaciones:

• Paso de dos a tres días de presencia. La nota explica que la decisión es de dirección del 2 de septiembre, que martes y jueves son fijos para garantizar solape entre áreas, y que el tercer día lo elige cada equipo para no romper la conciliación.

• Apartado nuevo de registro horario, con la referencia a la norma que lo obliga.

• Ampliación del equipamiento a monitor y silla, o ayuda de 300 euros, tras las quejas de la encuesta de julio.

La tentación es cambiarlo todo y confirmar una vez. Lo que se pierde ahí es exactamente lo que hace útil el sistema.

En paralelo va un archivo de decisiones: una tabla con fecha, qué se decidió, por qué y quién.

Lleva un apartado que no suele escribirse y que resulta ser el más rentable, el de lo descartado. “Cuatro días de presencia: rechazado por impacto en rotación.” “Ayuda mensual en lugar de pago único: complejidad de nómina.”

Ese apartado evita que en enero alguien proponga con entusiasmo las mismas cuatro ideas que ya se estudiaron.

Legal revisa sin tocar tu versión: propone cambios en una línea de trabajo paralela y comenta sobre las frases concretas que le preocupan. La discusión queda pegada al texto que la motivó, no repartida en once correos con adjuntos.

Al cerrar, la versión aprobada se marca como entrega, con el PDF firmado adjunto. La pregunta “¿qué política estaba en vigor en marzo de 2025?” pasa a ser un clic.

El resultado son unos diez puntos en el historial donde, sin abrir un solo archivo, se lee la secuencia entera: qué se pidió, de qué se partía, qué se cambió, por qué, qué se descartó y qué se entregó.

Lo que ha cambiado este año

Hasta hace poco esto era un argumento de trazabilidad y poco más. Ahora hay otro.

ChatGPT y Claude se conectan a repositorios y leen su contenido.

Eso significa que puedes pedirle tres cosas que antes no tenían dónde apoyarse:

• Que compare tu informe con las decisiones registradas y señale cualquier recomendación que contradiga una decisión ya tomada.

• Que localice lo que propone algo ya descartado.

• Que liste todas las cifras del informe y diga cuáles no constan en el archivo de fuentes.

Esa tercera pregunta es la que más devuelve. Siempre hay tres o cuatro cifras que se colaron sin origen, arrastradas de un borrador anterior.

Dos límites que conviene saber.

La IA no ve el historial de cambios, solo los archivos actuales. Si quieres que razone sobre la evolución de algo, esa evolución tiene que estar escrita en un archivo.

Y conectar el repositorio entero empeora las respuestas: la carpeta de descartes hace que la IA proponga con convicción justo lo que ya se rechazó.

Hay algo más, y es lo que menos se dice: funciona en los dos sentidos. La documentación bien escrita mejora las respuestas de la IA, y trabajar con IA sobre tu documentación revela sus huecos.

Pídele que se ponga en el papel de alguien que ejecuta tu procedimiento por primera vez y enumere las preguntas que tendría. Aparece la mitad de los agujeros en dos minutos.

No sustituye a dárselo a una persona de verdad, pero filtra lo obvio antes de molestar a nadie.

Cuánto cuesta

Dinero, cero. El plan gratuito incluye repositorios privados ilimitados con colaboradores ilimitados. Lo que se paga son funciones de revisión y seguridad que no vas a necesitar hasta que seáis un equipo.

Tiempo, unas dos horas para la primera parte y tres o cuatro más repartidas para trabajar con soltura. Una tarde larga.

El coste real es otro, y es diario: escribir una nota cada vez que confirmas un cambio. Al principio molesta.

A los dos meses es lo único que hace que el historial valga algo. Un historial de cuarenta entradas que dicen “actualización” no sirve para nada.

Por dónde empezar

Ni por el proyecto grande ni por trasladar el material histórico. Elige un documento que ya mantengas y que cambie: una metodología, un procedimiento, una política.

Ponlo en un repositorio privado, en Markdown, y trabájalo ahí durante un mes con las notas escritas de verdad.

Al cabo de esas semanas abre el historial y léelo de arriba abajo. Si se entiende qué pasó sin abrir ningún archivo, ya tienes lo que esto ofrece.

Si no se entiende, el problema son las notas, y ese es un hábito que se corrige en una tarde.

Lo demás (organizar varios proyectos, trabajar con otros, publicar) viene después y solo si hace falta.

He creado un Manual Práctico (GITHUB PARA PROFESIONALES: DE 0 A 100), paso a paso, para aprender a utilizar GitHub como sistema de trabajo para proyectos, desde los fundamentos hasta versionado, organización, documentación, seguridad...

Si quieres el manual completo (más de 305 paginas) y las plantillas de ejemplo, en este post de Linkedin verás cómo lo puedes conseguir.

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para financieros?

👉 Enlace Formación Claude para Financieros

Deja un comentario

Hay una asimetría en la evaluación de inversiones.

La parte que se enseña en las escuelas de negocio, descontar flujos y comparar tasas, es la que menos errores produce en la práctica.

La parte que decide el resultado no se enseña casi en ningún sitio: determinar qué flujos hay que descontar. Ahí es donde se rompen los expedientes.

Este artículo trata de la segunda parte.

El problema, definido

Un problema de decisión de inversión aparece cuando concurren cuatro condiciones:

• Hay que comprometer dinero hoy.

• Los retornos llegan repartidos en el tiempo.

• Esos retornos son inciertos.

• Las alternativas se excluyen entre sí.

Retirada cualquiera de las cuatro, el problema desaparece.

Si desembolso y retorno fueran simultáneos, bastaría una resta. Si los retornos fueran ciertos, sería aritmética. Si pudieran hacerse todos los proyectos, no habría que elegir.

Bajo esa definición cabe una familia amplia de decisiones que comparten método:

• Reemplazo de activos.

• Ampliación de capacidad.

• Fabricar o comprar.

• Abandono de una línea o un centro.

• Momento óptimo de acometer una inversión.

• Selección de cartera bajo racionamiento de capital.

Las diferencias entre ellas están en la forma del flujo. La disciplina de construcción es la misma.

La distinción que lo gobierna todo: flujo incremental

El objeto del análisis no son los flujos del proyecto. Son los flujos de la empresa con el proyecto menos los flujos de la empresa sin él.

La formulación parece un matiz académico. Tiene tres consecuencias inmediatas que explican buena parte de los errores de expediente.

Primera: hay que construir un caso base

Y el caso base no es la fotografía de hoy congelada durante diez años. Es la proyección de lo que ocurrirá si no se invierte, incluyendo su propio deterioro.

En una operación con volumen creciente, ese deterioro es real:

• Más incidencias por saturación.

• Mantenimiento creciente de un equipo que envejece.

• Necesidad de externalizar el exceso de capacidad, a un coste unitario superior.

Todo deterioro que la inversión evita es beneficio de la inversión. Un expediente que compara la alternativa contra la situación actual congelada infravalora el proyecto de forma sistemática.

Segunda: un mismo activo vale cosas distintas en dos empresas

El valor no está en la máquina. Está en la diferencia entre dos trayectorias.

Por eso ningún proveedor puede calcular correctamente el retorno de su propio equipo: no dispone del caso base de su cliente.

Tercera: hay costes que no entran y costes que entran sin factura

Los desembolsos ya realizados quedan fuera, porque no dependen de la decisión.

Los recursos que el proyecto consume o libera entran por su mejor uso alternativo, aunque no exista ningún apunte contable.

Cuando hay varios usos alternativos, se toma el mejor, nunca la suma. Los usos son excluyentes, y sumarlos contabiliza dos veces el mismo recurso.

Dónde entra Claude

La clasificación de las partidas de un expediente en hundidas, incrementales y de oportunidad es un trabajo de lectura y criterio, no de cálculo.

Es el tipo de tarea donde un modelo de lenguaje aporta. Leer cuarenta páginas de oferta, separar lo que depende de la decisión de lo que ya estaba comprometido, y devolver la clasificación con el criterio aplicado a cada línea.

Lo que se obtiene no es un número. Es una lista de discrepancias con el expediente original, que es lo que hace falta antes de abrir la hoja de cálculo.

Las seis métricas y sus zonas ciegas

Ninguna decide sola. Se usan juntas porque miden cosas distintas y fallan en sitios distintos.

1. Valor actual neto. Mide creación de valor en unidades monetarias. Es el criterio de decisión. Su limitación: no informa del tamaño relativo del esfuerzo ni del momento en que llega el dinero.

2. Tasa interna de retorno. Cómoda para comunicar, porque es una sola cifra comparable con el coste de capital.

   Falla cuando el flujo cambia de signo más de una vez: puede haber varias soluciones reales o ninguna. Un proyecto con reposiciones intermedias es exactamente ese caso.

3. Tasa interna de retorno modificada. Corrige el supuesto implícito de que los flujos intermedios se reinvierten a la propia tasa interna. A cambio, introduce una hipótesis explícita sobre la tasa de reinversión.

4. Plazo de recuperación descontado. Es la primera pregunta del consejo y no es un criterio de decisión.

   Ignora todo lo que ocurre después del punto de recuperación: mide exposición, no valor. Su lectura útil es otra. Cuando supera la vida útil del activo, el proyecto no se paga a sí mismo.

5. Índice de rentabilidad. Valor creado por unidad invertida. Manda cuando el capital está racionado y hay que ordenar proyectos que no caben todos.

6. Coste anual equivalente. Convierte el valor actual neto en una renta anual constante a lo largo de la vida del proyecto.

Es obligatorio al comparar alternativas de duración distinta, porque el proyecto más largo acumula más flujos por pura construcción.

Dónde entra Claude

En la elección de qué métrica manda en cada situación. Y sobre todo en la detección de cuándo una de ellas está engañando.

Comprobar si un flujo tiene varias tasas internas es un cálculo de raíces polinómicas que nadie hace a mano. Un modelo con ejecución de código lo resuelve en segundos.

Las seis decisiones de modelización

Enumeradas por orden de aparición en el trabajo real, y con la forma habitual de equivocarse en cada una.

1. Delimitación y costes hundidos. El error es incluir desembolsos ya realizados, normalmente estudios previos.

Alimenta el razonamiento de continuidad, que es el que sostiene proyectos que deberían pararse.

2. Construcción del caso base. Dos errores simétricos.

Por defecto, compararlo contra cero. Por exceso, proyectar un deterioro tan agresivo que infla artificialmente todos los ahorros.

El segundo es más peligroso, porque parece diligencia.

3. Techo de capacidad. Un caso base sin límite es un caso base falso.

Implica que la operación actual absorbe cualquier volumen sin coste adicional. Eso hace que mantener sea gratis para siempre, y que ninguna inversión se justifique nunca.

4. Materialización de los ahorros de personal. Aquí está la mayor distancia entre el expediente tipo y la realidad española.

Una reducción de plantilla no es un dato técnico. Es la consecuencia financiera de una decisión laboral, con su propio calendario y su propio coste.

Las vías son tres:

• Materialización inmediata. La que suponen los expedientes de proveedor. Prácticamente no ocurre.

• Amortización de vacantes por no reposición. Lo habitual en la empresa familiar. Difiere el ahorro tres o cuatro años.

• Despido objetivo por causas técnicas u organizativas, artículo 52 del Estatuto de los Trabajadores. Veinte días por año trabajado, con tope de doce mensualidades.

El resultado contraintuitivo aparece al comparar las tres con un modelo delante: la vía que no consume caja suele ser la que destruye más valor.

5. Desglose de la inversión por componentes. Una instalación no es un activo.

El coeficiente de amortización de la tabla del artículo 12.1 de la Ley del Impuesto sobre Sociedades depende del tipo de elemento. Aplicar uno solo a todo distorsiona el escudo fiscal.

Pero la consecuencia importante del desglose es otra, y es la siguiente.

6. Reposiciones dentro del horizonte. Si algún componente agota su vida útil antes del final del periodo analizado, hay que reponerlo. Esa reposición es salida de caja del proyecto.

Los sistemas de control y el software asociado a una instalación industrial suelen durar cinco años, frente a los diez del elemento mecánico.

Ninguna oferta comercial recoge ese desembolso: las ofertas describen la instalación, no su ciclo de vida.

Dos exigencias de coherencia

A las seis decisiones hay que añadir dos reglas que se rompen con frecuencia.

La variación de circulante entra en el flujo y revierte en el año terminal. Una liberación de existencias es caja una vez, no un ahorro recurrente.

Si el coste de la deuda está dentro de la tasa de descuento, los gastos financieros no pueden aparecer además dentro del flujo.

Dónde entra Claude

En las seis, pero de forma distinta en cada una.

En la primera y la cuarta, como clasificador con criterio: separar categorías que el expediente presenta mezcladas.

En la segunda, como contradictor. Proponer conductores de deterioro con un rango y después atacar su propia propuesta. Un caso base que sobrevive a esa doble ronda es un caso base defendible.

En la quinta y la sexta, como revisor mecánico. Recorrer componente a componente comparando vida útil contra horizonte, y clasificar partidas contra una tabla normativa señalando las dudosas.

En ninguna decide. La elección de vía de plantilla se toma en un despacho de dirección general, no en una hoja de cálculo.

Tres formas de mirar la incertidumbre, que no son la misma

Se confunden con frecuencia y responden a preguntas distintas.

Análisis de sensibilidad. Mueve una variable cada vez y mide el desplazamiento del resultado. Responde a qué hipótesis importa.

Análisis por escenarios. Mueve varias a la vez de forma coherente.

Un escenario no es todo un 10 % peor. Si cae el volumen, caen también las existencias necesarias y el ahorro de plantilla. Un descuento uniforme sobre todas las líneas no es prudencia: es ausencia de modelo.

Análisis de umbrales. Invierte la pregunta.

En lugar de medir cuánto cae el resultado si la variable empeora, determina hasta dónde puede empeorar antes de que el proyecto deje de crear valor. Es el único de los tres que se traduce en cláusula contractual.

Hay una cuarta prueba, menos habitual y más severa: suprimir cada palanca de ahorro por completo y observar qué queda.

Su lectura no es evidente. Un modelo que sobrevive a la supresión de cualquiera de sus palancas casi siempre está mal calibrado, no es robusto.

Significa que alguna hipótesis está inflada lo suficiente como para sostener el caso por sí sola.

La restricción que suele decidir: los covenants

Un proyecto rentable que rompe el contrato de financiación no es viable. Son dos preguntas distintas, y la segunda rara vez se hace en el comité de inversiones.

El momento crítico no es el que se mira. No es el ejercicio de máximo apalancamiento teórico, sino el primero.

Aquel en el que la inversión ya está desembolsada y los ahorros apenas han empezado a llegar. Con una vía de plantilla realista, el ahorro del primer ejercicio puede ser una fracción pequeña del ahorro de régimen.

De ahí se deriva una consecuencia práctica que cambia la naturaleza del proyecto. El calendario de puesta en marcha deja de ser una cuestión técnica y pasa a ser una variable financiera.

Un retraso de seis meses en la obra no solo tiene coste de oportunidad. Puede provocar el incumplimiento de un ratio.

Y de ahí se deriva la forma correcta de aprobar. Cada umbral crítico se convierte en cláusula:

• Penalización ligada al rendimiento medido, no a la fecha de entrega.

• Compromiso escrito sobre la materialización de plantilla, con un mínimo para el primer ejercicio.

• Postauditoría obligatoria sobre el mismo modelo.

Dónde entra Claude

En despejar hacia atrás.

La pregunta útil no es cuál es el ratio previsto, sino cuál es el ahorro mínimo del primer ejercicio compatible con el contrato.

Ese número, y no el valor actual neto, es el que se lleva a la conversación con dirección general.

Claude para Financieros

El problema: un modelo puede recalcular sin errores y estar mal

Aquí termina la parte metodológica y empieza la que menos se discute.

Un modelo de inversión completo ronda las mil fórmulas: caso base, alternativas, fiscalidad por componentes, circulante y covenants. La comprobación habitual consiste en verificar que no hay errores de fórmula.

Esa comprobación no demuestra nada sobre la corrección de los números.

Tres defectos típicos:

• Una referencia a la fila equivocada.

• Un rango desplazado en una celda.

• Una condición que apunta al año cinco cuando debería apuntar al seis.

Cada uno produce un libro impecable, sin un solo aviso, con todos los valores en su sitio y todos mal.

El error silencioso es el fallo característico de la hoja de cálculo, y no existe ninguna herramienta nativa que lo detecte.

La única solución seria es la redundancia: construir el modelo dos veces con herramientas independientes y obligarlas a coincidir.

En la práctica eso significa tres pasos:

1. Precalcular el modelo completo en un lenguaje de programación.

2. Exportar cada cifra resultante a una fuente única.

3. Contrastar la hoja de cálculo contra esa fuente celda a celda.

La condición de cierre es un residuo de cero entre el valor actual neto descontado directamente y el mismo valor descompuesto por sus fuentes:

• Ahorro operativo neto de impuesto.

• Escudo fiscal.

• Circulante.

• Reposiciones.

• Valor residual.

• Inversión neta.

Aplicando ese procedimiento a la construcción de un modelo de este tipo aparecieron dos defectos reales.

Una reposición situada en el año cinco de la hoja de cálculo y en el año seis del modelo de contraste. Y una referencia que apuntaba a una fila desplazada al reordenar una hoja.

El valor actual neto habría salido desviado en más de 22.000 €. El libro recalculaba perfectamente.

Dónde entra Claude

Aquí la aportación deja de ser cuestión de opinión y pasa a ser verificable.

No consiste en escribir mejores fórmulas. Consiste en tres cosas:

• Disponer de una segunda versión independiente del modelo con la que comparar.

• Ejecutar el contraste celda a celda sin cansarse a la comprobación número doscientos.

• Sostener la disciplina de no dar por bueno un entregable hasta que el residuo sea exactamente cero.

Un profesional puede hacer ese contraste. Casi ninguno lo hace, porque el coste marginal de construir el modelo dos veces es prohibitivo en tiempo.

Ese coste marginal es justamente el que ha cambiado.

Qué no cambia

Conviene cerrar por donde se debería empezar.

El criterio sobre si un proveedor cumplirá sus plazos sigue siendo humano. La decisión sobre plantilla se toma en dirección general.

La valoración de si un rendimiento técnico ofertado es creíble corresponde a quien conoce la tecnología. Y la responsabilidad de lo que se lleva al consejo no es delegable.

Lo que cambia es la capa intermedia:

• La construcción disciplinada del caso.

• La detección de lo que falta.

• La verificación de que el resultado es el que dicen las hipótesis.

Que era, precisamente, donde se rompían los expedientes.

En este post de Linkedin podrás acceder al kit INVERSION de Claude para Finanzas. Incluye un modelo completo de 28 hojas con las tres alternativas, los umbrales, los covenants y la verificación cruzada, además de la guía metodológica y la biblioteca de prompts.

Javier López Martín · jlopez@tallerformacion.com ·

https://claudefinanzaspro.netlify.app/

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para financieros?

👉 Enlace Formación Claude para Financieros

Deja un comentario

Hay una pregunta que todo director financiero recibe al menos una vez al año y que casi ningún modelo de previsión responde bien: cuánto dinero va a hacer falta pedir fuera, y en qué momento.

La respuesta habitual consiste en proyectar la cuenta de pérdidas y ganancias, comprobar que el beneficio crece y concluir que una empresa más rentable podrá financiarse sola.

Es un razonamiento que suena bien y que falla de forma sistemática, porque confunde generar beneficio con generar caja.

El crecimiento consume tesorería antes de producirla. Cuando las ventas suben, suben antes los saldos de clientes pendientes de cobro y las existencias en almacén que el cobro efectivo de ese negocio adicional.

Si además hay que invertir en capacidad, el desembolso llega íntegro por delante mientras el retorno se reparte a lo largo de varios ejercicios.

El desfase entre ambas cosas es exactamente el dinero que habrá que conseguir fuera, y solo aparece cuando se proyecta también el balance.

Este artículo recorre las seis dificultades técnicas que hacen ese trabajo más difícil de lo que parece, y señala en cada una dónde Claude aporta algo que una hoja de cálculo por sí sola no aporta.

Dónde entra Claude, antes de entrar en materia

Conviene decirlo al principio y con precisión, porque el malentendido habitual va en las dos direcciones.

Claude no calcula mejor que una hoja de cálculo. Una hoja bien construida multiplica y suma sin errores, y no necesita ayuda para eso.

Lo que aporta es una capa de razonamiento sobre el modelo, y se traduce en cuatro cosas concretas.

Explicita las hipótesis que normalmente quedan implícitas. Detecta que dos partidas del balance se contradicen antes de que la contradicción se propague por cinco ejercicios.

Localiza el punto exacto donde una cadena de cálculo se rompe. Y contrasta una conclusión contra la hipótesis de la que depende.

Dicho de otro modo: el valor no está en que haga las cuentas, sino en que reduce a la mitad las veces que hay que rehacerlas.

Primera dificultad: el balance es la única fuente de la cifra

Un balance previsto, por construcción, tiene que cuadrar. El activo debe igualar a la suma del patrimonio neto y el pasivo, igual que en el balance real.

La cuestión es que si proyectas cada partida por separado, no cuadra.

Los clientes y las existencias crecen con la actividad, y los proveedores también. Pero el capital social no crece solo, la deuda a largo plazo tampoco, y las subvenciones de capital se van imputando a resultados en lugar de aumentar.

Esa diferencia entre lo que la empresa va a tener y lo que va a deber es la nueva financiación neta.

No es un residuo del cálculo ni un error de cuadre: es la respuesta a la pregunta original.

Aquí aparece el error más extendido, y conviene subrayar que es un error de concepto, no de hoja de cálculo.

Consiste en proyectar la deuda financiera como un porcentaje de las ventas, igual que los clientes. Cuando se hace eso, el balance cuadra solo y el modelo deja de decir nada.

La deuda no crece por sí misma. Crece porque alguien decide pedirla, y esa decisión es precisamente el resultado que se estaba buscando.

Dónde entra Claude → Recorrer el balance partida por partida clasificando qué crece con la actividad y qué no es un trabajo de criterio, no de cálculo.

Claude puede hacer esa clasificación sobre los estados financieros reales, justificar cada asignación y señalar los casos dudosos, que suelen ser los pasivos por impuesto diferido, las subvenciones y las periodificaciones.

Segunda dificultad: el cálculo se muerde la cola

El dinero que se pide fuera devenga intereses, y esos intereses reducen el beneficio.

Un beneficio menor deja menos reservas y por tanto un patrimonio neto menor. Y un patrimonio neto menor obliga a pedir más dinero fuera.

Es una dependencia circular real, no un artefacto del modelo.

Buena parte de los manuales la esquiva suponiendo que los gastos financieros se mantienen constantes, y reconoce después en una nota al pie que por ese motivo la previsión queda incorrecta.

Hay dos formas de resolverla.

La primera es activar el cálculo iterativo de la hoja, que funciona pero depende de una configuración desactivada por defecto en la mayoría de instalaciones y convierte el modelo en una caja negra.

La segunda es hacer dos pasadas sucesivas: una estima la necesidad de financiación ignorando su propio coste, y la otra la recalcula ya incorporándolo.

La segunda opción es preferible por una razón que va más allá de lo técnico.

Deja las dos pasadas a la vista, una debajo de la otra, con la diferencia entre ambas escrita en una fila. Un modelo cuya circularidad se puede auditar visualmente es un modelo que se puede defender.

Dónde entra Claude → Explicar por qué existe la circularidad y decidir cómo resolverla es una conversación de diseño, y Claude la sostiene bien.

También sirve para verificar después que la segunda pasada usa el saldo correcto, que es donde suele estar el fallo: tomar el importe estimado del ejercicio anterior en lugar del definitivo, que a esas alturas ya se conoce.

Formación Claude para Financieros

Tercera dificultad: el porcentaje de ventas se rompe con la capacidad

Proyectar cada partida como un porcentaje de las ventas funciona razonablemente bien en empresas maduras que crecen despacio y de forma estable.

Deja de funcionar en cuanto aparece una restricción física.

Entonces las ventas no las decide el mercado sino la fábrica, y la producción es el menor de dos números: lo que la demanda pide y lo que la capacidad instalada permite sacar.

La diferencia entre ambos es negocio que la empresa rechaza, y tiene que aparecer escrita en el modelo.

La inversión se comporta igual de mal con el método del porcentaje.

No llega en dosis anuales proporcionales al crecimiento, sino de golpe, en bloques grandes y en momentos puntuales, con capacidad que tarda años en llenarse.

Ahí aparece la pregunta que el método del porcentaje de ventas nunca formula, y que es la que de verdad decide el asunto.

Cuánto cuesta cada unidad de capacidad instalada, comparado con el múltiplo al que el mercado va a valorar el resultado operativo que esa capacidad genere.

Cuando se compra capacidad a un precio que implica pagar el beneficio bruto de explotación a diez veces para venderlo a cinco, la inversión destruye valor por mucho que las ventas suban.

Dónde entra Claude → Traducir una inversión en euros a un precio por unidad de resultado operativo comprado es un cambio de marco, no un cálculo distinto.

Claude es útil precisamente para eso: para forzar el planteamiento alternativo antes de que el modelo se construya sobre el planteamiento evidente.

Cuarta dificultad: la contabilidad y la fiscalidad no van al mismo ritmo

En España, una sociedad de reducida dimensión puede amortizar fiscalmente los activos nuevos al doble del coeficiente de las tablas, mientras la amortización contable sigue su ritmo normal.

La diferencia entre ambas no es un tecnicismo: es dinero que no se paga a Hacienda durante unos ejercicios y que sí se paga después.

Modelarlo obliga a llevar dos cuadros de amortización en paralelo, generación de activo por generación de activo, y a registrar el pasivo por impuesto diferido que la diferencia genera.

Obliga también a arrastrar las bases imponibles negativas que aparezcan, con su límite de compensación y su mínimo absoluto.

Hay además un matiz que se pasa por alto con frecuencia.

El régimen de reducida dimensión tiene dos puertas distintas que se cierran en momentos distintos.

El tipo de gravamen reducido se pierde en cuanto se supera el umbral de cifra de negocios. Pero los incentivos del régimen especial, entre ellos la amortización acelerada, admiten una prórroga de tres ejercicios.

Son dos reglas separadas y casi nadie las separa.

Dónde entra Claude → Este es el terreno donde más se nota la diferencia entre una hoja de cálculo y una capa de razonamiento.

Claude puede leer el articulado aplicable, explicar qué caduca cuándo y por qué, y traducirlo a la estructura de filas del modelo.

Con una advertencia que conviene mantener siempre: la interpretación fiscal final es del asesor, no del modelo ni de la herramienta.

Quinta dificultad: el escudo fiscal de la deuda no es automático

La forma habitual de estimar el ahorro fiscal de los intereses consiste en multiplicarlos por el tipo impositivo.

Es un atajo que en determinadas circunstancias produce una cifra sencillamente falsa.

Los intereses solo generan ahorro si existe base imponible contra la que deducirlos.

Y cuando la amortización acelerada ya ha llevado la base a terreno negativo, no queda nada de lo que deducir. Los dos incentivos compiten por el mismo espacio fiscal, y el segundo llega tarde.

La forma correcta de calcularlo es por diferencia: el impuesto que la sociedad pagaría sin deuda menos el que paga con ella.

Esa resta obliga a construir una liquidación paralela, con su propio arrastre de bases negativas, y es un trabajo que casi nunca se hace.

Dónde entra Claude → Detectar que un cálculo estándar deja de ser válido en unas condiciones concretas es el tipo de razonamiento que una fórmula no hace.

Claude puede recorrer la liquidación ejercicio a ejercicio y señalar en cuáles el escudo fiscal es nominal y en cuáles es real.

Sexta dificultad: el valor de continuación decide el análisis

Cuando la previsión se usa para valorar una inversión, aparece un problema de proporciones que incomoda.

El valor asignado a lo que ocurre después del horizonte de previsión suele representar la mayor parte del valor total.

Es decir, un trabajo minucioso de cinco ejercicios decide una fracción menor del resultado, y el resto lo decide un múltiplo que alguien eligió a mano.

Eso no invalida el método, pero obliga a dos comprobaciones que rara vez se hacen.

La primera es calcular qué crecimiento a perpetuidad implica el múltiplo elegido, y comprobar que no supera el crecimiento nominal de la economía.

La segunda es construir la tabla de sensibilidad y localizar el múltiplo a partir del cual la inversión deja de crear valor.

Ese umbral, y no la cifra central, es la conclusión real del trabajo.

Dónde entra Claude → Cuestionar la hipótesis de la que depende la conclusión es un ejercicio incómodo cuando uno mismo la ha elegido.

Claude no tiene ese sesgo, y se le puede pedir explícitamente que ataque el múltiplo, que calcule el crecimiento implícito y que señale a partir de qué punto la recomendación se da la vuelta.

Lo que cierra el círculo

Existe una comprobación final que ordena todo lo anterior y que cabe en tres líneas.

La tasa de crecimiento sostenible es la que una empresa puede financiar manteniendo constante su estructura de capital, y sale de combinar la rentabilidad sobre fondos propios con la parte del beneficio que se retiene.

Comparada con el crecimiento real de las ventas, la brecha entre ambas explica, casi al euro, la financiación externa que el balance proforma ha revelado.

Cuando esa brecha se cierra, la necesidad de financiación deja de crecer.

Y cuando un director financiero puede enseñar esa brecha en una fila, la conversación con el consejo deja de ser sobre si el plan es optimista y pasa a ser sobre qué palanca se mueve primero.

He publicado el modelo completo de este análisis, construido sobre un caso industrial con restricción de capacidad, con las quince hojas de cálculo, los prompts y la guía paso a paso. Si trabajas en planificación financiera y quieres el material, escríbeme a

jlopez@tallerformacion.com.

Javier López Martín · IA Aplicada · Claude para Finanzas

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para financieros?

👉 Enlace Formación Claude para Financieros

Deja un comentario

Si ya usas Cowork, conoces la sensación. Unas veces el resultado sale redondo y otras, con el mismo tipo de encargo, sale torcido y no sabes del todo por qué.

La diferencia rara vez está en el prompt. Está en cómo estaba montado el proyecto antes de escribirlo.

Este artículo reúne las prácticas que uso para arquitectar un proyecto de Cowork: la estructura de carpetas anotada carpeta a carpeta, las convenciones de nombres, los documentos de gobierno y los prompts que definen el flujo.

El objetivo es pasar de «funciona a veces» a «funciona siempre», con ejemplos que puedes copiar.

Doy por hecho que ya sabes conectar una carpeta con «Work in a Folder», activar un conector desde «Customize → Connectors» y lanzar una tarea. Vamos al nivel siguiente: cómo se diseña el proyecto.

El principio: diseñas una arquitectura, no un prompt

Cowork trabaja por fases sobre tus archivos reales. Lee las fuentes, las transforma, construye un modelo, corre comprobaciones y deja un entregable, encadenando pasos sobre un mismo conjunto de ficheros.

A un proceso así no lo diriges con una instrucción. Lo diseñas. Y lo que diseñas es la estructura sobre la que el agente se mueve.

Esa estructura de carpetas cumple cuatro funciones, y conviene tenerlas presentes porque justifican cada decisión que viene después:

→ Selecciona el contexto. Lo que está dentro del perímetro conectado es lo que el agente puede leer.

→ Delimita la escritura. Separar entradas de transformaciones convierte «no toques el original» en una zona con reglas, no en una súplica.

→ Representa el estado. Permite distinguir un borrador de una salida aprobada.

→ Conserva la evidencia. Deja rastro de la fuente, el supuesto, el control y la aprobación.

Todo lo demás son formas concretas de que estas cuatro funciones ocurran.

Dos niveles: el paquete y la carpeta que se conecta

La primera decisión de arquitectura es qué construyes y qué conectas, y no son lo mismo.

Construyes un paquete: una carpeta contenedora con todo. Dentro de ese paquete hay una carpeta de trabajo, que es la única que conectas a Cowork, y otras carpetas que se quedan fuera del perímetro a propósito.

Conectar poco es una decisión de control. Lo que está fuera del perímetro, el agente no lo ve.

Y desde que Cowork puede llegar a manejar aplicaciones del equipo, no solo ficheros, cada carpeta de más que conectas es superficie de más para un error.

El árbol completo, anotado

Este es el árbol de un proyecto real, con cada carpeta marcada según se conecte o no, y para qué sirve.

FLUJO_CAJA_13S/                       [PAQUETE · NO se conecta]
│                                     Carpeta contenedora. La montas tú.
│                                     Solo se conecta una carpeta de dentro.
│
├── LEEME_PRIMERO.txt                 [NO] Nota de arranque: qué es el paquete
│                                     y qué carpeta hay que conectar.
├── VERSION_PAQUETE.txt               [NO] Versión y fecha del paquete.
│
├── 01_PROYECTO_COWORK/               [SE CONECTA · Work in a Folder]
│   │                                 El perímetro. Todo lo que el agente puede
│   │                                 ver y tocar vive aquí dentro.
│   │
│   ├── 00_GOBIERNO/                  Las reglas y el flujo. El agente lo lee primero.
│   │   ├── 00_INSTRUCCIONES_PROYECTO.md   Cómo trabaja siempre: rol, permisos, paradas.
│   │   ├── 01_BRIEF_PROYECTO.md           El encargo de ahora: fecha, audiencia, entregables.
│   │   ├── 02_REGISTRO_FUENTES.md         Ficha de cada fuente y su relación con las demás.
│   │   ├── 03_CONVENCIONES.md             Patrón de nombres, estados y prefijos.
│   │   ├── 04_PROMPTS/                    Biblioteca de prompts reutilizables del proyecto.
│   │   │   ├── P01_sesion_0.md
│   │   │   ├── P02_preparacion.md
│   │   │   ├── P03_construir_modelo.md
│   │   │   ├── P04_control_qa.md
│   │   │   └── P05_nota_ejecutiva.md
│   │   └── 05_TAREAS/                     El plan del proyecto.
│   │       └── PLAN_DE_TAREAS.md          Orden de tareas; cada una apunta a su prompt.
│   │
│   ├── 01_ENTRADAS_ORIGINALES/       Fuentes tal como llegan. SOLO LECTURA.
│   │   ├── Extracto_Bancos_2026-06.xlsx
│   │   ├── Cobros_Pendientes_2026-06-30.xlsx
│   │   └── Modelo_Flujo_13S_v07.xlsx      El canónico. El "corregido" se queda fuera.
│   │
│   ├── 02_PREPARACION/               Copias de trabajo. Aquí se limpia y transforma.
│   │   └── PREP_Movimientos_Banco_2026-06_v01.xlsx
│   │
│   ├── 03_MODELO/                    La lógica: cálculo, informe, hallazgos.
│   │   └── MODEL_Flujo_Caja_13S_2026-07-01_v01_BORRADOR.xlsx
│   │
│   ├── 04_SALIDAS/                   Solo lo aprobado. Empieza VACÍA a propósito.
│   │   └── (vacía hasta que algo pasa el control)
│   │
│   └── 05_CONTROL/                   La evidencia del proyecto.
│       ├── CHECKLIST_QA.md               Comprobaciones que debe pasar el resultado.
│       └── REGISTRO_CAMBIOS.md           Qué cambió, por qué y quién lo decidió.
│
└── 06_HISTORICO_NO_CONECTAR/         [NO se conecta] Periodos cerrados y versiones
                                      viejas. Fuera del perímetro para que el
                                      agente no las mezcle con lo activo.

Dos avisos que ahorran errores.

Primero, hay dos numeraciones distintas. La de fuera (01_, 06_) separa lo que se conecta de lo que no. La de dentro (00_ a 05_) son las seis capas del trabajo. No es la misma serie.

Segundo, el histórico va fuera de la carpeta conectada, no dentro. Si lo dejas dentro, el agente lo ve aunque le digas que no lo use. Fuera del perímetro, la exclusión es técnica.

Qué va y qué no va en cada capa

Anotar el árbol es la mitad. La otra mitad es tener claro qué pertenece a cada carpeta, porque el error más común es meter cosas donde no van.

00_GOBIERNO. Va: las reglas del proyecto, la biblioteca de prompts y el plan de tareas. No va: datos ni fuentes. El gobierno describe cómo se opera el proyecto, no lo alimenta.

01_ENTRADAS_ORIGINALES. Va: las fuentes tal como llegaron, sin tocar. No va: nada editado, ninguna versión de trabajo, ninguna salida. Si un archivo se ha modificado, ya no es una entrada original.

02_PREPARACION. Va: las copias transformadas, con su prefijo PREP_ y trazabilidad hasta la fuente. No va: el modelo final ni el entregable. Es un taller, no un escaparate.

03_MODELO. Va: el archivo que contiene la lógica, en estado de trabajo. No va: las salidas aprobadas, que tienen su propia carpeta, ni copias de seguridad sueltas.

04_SALIDAS. Va: solo lo que ha pasado el control y alguien ha aprobado, con el estado en el nombre. No va: borradores, notas internas, versiones intermedias. Que esté vacía significa que aún no hay entrega.

05_CONTROL. Va: el checklist ejecutado y el registro de cambios. No va: los datos en sí. El control apunta a lo que pasó, no lo reproduce.

Una regla mental sencilla para clasificar cualquier archivo: pregúntate en qué estado está (recibido, en preparación, en el modelo, aprobado) y ponlo en la capa de ese estado.

Si no sabes en qué estado está, ese es el problema, no la carpeta.

Tabla de referencia rápida

Convenciones de nombres

Sin una convención, dos versiones de un archivo compiten por el mismo significado. Con ella, el nombre dice el estado.

El patrón:

PREFIJO_Contenido_AAAA-MM-DD_vNN_ESTADO.ext

Ejemplos reales dentro del proyecto:

PREP_Movimientos_Banco_2026-06_v01.xlsx
MODEL_Flujo_Caja_13S_2026-07-01_v01_BORRADOR.xlsx
OUT_Flujo_Caja_13S_2026-07-01_v01_APROBADO.xlsx
QA_Flujo_Caja_13S_2026-07-01_v01.md

Prefijos por capa: PREP_ (preparación), MODEL_ (modelo), OUT_ (salida aprobada), QA_ (control). Fecha en ISO, para que ordene bien. Versión vNN. Estado en mayúsculas al final.

La máquina de estados

Aquí está lo que separa una arquitectura de una carpeta ordenada. La estructura existe para hacer visible el recorrido del trabajo.

recibido → validado → preparado → borrador → revisado → aprobado → cerrado

El detalle que casi nadie hace explícito: la transición de un estado al siguiente no ocurre porque el archivo se mueva de carpeta. Ocurre porque pasó algo verificable.

Una fuente confirmada. Una conciliación en cero. Una revisión. Una aprobación con nombre.

Un archivo que figura como APROBADO sin que exista el hecho que lo aprobó es una mentira silenciosa. El nombre y la carpeta reflejan el estado; quien lo genera es el control.

Diseñar el proyecto es, en el fondo, decidir qué estados tiene tu trabajo y qué hecho habilita cada paso.

El gobierno: lo que escribes antes de pedir cálculos

Antes de la primera instrucción de trabajo, deja escritas las reglas.

Conviene separar dos documentos que suelen mezclarse: las instrucciones (cómo trabaja el agente siempre en este proyecto) y el brief (qué encargo concreto ejecutas ahora).

Así, cuando cambie la fecha de corte, actualizas el brief sin reescribir las reglas.

00_INSTRUCCIONES_PROYECTO.md

ROL
Actúa como [analista de tesorería / consultor / investigador].

OBJETIVO
[Qué produce el proyecto y qué decisión permite tomar.]

LECTURA Y ESCRITURA
01_ENTRADAS_ORIGINALES es solo lectura. No sobrescribas archivos.
Transformaciones en 02_PREPARACION, trabajo en 03_MODELO,
solo versiones revisadas en 04_SALIDAS.

REGLAS
No elijas entre fuentes contradictorias: registra la incidencia y pregunta.
No sustituyas fórmulas por valores fijos sin aprobación.

PARADAS
Detente si dos versiones compiten, falta una fuente, un control no cuadra,
o la acción implica sobrescribir, borrar, enviar o publicar.

02_REGISTRO_FUENTES.md

El campo que marca la diferencia es Relación: es donde declaras cuál manda. Sin él, el agente adivina.

## [nombre_del_archivo]
Propietario: [área o persona]
Periodo: [fechas que cubre]
Función: [para qué se usa]
Control esperado: [ej. suma de saldos = 412.000 €]
Estado: [candidata / aprobada como fuente / descartada]
Relación: [es fuente / deriva de X / sustituye a Y / no usar, solo evidencia]

Un caso típico: tienes Modelo_v07.xlsx y Modelo_v07_corregido.xlsx, este último llegado por correo sin aprobar.

No dejes que el agente escoja. Declara en el registro que el canónico es v07 y que corregido se conserva como evidencia de una incidencia, no como fuente.

El flujo del proyecto: biblioteca de prompts y plan de tareas

Las seis capas dicen dónde vive el dato. No dicen cómo se ejecuta el proyecto: qué se pide, en qué orden y con qué prompt.

Ese flujo también es arquitectura, y también se escribe antes. Vive dentro de 00_GOBIERNO, en dos piezas.

La biblioteca de prompts. Una carpeta 04_PROMPTS/ con los prompts reutilizables del proyecto, uno por archivo.

No los improvisas cada vez. Los guardas, los versionas y los reutilizas entre proyectos parecidos.

04_PROMPTS/
├── P01_sesion_0.md          inventario sin tocar nada
├── P02_preparacion.md       normaliza las entradas
├── P03_construir_modelo.md  levanta el modelo
├── P04_control_qa.md        corre las comprobaciones
└── P05_nota_ejecutiva.md    redacta la salida

El plan de tareas. Una carpeta 05_TAREAS/ con un PLAN_DE_TAREAS.md: la lista ordenada de tareas del proyecto.

Cada tarea apunta al prompt que ejecuta, que vive en 04_PROMPTS/. El plan orquesta; la biblioteca contiene.

# Plan de tareas: Flujo de caja 13 semanas

T01  Inventario y plan        → P01_sesion_0          escribe: nada           → recibido
T02  Preparar los datos       → P02_preparacion       escribe: 02_PREPARACION → preparado
T03  Construir el modelo      → P03_construir_modelo  escribe: 03_MODELO      → borrador
T04  Control de calidad       → P04_control_qa        escribe: 05_CONTROL     → revisado
T05  Nota ejecutiva y salida  → P05_nota_ejecutiva    escribe: 04_SALIDAS     → aprobado (tras firma)

Una tarea dice cuándo y sobre qué. El prompt dice cómo. Leído de arriba abajo, el plan es el proyecto entero en una pantalla: qué se ejecuta, qué escribe y a qué estado lleva.

Esa separación da tres cosas:

• Reproducible. Cualquiera repite el proyecto siguiendo el plan, sin que estuvieras tú.

• Reutilizable. El mismo prompt sirve en varios proyectos del mismo tipo.

• Automatizable. Una tarea programada en «Scheduled» ejecuta un prompt de la biblioteca, que es la única fuente de la verdad sobre qué se ejecuta.

Un matiz para no duplicar. Hay tres tipos de texto y no cumplen la misma función:

• Las instrucciones permanentes (00_INSTRUCCIONES): cómo se comporta el agente siempre.

• Los prompts (04_PROMPTS/): qué se pide en cada paso.

• El plan (05_TAREAS/): en qué orden y con qué prompt.

No metas reglas permanentes dentro de un prompt de tarea, ni pasos de tarea dentro de las instrucciones. Cada cosa en su carpeta.

Los prompts que definen el flujo

Estos prompts viven en 04_PROMPTS/. Son cortos, reutilizables y se apoyan en el gobierno que ya escribiste. Algunos son pasos del plan de tareas; otros son transversales y los invocas cuando hacen falta.

Sesión 0: inventario sin tocar nada. Nada más conectar la carpeta, antes de pedir cualquier cambio.

Lee primero 00_GOBIERNO y después haz un inventario de los archivos visibles.
No modifiques ni crees nada todavía.
Devuélveme:
1. el objetivo y la decisión que entiendes;
2. las fuentes encontradas y su función;
3. las versiones o datos que compiten entre sí;
4. los controles que propones ejecutar;
5. un plan de trabajo en un máximo de ocho pasos;
6. los archivos que crearías y en qué carpeta.
Confirma qué carpetas puedes ver y detente para mi aprobación.

Si en la respuesta el agente dice que ve 06_HISTORICO_NO_CONECTAR, conectaste el nivel equivocado. Lo detectas sin haber tocado un archivo.

Diseño de la estructura, cuando arrancas un proyecto nuevo. Fíjate en que pregunta antes de proponer.

Actúa como diseñador de proyectos de Cowork, para un proyecto de tipo
[FINANZAS / CONSULTORÍA / INVESTIGACIÓN / RR. HH. / REPORTING].
Primero hazme estas preguntas y espera respuestas. No propongas estructura
hasta tenerlas:
1. ¿Qué entregable produce y quién lo aprueba?
2. ¿Qué fuentes son válidas y cuáles quedan fuera?
3. ¿Hay datos sensibles?
4. ¿Es de una vez o se repite cada periodo?
5. ¿Qué controles debe pasar el resultado?
6. ¿Trabajas en local o quieres poder automatizarlo?
Con mis respuestas, propón el perímetro mínimo, un árbol de carpetas con las
capas que este proyecto necesite y una convención de nombres. Explica qué
error evita cada carpeta. No inventes datos.

Resolver una contradicción entre fuentes. Para que el agente no decida en silencio.

Dos fuentes se contradicen: [descríbelo]. No elijas la más reciente ni la más
alta. Devuélveme las dos cifras y su origen, qué explicaría la diferencia, el
impacto de usar una u otra y qué habría que confirmar. No modifiques nada hasta
que yo confirme cuál es la buena.

Preparación de datos (P02). Sobre las entradas, sin tocar los originales.

Trabaja sobre 01_ENTRADAS_ORIGINALES en modo solo lectura. Para cada fuente,
crea una copia normalizada en 02_PREPARACION con el prefijo PREP_.
Normaliza fechas, unifica el criterio de signos y conserva un identificador
de origen por fila, para poder seguir cada importe hasta su fuente.
Registra cualquier incidencia (duplicados, fechas que no cuadran) y detente
si algo requiere una decisión. No modifiques ningún original.

Control de calidad (P04). Antes de dar nada por aprobado.

Ejecuta las comprobaciones de 05_CONTROL/CHECKLIST_QA.md sobre el modelo
actual. Devuélveme cada control como pasa o no pasa, con la cifra que lo
justifica. Marca las incidencias y su resolución. Añade una línea final de
"revisor: pendiente". No promuevas nada a 04_SALIDAS sin mi aprobación.

Perímetro y relaciones: dos prácticas que evitan la mayoría de fallos

Conecta el perímetro mínimo. No conectes la raíz del disco, todo «Documentos» ni una carpeta con varios clientes. Más no da más contexto útil; mezcla proyectos y amplía el acceso. Conecta solo 01_PROYECTO_COWORK.

Declara las relaciones, no solo ordenes. Una carpeta limpia sigue dejando que el agente adivine si no le dices cómo se relacionan los archivos:

• cuál es fuente;

• cuál deriva;

• cuál sustituye a cuál;

• cuál no debe leerse.

Esa jerarquía no se deduce del orden alfabético ni de la fecha. Se declara, en el registro de fuentes.

Dónde viven los datos: local, conector y la regla de oro

Aquí entra la distinción que decide si un proyecto se puede automatizar.

Separa dos cosas que la palabra «nube» confunde: dónde trabaja el agente (servidores de Anthropic o tu ordenador) y dónde viven tus ficheros (tu disco o un almacén como Drive, OneDrive o Dropbox).

Para tocar un fichero de tu disco, el agente necesita la aplicación de escritorio abierta, que hace de puente. Un conector, en cambio, llega al almacén en la nube directamente, sin depender de tu equipo.

De ahí una regla que decide cómo montas el proyecto:

• Modo manual y supervisado → un perímetro en tu disco es cómodo y controlable.

• Modo recurrente y automatizado → el perímetro tiene que vivir en un almacén en la nube por conector.

La regla de oro para automatizar: ningún extremo en C:.

En cuanto el origen o el destino es local, la tarea programada depende de que el equipo esté encendido a esa hora.

Con origen y destino en la nube, la tarea corre sola desde «Scheduled» aunque tengas el portátil cerrado.

Cómo evoluciona el árbol: de manual a automatizado

Un proyecto no nace automatizado. Suele empezar como un encargo manual y, si resulta útil, se convierte en algo recurrente. La arquitectura acompaña ese cambio sin rehacerse.

En la fase manual, el árbol vive en tu disco:

C:\Cowork_Projects\FLUJO_CAJA_13S\01_PROYECTO_COWORK\   ← conectado en local

El día que decides que el reporting se genere solo cada mes, mueves ese mismo árbol a un almacén en la nube y trabajas por conector:

Google Drive / Reporting_Mensual / 01_PROYECTO_COWORK/   ← alcanzado por conector

Las seis capas no cambian. Cambia dónde viven y cómo se alcanzan. Diseñar pensando en esta posible mudanza evita construir en C: algo que después habría que desmontar para poder programarlo.

Variantes por dominio, anotadas

El marco es agnóstico, pero cada dominio pone el peso en una capa distinta. Ajusta el árbol y las anotaciones en consecuencia.

Consultoría. El peso está en separar lo interno de lo entregable.

01_PROYECTO_COWORK/
├── 00_GOBIERNO/              Brief del encargo y fuentes autorizadas por el cliente.
├── 01_ENTRADAS_ORIGINALES/   Material recibido del cliente. Solo lectura.
├── 02_PREPARACION/           Análisis intermedio, tablas depuradas.
├── 03_MODELO/                Estructura de hallazgos del diagnóstico.
├── 04_SALIDAS/               Informe revisado. NUNCA las notas internas.
└── 05_CONTROL/               Responde al brief, usa solo fuentes autorizadas.

Fuera del perímetro: otros clientes, propuestas comerciales, material no autorizado.

Investigación. El peso está en la evidencia trazable.

01_PROYECTO_COWORK/
├── 00_GOBIERNO/              Pregunta de investigación y criterios de fuente válida.
├── 01_ENTRADAS_ORIGINALES/   Documentos y artículos recibidos. Solo lectura.
├── 02_PREPARACION/           Registro de evidencia: qué afirma cada fuente, limitaciones.
├── 03_MODELO/                Mapa de argumentos y hallazgos.
├── 04_SALIDAS/               Borrador construido sobre evidencia trazable.
└── 05_CONTROL/               Cada afirmación del borrador tiene fuente registrada.

Fuera del perímetro: resultados de búsqueda sin verificar mezclados con fuentes confirmadas.

Reporting recurrente. El peso está en el cierre y la reapertura de cada periodo.

FLUJO_MENSUAL/                       [PAQUETE · NO se conecta]
├── 01_PROYECTO_COWORK/              [SE CONECTA] Solo el periodo activo.
│   ├── 00_GOBIERNO/                 Plantilla de brief con la fecha de corte.
│   ├── 01_ENTRADAS_ORIGINALES/      Entradas del periodo en curso.
│   ├── 02_PREPARACION/
│   ├── 03_MODELO/
│   ├── 04_SALIDAS/                  Informe aprobado del periodo.
│   └── 05_CONTROL/                  Checklist y política de reapertura.
└── 06_HISTORICO_NO_CONECTAR/        [NO] Periodos cerrados. No entran por defecto.

Es el arquetipo que más pide automatización, así que su perímetro vive mejor en un conector.

Anti-patrones que conviene reconocer

Señales de que la arquitectura falla, y qué significan:

• El agente ve una carpeta que debía quedar fuera → conectaste el nivel equivocado.

• Toma por vigente el modelo «corregido» → el registro de fuentes no declara la relación.

• Propone guardar en 01_ENTRADAS_ORIGINALES → las reglas de escritura no están claras.

• Mueve un archivo pero deja copia → trabajas por el puente; para mover de verdad, en local o con un conector que lo permita.

• La tarea programada no corrió de noche → tenía un extremo en C:.

• Eligió entre dos cifras sin avisar → faltó la parada por contradicción en las instrucciones.

• Se lanzó a ejecutar sin plan → faltó la Sesión 0.

Checklist de arquitectura

Antes de escribir el primer prompt de trabajo, deberías poder responder que sí a todo esto:

• ¿Conectas solo 01_PROYECTO_COWORK y dejas fuera el histórico?

• ¿Existe 00_GOBIERNO con instrucciones, brief, registro de fuentes, convenciones, prompts y plan de tareas?

• ¿Cada fuente tiene declarada su relación con las demás?

• ¿Las entradas originales están intactas y las transformaciones viven en preparación?

• ¿04_SALIDAS está vacía hasta que algo pasa el control?

• ¿Sabes qué hecho verificable convierte un borrador en aprobado?

• ¿El almacén elegido encaja con el modo (local si es manual, conector si vas a automatizar)?

• ¿Los prompts que vas a ejecutar están guardados en 04_PROMPTS/, no improvisados?

• ¿El 05_TAREAS/PLAN_DE_TAREAS.md dice en qué orden y con qué prompt se ejecuta cada paso?

Si alguna respuesta es «todavía no», ahí está el trabajo pendiente, y es más barato hacerlo ahora que descubrirlo en el entregable.

En pocas palabras

La calidad de un proyecto con Cowork no se decide cuando el agente ejecuta, sino cuando tú lo arquitecturas.

La estructura de carpetas es el sistema de control: selecciona el contexto, delimita la escritura, representa el estado y conserva la evidencia.

Los nombres fijan el significado. El gobierno escrito quita al agente la carga de improvisar. Y la máquina de estados convierte «lo hizo Claude» en «pasó el control y alguien lo aprobó».

Cuando eso está montado, el prompt deja de cargar con el proceso entero. Se vuelve corto porque el terreno ya dice casi todo. Y el proyecto deja de depender de la suerte.

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para financieros?

👉 Enlace Formación Claude para Financieros

Deja un comentario

Calcula el coste de capital con Claude

Es el número que decide si una inversión crea valor o lo destruye: el tipo al que se descuenta el futuro de un negocio. Y casi ninguna empresa lo calcula bien.

Aquí está el proceso completo, de los datos del balance a una decisión de inversión: cinco fases, un caso real y cifras que cuadran hasta el último decimal. Claude aporta el razonamiento; Claude para Excel, el modelo que recalcula cuando cambian los datos.

El resultado es un CMPC (coste medio ponderado del capital, WACC en inglés) defendible ante un banco, un inversor o el consejo.

La cadena de cinco fases

El procedimiento es el mismo en cualquier país y cualquier tamaño. Cambia el parámetro, nunca el método.

Fase 1. Ponderaciones a valor de mercado. Se fijan los pesos de deuda y fondos propios sobre el valor de la empresa. Dónde entra Claude: explica por qué el valor de los fondos propios de una no cotizada se estima, en lugar de leerse del balance.

Fase 2. Coste de la deuda y escudo fiscal. Se calcula el coste medio de la financiación bancaria y se ajusta después de impuestos, tras validar el límite de deducibilidad de intereses. Dónde entra Claude: comprueba si el gasto supera ese límite y avisa cuando el escudo fiscal es solo parcial. Es razonamiento normativo, y la regla cambia según el país.

Fase 3. Coste de los fondos propios. Se estima la beta con comparables (desapalancar y reapalancar) y se aplica el modelo de valoración de activos del capital (CAPM) más primas. Dónde entra Claude: la selección de comparables y la magnitud de las primas son juicio, no fórmula.

Fase 4. Ensamblaje, escenarios y sensibilidad. Se compone el CMPC y se prueba qué supuesto lo mueve más. Dónde entra Claude: ordena los parámetros por impacto en un mini-tornado.

Fase 5. Valoración del proyecto. El CMPC se usa como tipo de descuento para calcular el valor actual neto (VAN) de una inversión. Dónde entra Claude: traduce el signo del VAN en una decisión clara.

El método es universal, los parámetros son locales

El procedimiento no cambia entre países. Lo que cambia es qué valor se pone en cada parámetro:

• El tipo impositivo es el del país. En España, una entidad de reducida dimensión tributa al 23% en 2026, y una empresa mayor al 25%.

• La deducibilidad de intereses se limita. En España, con el artículo 16 de la Ley del Impuesto sobre Sociedades (30% del beneficio operativo, mínimo un millón). En LATAM, con la regla equivalente derivada de BEPS Acción 4 sobre el EBITDA fiscal, más subcapitalización.

• La tasa libre de riesgo es el bono soberano local, en la moneda de los flujos.

• La prima de riesgo de mercado se toma de la encuesta por país (Fernández, IESE).

• Y aparece un parámetro que en España es cero: la prima de riesgo país. Fuera de un mercado estable, al CAPM se le suma el spread soberano. En un modelo bien montado es una celda editable: cero para España, ajustable para México, Colombia o Chile.

Un aviso que ahorra errores: los flujos y la tasa deben ir en la misma moneda y en la misma base, nominal o real. En países con inflación alta, mezclarlos rompe el resultado.

El papel de Claude para Excel

El razonamiento fija el método. Claude para Excel lo convierte en un modelo que se actualiza solo.

Cada supuesto queda como celda editable. Las betas se desapalancan fila a fila. El CMPC se recompone con referencias entre hojas. Un selector cambia de escenario y todo recalcula. La sensibilidad se resuelve con fórmulas, no con números pegados a mano.

El modelo responde cuando cambian los datos, con una hoja de verificación que exige residuo igual a cero. Y con una sola celda, el mismo modelo pasa de España a un contexto LATAM.

Post Linkedin Modelo de Calculo

El resultado del caso

Para la empresa del caso (un grupo industrial de transformados metálicos, no cotizado, de tamaño mediano-grande), el CMPC resultante es del 10,26%. La nueva línea de producción que se valora tiene un VAN positivo a ese CMPC, así que crea valor y debe aceptarse.

Hay un detalle que solo aparece a este tamaño: con una deuda relevante, el gasto financiero supera el mínimo de deducibilidad, y ya no basta ese mínimo para salvar el escudo fiscal. Hay que calcular el 30% del beneficio operativo y comparar.

En un año de beneficio bajo, el escudo se vuelve parcial y el coste de la deuda sube. Ese es el tipo de matiz donde el razonamiento importa más que la fórmula.

Una aclaración final: por qué esto solo es un reto cuando no cotizas

En una empresa cotizada, el mercado te da los números. En una no cotizada, los construyes con criterio.

La cotización aporta un precio continuo y observable, y de ahí salen la beta, el peso de los fondos propios y buena parte del coste de capital. Sin ese precio, esas piezas no existen y hay que estimarlas. Por eso todo lo anterior es necesario:

• La beta no se lee de la bolsa: se toma de comparables, se desapalanca y se reapalanca.

• El peso de los fondos propios no es la capitalización bursátil: se estima con múltiplos o descuento de flujos.

• El coste de los fondos propios no se queda en el CAPM: suma primas por tamaño e iliquidez, porque el accionista no puede vender ni diversificar igual.

Y no es un caso de nicho. La inmensa mayoría de las empresas no cotizan: familiares, filiales, participadas por fondos, negocios en transmisión.

El reto es el mismo para todas: lo que lo crea es la ausencia de precio de mercado, no el tamaño de la empresa.

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para financieros?

👉 Enlace Formación Claude para Financieros

Deja un comentario

Algoritmo Knapsack 0/1 (el problema de la mochila): Cómo se decide qué entra cuando no cabe todo

El viernes por la mañana, el tesorero tiene 800.000 € en la caja y facturas por 1,3 M€ encima de la mesa. Nadie le va a ingresar nada hasta el lunes, así que va a pagar unas y va a dejar otras para la semana que viene.

Esa misma semana, en una planta, el director de operaciones repasa los pedidos en firme del mes. Piden 2.000 horas de máquina y él tiene 1.400. Va a aceptar unos y va a rechazar otros.

Y en otra empresa, el comité de inversiones se sienta con 1,2 M€ de presupuesto y con proyectos sobre la mesa por 2,5 M€. Va a aprobar unos y va a aplazar otros.

Ninguno de los tres diría que hace lo mismo que los otros dos. El tesorero habla de proveedores, el de operaciones habla de capacidad y el comité habla de VAN.

Pero los tres tienen delante una lista de cosas que no caben en un sitio que no se puede agrandar, y los tres tienen que decidir cuáles entran.

Esa es la decisión, y es una sola.

Los tres la resuelven igual, además: ordenan la lista por lo que rinde cada cosa, bajan de arriba abajo y paran cuando se acaba el sitio.

El tesorero ordenará por descuento de pronto pago, el de operaciones por margen por hora de máquina y el comité por VAN entre inversión. El gesto es el mismo.

Ese gesto tiene una demostración de 1957 que dice que es óptimo. Y tiene una condición, en letra pequeña, que ninguno de los tres cumple.

Este artículo va de cuatro cosas:

• La forma que comparten los tres.

• Por qué la regla falla.

• Cómo se resuelve exacto desde hace setenta años.

• Hasta dónde llega Claude en eso.

Al final hay un caso con números y el cálculo entero para comprobarlo.

La forma

Un problema tiene esta forma cuando reúne tres ingredientes, y solo tres.

Un techo que no se puede rebasar. El dinero que hay en la caja. Las horas que tiene el equipo. El presupuesto que aprobó el consejo. No es un objetivo ni una orientación: es un muro.

Elementos que entran enteros o no entran. Cada uno consume una parte del techo.

Un valor propio por elemento. Lo que aporta si entra.

Eso es todo. Si su decisión tiene esos tres ingredientes, es el mismo problema que estos otros, por muy distinto que parezca el asunto:

Un tesorero, un director de operaciones, un director financiero, un controller, un auditor, un responsable de cuentas clave y el gestor de un programa público.

Ninguno de ellos diría que hace lo mismo que los otros. Los siete resuelven el mismo problema y los siete lo resuelven con la misma regla.

Y a los siete les falla por el mismo motivo.

La prueba que decide si es una mochila

Antes de nada, la comprobación que hay que hacer, porque hay casos que se parecen y no lo son.

Tiene 2 M€ para amortizar deuda anticipadamente y cuatro préstamos vivos. Parece la misma forma: un techo, unos elementos, un valor por elemento. No lo es.

Si su contrato le deja amortizar cualquier importe de cualquier préstamo, y la penalización es proporcional al importe, entonces los elementos se pueden trocear.

Y ahí no hay nada que calcular: ordene por intereses ahorrados menos penalización, por euro amortizado, empiece por arriba y gaste hasta el último euro. Es óptimo, está demostrado, no necesita a nadie.

Ahora cambie una cláusula. Si la penalización tiene un mínimo fijo, o si el contrato exige cancelar el préstamo entero o nada, ya no puede trocear. Y con eso vuelve a ser una mochila.

Esa es la prueba, y es toda la prueba: ¿puedo llevarme un trozo?

Por qué trocear lo cambia todo

Si pudiera pagar el 40% de una factura y llevarse el 40% del descuento por pronto pago, ordenar por rentabilidad sería imbatible.

La razón cabe en una frase: cada euro que gasta va al mejor sitio disponible en ese momento, y el último euro también.

Ese es el mecanismo entero, y lo demostró George Dantzig en 1957.

Baja por la lista y, al llegar al final, el euro que queda se coloca en una fracción del siguiente elemento. No sobra nada.

Cada euro fue al mejor destino que existía cuando le tocó, así que la suma es la mejor suma posible.

Pero no puede pagar el 40% de una factura y llevarse el descuento. No puede fabricar el 40% de un pedido. No puede construir el 40% de una cámara de frío. El elemento entra entero o no entra.

Y ahí se cae el argumento. El último euro se queda sin destino.

Por eso, cuando termina de bajar por la lista, casi siempre sobra algo. Sobran 60.000 € del presupuesto, o 90 horas de máquina, o 40.000 € en la caja del viernes.

Eso que sobra no es un residuo administrativo que se manda a contingencias: es la prueba de que el método perdió su garantía. Y la perdió al principio, no al final.

Lo que hay que ver

Si el orden por rentabilidad no es la respuesta, ¿cuál es la pregunta?

Suponga que le sobran 60.000 € y que en la lista hay dos elementos parecidos.

Uno de 140.000 € con una rentabilidad de 2,21 por euro, que sí entró. Y otro de 200.000 € con 1,90, que se quedó fuera precisamente por ser peor.

Cambie el primero por el segundo.

Ahora el techo cuadra exacto y el conjunto vale más, a pesar de que ha metido el peor de los dos.

Ese argumento no está en ninguna fila de la tabla. No está en el elemento bueno ni en el malo. Está en la relación entre los dos y en el hueco que dejó todo lo demás.

De ahí sale la única idea de este artículo:

Un elemento no vale lo que rinde. Vale lo que rinde más lo que deja caber detrás.

La columna de la rentabilidad mide lo primero, porque mira cada elemento en aislamiento, que es lo único que sabe hacer una columna. Y decidimos como si eso fuera todo.

No lo es, porque el techo es compartido y los elementos no compiten solo por rendir: compiten por encajar.

El salto es ese. De valorar elementos a valorar conjuntos.

El nombre y su edad

El problema se llama knapsack, que en inglés es mochila, y así lo va a encontrar en cualquier herramienta o buscador. En español es el problema de la mochila, y con apellido, mochila 0/1.

La imagen es la que dice el nombre: una mochila con una capacidad, objetos con un peso y un valor, y hay que decidir qué subconjunto meter para maximizar el valor sin pasarse.

Cada objeto entra o no entra, y de ahí el cero y el uno.

El apellido hace todo el trabajo. La versión que sí deja meter medio objeto se llama mochila fraccional. Es otro problema, con otra solución, que es justo la que su comité está usando por error.

Aparece en la literatura matemática en 1897, con George Mathews.

Su formulación moderna como problema de variables discretas viene de Dantzig, en los años cincuenta, el mismo que demostró que el orden por ratio funciona cuando se puede trocear.

La forma de resolverlo que se usa hoy es la programación dinámica, de Richard Bellman, misma década.

Más de setenta años. La caja del viernes, la carga de las máquinas y el comité de inversiones llevan setenta años usando la versión aproximada de un problema que ya estaba resuelto de forma exacta.

Una nota de vocabulario. Coger siempre lo que mejor pinta ahora y no mirar atrás se llama algoritmo voraz, o greedy.

Con knapsack, son las dos únicas palabras en inglés de este artículo, y las dos hay que sabérselas por el mismo motivo: son las que funcionan cuando busca.

Hay muchos algoritmos voraces y algunos son óptimos. Este lo es solo cuando se puede trocear.

Cómo se resuelve sin probarlo todo

La programación dinámica cambia la pregunta. En lugar de atacar “qué meto con todo el techo”, responde antes a todas las versiones pequeñas de esa misma pregunta.

Empieza por lo absurdo. Con un tramo mínimo de techo y un solo elemento disponible, ¿cuál es el mejor valor posible? Cero, no cabe. ¿Con dos tramos? Cero.

Y así, subiendo tramo a tramo hasta el techo entero, siempre con un único elemento sobre la mesa. Ciento veinte respuestas triviales.

Después añade el segundo elemento y repite las mismas ciento veinte preguntas. Y aquí está la observación que lo hace funcionar, que es lo más técnico que va a leer hoy.

Con el elemento nuevo disponible, y para un techo cualquiera, solo hay dos opciones.

No meterlo: entonces el mejor valor es el que ya calculó con un elemento menos y ese mismo techo.

Meterlo: entonces el mejor valor es el suyo sumado al que ya calculó con un elemento menos y el techo que queda tras pagarlo.

Las dos respuestas están escritas de antes. Coge la mayor y sigue.

No se explora nada. No se prueban combinaciones. Cada casilla se resuelve mirando dos casillas viejas.

Por eso una lista con miles de millones de combinaciones posibles se despacha en unos pocos miles de operaciones.

Cuando llega a la última casilla, la de todos los elementos y todo el techo, ahí está la respuesta óptima exacta.

Y como cada casilla recuerda si el elemento entró, se deshace el camino hacia atrás y sale la lista.

Esto exige que el problema tenga una propiedad, y conviene saber cuál porque es la segunda cosa que hay que comprobar: la mejor solución del problema grande tiene que estar hecha con las mejores soluciones de los problemas pequeños.

En la mochila se cumple. En muchos problemas financieros que se le parecen, no.

Hay un detalle del mecanismo que importa más que el resultado.

Para contestar a la pregunta del techo entero, la tabla tuvo que contestar antes a la de un tercio del techo, a la de la mitad y a todas las demás.

No hay forma de llegar al final sin pasar por ahí.

Cuando el cálculo termina, esa información ya está pagada, y normalmente se tira a la basura. Volveremos a ella.

Hasta dónde llega Claude

Conviene decirlo con precisión, porque el sector va lleno de gente prometiendo que la inteligencia artificial “resuelve” la planificación financiera.

Claude no es el algoritmo. Hace cuatro cosas, y solo la primera es difícil.

• Reconoce que una lista de facturas con un techo de caja, o de pedidos con un techo de horas, es una mochila 0/1 y no otra cosa.

• Comprueba si se pueden trocear. Si se pueden, le dice que ordene por ratio y no le cobre por nada más.

• Escribe y ejecuta el cálculo si no se pueden trocear. Son treinta líneas.

• Devuelve la selección óptima, la traza de qué entró y qué salió, y la tabla de techos que calculó por el camino.

Reconocer el problema es el trabajo. Ejecutarlo es aritmética.

Hay que ser justo con Excel: Solver resuelve esto. Lleva un motor de programación entera y está en la pestaña de Datos desde hace veinte años.

Lo que no hace Solver es:

• Leer la lista escrita en prosa.

• Decidir que es una mochila y no un problema de rutas.

• Avisar de que dos elementos tienen una dependencia que invalida el planteamiento.

• Dejarle la tabla de techos sin que se la pida.

Y lo que casi nadie hace con Solver es abrirlo.

El criterio sigue siendo suyo. El algoritmo dice qué combinación maximiza el número que le dio.

No dice si ese número es verdad, ni si a ese proveedor hay que pagarle igualmente porque es el único que le sirve el envase. Eso no está en la tabla y no va a estar nunca.

El prompt

Tengo esta lista de [facturas / pedidos / proyectos] con lo que consume cada uno y lo que aporta: [pega la tabla]. Techo: [800.000 € de caja / 1.400 horas de máquina / 1.200.000 € de presupuesto]. Los elementos son indivisibles: entran enteros o no entran. Resuélvelo como un problema de la mochila 0/1 (knapsack 0/1) con programación dinámica exacta, en rejilla de [10.000 €]. No lo ordenes por ratio. Devuélveme la selección óptima, la comparación contra lo que habría salido ordenando por ratio, y el valor óptimo para cada tramo de [100.000 €] de techo. Antes de calcular, comprueba dos cosas y párate si falla alguna: que los elementos no se puedan trocear, y que ninguno dependa de otro ni excluya a otro. Si se pueden trocear, dime solo el orden por ratio.

Los límites, que son tres y son serios

La independencia. Este es el grave, y es el que casi nadie menciona. Los objetos de una mochila no se hablan entre ellos.

Si un elemento es requisito de otro, o si dos se pisan porque necesitan la misma máquina, su decisión no es una mochila 0/1.

Es un problema de programación entera con restricciones, que se resuelve igual de bien pero con otro planteamiento.

La mayoría de las listas reales tienen alguna dependencia escondida, así que esto se mira antes de calcular nada.

La rejilla. El cálculo necesita que los consumos sean múltiplos de algo.

Si redondea a 10.000 €, la tabla son mil cuatrocientas casillas. Si redondea al euro, son catorce millones, y se vuelve lento sin ganar precisión real, porque nadie estima un VAN a cinco años al euro.

Lo que le cuesta al algoritmo no depende solo de cuántos elementos hay, sino de lo fina que sea la rejilla.

Redondear los consumos al alza es lo prudente: garantiza que la selección cabe de verdad.

El valor. El algoritmo optimiza los números que le dé. Si el VAN de una línea de envasado salió de una reunión de dirección, la selección óptima es la mejor combinación posible de cifras inventadas.

Precisión no es exactitud. Una mochila no arregla una estimación mala: la propaga con más decimales de los que merece.

Una honestidad sobre el tamaño. Con doce elementos hay 4.096 combinaciones y cualquier ordenador las prueba todas, una a una, en menos de un segundo.

A esa escala, la programación dinámica no gana velocidad: gana la tabla de techos.

La ventaja de velocidad aparece cuando la lista crece. Con cuarenta elementos, que son las facturas de una semana normal, las combinaciones pasan del billón y la tabla sigue siendo de unos pocos miles de casillas.

El caso: una distribuidora de 48 M€

Hasta aquí, la forma. Ahora los números, que son los que deciden si todo lo anterior era palabrería.

Elijo el comité de inversiones porque es donde el error sale más caro, pero valdría igual con las facturas del viernes.

Una distribuidora de alimentación de 48 M€ de ventas. Presupuesto anual de inversión, 1.200.000 €. Doce proyectos que piden 2.490.000 €, así que cabe menos de la mitad. El VAN, calculado a cinco años.

No hace falta estudiar la tabla: basta con tenerla a mano.

Primero, la prueba: ¿se puede trocear? No. Media cámara de frío no enfría. Es una mochila.

El comité baja por la lista y marca los siete primeros. Suman 1.140.000 € y 2.870.000 € de VAN.

El octavo es la cámara de frío, que cuesta 320.000 € y no cabe en lo que queda. El noveno tampoco. Ni el siguiente.

Quedan 60.000 € sin invertir. Ahí está el último euro sin destino, que ya sabemos lo que significa.

La selección óptima vale 2.940.000 € e invierte los 1.200.000 € exactos. Son 70.000 € más, un 2,4%.

Y los consigue con un solo cambio: saca la delegación en Portugal, de índice 2,21, y mete el segundo turno en la planta, de índice 1,90.

El peor de los dos, por 60.000 € más, que son justo los que sobraban, y 70.000 € más de VAN.

Es el intercambio que planteé en abstracto hace doce párrafos, ahora con nombres.

¿Y si el comité acertó?

70.000 € sobre 2,9 M€ de VAN es un 2,4%. Poco. Si el caso terminara aquí, tendría derecho a cerrar el artículo.

Así que simulé diez mil listas distintas con esta misma forma y comparé el orden por rentabilidad contra la selección óptima en cada una.

El orden por rentabilidad acierta la selección óptima casi la mitad de las veces. En el 45% de los casos, el comité tomó la mejor decisión posible y nunca lo supo.

En el resto, la pérdida típica es de medio punto porcentual, que es ruido comparado con el error de estimar un VAN a cinco años.

Y una de cada cien listas deja más del 10% del techo sobre la mesa.

La media no es el problema. El orden por rentabilidad no trae barra de error.

Sale un número, se aprueba en consejo, y nadie en la sala sabe si ese ejercicio se dejaron 4.000 € o 190.000 €.

Tampoco hay forma de distinguir la lista afortunada de la cara mirándola, porque lo que decide es el encaje, y el encaje no se ve.

El argumento a favor de calcular el óptimo es modesto, y por eso aguanta: no es que el comité lo esté haciendo mal. Es que decide a ciegas sobre algo que se puede ver en segundos.

La tabla que nadie pide

Aquí vuelve lo que quedó pendiente. La tabla tuvo que calcular el óptimo para cada techo intermedio antes de llegar al suyo. Si la conserva y la estira un poco más allá, aparece esto:

Lea la última columna despacio. Los 100.000 € que llevan de 1.200.000 a 1.300.000 compran 150.000 € de VAN. Los siguientes 100.000 € compran 220.000 €.

El segundo tramo rinde más que el primero. Eso contradice la intuición financiera básica, según la cual el rendimiento marginal decrece según se agotan las buenas oportunidades.

En una lista indivisible no decrece de forma ordenada, y el motivo es el mismo de todo el artículo. El techo extra no compra más de lo mismo: compra elementos enteros.

Hay tramos donde 100.000 € adicionales no alcanzan para meter nada nuevo y solo permiten recolocar. Y hay tramos donde de golpe entra algo grande que llevaba todo el rato fuera.

El rendimiento marginal de una decisión indivisible va a saltos, no en pendiente.

Lo que un director financiero hace con eso no tiene nada que ver con algoritmos.

Va al consejo y dice: ampliar el presupuesto en 100.000 € es mal negocio, rinde 1,5 veces; ampliarlo en 200.000 € rinde 1,85. La ampliación pequeña es la mala, y aquí está la tabla.

Ninguna reunión de comité produce esa frase.

Una costura de este caso, por honestidad: trata la certificación de calidad y la delegación en Portugal como independientes. En el mundo real, la segunda probablemente exija la primera, y entonces esto ya no sería una mochila limpia.

Es exactamente el primer límite que enuncié, y mi propio ejemplo lo pisa.

Las otras dos salas

Consultoría. En todo plan de transformación aparece la matriz de dos ejes: impacto arriba, esfuerzo a la derecha, y las iniciativas de arriba a la izquierda van primero.

Eso es ordenar por valor dividido entre coste, así que hereda entera la garantía de Dantzig y su condición.

La matriz añade además un problema propio: no sabe sumar. Coloca cada iniciativa en su punto sin mirar el techo de horas del equipo, y en cuanto ese techo existe, el cuadrante bueno puede no caber entero.

La pregunta que la rompe es siempre la misma: con este techo concreto, ¿qué subconjunto entra y cuánto vale?

La matriz sirve para explicar una idea en una reunión, y se usa para decidir.

Investigación. Una agencia que reparte 12 M€ entre noventa propuestas evaluadas por un panel tiene una mochila de manual. Con noventa candidatas, la fuerza bruta ya no existe como opción.

Solo que el valor de una propuesta de investigación no es un número: es una distribución muy ancha. Optimizar sobre la media es precisión falsa.

Lo que se hace es resolver la mochila muchas veces, una por escenario de valores, y contar en cuántos escenarios aparece cada propuesta.

Las que salen en el 95% se financian sin debate. Las que salen en el 30% son la conversación real del panel.

El algoritmo deja de dar una respuesta y pasa a dar una frecuencia, que para decidir bajo incertidumbre sirve más.

Para el lunes

No hace falta esperar al comité de inversiones, que es anual. La caja del viernes es semanal.

Coja la lista de lo que no cupo la última vez, con lo que consumía cada cosa y lo que aportaba, y el techo que había.

Antes de nada, hágase la pregunta de la prueba: ¿podía llevarme un trozo?

Si podía, ordene por ratio y cierre el asunto, que ya está resuelto. Si no podía, pida la selección óptima y la tabla de techos.

Puede que salga que acertó, y hay un 45% de posibilidades de que así sea. Eso también es información: significa que esa lista era de las fáciles.

Lo que va a salir seguro es la tabla.

Y con ella, la conversación de septiembre deja de ser cuánto más presupuesto se pide y pasa a ser cuánto compra cada tramo. Son preguntas distintas, y solo la segunda tiene respuesta.

El cálculo, para quien quiera reproducirlo

No hace falta leerlo para usar el artículo. Está aquí para que los números se puedan comprobar.

python  
from itertools import combinations

# (elemento, lo que consume, lo que aporta)
P = [
    ("Renovacion de la flota comercial", 180_000, 420_000),
    ("Ampliacion de la camara de frio",  320_000, 640_000),
    ("Renovacion del ERP",               260_000, 300_000),
    ("Sistema de gestion de almacen",    150_000, 330_000),
    ("Autoconsumo fotovoltaico",          90_000, 260_000),
    ("Delegacion en Portugal",           140_000, 310_000),
    ("Automatizacion de pedidos",        120_000, 400_000),
    ("Segundo turno en la planta",       200_000, 380_000),
    ("Certificacion de calidad",         110_000, 250_000),
    ("Recambio de carretillas",          170_000, 300_000),
    ("Nueva nave de almacenaje",         400_000, 700_000),
    ("Nueva linea de envasado",          350_000, 900_000),
]
TECHO, PASO = 1_200_000, 10_000

def mochila(items, techo, paso):
    """Mochila 0/1 exacta. Devuelve (valor optimo, seleccion)."""
    W = techo // paso
    pesos = [c // paso for _, c, _ in items]
    t = [[0] * (W + 1) for _ in range(len(items) + 1)]
    for i in range(1, len(items) + 1):
        w_i, v_i = pesos[i - 1], items[i - 1][2]
        for w in range(W + 1):
            t[i][w] = t[i - 1][w]                      # no meterlo
            if w_i <= w:                               # o meterlo
                t[i][w] = max(t[i][w], t[i - 1][w - w_i] + v_i)
    sel, w = [], W                                     # deshacer el camino
    for i in range(len(items), 0, -1):
        if t[i][w] != t[i - 1][w]:
            sel.append(items[i - 1])
            w -= pesos[i - 1]
    return t[len(items)][W], sel[::-1]

def por_ratio(items, techo):
    """Lo que se hace hoy: ordenar por valor/consumo y bajar."""
    resto, sel = techo, []
    for it in sorted(items, key=lambda x: -x[2] / x[1]):
        if it[1] <= resto:
            sel.append(it)
            resto -= it[1]
    return sel, resto

V_opt, seleccion = mochila(P, TECHO, PASO)
g, resto = por_ratio(P, TECHO)
V_g = sum(v for _, _, v in g)

# Verificacion independiente: las 4.096 combinaciones, una a una
mejor = max(
    sum(x[2] for x in c)
    for r in range(len(P) + 1)
    for c in combinations(P, r)
    if sum(x[1] for x in c) <= TECHO
)

print(f"por ratio: {V_g:,} (sin usar {resto:,})")    # 2.870.000 (sin usar 60.000)
print(f"optimo:    {V_opt:,}")                       # 2.940.000
print(f"fuerza bruta coincide: {mejor == V_opt}")    # True

for b in range(1_200_000, 1_400_001, 100_000):       # la tabla de techos
    v, _ = mochila(P, b, PASO)
    print(f"{b:>10,} -> {v:>10,}")

Para la simulación de las diez mil listas, sustituye P por consumos y ratios aleatorios y compara mochila con por_ratio en bucle.

Escrito con Claude, que ejecutó el cálculo y devolvió las trazas. Los números de este artículo salen de ahí, no de mi cabeza.

IA Aplicada. jlopez@tallerformacion.com

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para financieros?

👉 Enlace Formación Claude para Financieros

Deja un comentario

Un descuento del 10% no reduce el margen un 10%

Cuando el precio baja un d y los costes variables no cambian, el margen unitario no cae en la misma proporcion que el precio: cae mas.

Para recuperar el mismo margen de contribucion total hay que vender un 33% mas de unidades (con mo = 0,40 y d = -10%), no un 10% mas.

Esa asimetria convierte la mayoria de los planes de descuento en decisiones que nadie habria aprobado si hubiera calculado el numero correcto.

La herramienta que cambia el analisis no es una hoja de calculo mas rapida.

Es un modelo que integra las variables de cinco agentes, calcula el descuento maximo que cada combinacion puede sostener y produce una regla de decision que toda la direccion puede firmar.

1. El problema: por que el descuento destroza el margen mas de lo que parece

La relacion coste-volumen-resultado (CVR) establece que el resultado de explotacion es funcion del margen unitario y del volumen de ventas. En la version mas simple, con un solo producto y costes variables constantes:

R = m · V - CE

Donde:

• m es el margen unitario de contribucion: la fraccion de cada euro vendido que queda libre de costes variables.

• V son las ventas totales.

• CE son los costes de estructura.

El punto de equilibrio, o ventas de equilibrio (VE), es el nivel de ventas en que el margen de contribucion cubre exactamente los costes de estructura:

VE = CE / m

Cuando la empresa baja sus precios un d por ciento (d negativo), los costes variables unitarios en euros no cambian de inmediato.

Lo que cambia es el precio de cada unidad vendida: el ingreso por unidad cae de 1 a (1 + d).

El coste variable, que representaba Cv por unidad monetaria de precio, ahora representa Cv / (1 + d) por cada euro del nuevo precio. El margen unitario final es:

mf = (mo + d) / (1 + d)

Con mo = 0,40 y d = -0,10: mf = (0,40 - 0,10) / (1 - 0,10) = 0,30 / 0,90 = 0,3333. El margen no ha bajado un 10%: ha bajado un 16,7% en terminos relativos.

2. La asimetria que nadie nombra: ingresos no son unidades

Para mantener el mismo resultado de explotacion, el margen de contribucion total debe quedar igual. Como los costes de estructura no han cambiado:

VTf · mf = VTo · mo  =>  VTf / VTo = mo / mf

Con mo = 0,40 y mf = 0,3333: VTf / VTo = 0,40 / 0,3333 = 1,20. Las ventas en euros deben crecer un 20%.

Pero la empresa no vende euros: vende unidades. Si el precio ha bajado un 10%, cada unidad factura un 10% menos. La relacion entre unidades finales e iniciales es:

Nf / No = (VTf / VTo) / (1 + d) = mo / (mo + d)

Con mo = 0,40 y d = -0,10: Nf / No = 0,40 / 0,30 = 1,333. Hay que vender un 33,3% mas de unidades para no perder un euro de beneficio.

La ultima fila es la referencia que nunca aparece en la presentacion de Comercial. Una subida del coste variable del 10% exige vender un 17,6% mas: la mitad del esfuerzo que un descuento del 10% en precio.

Defender el precio es siempre preferible a contener el coste cuando los porcentajes son equivalentes.

Donde entra Claude (1 de 3). Con la cuenta de resultados y el descuento propuesto, Claude calcula mf, la ratio de ingresos, la ratio de unidades y la elasticidad implicita del plan. Devuelve la tabla comparativa y un veredicto en formato BLUF. El analista no necesita construir el modelo: pega los datos y recibe el diagnostico con el numero que nadie habia calculado.

3. Invertir la pregunta: el descuento maximo defendible

La pregunta habitual: dado un descuento, cuanto mas hay que vender.

La pregunta util para direccion: dado un techo realista de unidades, cual es el descuento maximo que la empresa puede conceder sin destruir beneficio.

Partiendo de Nf / No = mo / (mo + d), si el techo de unidades es g (en tanto por uno), entonces Nf / No = 1 + g. Despejando d:

d_max = -mo · g / (1 + g)

El plan ingenuo del 10% implica creerse que el mercado respondera con una elasticidad de 3,33.

En distribucion industrial, con contratos y costes de cambio, la elasticidad tipica se mueve entre 0,5 y 1,5.

El plan no es arriesgado: es incompatible con los datos del sector.

4. La decision multiagente: cuando cada area tiene razon y nadie tiene razon

El error de los descuentos no es aritmetico: es organizativo. Cada area llega a la reunion con su variable y no hay ningun modelo que las integre antes de la decision.

La formula combinada que integra el cambio de precio y el cambio de coste en un solo margen es:

mc = (mo + d) · (1 + j) / (1 + d) - j

Fijados el techo de unidades g y la mejora de coste j, existe un descuento exacto d* que iguala el margen de contribucion al objetivo (CE + R). Ese valor se resuelve con la formula cerrada:

d* = mo / (1 + g) - mo · (1 + j) + j

Con mo = 0,40, g = 0,15 y j = -0,05: d* = -8,2174%.

El descuento que la mesa puede firmar no es el 10% de Comercial ni el 5,2% puro de Direccion: es el valor que equilibra las tres palancas a la vez.

La elasticidad que exige esa decision (g / |d*| = 0,15 / 0,082174 = 1,83) sigue siendo alta para el sector. Eso convierte el piloto en condicion necesaria, no opcional.

Donde entra Claude (2 de 3). Con el diagnostico anterior y las variables de cada agente, Claude calcula d_max, mc y d* con las formulas cerradas, detecta los conflictos (veto, alerta, aviso), construye la cuenta de resultados reconciliada y verifica residuo 0,00 euros. El analista no negocia en la sala sin este numero.

5. Las capas que el resultado de explotacion no muestra

La cuenta de resultados cuadra. El circulante no aparece en ella. Tres capas complementan el analisis antes de firmar cualquier plan de descuento.

5.1 Circulante: el plan neutro que cuesta dinero

Un aumento del volumen de ventas inmoviliza circulante. Con dias de cobro DSO, dias de stock DIO y dias de pago DPO, el circulante neto incremental es:

NWC = dV · DSO/365 + dCV · DIO/365 - dCV · DPO/365

Donde dV es el incremento de ventas y dCV el incremento de coste variable.

Con dV = 138.750 eur, DSO = 75, DIO = 60, DPO = 45 y kd = 6%: NWC neto = 34.212 eur, coste financiero anual 2.053 eur.

El plan neutro en resultado de explotacion tiene un coste real de caja.

5.2 Reversibilidad: la cola de riesgo que nadie modela

Si el volumen no llega, el descuento se consolida como precio de referencia para el cliente.

Con j que revierte a 0 y las unidades que vuelven a la base, el resultado cae de 300.000 eur a 94.565 eur: un -68%.

La decision de descuento es asimetrica: el beneficio del exito es limitado (mantenemos el resultado); el coste del fracaso es severo.

5.3 Descuento selectivo frente a lineal

Un descuento del -8,2% aplicado linealmente sobre las ventas iniciales cede 205.435 eur de margen a clientes que habrian comprado igual sin el descuento.

Un descuento dirigido, aplicado solo al volumen incremental o a cuentas nuevas, consigue el mismo arrastre de volumen cediendo mucho menos margen sobre la base existente.

Donde entra Claude (3 de 3). Con el resultado anterior y los parametros de circulante, Claude calcula las tres capas, construye el caso malo realista y redacta la regla de decision en cinco lineas: descuento autorizado, condicion de piloto, criterio de parada y restriccion sobre la forma de aplicar el descuento. El entregable entra directamente en el acta de la reunion.

6. La regla, no el numero

El entregable de un analisis de descuento no es el porcentaje: es la regla que el comite firma. Una regla bien construida tiene cuatro elementos:

1. El descuento autorizado con el nivel exacto que cierra el sistema (d* = -8,2174%, comunicado como -8,2%).

2. La condicion de piloto: el plan se prueba en una linea durante N semanas. El umbral de unidades observable se deriva de la elasticidad exigida.

3. El criterio de parada: si el incremento de unidades no alcanza el umbral en la fecha fijada, el precio vuelve a lista y el acuerdo de Compras se da por vencido.

4. La restriccion de aplicacion: el descuento se aplica de forma dirigida (nuevas cuentas o tramos de volumen incremental), no linealmente sobre la cartera existente.

La diferencia entre el plan ingenuo y la decision reconciliada no la hizo un calculo. La hicieron cuatro movimientos de razonamiento:

• Invertir la pregunta.

• Sumar la palanca de Compras.

• Respetar el suelo de Direccion.

• Poner precio al riesgo que queda.

Eso es lo que Claude produce cuando el analista sabe que preguntas hacer.

7. Como replicar el analisis en tu empresa

Los cuatro prompts del kit COMPENSA siguen la misma secuencia que este articulo.

En este post de Linkedin puedes pedir un modelo Excel, guia y los cuatro prompts para que generes tu propio modelo de simulación

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para financieros?

👉 Enlace Formación Claude para Financieros

Deja un comentario

Cowork no se usa. Se organiza.

He escrito un manual de Claude Cowork (9 guías) que recojen mi trabajo con esta herramienta en entornos de Finazas, Consultoría y Procesos.

Lo que sigue es el resumen técnico de lo que salió, contrastado con la documentación de Anthropic en julio de 2026. Lo que no está documentado va marcado como observación de uso.

La tesis, por delante:

Cowork no es un chat con acceso a archivos. Es un agente que trabaja sobre tu disco el tiempo que sea necesario. Eso convierte el problema en uno de gestión de proyecto, no de prompting.

Casi todo lo que sale mal, sale mal por ahí.

1. La arquitectura

Cuatro hechos que explican los comportamientos que desconciertan al principio.

Por defecto la sesión corre en los servidores de Anthropic.

Ejecución remota, en beta, desplegándose por fases empezando por el plan Max. Puedes cerrar el portátil y el trabajo sigue.

En despliegues de escritorio antiguos la sesión puede correr en local. Ahí, cerrar la app la corta. Si no sabes en cuál estás, no cierres la tapa a mitad de una fase.

Tus archivos siguen en tu máquina.

Cuando la sesión remota necesita un fichero tuyo, lo pide a través de la app de escritorio. Si la app está cerrada, la sesión sigue viva pero se queda ciega.

Esto vale también desde web y móvil. Cowork funciona ahí, y llega a tus archivos solo si la app de escritorio de ese ordenador está abierta y la carpeta conectada.

El código se ejecuta en una VM aislada.

Shell y Python corren en una máquina separada de tu sistema. La consecuencia práctica es buena: puedes pedirle que verifique un modelo con un script sin instalar nada.

Solo ve las carpetas que le conectas.

Fuera de ellas es ciego. Dentro, lo ve y lo toca todo, subcarpetas incluidas.

Y un límite documentado que sorprende en entorno corporativo: en Windows, las unidades de red mapeadas y las rutas UNC no se admiten como carpeta de trabajo.

2. Los cuatro arquetipos

Esto es lo único de todo el manual que yo llamaría un hallazgo, y no está en ninguna documentación.

No todos los trabajos con un agente se rompen igual. Y por tanto no se verifican igual.

Arquetipo Cómo se rompe Control de cierre Construcción (modelo financiero, cierre mensual, DCF)

El error de la fase 2 llega intacto a la fase 8. Y las cifras siguen pareciendo razonables. Recálculo independiente.

Diferencia cero. Síntesis (due diligence, informe de mercado) Inventa un dato plausible. Omite lo que contradice la tesis.

Trazabilidad (afirmación → documento → página → cita) y

contra-tesis no vacía. Documentación (manual, SOP, política) Falta una sección. El término cambia en la página 40. Dos apartados se contradicen.

Comprobación estructural: secciones × glosario × contradicciones.

Transformación (limpiar un CSV, convertir 200 PDFs) Pierde filas en silencio. Conteo: entraron N, salieron N.

Identificar el arquetipo antes de empezar te da tres cosas gratis:

• El control de cierre.

• El error que tienes que estar buscando todo el rato.

• La estructura de carpetas.

Un proyecto puede ser dos arquetipos a la vez. Una due diligence con un modelo dentro es síntesis y construcción. Entonces necesitas los dos controles, cada uno sobre su parte. No elijas.

3. El contrato de carpetas

La pregunta que casi nadie hace: ¿cómo sabe Claude en qué carpeta escribir?

No lo sabe. Decide por tres vías, en este orden de fiabilidad:

1. La ruta que le das en el prompt. Fiabilidad total.

2. Lo que digan las instrucciones o el contrato. Alta.

3. Se lo inventa. Mira lo que hay, deduce, elige. Y no te avisa de que está adivinando.

Nombrar una carpeta 02_Verificacion no le dice nada sobre qué es una verificación. Es un nombre.

La estructura de carpetas es decorativa si no la declaras.

La solución que uso

Un LEEME_CLAUDE.md en la raíz del proyecto que declara el mapa.

## Mapa de carpetas: reglas de escritura

| Carpeta               | Contiene              | LEER | ESCRIBIR    |
|-----------------------|-----------------------|------|-------------|
| 00_Fuentes/           | Lo que me han dado.   | SÍ   | NO. NUNCA.  |
| 01_Trabajo/           | Donde construyes.     | SÍ   | SÍ          |
| 01_Trabajo/versiones/ | Copias fechadas.      | SÍ   | SÍ (añadir) |
| 02_Verificacion/      | Comprobaciones.       | SÍ   | SÍ          |
| 03_Entregables/       | Solo lo verificado.   | SÍ   | SÍ          |

## Reglas que no se negocian
1. 00_Fuentes/ es de SOLO LECTURA.
2. Nada llega a 03_Entregables/ sin pasar el control de cierre.
3. Antes de sobrescribir en 01_Trabajo/, copia a versiones/.
4. Si no sabes en qué carpeta va algo, PREGÚNTAME.
5. Si te encuentras algo que no encaja, PARA y avísame.

Por qué un archivo y no solo las instrucciones del proyecto.

Los proyectos de Cowork son locales y no se pueden compartir, ni siquiera en planes Team. El LEEME_CLAUDE.md viaja dentro de la carpeta.

Es la única parte del montaje que se puede pasar a un compañero.

La sección que lo mantiene vivo

Un apartado “Estado actual”, una línea por sesión, actualizada al cerrar.

La próxima sesión Claude la lee y sabe dónde estabais. Vale más que la memoria del proyecto, porque es literal y la controlas tú.

Estructuras por arquetipo

No hay una universal.

En síntesis, 00_Fuentes/ se subdivide en 01_Primarias/, 02_Secundarias/ y 03_Dudosas/. Y aparece un archivo raro y decisivo: 02_Verificacion/Contra-tesis.md.

Si ese archivo está vacío al terminar, no hiciste una due diligence: hiciste una justificación.

En documentación, dos archivos que empiezan por 00_ dentro de 01_Trabajo/: la estructura de secciones y el glosario canónico. Se cierran antes de redactar una línea.

Si los dejas para el final, reescribes el documento entero.

4. Los tres niveles de instrucciones

Aquí es donde más gente mete la regla en el sitio equivocado: Nivel dónde alcance

Qué va Globales Settings → Cowork → Global instructions Todas tus sesiones

Lo cierto de ti: idioma, sector, formato de cifras, reglas de honestidad.

De proyecto: al crear o editar el proyecto Todas las tareas de ese proyecto Lo cierto del trabajo: rol, fuentes, convenciones, método, control de cierre.

De carpeta Asociadas a la carpeta local. Claude puede actualizarlas él mismo durante una sesión. Cuando esa carpeta está conectada

Detalles del contenido.

La regla para decidir dónde va cada cosa es una pregunta: ¿esto seguiría siendo cierto en otro proyecto?

• Sí → globales.

• No, pero es cierto en todas las tareas de este → proyecto.

• Solo aquí y ahora → al prompt.

El error frecuente: meter datos del proyecto en las globales. Cambias de trabajo y Claude sigue creyendo que existe un Maestro_cuentas.xlsx, y lo busca donde no está.

Sobre la memoria, cuatro cosas

• Solo funciona dentro de proyectos. La del chat normal no pasa a Cowork.

• Es acumulativa, y eso corta por los dos lados: no repites contexto, pero una convención mal fijada en la sesión 1 se propaga a todas.

• No la ves. No hay panel donde leer qué recuerda.

• Es aproximada. Las instrucciones son literales.

Por eso las convenciones críticas van en instrucciones, no en memoria.

La plantilla

Siete bloques, del 0 al 6: contrato de carpetas, rol y prioridad, fuentes, convenciones, método, control de cierre, estilo.

El bloque 5 es el que casi nadie escribe. Es el que impide que te entreguen algo que “parece bien”.

5. Las convenciones

Una convención es cualquier definición donde dos personas razonables podrían interpretar distinto y llegar a resultados distintos sin que ninguna se haya equivocado.

No son errores. Son elecciones.

Si no las fijas por escrito, Claude elige una y tú otra. Y pierdes una tarde buscando un error de cálculo que no existe.

De un cierre mensual

• ¿La desviación va contra presupuesto o contra el mismo mes del año anterior?

• ¿Los importes con IVA o sin IVA?

• Una factura del día 31 contabilizada el día 2: ¿de qué mes es?

• El porcentaje de variación, ¿sobre presupuesto o sobre real? Cambia el denominador.

• ¿Qué se hace con una cuenta del ERP que no está en el maestro? Ignorar, agrupar en “otros”, o parar y avisar.

La última es la que casi nadie define. Y es la que rompe cierres en silencio: la cuenta nueva se agrupa en “otros”, el cierre cuadra, y cuadra mal.

De una due diligence

• Si dos fuentes se contradicen, ¿cuál gana? La respuesta correcta es ninguna: se reportan las dos.

• ¿Se puede afirmar algo que solo dice una fuente?

• ¿”No hay datos suficientes” es una conclusión válida? Debe serlo. Si no, estás forzando una conclusión.

La que sirve para los tres arquetipos

Escríbela siempre:

Si te encuentras algo que no encaja, para y pregúntame.

Si no la escribes, Claude decidirá algo razonable y seguirá. Y tú no te enterarás.

6. Skills

Las skills no se invocan. Claude ve la descripción de cada una (no el cuerpo) y carga la que encaja con lo que le pides. Anthropic lo llama divulgación progresiva.

Dos consecuencias.

La buena. Si tienes una skill que audita modelos financieros, se dispara cuando la necesitas aunque no sepas que existe.

La que despista. A veces Claude hace más de lo que le pediste. No es capricho: es una skill que se ha disparado. Puedes preguntárselo directamente.

Y el corolario que más rendimiento da:

Tu vocabulario es tu interfaz.

“Mira a ver si esto está bien” te da una opinión.

“Audita el Excel, cuadra los números y verifica las fórmulas encadenadas” te dispara un protocolo de auditoría con recálculo independiente en Python.

Diez segundos de vocabulario. Un protocolo profesional de diferencia.

Si escribes tus propias skills

La descripción es lo único que decide si existen. Debe listar dos cosas:

• Las frases literales con las que la pedirías.

• Cuándo NO debe usarse.

Una skill que no se dispara es una skill que no existe.

Pruébala: escribe tres frases (la obvia, un rodeo natural, algo tangencial) y comprueba cuáles la activan.

7. Conectores: el error de seguridad que yo mismo cometí

Escribí en el borrador del manual que los conectores “solo leen”. Es falso, y la auditoría lo cazó.

• Google Drive lee Docs, Sheets, Slides y PDFs. Y también sube archivos, crea carpetas y guarda en tu Drive lo que Claude genere.

• Microsoft 365, si tu organización activa las herramientas de escritura, puede enviar correo en tu nombre y crear o modificar archivos en OneDrive y SharePoint.

Esto importa porque toda estrategia anti-inyección que se apoye en “como mucho me lee algo” es falsa.

En un trabajo que lee cincuenta documentos de terceros: cero conectores activos. Si Claude no puede actuar fuera de la carpeta, una inyección no tiene a dónde ir. Con un conector de escritura activo, sí lo tiene.

El botón “+” de la caja de mensaje decide qué conectores están vivos en esa sesión concreta. No hace falta desinstalar nada.

Dos matices más:

• Del contenido de un Sheet, el conector extrae texto y valores. Si necesitas auditar fórmulas, descarga el .xlsx a la carpeta local. (Observación de uso, no límite documentado.)

• Un conector no es una carpeta de trabajo. Claude no itera archivo a archivo dentro de Drive como lo hace en local.

8. Permisos, cuota y lo que no está cubierto

Los tres modos

• Manually approve. Para en cada acción.

• Automatically approve. Trabaja seguido, revisa cada acción por seguridad, y consume más cuota por esa revisión.

• Skip all approvals. No pregunta y nada revisa.

Hay acciones que ni el modo Auto autoriza solo: borrar archivos, dar acceso a carpetas nuevas, crear tareas programadas. Y el borrado pide permiso explícito en cualquier modo, siempre.

Inyección de prompt, en una línea

Para que funcione tienen que darse dos cosas a la vez: que Claude pueda leer contenido que no controlas, y que pueda actuar de forma que te perjudique.

Rompe una y el ataque no va a ningún sitio. Eso es exactamente lo que puedes controlar.

Tareas programadas: el límite antes de ilusionarse

Una tarea programada no puede atarse a una carpeta de tu ordenador. Trabaja con conectores y con los archivos guardados en tu cuenta.

Si necesita archivos locales, solo se ejecuta en local, con la app abierta.

Traducción para un cierre mensual cuyos ficheros están en tu disco: la programación te sirve de disparador, no de automatización desatendida.

Lo que no está cubierto

• La actividad de Cowork no aparece en registros de auditoría, ni en la Compliance API, ni en exportaciones de datos.

• En Team y Enterprise hay salida vía OpenTelemetry a tu SIEM.

• Las herramientas EDR no pueden inspeccionar lo que ocurre dentro de la VM ni en sesiones remotas.

Si tu cumplimiento depende de visibilidad en el endpoint, tenlo en cuenta antes de desplegar.

El aviso incómodo

En un contexto financiero hay que decirlo.

La documentación de Anthropic recomienda expresamente evitar dar acceso a archivos locales con información sensible, y cita los documentos financieros como ejemplo.

Los archivos que Claude abre a través de la app salen de tu ordenador y se procesan en servidores de Anthropic.

Carpeta dedicada, datos anonimizados, o consulta la política de tu empresa.

Cuota

Cowork consume bastante más que el chat. Lo que más ahorra, por este orden:

1. Pensar en el Chat y ejecutar en Cowork.

2. Montar el proyecto. Contexto repetido son tokens repetidos.

3. Un prompt, una fase. Los encargos vagos hacen que explore, y explorar es lo caro.

4. Dar la ruta exacta.

Y una que ahorra más que todas: cuadrar cada fase antes de la siguiente.

Un error de la fase 3 detectado en la fase 8 son cinco fases a rehacer. El método no es solo más fiable: es más barato.

9. El caso: TESOSTOCK

Un presupuesto de tesorería mensual con almacén.

Cuatro políticas de stock. Doce meses con estacionalidad. Demoras de cobro y pago. IVA trimestral. Línea de crédito. Dos inversiones que revientan la caja en marzo y julio. Cinco indicadores por política y un memo al consejo.

Arquetipo: construcción. Doce fases encadenadas, cada una con su prompt y su control.

El control temprano que salva el caso

El cobro de enero debe salir 63.620 €:

30 % x 95.400 (ventas de enero)      = 28.620
40 % x 40.000 (ventas de diciembre)  = 16.000
20 % x 60.000 (ventas de noviembre)  = 12.000
10 % x 70.000 (ventas de octubre)    =  7.000
                                       ------
                                       63.620

Si te sale 28.620 (solo el primer sumando), te faltan las ventas históricas y vas a arrastrar el error todo el primer trimestre.

Ese control no distingue 62.000 de 63.620. Distingue 63.620 de 28.620. Para eso sirve.

El control de cierre

Un script de Python que reconstruye el presupuesto completo desde la hoja de inputs. Sin leer ninguna otra hoja. Sin copiar ninguna fórmula del Excel.

Se comparan las dos salidas celda a celda. Diferencia total: 0,00 €.

Esto no es que Claude “se revise a sí mismo”, que sirve de poco.

Es que el mismo problema se resuelve dos veces por caminos independientes: fórmulas encadenadas de Excel por un lado, código por otro.

Si dos caminos distintos llegan al mismo número al céntimo, la probabilidad de que ambos se equivocaran igual es despreciable.

10. Auditar tu propio trabajo no funciona

Cuando terminé las nueve guías, le pedí a la IA que las auditara. Lo que salió de ahí es probablemente lo más útil del proyecto.

Un modelo que revisa su propio output se aprueba. Es sesgo de auto-preferencia, y está medido.

Así que en vez de pedir “revísate”, lancé auditores con contexto limpio, sin saber que revisaban su propio trabajo.

Encontraron esto.

Un bloqueante que yo no había visto. Seis de las nueve guías estaban truncadas a mitad de frase en disco. La herramienta de escritura cortaba los archivos grandes sin dar error. Los entregables que ya había generado estaban incompletos.

Lo detectó el auditor al no poder auditar contenido que no existía.

Un error de seguridad que iba en la dirección peligrosa. El manual afirmaba que los conectores solo leen, y sobre esa premisa construía la defensa anti-inyección. El manual tranquilizaba donde debía alertar.

Un control mal parametrizado. El cobro de enero fijado en 62.000 € cuando el cálculo daba 63.620 €.

Residuos de versiones anteriores. Un capítulo que decía “Doce fases” y en la línea siguiente “Ocho fases”. Un archivo fantasma que una fase daba por existente y ninguna creaba. Un control de IVA tautológico.

Ninguno lo habría encontrado yo pidiendo “revisa esto”. Los encontró un auditor externo, con contexto limpio, buscando errores en vez de confirmar aciertos.

Verificar no es un extra. Es una fase. Y no la puede hacer el mismo que construyó.

Los siete pasos

Es lo único que se queda cuando se olvidan las cifras.

1. Enmarcar. Mapa antes de fórmulas.

2. Partir en fases encadenadas.

3. Cuadrar sobre la marcha. No avanzar con un control en rojo.

4. Separar datos de fórmulas, para que cambiar de escenario sea cambiar un dato.

5. Verificar al cierre por un camino independiente. El control es el de tu arquetipo.

6. Decidir. El indicador no es el final. La recomendación sí.

7. Empaquetar lo reutilizable.

No dependen de Cowork ni de TESOSTOCK. Sirven para un puente de EBITDA, un punto muerto o una previsión de cierre.

Cowork no se usa. Se organiza.

Post con Acceso 9 Guias de Claude Cowork

Documentación oficial de Anthropic consultada en julio de 2026:

Get started with Claude Cowork,

Cowork architecture overview,

Use Claude Cowork safely,

Projects in Cowork,

Desktop and filesystem access,

Schedule recurring tasks,

Google Workspace connectors,

Microsoft 365 connector.

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para finanzas?

👉 Enlace Formación Claude para Financieros

Deja un comentario

Existen tres versiones del mismo beneficio, y la mayoría de los análisis se queda en una. La diferencia entre ellas es dinero, y no solo en una compraventa.

El beneficio del que hablamos es el EBITDA, el beneficio antes de intereses, impuestos, depreciaciones y amortizaciones. Mide el resultado operativo, sin la financiación ni los impuestos.

Un año contable mezcla la marcha normal del negocio con hechos que no volverán. Separar lo recurrente de ese ruido da una cifra distinta según quién la calcule:

• El reportado, que sale de las cuentas auditadas.

• El ajustado por quien lo presenta, siempre el más alto.

• El ajustado con criterio propio, tras revisar cada partida.

Esa cifra ajustada no se usa una sola vez. Se reutiliza como base de decisiones muy distintas.

Un número que se reutiliza

El mismo EBITDA ajustado aparece en:

• Los covenants bancarios, que se miden sobre él.

• La capacidad de deuda, que es un múltiplo de él.

• El presupuesto del año, que parte de él.

• El bonus variable, que puede quedar ligado a él.

• La valoración de una compañía, que se multiplica por él.

Por eso un ajuste mal aceptado no falla en un único sitio. Reaparece en el covenant, en el forecast, en la deuda, en el bonus y en el precio. Un error, varias consecuencias.

Calcular bien los tres niveles no es sofisticación financiera. Es higiene financiera.

Qué es la calidad del beneficio

La calidad del beneficio, o quality of earnings, mide cuánto del resultado declarado es sostenible. Un año contable esconde partidas que no volverán:

• Un pleito.

• Una indemnización cobrada.

• Una reestructuración.

• Una subvención puntual.

Depurar ese ruido es el objetivo.

El instrumento es el ajuste, conocido como add-back. Consiste en volver a sumar un gasto que no se repetirá, o en restar un ingreso que tampoco. Bien aplicado, el ajuste acerca la cifra a la capacidad real del negocio. Mal aplicado, la infla.

Dónde está la dificultad

La dificultad no es aritmética. Sumar y restar ajustes lo hace cualquiera. La dificultad es el juicio sobre cada partida:

• Un gasto etiquetado como puntual puede repetirse cada año bajo otro nombre.

• Una normalización razonable puede estar exagerada en su importe.

• Una proyección anualizada puede no cumplirse.

• Sobre todo, un ingreso extraordinario puede seguir inflando el resultado sin que nadie lo haya restado, porque a quien lo presenta no le conviene señalarlo.

Cada ajuste es, en el fondo, una afirmación que hay que probar. Exige una pregunta constante: ¿esta partida volverá a aparecer el año que viene en el curso normal del negocio? La respuesta ordena la decisión de aceptar, recortar o rechazar.

Formación Claude para Financieros

Un ejemplo: la compra de una empresa

El caso donde esta cifra pesa más y el conflicto de intereses es más visible es la compra de una empresa.

La diferencia entre el beneficio que presenta el vendedor y el que acepta el comprador, multiplicada por el múltiplo, es una petición de rebaja de precio.

Otros hallazgos se canalizan mediante:

• Depósitos en garantía.

• Indemnizaciones.

• Pagos aplazados por resultados.

• Ajustes de deuda neta y de circulante.

Hay además una cuestión de momento. Los asuntos que mueven la cifra de cabecera deben cerrarse antes de firmar, porque después el precio ya está fijado. Los que solo afectan a la medición fina pueden resolverse entre la firma y el cierre.

Ordenar cada hallazgo por su palanca y su momento es parte del trabajo.

Dónde entra Claude

El análisis de calidad del beneficio es repetitivo y exige disciplina. Hay que leer varias fuentes que no cuadran entre sí, aplicar el mismo criterio escéptico a cada partida y no dejar pasar ninguna.

El error humano aparece por fatiga, por prisa o por exceso de confianza en la lista que entrega quien presenta las cuentas.

Aquí Claude trabaja como capa de razonamiento sobre las herramientas de cálculo, no como sustituto de ellas:

• Lee las fuentes.

• Separa los tres niveles de beneficio.

• Clasifica cada ajuste por tipo, recurrencia y evidencia.

• Le asigna un nivel de confianza y propone una decisión con su comentario.

• Rastrea los ingresos extraordinarios que nadie ha restado.

El criterio final sigue siendo del analista. Lo que cambia es el punto de partida: en lugar de una hoja en blanco, un puente completo, trazable y sometido a escrutinio, listo para retar.

El trabajo bruto pasa de horas a minutos, y la atención se concentra donde importa, en el juicio.

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para finanzas?

👉 Enlace Formación Claude para Financieros

Deja un comentario

Ordenar los clientes por facturación es la primera foto que se mira en cualquier comité comercial. También es la que más decisiones equivoca.

La facturación mide tamaño. El beneficio depende de algo que esa cifra no recoge: lo que cuesta atender a cada cliente después del margen bruto.

El problema: la facturación no mide el beneficio

El margen bruto compara precio de venta y coste del producto. Se detiene ahí.

No incluye los días que un cliente tarda en pagar, las devoluciones que genera, las urgencias que impone ni el rappel que negocia.

Dos clientes con la misma facturación y el mismo margen bruto pueden dejar resultados opuestos.

Uno paga a 30 días y pide en ruta. El otro cobra a 100 días, devuelve una parte y exige entregas fuera de planificación.

El segundo puede terminar en pérdidas sin que la cuenta de resultados global lo delate.

Qué es el coste de servir

El coste de servir (cost to serve) reúne el consumo de recursos posterior al margen bruto. Se descompone en capas medibles, una por cada forma en que un cliente cuesta dinero:

• Coste financiero del crédito comercial: el dinero inmovilizado mientras el cliente no paga.

• Sobrecoste por mora: los días que superan el plazo legal, financiados al tipo de interés de demora.

• Coste financiero del IVA (Impuesto sobre el Valor Añadido) adelantado a Hacienda antes de cobrar.

• Devoluciones y abonos: la operativa de gestionar lo devuelto, más allá del importe abonado.

• Urgencias y pedidos fuera de ruta: las entregas que rompen la planificación logística.

• Coste fijo por pedido: la administración que consume cada pedido, con independencia de su tamaño.

• Rappels y descuentos: el retorno por volumen, que sale íntegro del margen.

• Riesgo de impago: la pérdida esperada por la probabilidad de no cobrar.

Restadas del margen bruto, estas capas dejan el margen de contribución real de cada cliente. Esa es la cifra que mide valor.

Dónde entra Claude. Montar ocho capas para toda una cartera es trabajo repetitivo y propenso al error. Claude las calcula cliente a cliente sobre tus datos y deja el rastro de cada supuesto, sin arrastrar fórmulas por cientos de filas.

Qué es la curva de ballena

Con el margen de contribución de cada cliente, se ordena la cartera de mayor a menor y se acumula.

La línea sube deprisa con los clientes rentables, alcanza un pico y después desciende, arrastrada por los que destruyen margen. Su silueta recuerda a una ballena.

El pico marca el punto donde la cartera acumula más beneficio del que la empresa gana en total: supera el 100%.

La cola, los clientes de margen negativo, devuelve la curva hacia abajo.

En un caso de 240 clientes, 30 cuentas bastaban para erosionar el 17% del beneficio de explotación.

La técnica tiene raíz en el ABC (Activity-Based Costing, coste basado en actividades). Algunos autores la llaman pirámide de la rentabilidad comercial.

El nombre cambia; la lectura no.

La dificultad real: el dato y el criterio

El cálculo de cada capa es aritmética simple. La dificultad está en dos sitios distintos.

El dato. La información vive dispersa:

• facturación en el ERP (Enterprise Resource Planning, sistema de gestión empresarial)

• días de cobro en la cartera

• devoluciones en abonos

• condiciones en tesorería

El mismo cliente aparece con tres códigos. Sin consolidar eso, no hay análisis.

El criterio. La curva ordena, no juzga.

• Un cliente nuevo con días de cobro altos no es un destructor estructural.

• Uno estacional se ve raro a mitad de año.

• Un cliente estratégico puede justificar una pérdida temporal, con fecha de revisión.

Leer la ballena sin estos matices produce decisiones malas.

Dónde entra Claude. El paso previo a calcular es preparar el dato. Claude unifica fuentes, reconcilia el mismo cliente con códigos distintos, detecta huecos y valores atípicos, y marca lo que supone. Si falta un dato, lo pide en lugar de inventarlo.

De la curva a la decisión

El diagnóstico solo vale si termina en acción. Tres piezas cierran el análisis.

La rejilla de acción cruza tamaño y rentabilidad en cuatro cuadrantes:

• proteger a los grandes rentables

• renegociar con los grandes que pierden

• desarrollar a los pequeños rentables

• revisar o soltar la cola pequeña

Las palancas cuantifican el mínimo que lleva a cada cliente en pérdidas al equilibrio:

• una subida de precio

• un recorte de días de cobro

• una reducción de rappel

A veces una sola no basta, y el problema resulta comercial antes que financiero.

La cadencia lleva el análisis de la foto puntual al cuadro de mando trimestral. Rehecho cada trimestre, avisa de los clientes que cruzan a margen negativo antes de que el resultado lo note.

El papel de Claude

Hasta aquí, el método. La herramienta de cálculo puede ser una hoja de Excel.

Lo que decide la calidad del análisis no es la fórmula, sino el razonamiento alrededor: qué datos cruzar, qué supuesto marcar, qué cliente merece una excepción.

Ahí trabaja Claude, como capa de razonamiento sobre tus datos:

1. Prepara el dato: consolida las fuentes y entrega una tabla limpia con un informe de calidad.

2. Construye el análisis: calcula las capas, ordena la cartera y traza la curva.

3. Ayuda a decidir: clasifica en la rejilla y cuantifica la palanca de cada cliente en pérdidas.

Lo que no se delega: la decisión final y la validación de los supuestos.

Claude estructura y calcula. La responsabilidad de renegociar o soltar a un cliente sigue siendo de quien dirige.

El cálculo estaba resuelto desde hace décadas. Lo que faltaba era una forma de hacerlo rápido, sobre datos propios y sin perder el criterio por el camino.

Esa es la distancia entre tener la fórmula y usarla.

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para finanzas?

👉 Enlace Formación Claude para Financieros

Deja un comentario

El análisis de sensibilidad no calcula: decide qué mirar

Hay una idea equivocada sobre el análisis de sensibilidad: que es un ejercicio de cálculo. Que consiste en meter unos números en una tabla de Excel y ver qué sale. No es eso.

El cálculo es la parte trivial. La parte difícil es decidir qué variables se mueven, cuánto se mueven y cómo se lee el resultado. Eso no lo hace una fórmula. Lo hace un criterio.

Ahí es donde cambia el papel de una herramienta como Claude. No sustituye a la hoja de cálculo: la hoja sigue calculando. Claude se sitúa por encima, en la capa donde se toman las decisiones que la fórmula no puede tomar.

Este artículo recorre los conceptos técnicos del método y señala, en cada uno, dónde entra ese criterio.

Sensibilidad no es escenario

El primer error conceptual es confundir dos técnicas que se parecen y no lo son.

→ La sensibilidad mueve una sola variable cada vez y deja el resto en su valor base. Aísla el efecto puro de un driver. Responde a una pregunta limpia: cuánto duele mover esta palanca, y solo esta.

→ El escenario mueve un conjunto coherente de variables a la vez. Una recesión no baja solo el precio: baja el volumen, tensa el coste financiero y estira los plazos de cobro. Responde a otra pregunta: qué pasa en este futuro concreto.

La diferencia no es semántica. Si mueves dos variables a la vez y el output se desplaza, no sabes cuál lo causó.

Has perdido la trazabilidad, que es justo lo que la sensibilidad venía a darte. Un análisis que mezcla ambos enfoques confunde en vez de informar.

Dónde entra Claude. En imponer la disciplina. Cuando le pides que sensibilice, mantiene todas las variables ancladas salvo la que toca, y avisa si lo que describes es en realidad un escenario. Esa vigilancia sobre la definición del ejercicio es difícil de sostener a mano cuando el modelo crece.

Variables críticas y elasticidad

En un modelo con 20 entradas, no todas importan. Un grupo pequeño concentra casi todo el impacto sobre el output. A esas se las llama variables críticas, y encontrarlas es el objetivo real del análisis.

Alrededor de cada una hay un segundo concepto: la elasticidad.

No basta saber que el precio importa. Importa saber hasta cuánto puede desviarse antes de que el output cruce un umbral: un covenant, un valor actual neto igual a cero, un margen mínimo.

La elasticidad convierte una intuición (”el precio es sensible”) en un límite medible (”el precio aguanta hasta aquí”).

Dónde entra Claude.

En proponer qué merece entrar en el análisis y qué es ruido, antes de tocar la hoja. Distingue drivers operativos (precio, volumen, coste unitario) de financieros (tipo de interés, impuestos), y recuerda que el apalancamiento operativo suele hacer que los primeros dominen.

Y cuando una variable tiene comportamiento no lineal, lo señala antes de fijar el rango, no después de que el resultado salga raro.

Reconstrucción explícita frente a tabla de datos nativa

Este es el núcleo técnico del método, y donde más se juega la calidad.

Excel trae una herramienta nativa para tablas de datos: Datos, Análisis de hipótesis, Tabla de datos. Genera la matriz con una función interna, TABLE, y lo hace rápido. Pero tiene 2 problemas serios para un trabajo reproducible.

El primero: oculta la fórmula. Cada celda muestra un número, pero no puedes ver qué calcula ni auditarlo.

El segundo: esa función interna no se transporta bien entre motores de cálculo, así que el modelo se vuelve frágil en cuanto sale de Excel.

La alternativa es la reconstrucción explícita. Cada celda recalcula el output completo desde cero, sustituyendo solo la variable de su fila o su columna, con el resto anclado a la hoja de inputs mediante referencias absolutas.

En una tabla de dos entradas se usan referencias mixtas: una única fórmula, copiada por toda la matriz, toma el valor de fila de su cabecera de fila y el de columna de su cabecera de columna.

Frente a la herramienta nativa, la reconstrucción gana en tres cosas:

→ Es auditable. La fórmula queda a la vista celda a celda, no escondida en una función interna.

→ Es portable. No depende de ninguna función propia de Excel, así que el modelo aguanta al salir de la aplicación.

→ Permite comprobar el residuo. La celda del caso base debe reproducir exactamente el motor, con diferencia cero. Si no da cero, hay un error de anclaje, y se ve al instante.

Dónde entra Claude.

En construir esa reconstrucción con las referencias bien puestas. Colocar los signos de dólar donde tocan, anclar el resto de inputs y verificar que el residuo cierra es un trabajo minucioso donde un error de una celda arruina la tabla entera.

Claude lo monta con la fórmula visible y comprueba el cierre.

El tornado como criterio, no como adorno

El gráfico tornado tiene mala fama de infografía bonita. Es lo contrario: es un criterio de atención convertido en imagen.

Se construye en cinco pasos:

→ Flexar cada variable un porcentaje constante arriba y abajo, por defecto un 10%, siempre aislada.

→ Calcular el output en los dos extremos.

→ Medir el recorrido: la diferencia en valor absoluto entre ambos extremos. Ese es el impacto de la variable.

→ Ordenar las variables de mayor a menor recorrido.

→ Graficar como barras horizontales, la más ancha arriba. Esa forma, ancha arriba y estrecha abajo, da nombre a la técnica.

Dos detalles técnicos separan un tornado bien hecho de uno decorativo.

• El primero: se grafica la diferencia respecto al caso base, no el valor absoluto del output. Así las barras nacen en el punto de referencia y el gráfico queda centrado.

• El segundo: la asimetría entre el extremo negativo y el positivo no es un defecto, es información. Señala que el driver tiene efecto no lineal, algo que importa para gestionar el riesgo a la baja.

Y hay una conexión que suele pasarse por alto: el tornado no termina en sí mismo. Sus dos cabezas, las dos variables de mayor recorrido, son las que merecen cruzarse en una tabla de dos entradas. El tornado elige; la 2D entra en el detalle de esas dos.

Dónde entra Claude.

En ordenar los drivers, explicar qué dice la asimetría de cada uno y encadenar el resultado con la tabla siguiente. La lectura del tornado, no su dibujo, es donde el análisis se vuelve útil.

La trampa del colchón del ratio

Un concepto que engaña a directivos con experiencia. Cuando un ratio de cobertura supera su umbral con holgura, es tentador leer esa holgura como margen de seguridad. Un ratio un 15% por encima del mínimo parece cómodo.

No lo es necesariamente. El colchón del ratio no es el colchón de la variable que lo mueve. Si el driver dominante tiene un recorrido grande, una desviación pequeña consume todo el margen aparente.

El 15% del ratio puede ser un 2% en el precio. El número final tranquiliza; la variable que lo sostiene, no.

Dónde entra Claude.

En traducir.

Convierte el colchón expresado en el ratio a colchón expresado en la variable dominante, que es la cifra que de verdad importa para la gestión.

Esa traducción es la diferencia entre creerse a salvo y saber a qué distancia está el borde.

Detalles que rompen un modelo

Por último, tres decisiones técnicas que parecen menores y no lo son:

→ Los intereses se calculan sobre la deuda de apertura, no sobre un saldo que a su vez depende del flujo. Calcularlos sobre el saldo medio crea una referencia circular que corrompe el modelo.

→ El impuesto lleva un suelo en cero. Si el resultado antes de impuestos es negativo, el impuesto es cero, no una cifra negativa que inventaría una devolución que no existe.

→ Los formatos de número deben ser portables entre regiones, sin separadores locales dentro de las fórmulas de texto, o el modelo se rompe al abrirlo en otra configuración.

Dónde entra Claude.

En conocer estas trampas y evitarlas por defecto. Son el tipo de detalle que no está en ningún manual de fórmulas y que se aprende rompiendo modelos. Tenerlo incorporado ahorra la ronda de errores.

El criterio, no la calculadora

El análisis de sensibilidad estructurada no premia a quien calcula más rápido. Premia a quien decide bien qué mirar: qué variables, con qué rango, y cómo leer lo que sale.

La hoja de cálculo hace la aritmética. El criterio decide dónde apuntarla.

Ese reparto es el que propone trabajar con Claude en finanzas. La calculadora es Excel.

El razonamiento (elegir drivers, fijar rangos, reconstruir fórmulas vivas, leer la asimetría y traducir el colchón) es donde una capa de inteligencia por encima de la hoja cambia el resultado.

Este análisis forma parte de “Claude para Finanzas”, el programa que enseña a directores financieros, controllers y equipos de FP&A (Financial Planning & Analysis: planificación y análisis financiero) a usar Claude en el trabajo financiero real. Para recibir el kit completo con el modelo, la guía, el manual técnico y los ocho prompts, sigue las instrucciones de este post.

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para finanzas?

👉 Enlace Formación Claude para Financieros

Deja un comentario

El método Claude para proyectar el Fondo de Maniobra

Hay una escena que se repite en muchas pymes industriales. El beneficio sube ejercicio tras ejercicio, los márgenes aguantan, la actividad crece a doble dígito, y sin embargo la tesorería se estrecha hasta que un día la empresa depende de la póliza de crédito para llegar a fin de mes.

El director financiero mira la cuenta de resultados, la ve mejor que nunca, y no entiende de dónde sale la tensión de caja.

La respuesta no está en la cuenta de resultados. Está en el circulante, y en concreto en la distancia entre dos magnitudes que conviene no confundir.

Primero, el vocabulario

El fondo de maniobra (FM) es un concepto de estructura, del lado de la financiación: recursos permanentes menos activo no corriente, o de forma equivalente activo corriente menos pasivo corriente. Es lo que tienes de forma estable para sostener la operación.

La necesidad operativa de fondos (NOF) es un concepto de inversión, del lado de la operación: existencias más clientes menos proveedores. Es lo que el ciclo de explotación te pide para funcionar.

En una frase: el FM es lo que tienes, el NOF es lo que la operación necesita, y la empresa está sana cuando el primero cubre al segundo.

Falta una etiqueta que suele meter ruido: “working capital”.

En contabilidad significa activo corriente menos pasivo corriente, es decir, el FM.

En modelización financiera y en el día a día de un equipo de planificación casi siempre se refiere al circulante operativo, es decir, al NOF.

Las mismas dos palabras inglesas apuntan a dos conceptos distintos, y ese es el origen de más de un modelo torcido.

Para evitarlo, aquí solo se usan dos etiquetas con un único significado cada una: FM para la cobertura, NOF para la necesidad. Su diferencia es la tesorería neta.

Por qué crecer consume caja

El NOF crece con las ventas. Más actividad significa más existencias en almacén y más saldo pendiente de clientes, solo en parte compensado por más crédito de proveedores.

Si los días de cobro, inventario y pago se mantienen, el NOF crece casi en la misma proporción que la cifra de negocio.

El FM crece por otra vía mucho más lenta: el beneficio que la empresa retiene cada año, más, en su caso, nueva deuda a largo o ampliaciones de capital.

Beneficio retenido y crecimiento del circulante juegan en ligas distintas. En un negocio industrial que crece al 15% anual con un circulante en el entorno del 30% de las ventas, la necesidad operativa puede sumar en cinco años más del doble de lo que suma la cobertura estructural en el mismo periodo.

El día en que el FM deja de cubrir el NOF, esa diferencia se convierte en financiación a corto que hay que negociar con el banco. Y ocurre con la cuenta de resultados mejorando, no empeorando. Ahí está la paradoja.

Dónde está la dificultad

Proyectar esto bien tiene más trampa de la que parece, y casi toda se concentra en un punto: convertir días de rotación en saldos de balance sin cometer errores silenciosos, esos que no saltan a la vista pero rompen el modelo.

Tres focos:

→ Las bases de los días. Los días de cobro (DSO, días de venta pendientes de cobro) se aplican sobre ventas; los días de inventario (DIO) sobre coste de ventas o sobre consumo según el componente; los días de pago (DPO) sobre compras, no sobre coste de ventas. Mezclar las bases infla o desinfla saldos sin que el número parezca raro.

→ El IVA. Aquí está el error más común. Las ventas y las compras se registran sin IVA (impuesto sobre el valor añadido), pero los saldos de clientes y proveedores lo llevan incorporado, porque lo que el cliente debe es la factura con impuesto incluido. Si aplicas los días de cobro directamente sobre la venta sin IVA, el saldo de clientes sale corto y el balance no cuadra. Hay que hacer el ajuste, y en la dirección correcta.

→ La posición con Hacienda. El IVA repercutido menos el soportado deja una posición neta con la Administración que se liquida por trimestres. Al cerrar el ejercicio queda casi siempre un trimestre devengado y sin liquidar, que es una partida de circulante como cualquier otra. Casi nadie la modela, y es una de las razones por las que un balance proyectado “casi cuadra” pero no cuadra del todo.

Por encima de todo esto está la condición que separa un modelo fiable de uno decorativo: el residuo cero.

→ El balance proyectado tiene que cerrar exactamente.

→ La variación del NOF calculada como diferencia de saldos tiene que coincidir con la suma de las variaciones de sus componentes.

→ La identidad que une fondo de maniobra, necesidad operativa y tesorería neta tiene que cumplirse al céntimo.

Cuando cualquiera de esas tres condiciones falla por unos euros, no es un redondeo: es un error de base o de IVA escondido en alguna celda.

El papel de Claude

Construir esta proyección a mano lleva horas y es frágil:

→ cada componente del inventario con su base; → la capa de IVA en clientes y proveedores; → la posición con Hacienda; → la cascada que lleva de los días a los saldos, de los saldos al NOF, del NOF al gap con el FM y del gap a la necesidad de financiación.

Un error en cualquier eslabón se arrastra hasta el final.

Claude hace dos cosas, y la segunda es la que cuenta.

Primero construye: toma la cuenta de resultados y los días objetivo de cada año y levanta la proyección completa del circulante con la capa de IVA y la posición de Hacienda ya resueltas. Eso ahorra tiempo, pero no es lo decisivo.

Lo decisivo es que Claude verifica. Recalcula el modelo de forma independiente y comprueba que:

→ el balance cierra a 0,00 euros; → la variación del NOF reconcilia por componentes; → la identidad entre fondo de maniobra, necesidad operativa y tesorería se cumple.

Es justo la parte que un modelo hecho a mano no se autocomprueba, y donde se cuelan los errores que luego cuestan una decisión de financiación mal calibrada.

El valor no está en calcular más rápido, sino en no fiarse del propio cálculo y someterlo a una verificación que un humano rara vez tiene tiempo de hacer con este detalle.

La lectura que importa

Cuando la proyección está cerrada y verificada, aparece lo único que de verdad sirve para dirigir: el año concreto en que el fondo de maniobra deja de cubrir la necesidad operativa, y cuánta financiación a corto plazo genera cada punto de crecimiento a partir de ahí.

Ese dato es un indicador adelantado mucho mejor que la cuenta de resultados.

La cuenta de resultados te dice que el negocio va bien. El gap entre fondo de maniobra y necesidad operativa te dice si ese “ir bien” te va a dejar sin caja, y cuándo.

Anticiparlo con años de margen, o descubrirlo el día que el banco llama, depende de proyectarlo con rigor y verificarlo hasta el céntimo.

Post de Linkedin Modelo Covenants Gratis

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para finanzas?

👉 Enlace Formación Claude para Financieros

Deja un comentario

Covenants de deuda: la letra que decide si tu empresa rompe su financiación

El banco no audita tu beneficio. Audita si sigues cumpliendo lo que firmaste.

Cuando una empresa firma deuda con un banco o un sindicato, el tipo de interés es la parte visible del trato. La otra parte son los covenants: las cláusulas que convierten ciertas métricas y ciertas conductas en obligaciones contractuales, con consecuencias si te desvías.

Son la forma que tiene el acreedor de vigilar su riesgo entre el día que presta y el día que cobra, sin esperar a que dejes de pagar para reaccionar.

Conviene empezar por un matiz que se pasa por alto y que ordena todo lo demás. El covenant no es el ratio. El ratio (apalancamiento, cobertura) es la métrica; el covenant es la cláusula que la eleva a obligación y le ata una consecuencia. El ratio es el gatillo; el covenant es lo que dispara.

De ahí una consecuencia incómoda: una empresa puede ganar dinero, pagar cada cuota a tiempo y aun así haber incumplido su contrato de financiación. Basta con que una métrica se salga de su umbral, o con que la compañía haga algo que el contrato le prohíbe.

Este artículo recorre los covenants de deuda de punta a punta: cómo se clasifican, por qué su cálculo es más difícil de lo que parece, qué los hace moverse entre sí, qué pasa cuando se rompen y dónde una herramienta como Claude cambia de forma material el trabajo.

La anatomía: financieros y no financieros

Un contrato de financiación apalancada moderno mezcla tres familias de covenants. Distinguirlas no es un capricho taxonómico: cada una se comprueba de una forma distinta y falla por motivos distintos.

Covenants financieros (de mantenimiento)

Son los ratios que la empresa debe mantener dentro de un umbral en cada fecha de prueba, normalmente cada cierre trimestral o anual. Se llaman de mantenimiento (maintenance) porque se verifican siempre, haga la empresa lo que haga. Los cuatro habituales:

• Apalancamiento (deuda financiera neta sobre EBITDA): cuántos años de resultado operativo representa la deuda. Suele ser el covenant que de verdad condiciona.

• Cobertura del servicio de la deuda (DSCR): la caja disponible frente al principal y los intereses que vencen ese año.

• Cobertura de intereses (EBITDA sobre gastos financieros): cuántas veces el resultado operativo cubre la factura financiera.

• Gearing (deuda neta sobre fondos propios): el equilibrio entre financiación ajena y propia.

Covenants no financieros cuantificables (de incurrencia)

Aquí está la primera distinción técnica que mucha gente se salta. Junto a los ratios de mantenimiento conviven límites de incurrencia (incurrence): no se comprueban en cada fecha contra un umbral, sino que acotan lo que la empresa puede hacer. No miden un estado, autorizan o bloquean una acción y fijan cuánto margen queda. Los principales:

• Pagos restringidos (restricted payments): cuánto dividendo se puede repartir, normalmente atado a que el apalancamiento esté por debajo de un nivel y a una cesta que acumula la caja no repartida.

• Deuda permitida (permitted indebtedness): cuánta deuda nueva se puede asumir, a menudo sujeta a un test de incurrencia (solo si el apalancamiento pro forma, ya con la deuda nueva dentro, sigue por debajo de un umbral).

• Venta de activos (disposals): cuánto se puede vender, con la obligación de reinvertir los importes o destinarlos a amortizar deuda.

• Inversión (CAPEX) máxima: el límite anual de inversión, a veces con arrastre de lo no gastado.

La diferencia entre mantenimiento e incurrencia no es académica. Un ratio de mantenimiento roto es un incumplimiento aquí y ahora. Un límite de incurrencia no se rompe por sí solo: se agota, y cuando se agota, te quita una palanca (no puedes repartir, no puedes endeudarte más).

Por eso se leen mejor como capacidad disponible que como semáforo de cumplimiento.

Covenants cualitativos

La tercera familia no se calcula. Son obligaciones de hacer o no hacer, binarias y de calendario: entregar el certificado de cumplimiento en plazo, mantener los seguros, no pignorar activos sin permiso (negative pledge), no fusionarse, no cambiar de objeto social, y la cláusula de cambio material adverso.

Buena parte de los incumplimientos reales llegan por aquí, por cláusulas que casi nadie vigila con la misma atención que pone en los ratios. Pero pertenecen a una checklist de cumplimiento, no a un modelo financiero, y conviene no mezclarlas con lo que sí se calcula.

El resto de este artículo se centra en lo calculable, que es donde está la dificultad técnica y donde una herramienta como Claude aporta de verdad.

La trampa de la definición

Aquí está el primer motivo por el que comprobar covenants descuadra a la primera. El resultado no lo decide el número, lo decide la definición que hay detrás del número.

Tomemos el apalancamiento. “Deuda financiera neta sobre EBITDA” parece inequívoco hasta que se mira el contrato:

• La deuda neta, ¿resta toda la tesorería o solo la caja por encima de un mínimo operativo? ¿Incluye el arrendamiento financiero? ¿Y el factoring o el confirming?

• El EBITDA, ¿es el contable o el ajustado, con add-backs de partidas no recurrentes? ¿Hay un tope a esos add-backs?

• El servicio de la deuda del DSCR, ¿computa la disposición de la línea revolving o solo la amortización contractual de principal?

• El CFADS, ¿se calcula antes o después del CAPEX, y de qué CAPEX, solo el de mantenimiento?

Cada una de esas preguntas tiene una respuesta concreta en el contrato, y cada respuesta mueve el resultado. Dos analistas razonables, con las mismas cuentas, pueden llegar uno a “cumple” y otro a “incumple” solo por leer “deuda neta” de forma distinta.

Por eso el trabajo de verdad no es dividir dos cifras: es trasladar la proyección a la definición exacta del contrato, término a término, y leerla frente al umbral del año.

Y hay un detalle que multiplica la dificultad: el umbral no suele ser fijo. El apalancamiento se pacta con frecuencia con un step-down, un escalón que se endurece cada año (por ejemplo 3,50x, luego 3,25x, luego 3,00x) y obliga a desapalancar. Una empresa puede mejorar su ratio y aun así incumplir, porque el listón ha subido más deprisa que su mejora.

Para que esos ratios sean fiables hace falta antes una proyección integrada de los tres estados financieros, con su cuadro de deuda, que cuadre el balance a cero cada ejercicio. Si el balance no cuadra, los ratios no valen. Aquí el ejercicio deja de ser una división y se convierte en un modelo.

El certificado de cumplimiento que la empresa entrega al banco en cada fecha documenta precisamente estos cálculos.

La maquinaria que se realimenta

El segundo motivo por el que el cálculo se complica es que un contrato realista no fija unas condiciones y se olvida. Incorpora mecanismos que se mueven con la propia salud de la empresa, y que se realimentan entre sí.

La rejilla de precios (margin grid). El diferencial sobre el índice de referencia no es fijo: sube por tramos cuando el apalancamiento del cierre anterior empeora y baja cuando mejora. Es procíclico, es decir, encarece la deuda justo en el peor año, cuando la empresa menos lo necesita.

El barrido de caja (cash sweep). Un porcentaje del excedente de tesorería prepaga el préstamo de forma obligatoria, escalonado según el apalancamiento. En los años buenos consume la caja que de otro modo se acumularía; en los malos no actúa, porque no hay excedente que barrer.

El bloqueo de dividendo (lockup). Solo se reparte si el apalancamiento baja de un umbral. Ata la política de distribución a un covenant y da salida ordenada al excedente.

El equity cure. El derecho del accionista a inyectar capital, computado como mayor EBITDA o menor deuda, para restaurar un ratio incumplido, con límites de frecuencia.

Estas piezas no son independientes. El barrido prepaga deuda, lo que cambia el apalancamiento, lo que cambia el margen de la rejilla, lo que cambia el interés, lo que cambia la caja disponible para el barrido.

Existe una circularidad real entre el interés y el prepago que, mal montada, mete el modelo en una referencia circular y lo deja sin calcular. La forma limpia de romperla (calcular el interés sobre el saldo previo al barrido, no sobre el posterior) no es evidente para quien no ha lidiado antes con ella, y es justo el tipo de detalle que diferencia un modelo que cuadra de uno que parece cuadrar.

Un caso trabajado: ENVALSA

Con las piezas sobre la mesa, conviene verlas operar sobre números. ENVALSA es un fabricante de envase metálico para alimentación y bebidas, con 40 millones de ventas y un EBITDA del 14%. Es un caso de formación, pero sus condiciones están calibradas contra el mercado español.

Cierra una refinanciación sindicada de 16 millones a plazo, una línea revolving de 4 millones y medio millón de arrendamiento, con un apalancamiento de partida de 2,77x. Acepta los cuatro covenants financieros, con el de apalancamiento en step-down de 3,50x a 3,00x.

El plan se proyecta a cuatro años bajo cuatro escenarios: base, bueno y dos versiones del malo, una con recuperación en forma de V y otra con deterioro persistente en forma de L.

En el escenario base cumple con holgura creciente. El apalancamiento baja de 2,33x a 1,34x y la cobertura de intereses sube por encima de 11x. El barrido y el dividendo impiden que la caja se acumule sin destino.

En el escenario malo, el contrato se rompe, y rompe de una forma que enseña:

Indicador Umbral Base (2025 a 2028) Malo en V (2025 a 2028) Apalancamiento (DFN/EBITDA) 3,50x a 3,00x 2,33 a 1,34x 3,62 a 3,38x DSCR 1,20x 1,52 a 2,11x 0,57 a 1,27x Cobertura de intereses 3,50x 6,15 a 11,93x 3,87 a 3,45x (valle en 2026) Gearing (DFN/FFPP) 1,75x 0,94 a 0,45x 1,21 a 0,92x

El apalancamiento incumple los cuatro años: es el covenant que de verdad condiciona, el binding. El DSCR es el más violento: cae a 0,57x en 2025 por el golpe del circulante, no por el nivel de deuda.

La cobertura de intereses, que parecía la superviviente, la tumba la propia rejilla de precios: cuando el apalancamiento supera 3,00x, el margen salta al tramo más caro, y ese encarecimiento empuja la cobertura por debajo de 3,50x en 2026, el año del valle. El gearing, en cambio, no rompe nunca, porque el problema de ENVALSA es de caja, no de capital.

El matiz más interesante solo aparece al comparar las dos versiones del malo. Si el deterioro se recupera en V, el DSCR vuelve a cumplir en 2028 y la cobertura solo rompe un año. Si el deterioro persiste en L, el DSCR no se recupera (se queda en 1,04x) y la cobertura rompe dos años seguidos.

La hipótesis de recuperación, y no el golpe inicial, es lo que decide cuánto dura el incumplimiento. Esa conclusión no se lee en una tabla de ratios: se ve cuando se comparan dos versiones del mismo modelo.

Cuando se rompe: qué pasa después

Romper un covenant financiero no es, por sí mismo, dejar de pagar. Es un supuesto de incumplimiento (un default técnico) que activa derechos del acreedor. Las consecuencias van de lo negociado a lo drástico:

• Dispensa (waiver): el banco perdona el incumplimiento de esa fecha, casi siempre a cambio de una comisión y, a veces, de condiciones más duras.

• Recálculo de condiciones (reset): se renegocian los umbrales para adaptarlos a una realidad nueva.

• Equity cure: el accionista inyecta capital y restaura el ratio, dentro de los límites del contrato.

• Aceleración y cross-default: en el extremo, el banco declara vencida la deuda, y las cláusulas de cross-default pueden arrastrar al resto de financiadores.

Si la situación es estructural y no de un año, el marco español ofrece los planes de reestructuración de la Ley 16/2022, que permiten quitas, esperas, capitalización de deuda y arrastre de clases disidentes con homologación judicial.

Lo relevante para el director financiero es que casi nunca se llega ahí de golpe: entre el incumplimiento técnico y la reestructuración hay una conversación con el banco, y a esa conversación se llega mejor o peor según se conozca con cuánta holgura se incumple, qué covenant condiciona y qué se puede ofrecer a cambio.

Dónde entra Claude

Nada de lo anterior es conceptualmente inalcanzable para un buen profesional. El obstáculo no es de comprensión, es operativo.

Montar la proyección integrada de los tres estados, atar el cuadro de deuda, resolver la circularidad del barrido, programar la rejilla por tramos, encajar el step-down, cuadrar el balance a cero y repetirlo para cuatro escenarios es una jornada de trabajo, y eso si no se cuela un descuadre.

El error no suele saltar en una celda roja: se esconde en un ratio que sale bien por una razón equivocada.

Aquí es donde Claude cambia el trabajo de forma material.

Se le da el cierre del último ejercicio, las condiciones del contrato y los drivers de cada escenario, y levanta el modelo completo: los tres estados, el cuadro de deuda con rejilla y barrido, los cuatro covenants con su step-down y un panel con semáforo, todo enlazado por fórmulas vivas y con el residuo del balance verificado a cero en cada escenario.

Se cambia de escenario con un selector y se lee cómo se mueve cada ratio.

Hay tres formas de hacerlo, según el flujo de cada uno:

• En el chat, pegando los datos y recibiendo la proyección, los ratios y el veredicto.

• En Claude Cowork, dejando que trabaje sobre los archivos (el cierre y el extracto del contrato) y devuelva el Excel y un informe.

• Con Claude para Excel, construyendo las hojas, el selector y el panel dentro de la propia hoja de cálculo.

Lo decisivo no es la velocidad, aunque pasar de una jornada a una hora ya justifica el cambio. Lo decisivo es que cada cuadre se verifica solo:

• El activo iguala al pasivo cada año.

• La deuda neta del ratio coincide con el cuadro de deuda menos la tesorería.

• El servicio del DSCR excluye la revolving.

• El interés se calcula sobre el saldo correcto y no genera referencias circulares.

La definición del contrato, que era la fuente silenciosa de errores, queda respetada al detalle y, sobre todo, auditable: cada cifra es trazable hasta su fórmula.

El mismo patrón se extiende a los límites de incurrencia.

El bloqueo de dividendo ya es, en la práctica, un control de capacidad (”puedes repartir esto, no más”), y la deuda permitida, los disposals y el CAPEX máximo se modelan replicando esa misma lógica de cesta y holgura. La cascada, así, se completa: del ratio de mantenimiento al límite de lo que la empresa puede hacer.

Para este tipo de análisis, esa combinación de definiciones respetadas al milímetro y cuadres verificados sin esfuerzo manual es lo que convierte a Claude en una herramienta imprescindible, y no en un adorno.

No sustituye el criterio: hace el trabajo lento y frágil para que el criterio se aplique sobre números fiables.

El cálculo está hecho; el juicio es tuyo

Un covenant no lo rompe el número, lo rompe la definición. Y la definición, llevada a un modelo que cuadra y que recorre los escenarios, deja de ser una fuente de errores para convertirse en lo que debía ser desde el principio: la base sobre la que negociar. El cálculo, que era la parte lenta y propensa al descuadre, ya no es el cuello de botella.

Lo que queda (leer qué covenant condiciona, medir con cuánta holgura se incumple, decidir si pedir un waiver, un reset o un equity cure, y con qué carta sentarse delante del banco) sigue siendo, y seguirá siendo, trabajo del analista. Claude se ocupa de que ese trabajo empiece desde una cifra en la que se puede confiar.

Si trabajas con financiación sindicada y quieres el modelo completo de ENVALSA, con sus cuatro escenarios, la cascada de covenants y los prompts para reproducirlo en tu empresa, escríbeme a jlopez@tallerformacion.com o comenta COVENANTS y escibreme un mesnaje en este posty

Post de Linkedin Modelo Covenants Gratis

Francisco Javier López Martín · IA Aplicada · jlopez@tallerformacion.com · Perfil de Linkedin

¿Quieres formarte en Claude para finanzas?

👉 Enlace Formación Claude para Financieros

Deja un comentario