Inteligencia operacional en ERPs y procesos

01

El ERP contiene una parte del estado. La operación completa suele vivir fuera de él.

Una solicitud puede empezar en un correo, una conversación, un documento o una incidencia. Para resolverla, una persona consulta varias pantallas, interpreta una regla, busca un dato en otro sistema, pide una autorización, espera una respuesta, actualiza el ERP y comprueba después si el cambio produjo el efecto esperado.

Ese recorrido contiene conocimiento que rara vez se encuentra en un único lugar. Parte está en los datos y configuraciones del ERP; parte, en código, procedimientos, hojas de cálculo y documentos; y parte, en la experiencia de quienes conocen las excepciones.

Construimos sistemas que reúnen ese contexto y coordinan el trabajo alrededor de las aplicaciones empresariales existentes. La interfaz conversacional se conecta con un sistema capaz de conservar estado, aplicar políticas, ejecutar herramientas y verificar el resultado, para que una solicitud avance de forma comprensible, controlada y comprobable.

02

Del lenguaje a una operación controlada

Una interfaz conversacional puede facilitar la entrada: «crea este proveedor», «comprueba por qué no se ha servido el pedido», «prepara la regularización» o «dime qué falta para cerrar el expediente».

La conversación, sin embargo, es solo uno de los puntos de entrada. Detrás debe existir un sistema capaz de:

• reconocer la intención y pedir los datos que faltan;
• identificar las entidades y expedientes correctos;
• reconstruir el estado actual y las operaciones relacionadas;
• consultar la lógica, las políticas y los permisos aplicables;
• preparar una propuesta o una vista previa antes de una acción sensible;
• solicitar autorización con el contexto necesario para decidir;
• ejecutar mediante la herramienta adecuada;
• conservar el trabajo si debe esperar o continuar más tarde;
• comprobar el efecto y registrar aquello que permanece abierto.

La capacidad útil consiste en reducir el esfuerzo de reconstruir, coordinar y seguir un caso, conservando visible cómo se decidió y quién mantiene la autoridad.

03

Casos de uso habituales

La arquitectura puede aplicarse, entre otros, a recorridos como:

• altas y modificaciones de datos maestros con comprobaciones documentales;
• preparación y seguimiento de pedidos, compras, inventario o facturación;
• conciliaciones, regularizaciones y controles previos al cierre;
• clasificación y enriquecimiento de incidencias o solicitudes internas;
• recogida de documentación y seguimiento de expedientes incompletos;
• coordinación de aprobaciones entre áreas y aplicaciones;
• investigación de por qué una operación quedó bloqueada;
• generación de avisos, tareas y actuaciones a partir de cambios de estado;
• actualización coherente de varios sistemas después de una misma decisión.

La conveniencia de automatizar cada paso depende del impacto, la reversibilidad, la calidad de la información, la estabilidad de la regla y la autoridad que requiera.

04

La intervención humana se diseña con una función, un contexto y una autoridad definidos

El human in the loop es una función de conocimiento y decisión: la persona recibe el caso preparado y actúa dentro de una autoridad explícita.

Diseñamos intervenciones humanas distintas según la función que cumplen:

• completar contexto cuando falta información que el sistema no puede obtener;
• validar una inferencia cuando la lógica se ha reconstruido a partir de evidencia incompleta;
• elegir entre compromisos cuando tiempo, coste, calidad o riesgo compiten;
• autorizar una acción por su impacto, irreversibilidad o responsabilidad;
• resolver una excepción que todavía no tiene un recorrido aceptado;
• detener o corregir el proceso cuando la situación observada contradice sus supuestos;
• revisar la regla cuando las excepciones muestran que el diseño ya no representa el trabajo.

La persona debe recibir el caso preparado: situación actual, información utilizada, alternativa propuesta, motivo de la derivación, consecuencias previsibles y opciones permitidas. Pedir intervención humana sin ese contexto solo desplaza el trabajo.

