Desde una torre de control portuaria, un contenedor no pertenece a una sola historia. Está vinculado a un pedido, viaja en un buque, pasa a un camión, puede dividirse en varias entregas y termina relacionado con facturas, inspecciones y pagos. Si alguien obligara a describir todo ese movimiento con una única línea, el mapa sería sencillo. También sería falso.
Eso mismo ocurre con muchos procesos empresariales. El process mining tradicional reconstruye la ejecución alrededor de un identificador de caso: pedido, factura, incidencia o empleado. Es una perspectiva muy útil cuando el proceso tiene un centro estable. Pero un ciclo order-to-cash real contiene relaciones uno-a-muchos y muchos-a-muchos: un pedido genera varias entregas; una entrega consolida posiciones de varios pedidos; una factura puede agrupar documentos; un pago liquida varias partidas.
La cuestión no es elegir entre una línea y una red como si una de las dos fuera siempre superior. La cuestión es saber cuándo una perspectiva de caso explica el proceso y cuándo empieza a deformarlo. Esta guía propone un patrón para modelar esa segunda situación con SAP Signavio Process Intelligence y su análisis centrado en objetos.
Lo confirmado: de casos fijos a redes de objetos
La documentación vigente de SAP Signavio Process Intelligence distingue dos tipos de data pipeline. El case-based genera un registro de eventos con una definición de caso fijada en los scripts SQL. El object-based separa la preparación de datos de la perspectiva de análisis: primero se definen objetos, claves, relaciones y colectores; después se decide desde qué objeto se quiere observar el proceso.
SAP denomina Process Networks Discovery a la visualización que conecta eventos de varios objetos —por ejemplo, pedido, expedición y factura— y muestra dónde se dividen o convergen sus recorridos. La guía oficial de Process Networks indica que esta vista evita las distorsiones de una representación lineal y de perspectiva única.
Esto no reemplaza el análisis basado en casos. SAP sigue ofreciendo pipelines, dashboards, variantes y métricas tradicionales. La nueva capacidad amplía la caja de herramientas cuando el negocio no cabe de forma natural dentro de un solo expediente.
El error silencioso: fabricar un caso artificial
Supongamos que el equipo elige el pedido de ventas como caso. Cada actividad debe copiarse bajo ese identificador. Cuando dos pedidos comparten una expedición, el mismo evento logístico puede quedar duplicado; cuando un pedido se divide en cuatro entregas, una media de ciclo puede mezclar esperas distintas. Si se cambia la perspectiva a factura, se reconstruye otro dataset y aparecen nuevas duplicidades.
El resultado puede ser técnicamente consistente y semánticamente engañoso. Un cuello de botella aparente quizá proceda del modo en que se aplanaron las relaciones, no de la operación. Las frecuencias se inflan, los recorridos parecen más largos y la comparación entre perspectivas exige mantener varias transformaciones.
Análisis de Sapindex: el enfoque object-centric merece considerarse cuando concurren tres señales: la pregunta cambia de objeto con frecuencia; existen relaciones uno-a-muchos o muchos-a-muchos relevantes; y la duplicación de eventos altera métricas de volumen, tiempo o conformidad. Si el proceso posee un caso inequívoco y estable, un pipeline case-based seguirá siendo más sencillo y más barato de gobernar.
Arquitectura de referencia: seis capas para no confundir el mapa con el territorio
1. Fuentes y extracción con propósito
El punto de partida puede ser SAP S/4HANA, SAP ECC, CRM u otros sistemas. No conviene extraer tablas enteras «por si acaso». Cada campo debe responder a una pregunta analítica, construir una clave, fechar un evento, describir una relación o permitir una segmentación legítima.
Antes de conectar nada, defina el alcance temporal, sociedades, organizaciones de ventas, monedas, zonas horarias y frecuencia de actualización. Process mining no corrige una semántica que nadie ha acordado. La misma disciplina que exige un producto de datos con contexto se aplica aquí: propietario, definición, procedencia, calidad y política de cambio.
2. Modelo de objetos y claves estables
Para un piloto order-to-cash, un modelo mínimo podría contener SalesOrder, Delivery, Shipment, Invoice y Payment. Cada objeto necesita una clave que sea única también cuando se combinan mandantes, sociedades o sistemas. Un número de documento aislado puede no serlo; una clave compuesta por sistema, mandante, sociedad y documento suele ser más segura.
La secuencia oficial para object-based pipelines incluye crear el pipeline, configurar objetos y colectores, establecer relaciones, definir el case scope, validar y ejecutar, y finalmente analizar. El orden importa: cambiar tarde una clave obliga a revisar colectores y relaciones dependientes.
3. Eventos como hechos auditables
Un evento necesita, como mínimo, objeto, actividad y fecha-hora. Añada origen, usuario o tipo de ejecutor solo cuando aporten una comparación útil. «Entrega creada» y «salida de mercancía contabilizada» deben representar hechos distintos, con reglas de extracción documentadas.
Los colectores de eventos se expresan mediante consultas SQL dentro del pipeline. Este pseudocódigo muestra el contrato, no una consulta lista para cualquier sistema:
SELECT
source_system,
client,
delivery_id AS object_key,
'Goods issue posted' AS event_name,
posted_at_utc AS event_time,
execution_type
FROM delivery_events
WHERE posted_at_utc IS NOT NULL;La documentación de colectores permite guardar consultas todavía inválidas, pero solo una transformación válida generará correctamente el registro de eventos. Por eso la revisión del resultado debe formar parte del diseño, no limitarse a comprobar que el job terminó.
4. Relaciones antes que recorridos
Las relaciones conectan objetos: pedido–entrega, entrega–expedición, entrega–factura, factura–pago. Hay que declarar cardinalidad y procedencia, y comprobar que el join no multiplica filas. SAP puede descubrir algunas conexiones entre objetos a partir de colectores con el calificador de creación, pero esas relaciones deben revisarse; la automatización no conoce todas las excepciones del negocio.
Un control especialmente valioso es el factor de expansión: número de filas después del join dividido por filas antes del join. Si pasa de 1 a 18 sin una explicación empresarial, probablemente hemos creado un puerto fantasma.
5. Vistas semánticas, alcance y Process Networks
Una process semantic view selecciona los objetos relevantes. El case scope establece un objeto principal y determina qué objetos relacionados son alcanzables. Cambiar de objeto principal permite responder otra pregunta sin reconstruir toda la preparación: del pedido que espera una entrega a la factura que espera un pago.
Process Networks Discovery muestra después el grafo real: bifurcaciones, convergencias y eventos compartidos. No debería utilizarse como una postal espectacular, sino como instrumento para formular hipótesis. Por ejemplo: «las entregas divididas y consolidadas están asociadas a una mayor demora de facturación». La red revela el patrón; todavía falta comprobarlo.
6. Métricas, conformidad y acción controlada
SAP Signavio Analytics Language (SIGNAL) permite construir métricas. La guía oficial ofrece este patrón para calcular el tiempo medio de ciclo en una configuración basada en casos:
SELECT AVG(
(SELECT LAST(end_time) - FIRST(end_time))
) AS "Average Cycle Time"
FROM THIS_PROCESSLa cifra solo es útil si se acompaña de percentiles, volumen y segmentación. Una media puede mejorar mientras empeoran los casos críticos. Para conformidad, Process Atoms permite expresar patrones reutilizables y clasificarlos como conformes, no conformes o no aplicables. La documentación de Process Atoms confirma que pueden referenciarse desde métricas y reutilizarse en artefactos importables y exportables.
Dos átomos iniciales podrían ser: «la salida de mercancía nunca precede a la creación de entrega» y «una factura anulada debe estar seguida por el evento de corrección definido». Solo después de estabilizar el diagnóstico debería conectarse una acción, una automatización o una alerta. La lección del gobierno de la automatización sigue vigente: detectar una excepción no concede permiso automático para modificar el ERP.
Un piloto reutilizable en cuatro semanas
- Semana 1 — pregunta y contrato: elegir una hipótesis económica concreta; definir objetos, claves, eventos, relaciones, responsables y reglas de acceso.
- Semana 2 — calidad: cargar una ventana acotada; comprobar unicidad, eventos huérfanos, fechas imposibles, zonas horarias, nulos, volumen y factor de expansión.
- Semana 3 — análisis: comparar dos perspectivas, construir tres métricas y dos Process Atoms; revisar los diez casos de mayor impacto con responsables operativos.
- Semana 4 — intervención: seleccionar una mejora reversible, fijar grupo o periodo de comparación y medir resultado, efectos secundarios y adopción.
La hipótesis debe poder fracasar. «Signavio encontrará eficiencias» no es una hipótesis; «reducir las entregas divididas en el segmento X disminuirá el percentil 90 entre salida de mercancía y factura sin aumentar rechazos» sí lo es.
Checklist de calidad antes de creer el diagrama
- ¿Cada clave identifica un objeto de forma única entre sistemas y mandantes?
- ¿Los timestamps comparten zona horaria y precisión conocidas?
- ¿Los eventos duplicados representan repeticiones reales o errores de join?
- ¿Las relaciones muchos-a-muchos están justificadas y medidas?
- ¿La población excluida está cuantificada?
- ¿Las métricas muestran distribución y volumen además de promedio?
- ¿Un experto del proceso ha revisado los casos concretos detrás del patrón?
- ¿La mejora tiene propietario, coste, riesgo, línea base y criterio de éxito?
Costes y límites: una red más fiel también es más exigente
El análisis object-centric conserva relaciones y puede generar más registros que un log basado en un solo caso. La cardinalidad de las relaciones, el volumen extraído y la complejidad de las métricas afectan al tiempo de ejecución y al consumo de recursos; por eso conviene empezar con pocos objetos, medir cada iteración y confirmar las cuotas aplicables al contrato. Además, Process Networks Discovery y Process Atoms requieren las autorizaciones y el paquete de funciones correspondientes de SAP Signavio Process Insights and Intelligence.
Esto conduce a una regla sobria: no modele toda la empresa como un grafo desde el primer día. Empiece con tres a cinco objetos y una pregunta valiosa. La guía de buenas prácticas para object-based pipelines recomienda probar componentes individualmente, trabajar primero en un entorno de test, documentar decisiones y reutilizar vistas de datos para transformaciones complejas.
También deben minimizarse datos personales y atributos sensibles, limitar accesos por rol y establecer retención. Y conviene recordar una frontera intelectual: process mining muestra asociaciones y secuencias; no demuestra por sí solo causalidad. Una red puede señalar dónde mirar. La decisión de cambiar el proceso necesita conocimiento operativo y, cuando el impacto lo justifique, un experimento.
Del mapa a la transformación
Un puerto funciona porque nadie confunde el barco con el contenedor, el contenedor con la factura ni la ruta con la mercancía. Cada objeto conserva su identidad y, al mismo tiempo, participa en una red común.
Los procesos empresariales merecen el mismo rigor. SAP Signavio Process Intelligence permite conservar los objetos y sus relaciones en lugar de forzarlos prematuramente dentro de una sola línea. Pero la tecnología no absuelve al arquitecto de elegir buenas claves, validar tiempos, controlar cardinalidades y convertir cada hallazgo en una hipótesis medible.
Cuando ese trabajo se hace bien, el diagrama deja de ser una ilustración del proceso ideal. Se convierte en un instrumento de navegación para la empresa real.
