Soluciones · Conocimiento operativo
Lógica de negocio y conocimiento operativo
Profundización
El software ejecuta decisiones que la organización debería poder volver a comprender.
En una página
Sistemas que reconstruyen y hacen examinable la lógica distribuida entre código, configuraciones, reglas, documentación, datos y práctica operativa.
- 01La lógica de negocio rara vez vive en un único lugar. Una aplicación empresarial ejecuta decisiones continuamente: qué dato es válido, qué estado puede seguir a otro, qué condición bloquea una operación, qué cálculo se aplica, quién puede autorizar, qué excepción cambia…
- 02No generamos una explicación única y la damos por cierta. Un modelo puede leer código o documentación y producir una descripción convincente.
- 03Qué puede reconstruirse. Según las fuentes disponibles, el sistema puede identificar y relacionar:
La lógica de negocio rara vez vive en un único lugar
Una aplicación empresarial ejecuta decisiones continuamente: qué dato es válido, qué estado puede seguir a otro, qué condición bloquea una operación, qué cálculo se aplica, quién puede autorizar, qué excepción cambia el recorrido y qué efectos produce cada acción.
Con el tiempo, esas decisiones se distribuyen entre:
- código y procedimientos almacenados;
- configuraciones del ERP y motores de workflow;
- tablas de decisión y reglas;
- formularios, validaciones e interfaces;
- documentación funcional y técnica;
- hojas de cálculo y plantillas;
- incidencias y tickets que explican excepciones;
- datos históricos y trazas de ejecución;
- conocimiento que conservan determinadas personas.
Cuando la organización necesita modernizar, integrar, automatizar o auditar, descubre que conoce el sistema por fragmentos, pero no dispone de una representación común de la lógica que realmente gobierna el trabajo.
Construimos sistemas para reconstruir esa lógica, hacerla examinable y mantenerla conectada con sus evidencias y con las personas capaces de validarla.
No generamos una explicación única y la damos por cierta
Un modelo puede leer código o documentación y producir una descripción convincente. Ese resultado es útil como punto de partida, pero no demuestra que la lógica sea completa, vigente ni correcta.
Distinguimos varios estados:
- observado: aparece de forma directa en un artefacto;
- inferido: se deduce de varias señales, pero necesita validación;
- confirmado: una persona o una prueba suficiente lo valida dentro de un ámbito definido;
- contradicho: otra evidencia muestra una versión incompatible;
- obsoleto: perteneció al sistema, pero ya no debería aplicarse;
- desconocido: falta evidencia para representar la decisión.
Esta distinción permite utilizar modelos para acelerar la investigación sin convertir su fluidez en autoridad.
Ø sin fuente en el corpus
Qué puede reconstruirse
Según las fuentes disponibles, el sistema puede identificar y relacionar:
- entidades y atributos de negocio;
- estados y transiciones;
- condiciones, umbrales y validaciones;
- cálculos y transformaciones;
- permisos y segregación de funciones;
- decisiones y alternativas;
- dependencias entre módulos y aplicaciones;
- llamadas, eventos y efectos secundarios;
- excepciones y recorridos de recuperación;
- versiones y ámbitos de aplicación;
- reglas duplicadas o potencialmente contradictorias;
- preguntas abiertas que necesitan conocimiento de dominio.
La representación puede adoptar distintas formas: mapas navegables, grafos, tablas de decisión, modelos de proceso, fichas de regla, documentación enlazada, APIs o contexto estructurado para asistentes y agentes.
La procedencia forma parte de cada regla
Una regla sin origen es difícil de discutir y peligrosa de reutilizar.
Cada elemento debe conservar:
- el artefacto y la ubicación de la que procede;
- el fragmento de código, configuración, documento o traza relevante;
- la versión y el ámbito;
- el método con el que se extrajo o infirió;
- las evidencias que la apoyan y contradicen;
- su estado de validación;
- las personas o pruebas que intervinieron;
- las relaciones y dependencias conocidas;
- las preguntas todavía abiertas.
Así, una persona puede pasar de una explicación de alto nivel al detalle que la sostiene y corregir el conocimiento sin rehacer toda la investigación.
La intervención humana valida significado, no copia resultados
Las personas de dominio no deberían revisar una lista interminable de reglas aisladas. El sistema debe agrupar y priorizar aquello que merece atención:
- contradicciones entre fuentes;
- inferencias con evidencia débil;
- reglas con gran impacto o muchas dependencias;
- diferencias entre documentación y ejecución;
- excepciones frecuentes;
- comportamientos sin responsable claro;
- decisiones que afectan a autoridad, cumplimiento o riesgo;
- ámbitos donde una regla puede haberse generalizado demasiado.
La revisión debe permitir confirmar, rechazar, editar, limitar el ámbito, añadir una excepción o declarar que la intención organizativa debe cambiar aunque el software actual haga otra cosa.
El sistema existente no siempre representa el sistema deseado
Reconstruir lógica no equivale a preservarla toda.
El código puede contener un defecto. Una configuración puede reflejar una decisión antigua. Un atajo operativo puede ser razonable en un contexto y peligroso si se generaliza. Una excepción frecuente puede indicar que la regla principal está mal diseñada.
Por eso separamos dos preguntas:
- ¿Qué lógica parece ejecutar hoy el sistema?
- ¿Qué lógica quiere conservar o cambiar la organización?
La primera puede investigarse con artefactos y comportamiento. La segunda necesita responsabilidad y decisión humana.
Casos de uso
Modernización y migración
Antes de sustituir un ERP, un módulo o una aplicación, permite inventariar reglas, dependencias y excepciones que deben conservarse, transformarse o retirarse.
Análisis de impacto
Conecta una propuesta de cambio con los procesos, datos, interfaces, pruebas y decisiones que podrían verse afectados.
Automatización y agentes
Proporciona una fuente de lógica y contexto más fiable para que un bot o un agente sepa qué puede hacer, bajo qué condiciones y cuándo debe consultar.
Documentación viva
Relaciona explicaciones con código, configuraciones, decisiones y pruebas, de forma que una actualización pueda propagarse y discutirse.
Auditoría técnica y funcional
Permite examinar dónde se aplica una política, qué variantes existen y qué evidencia sostiene cada afirmación sobre el sistema.
Optimización de procesos
Hace visibles reglas duplicadas, ramas con alto retrabajo, excepciones recurrentes, dependencias innecesarias y puntos donde el proceso pierde contexto.
Del inventario al conocimiento operativo
El resultado no debería ser un informe que envejece desde el momento en que se entrega.
Debe poder mantenerse como una capa de conocimiento operativo:
- versionada;
- consultable por personas;
- accesible por software mediante contratos;
- conectada con pruebas y observabilidad;
- capaz de representar contradicciones;
- explícita sobre lo que todavía no sabe;
- útil para la siguiente decisión de cambio.
Esta línea de trabajo se alimenta de la experiencia de DocuLogic: investigar cómo convertir artefactos de sistemas empresariales en una representación más auditable de su lógica, sin confundir extracción, inferencia y aprobación.
Observado, inferido, validado y acordado
La representación distingue cuatro estados de una misma regla:
- comportamiento observado: lo que el software ejecuta hoy y las trazas permiten comprobar;
- lógica inferida: la explicación candidata que un análisis propone, con su evidencia y su incertidumbre;
- conocimiento validado: lo que una persona con autoridad de dominio ha confirmado y acotado;
- decisión organizativa: lo que la organización acuerda que debe ocurrir a partir de ahora.
Esta distinción permite utilizar el software existente como fuente conservando la autoridad donde corresponde. Una implementación puede contener una adaptación histórica, una inconsistencia o un comportamiento que la organización desea cambiar.
DocuLogic, KIR y tecnologías semánticas
DocuLogic mantiene el conocimiento reconstruido como una capa de autoría y revisión humana: expresa conceptos, reglas, cálculos y excepciones en formatos legibles y versionables, junto con procedencia, estado de verificación, vigencia, ámbito, ciclo de vida y relaciones. Una persona puede leerlo, discutirlo y corregirlo sin trabajar sobre una base de datos ni sobre una representación de ejecución.
KIR —Knowledge Intermediate Representation— es la representación intermedia tipada y canónica que recibe ese conocimiento y lo proyecta hacia bases relacionales, grafos, índices semánticos, motores de reglas, APIs, MCP y agentes.
Según el caso, la estructura puede apoyarse en LinkML para definir esquemas, TypeDB u otros grafos tipados para relaciones complejas, PostgreSQL y pgvector para conocimiento relacional, léxico y semántico, Datalog para deducción, DMN para decisiones, CEL para validaciones y Tree-sitter y LSP para estructura de código.
Esta página profundiza en una capacidad de la inteligencia informacional: hacer examinable la lógica que hoy vive repartida entre software, configuraciones, documentación y experiencia.
De artefactos dispersos a lógica examinable
- 01Reunir evidenciasIncorporar código, configuraciones, tablas, procedimientos, modelos de proceso, hojas de cálculo, tickets y otros artefactos relevantes.
- 02Reconstruir estructuraIdentificar entidades, estados, condiciones, decisiones, acciones, dependencias y excepciones.
- 03Inferir lógica candidataProponer reglas y recorridos cuando no están expresados de forma directa, conservando la evidencia y la incertidumbre.
- 04Relacionar versiones y contradiccionesDistinguir qué lógica está vigente, duplicada, obsoleta o en conflicto entre sistemas y documentos.
- 05Validar con personas y pruebasConfirmar, rechazar o acotar cada inferencia mediante conocimiento de dominio, ejemplos, datos y comportamiento observable.
- 06Representar y publicarConvertir la lógica en mapas, decisiones, tablas, grafos, documentación, APIs o conocimiento consultable.
- 07Mantener y reutilizarVersionar los cambios y conectar la lógica con modernización, automatización, auditoría, agentes y optimización.
Resultado
Un mapa versionado y consultable de decisiones, condiciones, excepciones y dependencias, conectado con la evidencia que lo sostiene y con el estado de su validación.
Puede alimentar documentación, análisis de impacto, modernización, pruebas, automatización, asistentes y agentes sin presentar como verdad aquello que el sistema solo ha inferido.
Cuándo aparece esta necesidad
- 01cuando nadie puede explicar de principio a fin por qué el sistema toma una decisión
- 02cuando una migración depende de reglas repartidas entre varias tecnologías
- 03cuando la documentación describe el proceso, pero no sus excepciones reales
- 04cuando distintas aplicaciones aplican versiones diferentes de la misma política
- 05cuando un agente necesita actuar y todavía no existe una fuente fiable de lógica de negocio
- 06cuando cada cambio exige localizar manualmente dependencias y efectos secundarios
- 07cuando una excepción recurrente se resuelve por experiencia, pero nunca se incorpora al conocimiento compartido
El sistema por dentro
Madurez · Evaluación- Cómo se organiza
- La ingesta procesa artefactos de software y operación; una capa de análisis identifica entidades, condiciones, ramas, decisiones y efectos; y una representación común relaciona cada elemento con su ubicación de origen. Las reglas inferidas se almacenan como hipótesis, no como hechos, y se contrastan con documentación, datos, pruebas y conocimiento de dominio.
- Qué puede examinarse
- Puede examinarse el inventario de artefactos, el mapa de dependencias, una regla con todas sus evidencias, una contradicción entre versiones, el historial de validación y la transformación de lógica confirmada en tabla de decisión, documentación o interfaz consultable.
- Cómo se comprueba
- Comprobamos cobertura de artefactos, precisión de referencias, consistencia entre representaciones y capacidad de reproducir comportamientos conocidos mediante pruebas. La revisión adversarial busca reglas inventadas, condiciones omitidas, ámbitos mal generalizados y diferencias entre lo documentado, lo implementado y lo observado.
Condiciones y límites
El comportamiento existente no demuestra por sí solo la intención correcta: puede contener errores, excepciones históricas o acuerdos ya obsoletos. Parte de la lógica depende de contexto humano no registrado. La validación de dominio y la decisión sobre qué debe mantenerse siguen siendo responsabilidades organizativas.