05

De automatizar tareas a optimizar la operación

Una vez que el proceso conserva estado y deja trazas comparables, puede observarse como un sistema y no como una suma de tareas.

La optimización puede buscar, según el caso:

• reducir el tiempo completo desde la solicitud hasta el resultado;
• distinguir tiempo de trabajo de tiempo de espera;
• disminuir recopilaciones repetidas de la misma información;
• evitar traspasos que pierden contexto;
• reducir retrabajo, duplicados y casos incompletos;
• mejorar el porcentaje de operaciones resueltas correctamente a la primera;
• reservar la atención humana para decisiones donde aporta criterio o autoridad;
• acortar el tiempo de recuperación después de un fallo;
• elegir entre herramientas, modelos o recorridos según coste, riesgo y calidad;
• detectar excepciones recurrentes que deberían convertirse en una regla o provocar un rediseño del proceso.

Optimizar consiste en mejorar el sistema completo y preservar los compromisos importantes entre tiempo, coste, calidad, carga humana y riesgo. Un proceso más rápido puede producir más errores; uno con menos escalados puede estar ocultando incertidumbre; uno más automatizado puede trasladar trabajo a una fase posterior. Por eso cada objetivo debe acompañarse de restricciones y métricas de calidad, riesgo y resultado.

06

Hiperautomatización, definida con precisión

Utilizamos «hiperautomatización» para describir la coordinación de varios tipos de capacidad alrededor de un proceso que atraviesa sistemas y no cabe en una automatización lineal.

Puede combinar:

• reglas y cálculos deterministas;
• modelos de clasificación, predicción o lenguaje;
• optimización;
• agentes que eligen entre herramientas o recorridos permitidos;
• workflows duraderos;
• APIs, eventos y bots;
• documentos y conocimiento operativo;
• decisiones, autorizaciones y excepciones humanas;
• trazas, evaluación y señales de resultado.

El valor está en utilizar solo las piezas necesarias, asignarles una función clara y orquestarlas de forma que el trabajo pueda comprenderse, recuperarse y mejorarse.

07

Qué debería poder examinar una organización

Un sistema operacional debe hacer visibles, como mínimo:

• el estado actual de cada caso;
• la información que utilizó y la que faltaba;
• la regla, política o modelo que influyó en una decisión;
• la herramienta y la identidad con la que se actuó;
• quién revisó o autorizó y con qué contexto;
• qué esperas, reintentos o errores ocurrieron;
• qué señal permitió declarar el resultado completado;
• qué casos siguen abiertos y quién es responsable de ellos;
• qué excepciones se repiten y qué parte del diseño conviene revisar.

Esta visibilidad sirve para operar, auditar, aprender y optimizar. También mantiene la automatización examinable por quienes operan y gobiernan el ERP.

08

ERP-Bots, DocuLogic y la mejora continua del recorrido

ERP-Bots es nuestra línea de bots y agentes operacionales: completan trabajo dentro de ERPs y aplicaciones de negocio bajo políticas explícitas, conservando el estado del caso y comprobando el efecto en la fuente. DocuLogic aporta la reconstrucción y validación de la lógica que necesitan esos recorridos, separando comportamiento observado, inferencia, validación y decisión organizativa.

Una vez que el recorrido conserva estado y trazas comparables, la optimización puede eliminar un paso, pedir antes una información, cambiar una interfaz, formalizar una regla, sustituir un modelo, añadir o retirar un agente, acercar una decisión a la fuente, modificar un umbral, paralelizar tareas, preparar mejor una intervención humana o rediseñar el criterio de finalización.

Esta página aplica la inteligencia operacional al ERP y a los procesos empresariales. El marco completo —representación del objetivo, contexto, lógica, reparto de trabajo, orquestación, durabilidad, intervención humana, ejecución bajo contrato, recuperación y verificación— vive en Inteligencia operacional.