Integración de arquitectura, procesos e inteligencia artificial en SAP BTP
¿Planeas implementar IA y automatización? Empieza por preparar tus cimientos. La mayoría de las organizaciones documentan sus procesos y su arquitectura, pero no los conectan de una manera que resulte útil para los modelos de IA y los flujos de trabajo de automatización. Este libro te muestra cómo utilizar SAP Signavio, SAP LeanIX y WalkMe para transformar tus datos de arquitectura y procesos en una capa de ejecución unificada en SAP BTP. Aprenderás a modelar procesos, asignar aplicaciones a pasos de proceso, capturar telemetría de adopción, diseñar flujos de integración y preparar datos para la IA y la automatización. ¡Pasa de la documentación estática a una arquitectura SAP lista para la ejecución!
- Integra datos de SAP Signavio, SAP LeanIX y WalkMe utilizando SAP BTP
- Crea una columna vertebral de datos canónica y lista para la ejecución, destinada a la IA y la automatización
- Implementa servicios de ejecución, flujos de trabajo y capacidades de IA de SAP utilizando el modelo de datos unificado
Aprenderás sobre:
- Diseño de la columna vertebral de datos canónicos:
Descubra por qué fallan las integraciones punto a punto y cómo implementar un modelo canónico normalizado en SAP BTP. Defina identificadores estables, reglas de propiedad, estrategias de control de versiones y mecanismos de auditoría que respalden la automatización y la IA a nivel de ejecución.
- Integración de datos de procesos y arquitectura:
Estructura los datos de procesos y arquitectura para su uso posterior con SAP Signavio y SAP LeanIX. Asigna los pasos de los procesos de nivel L4/L5 a aplicaciones e interfaces, diseña flujos de ingesta y crea servicios de ejecución reutilizables para la búsqueda de procesos, el enriquecimiento de contexto y el análisis del impacto de los cambios.
- Habilitación de la IA y la automatización:
Prepara los datos empresariales para los servicios de IA de SAP. Define reglas de elegibilidad, alcance basado en roles, restricciones de validación y validación con intervención humana. Implementa servicios de IA sobre una base segura e integrada.
Aspectos Destacados:
- SAP Signavio
- SAP LeanIX
- WalkMe
- Ejecución de IA
- SAP AI Core
- Centro de IA generativa
- Flujos de trabajo automatizados
- Automatización de procesos de SAP Build
- Zona de trabajo de SAP Build
- Seguridad
- Monitoreo
Ver Tabla de Contenidos Completa
- Prefacio
- PARTE I: Contexto técnico y principios de integración
- 1 Por qué es necesario integrar los datos de la arquitectura empresarial y la arquitectura de procesos de negocio para la ejecución de la IA
- 1.1 El fracaso estructural de la mayoría de los programas de transformación
- 1.1.1 Diseño, implementación, telemetría y mejora
- 1.1.2 La pirámide de ejecución empresarial
- 1.1.3 Por qué la IA amplifica tanto la coherencia como la fragmentación
- 1.2 Limitaciones de los repositorios de procesos aislados
- 1.3 Limitaciones de los repositorios aislados de arquitectura empresarial
- 1.3.1 Arquitectura sin semántica de ejecución
- 1.3.2 Desviación del middleware y lógica de integración desconectada
- 1.3.3 La arquitectura describe los sistemas; el proceso describe la ejecución
- 1.4 Por qué SAP AI requiere un contexto semántico unificado
- 1.4.1 SAP AI tiene una estructura en capas, no monolítica
- 1.4.2 Lo que cada capa requiere de la base semántica
- 1.4.3 Los requisitos específicos de la IA generativa y agencial
- 1.4.4 Los paquetes de anclaje de IA y el papel de la capa canónica
- 1.5 El papel de SAP BTP como columna vertebral de datos, capa de integración y capa de extensión
- 1.5.1 Las tres funciones arquitectónicas de SAP BTP
- 1.5.2 Por qué la semántica canónica reside en SAP BTP
- 1.5.3 Validación, publicación y el papel de la aplicación de límites
- 1.5.4 SAP BTP como coordinador del ciclo del diseño a la entrega
- 1.6 Lo que no se debe automatizar: lo que la IA no debe hacer
- 1.7 Resumen
- 1.7.1 Puntos clave de aprendizaje
- 1.7.2 Errores comunes de diseño
- 1.7.3 Preguntas de repaso
- 1.7.4 Notas complementarias para los estudiantes
- 2 Arquitectura de integración de referencias
- 2.1 Descripción general de la arquitectura lógica
- 2.2 Sistemas de registro autoritativos
- 2.3 Propiedad de los datos y límites de escritura
- 2.3.1 Las tres reglas de los límites de escritura
- 2.3.2 Por qué la aplicación de los límites no puede ser convencional
- 2.3.3 Ejemplo práctico: seguimiento de una actualización de un centro de costos a lo largo de la arquitectura
- 2.4 Responsabilidades de integración y extensión
- 2.5 Capas de ejecución y consumo
- 2.6 Principios de arquitectura de seguridad para la integración impulsada por procesos e inteligencia artificial
- 2.7 Identidad, autenticación y autorización en SAP Signavio, SAP LeanIX y SAP BTP
- 2.8 Segmentación del acceso a los datos y exposición basada en roles de la columna vertebral de datos
- 2.8.1 Tres dimensiones de la segmentación
- 2.8.2 Segmentación en el token
- 2.8.3 Segmentación para los consumidores de IA
- 2.8.4 El vocabulario de alcance en la práctica
- 2.9 Límites de seguridad entre los servicios de ejecución, los servicios de IA y las interfaces de usuario
- 2.10 Auditabilidad, trazabilidad y no repudio por diseño
- 2.11 Asignación de responsabilidades de seguridad entre plataformas
- 2.12 Resumen
- 2.12.1 Puntos clave de aprendizaje
- 2.12.2 Errores comunes de diseño
- 2.12.3 Preguntas de repaso
- 2.12.4 Notas complementarias para los estudiantes
- PARTE II: Configuración de SAP Signavio para la ejecución y la preparación para la IA
- 3 Modelo de datos de SAP Signavio para la integración
- 3.1 Requisitos de los objetos de proceso L4 y L5
- 3.1.1 Objetos de paso de proceso de nivel L4
- 3.1.2 Objetos de instrucciones de trabajo de L5
- 3.1.3 La evaluación de descubrimiento digital como fuente para L4
- 3.2 Identificadores de procesos y actividades
- 3.2.1 El estándar de identificadores
- 3.2.2 Inmutabilidad y cambio de nombre
- 3.2.3 Asignaciones de identificadores a sistemas
- 3.3 Atributos de ejecución obligatorios
- 3.3.1 Identificador de paso
- 3.3.2 Rol de ejecución
- 3.3.3 Disparador del sistema
- 3.3.4 Referencia de la aplicación
- 3.3.5 Intención de control
- 3.3.6 Objetos de datos de entrada y salida
- 3.3.7 Ancla de indicador clave de desempeño
- 3.4 Roles, variantes y localización
- 3.4.1 La taxonomía de las seis funciones
- 3.4.2 Disciplina de carriles
- 3.4.3 Clasificación de variantes
- 3.4.4 Marcadores de localización
- 3.5 Control de versiones y gestión del ciclo de vida
- 3.5.1 La máquina de estados de versiones
- 3.5.2 Reglas de cambio: mayor, menor, parche y variante
- 3.5.3 El hilo digital: de DDA a BPMN y al tiempo de ejecución
- 3.6 Lo que no se debe modelar en SAP Signavio
- 3.7 Resumen
- 3.7.1 Puntos clave de aprendizaje
- 3.7.2 Errores comunes de diseño
- 3.7.3 Preguntas de repaso
- 3.7.4 Notas complementarias para los alumnos
- 4 Ampliación de SAP Signavio para su uso posterior
- 4.1 Atributos estándar frente a atributos personalizados
- 4.1.1 El papel de los atributos en un modelo de proceso listo para la integración
- 4.1.2 Atributos estándar: qué abarcan y dónde terminan
- 4.1.3 Una estrategia disciplinada de atributos personalizados
- 4.1.4 Convenciones de nomenclatura y gestión del diccionario
- 4.1.5 Errores comunes en el diseño de atributos
- 4.1.6 Ámbito de los atributos: proceso, actividad, carril y espacio de trabajo
- 4.1.7 Tipos de datos y enumeraciones controladas
- 4.1.8 Ejemplo práctico: atributos personalizados en tres dominios de proceso
- 4.2 Patrones de referencia externa
- 4.2.1 Definición de una referencia externa
- 4.2.2 Por qué se evita el enlace basado en URL
- 4.2.3 Patrones de referencia por sistema de destino
- 4.2.4 Referencias multivaloradas y calificadas
- 4.2.5 Gobernanza de las referencias a lo largo de los ciclos de vida
- 4.3 Preparación de las API de SAP Signavio para la extracción
- 4.3.1 El panorama de las API de SAP Signavio
- 4.3.2 Autenticación, tokens e identidades de servicio
- 4.3.3 Inventario de puntos finales para la ingesta en Spine
- 4.3.4 Alcance y permisos
- 4.3.5 Límites de tasa, paginación y retrasos
- 4.3.6 Control de versiones de esquemas y disciplina de compatibilidad
- 4.3.7 Ejemplos de llamadas a la API y manejo de respuestas
- 4.3.8 Llamadas a las API de SAP Signavio: SAP Integration Suite frente a directamente desde SAP BTP
- 4.3.9 Telemetría operativa para el flujo de extracción
- 4.4 Consideraciones sobre la exportación por eventos frente a la exportación por lotes
- 4.4.1 Dos patrones, dos modos de falla
- 4.4.2 Diseño de la exportación por lotes
- 4.4.3 Diseño de la exportación impulsada por eventos
- 4.4.4 Reconciliación entre las exportaciones por evento y por lotes
- 4.4.5 Heurísticas de decisión: cómo elegir el patrón adecuado
- 4.4.6 Ejemplo práctico: un ciclo de conciliación
- 4.4.7 Manejo de fallas y manuales operativos
- 4.5 Validación y controles de calidad de datos
- 4.5.1 Dónde se ejecutan las validaciones en el contrato de extensión
- 4.5.2 Categorías de controles de validación
- 4.5.3 Niveles de gravedad y manejo de resultados
- 4.5.4 Cuarentena frente a rechazo: manejo de registros erróneos
- 4.5.5 Cerrar el ciclo con los equipos de modelado
- 4.5.6 Ejemplo práctico: validación de una actividad lista para la ejecución
- 4.5.7 La puntuación de calidad como indicador adelantado
- 4.5.8 Ejemplo práctico: validación en una variante del proceso
- 4.5.9 Auditabilidad de la capa de validación
- 4.6 Resumen
- 4.6.1 Puntos clave de aprendizaje
- 4.6.2 Errores comunes de diseño
- 4.6.3 Preguntas de repaso
- 4.6.4 Notas complementarias para los estudiantes
- PARTE III: Configuración de SAP LeanIX para datos de dependencia y contexto
- 5 Modelo de datos de SAP LeanIX para la integración
- 5.1 El escenario en ejecución: del centro de costos a la posición
- 5.2 Objetos de aplicación necesarios para la integración
- 5.2.1 La aplicación apta para la integración
- 5.2.2 El conjunto de atributos obligatorios
- 5.2.3 Aplicación frente a componente de TI
- 5.2.4 Análisis detallado de una ficha técnica de aplicación
- 5.2.5 La disciplina del inventario de aplicaciones
- 5.2.6 Ficha técnica de la aplicación: especificación de construcción
- 5.3 Modelado de interfaces y dependencias
- 5.3.1 Qué debe incluir una ficha técnica de interfaz
- 5.3.2 Modelado de dependencias y cadenas
- 5.3.3 Ejemplo práctico: del centro de costos al puesto
- 5.3.4 Interfaces centrales y los límites del modelado directo
- 5.3.5 Hoja de datos de la interfaz: especificación de construcción
- 5.4 Atributos relacionados con el ciclo de vida y los cambios
- 5.4.1 El modelo de ciclo de vida de cinco fases
- 5.4.2 Los dos indicadores de aprobación
- 5.4.3 Las transiciones del ciclo de vida como eventos de gobernanza
- 5.4.4 Más allá de las fases: otros atributos relacionados con el cambio
- 5.4.5 Matriz de visibilidad de fase a consumidor
- 5.4.6 Conjunto de atributos del ciclo de vida: especificación de compilación
- 5.5 Identificadores y claves estables
- 5.5.1 El factSheetId como clave primaria
- 5.5.2 Identificadores externos como referencias resolubles
- 5.5.3 Cambios en los identificadores como eventos de gobernanza
- 5.5.4 Vinculación de identificadores a actividades
- 5.5.5 El ID de la aplicación SAP Fiori como identificador secundario
- 5.5.6 Conjunto de identificadores: especificación de construcción
- 5.5.7 Glosario de nombres de campos de todos los capítulos
- 5.6 Cómo evitar la superposición con SAP Signavio
- 5.6.1 La división de responsabilidades
- 5.6.2 Antipatrones y sus costos
- 5.6.3 Ejemplo práctico: Límite: propagación del centro de costos a la posición
- 5.7 Resumen
- 5.7.1 Puntos clave de aprendizaje
- 5.7.2 Errores comunes de diseño
- 5.7.3 Preguntas de repaso
- 5.7.4 Notas complementarias para los estudiantes
- 6 Mapeo de SAP LeanIX a la semántica de procesos
- 6.1 Vinculación de aplicaciones con actividades de L4/L5
- 6.1.1 La referencia LEANIX|APPLICATION
- 6.1.2 Cardinalidad y la regla de ubicación de ejecución única
- 6.1.3 Activity_Stable_ID como propietario del enlace
- 6.1.4 Resolución en el momento de la consulta, no en el momento del enlace
- 6.1.5 Ejemplo práctico: vinculaciones de aplicaciones de centro de costo a puesto
- 6.2 Relaciones entre la interfaz y el proceso
- 6.2.1 La referencia LEANIX|INTERFACE
- 6.2.2 Semántica de las etiquetas de rol
- 6.2.3 Interfaces de concentrador y enlaces bilaterales
- 6.2.4 La declaración de flujo de datos a nivel de actividad
- 6.2.5 Ejemplo práctico: Enlaces de interfaz entre centro de costo y puesto
- 6.2.6 Lo que no incluye el enlace de interfaz
- 6.3 Alineación de capacidades y dominios
- 6.3.1 El mapa de capacidades en SAP LeanIX
- 6.3.2 La capa de dominio por encima del mapa de capacidades
- 6.3.3 Herencia de capacidades y dominios a través de la columna vertebral de datos
- 6.3.4 Vistas de procesos de extremo a extremo a partir de capacidades heredadas
- 6.3.5 Ejemplo práctico: herencia de capacidades y dominios del centro de costos a la posición
- 6.4 Casos de uso del impacto de los cambios
- 6.4.1 Caso de uso 1: Retirada gradual de una aplicación
- 6.4.2 Caso de uso 2: Obsoleción de una interfaz
- 6.4.3 Caso de uso 3: Reorganización de roles
- 6.4.4 Caso de uso 4: Cambio en la intención de control
- 6.4.5 Ejemplo práctico: Impacto del cambio compuesto de centro de costo a puesto
- 6.5 Preparación de datos para la ingesta en SAP BTP
- 6.5.1 Etapa 1: Extracción
- 6.5.2 Etapa 2: Validación
- 6.5.3 Etapa 3: Almacenamiento
- 6.5.4 Etapa 4: Enriquecimiento
- 6.5.5 Etapa 5: Publicar
- 6.5.6 Composición con SAP Signavio Pipeline
- 6.5.7 Ejemplo práctico: Registro de publicación de un paquete de centros de costo a puestos
- 6.6 Continuidad del vocabulario entre capítulos
- 6.7 Resumen
- 6.7.1 Puntos clave de aprendizaje
- 6.7.2 Errores comunes de diseño
- 6.7.3 Preguntas de repaso
- 6.7.4 Notas complementarias para los estudiantes
- PARTE IV: WalkMe para la adopción basada en procesos y la telemetría
- 7 Diseño de WalkMe para una adopción orientada a los procesos
- 7.1 Posicionamiento de WalkMe en una arquitectura impulsada por procesos
- 7.1.1 Por qué es importante la distinción de objetivos
- 7.1.2 WalkMe como un grafo de conocimiento
- 7.1.3 WalkMe en las zonas de confianza de la arquitectura de referencia
- 7.2 Asignación del contenido de WalkMe a los pasos de proceso L4/L5
- 7.2.1 Identificadores estables como mecanismo de vinculación
- 7.2.2 La entidad WALKME_ASSET_BINDING y el modelo de datos
- 7.2.3 Ejemplo práctico: del centro de costos al puesto con la superposición de WalkMe
- 7.2.4 Resolución en el momento del renderizado
- 7.3 Alineación de WalkMe con SAP Signavio y SAP Build Work Zone
- 7.3.1 SAP Signavio: la referencia autorizada de procesos
- 7.3.2 SAP Build Work Zone: la superficie de lanzamiento
- 7.3.3 WalkMe: la superficie de orientación
- 7.3.4 Cadencia operativa conjunta
- 7.4 Gobernanza de la orientación dentro de la aplicación y los cambios
- 7.4.1 El ciclo de vida de un activo de WalkMe
- 7.4.2 Aprobación y separación de funciones
- 7.4.3 WalkMe como destino para los agentes de IA
- 7.4.4 Coordinación de cambios con SAP Signavio y SAP LeanIX
- 7.4.5 Evidencia de auditoría y retención
- 7.5 Resumen
- 7.5.1 Puntos clave de aprendizaje
- 7.5.2 Errores comunes de diseño
- 7.5.3 Preguntas de repaso
- 7.5.4 Notas complementarias para los estudiantes
- 8 Uso de la telemetría de WalkMe para mejorar los resultados de los procesos y la integración
- 8.1 Captura de señales de interacción del usuario
- 8.1.1 Los cuatro canales de señales
- 8.1.2 Etiquetado de identidad en el borde
- 8.1.3 La puerta de enlace única y regulada
- 8.2 Vinculación de los datos de adopción con la columna vertebral de datos de SAP BTP
- 8.2.1 El modelo de datos de telemetría
- 8.2.2 El proceso de ingesta de cinco etapas
- 8.2.3 La cola de mensajes fallidos y la reproducción
- 8.3 Detección de fricciones, desviaciones y brechas de capacitación
- 8.3.1 Detección de fricciones
- 8.3.2 Detección de desviaciones
- 8.3.3 Detección de brechas de capacitación
- 8.4 Incorporación de información sobre la adopción a los servicios de IA posteriores
- 8.4.1 WalkMe como destino para los agentes de IA
- 8.4.2 Los dos destinos posteriores
- 8.4.3 Señales de adopción en el grafo de conocimiento
- 8.4.4 El ciclo de extremo a extremo
- 8.5 Resumen
- 8.5.1 Puntos clave de aprendizaje
- 8.5.2 Errores comunes de diseño
- 8.5.3 Preguntas de repaso
- 8.5.4 Notas complementarias para los estudiantes
- PARTE V La columna vertebral de datos en SAP BTP
- 9 Diseño de la columna vertebral de datos canónica
- 9.1 Por qué fallan las integraciones punto a punto
- 9.2 Entidades y relaciones de la columna vertebral de datos canónica
- 9.2.1 Descripción general del modelo de dominio y límites arquitectónicos
- 9.2.2 De los dominios a las entidades canónicas
- 9.2.3 El contexto de ejecución como eje estructural
- 9.2.4 Consolidación lógica del modelo canónico
- 9.3 Claves de proceso, actividad, aplicación e interfaz
- 9.3.1 Identidad y versión estables: proceso y actividad
- 9.3.2 Claves de arquitectura e identidad: aplicaciones e interfaces
- 9.3.3 Tablas de correspondencia: de proceso a arquitectura y participación del sistema
- 9.3.4 Contexto de ejecución: claridad de la propiedad en procesos multisistema
- 9.3.5 Referencia a datos maestros (no replicación)
- 9.3.6 Adopción y telemetría: WalkMe
- 9.3.7 Objetos de configuración y mapeo de actividades
- 9.3.8 Superposición de gobernanza: validación y publicación
- 9.3.9 Artefactos de IA: separados de la verdad canónica
- 9.4 Caso de uso: Creación de un nuevo puesto
- 9.4.1 Conjunto de datos de muestra
- 9.4.2 Contexto de negocio y alineación con las mejores prácticas de SAP
- 9.4.3 Flujo integral entre sistemas
- 9.4.4 El contexto de ejecución como control estructural
- 9.4.5 Referencias a datos maestros en la columna vertebral de datos
- 9.4.6 Dependencias de configuración
- 9.4.7 Disciplina de validación y publicación
- 9.4.8 Flujo de sugerencias gobernado por IA
- 9.4.9 Resultado arquitectónico
- 9.5 Estrategia de control de versiones y linaje
- 9.5.1 Identidad estructural y separación de versiones
- 9.5.2 Grafo de versiones y modelado de linaje
- 9.5.3 Validez temporal y resolución en tiempo de ejecución
- 9.5.4 La publicación como límite estructural de la ejecución
- 9.5.5 Revalidación de dependencias ante cambios estructurales
- 9.5.6 Anclaje de IA e inmutabilidad de paquetes
- 9.5.7 Gestión de ramas variantes y normativas
- 9.5.8 El control de versiones como sistema de control operativo
- 9.6 Reglas de propiedad y ciclo de vida
- 9.6.1 Límites de propiedad de las entidades
- 9.6.2 Límites de identidad y mutabilidad
- 9.6.3 Modelo de estados del ciclo de vida
- 9.6.4 Autoridad de validación y publicación
- 9.6.5 Disciplina de cambios entre dominios
- 9.6.6 Separación de funciones y control de acceso
- 9.6.7 Límites de consumo de IA
- 9.6.8 La gobernanza como integridad estructural
- 9.7 Resumen
- 9.7.1 Puntos clave de aprendizaje
- 9.7.2 Errores comunes de diseño
- 9.7.3 Preguntas de repaso
- 9.7.4 Notas complementarias para los estudiantes
- 10 Implementación de Data Spine en SAP BTP
- 10.1 Opciones de persistencia en SAP BTP
- 10.1.1 SAP HANA Cloud como núcleo relacional canónico
- 10.1.2 Almacén de objetos para telemetría sin procesar y cargas útiles de archivo
- 10.1.3 Almacén de documentos para cargas útiles sin esquema y variantes
- 10.1.4 Motor vectorial de SAP HANA Cloud para incrustaciones de base de IA
- 10.1.5 Malla de eventos para la propagación de cambios
- 10.1.6 Automatización del proceso de compilación de SAP para los estados del flujo de trabajo
- 10.1.7 Elección del almacén adecuado para cada aspecto canónico
- 10.2 Diseño de tablas y esquemas
- 10.2.1 Tablas de procesos y actividades
- 10.2.2 Tablas de arquitectura
- 10.2.3 Contexto de ejecución: donde el proceso se une con la arquitectura
- 10.2.4 Datos maestros y referencias de adopción
- 10.2.5 Tablas de auditoría y consumo de IA
- 10.3 Patrones de extensión de datos
- 10.3.1 Por qué el núcleo canónico permanece cerrado
- 10.3.2 El patrón de la tabla lateral de extensión
- 10.3.3 El antipatrón que destruye la columna vertebral de datos
- 10.3.4 Variantes sectoriales y extensiones verticales
- 10.3.5 Extensiones derivadas de la IA
- 10.3.6 Detectabilidad de las extensiones
- 10.4 Diseño de la API para la ingesta y el acceso
- 10.4.1 La API de ingestión: escrituras idempotentes desde fuentes de origen
- 10.4.2 La API de acceso: lectura con contexto de rol y versión
- 10.4.3 La API de gobernanza: transiciones de estado a través del flujo de trabajo
- 10.4.4 Puntos finales de anclaje de IA
- 10.4.5 Integración de Event Mesh
- 10.4.6 Control de versiones de la superficie de la API
- 10.4.7 Alineación con la política de API de SAP v.4.2026a
- 10.5 Gobernanza y auditabilidad
- 10.5.1 Eventos de auditoría encadenados mediante hash
- 10.5.2 El linaje como ruta de consulta de primera clase
- 10.5.3 Separación de funciones mediante los alcances de autorización de SAP y del Servicio de Gestión de Confianza
- 10.5.4 Niveles de retención y anclaje criptográfico
- 10.5.5 Cadena de evidencia de cumplimiento
- 10.6 Resumen
- 10.6.1 Puntos clave de aprendizaje
- 10.6.2 Errores comunes de diseño
- 10.6.3 Preguntas de repaso
- 10.6.4 Notas complementarias para los estudiantes
- PARTE VI Flujos de integración y servicios de ejecución en SAP BTP
- 11 Flujos de integración desde SAP Signavio y SAP LeanIX
- 11.1 Flujos de ingesta de SAP Signavio a SAP BTP
- 11.1.1 Arquitectura de referencia para la ingesta de SAP Signavio
- 11.1.2 Patrones de ingesta por eventos y por lotes
- 11.1.3 Flujo de ingesta de SAP Signavio de extremo a extremo
- 11.1.4 Mapeo de la carga útil en el Canonical Data Spine
- 11.1.5 Notas sobre la implementación del adaptador
- 11.1.6 Autenticación y rotación de credenciales
- 11.2 Flujos de ingesta de SAP LeanIX a SAP BTP
- 11.2.1 SAP LeanIX como sistema de registro de la arquitectura
- 11.2.2 Orden de ingesta basado en las dependencias
- 11.2.3 Alineación de capacidades y dominios
- 11.2.4 Semántica de los webhooks de SAP LeanIX y dimensionamiento de la exportación masiva
- 11.2.5 Clasificación de datos y manejo de atributos sensibles
- 11.3 Sincronización y conciliación
- 11.3.1 Estados y transiciones
- 11.3.2 Ciclo diario de conciliación
- 11.3.3 Clasificación de desviaciones: sustanciales frente a no sustanciales
- 11.3.4 Retención de instantáneas y reproducción forense
- 11.3.5 Marcas de agua y semántica del reinicio en caliente
- 11.3.6 Cadencia operativa y postura de guardia
- 11.4 Manejo de errores y reintentos
- 11.4.1 Clasificación de errores
- 11.4.2 Disciplina de idempotencia
- 11.4.3 Reintentos, retrasos y enrutamiento de mensajes perdidos
- 11.4.4 Observabilidad vinculada a las fallas
- 11.4.5 Objetivos de nivel de servicio y umbrales de alerta
- 11.4.6 Mensajes maliciosos y disyuntores
- 11.5 Validación de la consistencia de los datos
- 11.5.1 Modelo de validación de cuatro niveles
- 11.5.2 Catálogo de reglas de validación
- 11.5.3 El registro de validación como eje central de la auditoría
- 11.5.4 Ciclo de vida y control de versiones de las reglas
- 11.5.5 Disciplina de validación y confianza en los informes financieros
- 11.5.6 Ejemplo práctico: una actividad a lo largo del proceso
- 11.6 Resumen
- 11.6.1 Puntos clave de aprendizaje
- 11.6.2 Errores comunes de diseño
- 11.6.3 Preguntas de repaso
- 11.6.4 Notas complementarias para los estudiantes
- 12 Servicios de ejecución sensibles a los procesos
- 12.1 Servicios de consulta de procesos
- 12.1.1 Límites del servicio y contrato de solo lectura
- 12.1.2 Presupuesto de latencia y objetivo de rendimiento
- 12.1.3 Ejemplo práctico: una sola llamada de consulta de procesos
- 12.1.4 Predicados de filtro y su costo
- 12.2 API de enriquecimiento de contexto
- 12.2.1 Las tres propiedades distintivas
- 12.2.2 Presupuesto de latencia y almacenamiento en caché
- 12.2.3 Por qué el enriquecimiento de contexto es la fuente para la fundamentación de la IA
- 12.2.4 Esquema de salida del enriquecimiento
- 12.3 Servicios de resolución del impacto de los cambios
- 12.3.1 Impacto directo
- 12.3.2 Impacto inverso
- 12.3.3 Rendimiento y almacenamiento en caché de recorridos por grafos
- 12.3.4 Patrones de recorrido de grafos por caso de uso
- 12.3.5 Ejemplo práctico: Retirar una interfaz
- 12.3.6 Casos extremos que el servicio maneja explícitamente
- 12.4 Servicios de integración reutilizables
- 12.4.1 La biblioteca de acciones
- 12.4.2 Control de versiones y obsolescencia de las acciones
- 12.4.3 Estabilidad del contrato
- 12.4.4 Formato de definición de acciones
- 12.4.5 Contrato de servicio: vista de búsqueda de procesos
- 12.5 Consideraciones sobre el rendimiento y la escalabilidad
- 12.5.1 Límites de latencia y objetivos de rendimiento
- 12.5.2 Almacenamiento en caché de tres niveles
- 12.5.3 Invalidación de caché y lecturas obsoletas
- 12.5.4 Composición de servicios y control de versiones
- 12.5.5 Planificación de la capacidad
- 12.5.6 Modos de falla y degradación ordenada
- 12.5.7 Implementación multirregional
- 12.5.8 Consideraciones sobre costos y recursos
- 12.5.9 Desglose de la planificación y el análisis financieros y el rastreo del controlador
- 12.5.10 Forma del paquete de conexión a tierra de IA
- 12.6 Resumen
- 12.6.1 Puntos clave de aprendizaje
- 12.6.2 Errores comunes de diseño
- 12.6.3 Preguntas de repaso
- 12.6.4 Notas complementarias para los estudiantes
- PARTE VII: Uso de la columna vertebral de datos por parte de SAP AI
- 13 Introducción a la arquitectura de SAP AI
- 13.1 Modelo de ejecución central de SAP AI
- 13.1.1 Escenarios, ejecutables, implementaciones y servicio
- 13.1.2 Grupos de recursos y tenencia
- 13.1.3 Política de escalabilidad y razonamiento de capacidad
- 13.1.4 Linaje de inferencia e INFERENCE_EVENT
- 13.1.5 Ejemplo práctico: manifiesto de implementación
- 13.2 SAP AI Launchpad y acceso a modelos
- 13.2.1 Categorías de proveedores y sus propiedades de gobernanza
- 13.2.2 Generative AI Hub y la interfaz del modelo base
- 13.2.3 Dimensiones del catálogo y la decisión de implementación
- 13.3 Ciclo de vida y gobernanza de la IA
- 13.3.1 Estados del ciclo de vida y lo que prometen
- 13.3.2 Las etapas y sus veredictos
- 13.3.3 Evaluación continua: por qué la etapa no es una revisión única
- 13.3.4 Veredictos del ciclo de vida y el rastro de planificación y análisis financiero
- 13.4 Joule como capa de interacción
- 13.4.1 Joule Studio y la creación de agentes
- 13.4.2 La matriz de capacidades de los agentes
- 13.4.3 El catálogo de herramientas de Joule es la biblioteca de acciones de automatización del proceso de compilación de SAP
- 13.5 Integración de la IA con las API de SAP BTP
- 13.5.1 Puntos finales de conexión de la IA: el contrato de consumidor
- 13.5.2 Vías de consumo de IA y sus firmas de auditoría
- 13.5.3 Rastreo de extremo a extremo: la pregunta sobre la variación del controlador
- 13.5.4 Lineaje de costos: INFERENCE_EVENT como elemento controlable
- 13.6 Resumen
- 13.6.1 Puntos clave de aprendizaje
- 13.6.2 Errores comunes de diseño
- 13.6.3 Preguntas de repaso
- 13.6.4 Notas complementarias para los estudiantes
- 14 Preparación de datos para la IA de SAP
- 14.1 Requisitos de los datos para su uso en IA
- 14.1.1 La política de elegibilidad
- 14.1.2 Tres clases de elegibilidad
- 14.1.3 La inelegibilidad por defecto
- 14.1.4 Frecuencia de revisión y reevaluación
- 14.1.5 La matriz de decisión de elegibilidad
- 14.1.6 Ejemplo práctico: una fila de datos maestros de nómina alemana
- 14.2 Filtrado y alcance basado en roles
- 14.2.1 Por qué los conjuntos de datos preparados nunca se reutilizan entre actores
- 14.2.2 El algoritmo de ensamblaje con alcance basado en roles
- 14.2.3 El caso de los roles compuestos
- 14.2.4 Rechazo en lugar de devolución parcial
- 14.3 Control de versiones y aprobaciones
- 14.3.1 El pin PROCESS_VERSION
- 14.3.2 La semántica AS-OF
- 14.3.3 La cadena de aprobaciones
- 14.3.4 Ejemplo práctico: aprobación
- 14.3.5 Presupuestos de vigencia y su propiedad unidireccional
- 14.4 Reglas y restricciones de fundamentación
- 14.4.1 La fundamentación como propiedad del conjunto de datos preparado
- 14.4.2 Firma de manifiestos e inmutabilidad
- 14.4.3 El contrato de citación
- 14.4.4 Restricciones de anclaje: lo que se puede y lo que no se puede vincular
- 14.5 Prevención de alucinaciones y desviaciones
- 14.5.1 La prevención de las alucinaciones como propiedad estructural
- 14.5.2 La deriva como una preocupación constante
- 14.5.3 Detección de la deriva en la práctica
- 14.5.4 Un ciclo práctico de detección de desviaciones
- 14.6 Resumen
- 14.6.1 Puntos clave de aprendizaje
- 14.6.2 Errores comunes de diseño
- 14.6.3 Preguntas de repaso
- 14.6.4 Notas complementarias para los estudiantes
- 15 Generación de sugerencias de procesos mediante IA
- 15.1 Definición de sugerencias de procesos
- 15.1.1 El artefacto de sugerencias
- 15.1.2 La tabla de sugerencias
- 15.1.3 El ciclo de vida de las sugerencias
- 15.1.4 Cumplimiento de los límites establecidos para la IA
- 15.1.5 Dónde se ubica operativamente el flujo de trabajo de sugerencias
- 15.2 Detección de patrones y análisis de similitud
- 15.2.1 Ejemplo práctico: una sugerencia de armonización
- 15.2.2 El corpus de referencia es en sí mismo un artefacto regulado
- 15.2.3 Modos de falla contra los que está diseñada la disciplina
- 15.3 Lógica de puntuación y priorización
- 15.3.1 Los cuatro factores en detalle
- 15.3.2 Ejemplo práctico: puntuación de una sugerencia de brecha de control
- 15.3.3 Las ponderaciones son una configuración, no un proceso de aprendizaje
- 15.3.4 La reevaluación y la garantía de estabilidad
- 15.4 Explicabilidad y trazabilidad
- 15.4.1 La tabla SUGGESTION_EXPLANATION
- 15.4.2 Lo que ve el validador
- 15.4.3 La explicación bajo revisión adversaria
- 15.5 Validación con intervención humana
- 15.5.1 La tabla VALIDATION_VERDICT
- 15.5.2 La cadena de confirmaciones regulada
- 15.5.3 Los agentes híbridos y los que no son del SAP envían a través de la misma ruta
- 15.5.4 Lo que el veredicto no resuelve
- 15.6 Resumen
- 15.6.1 Puntos clave de aprendizaje
- 15.6.2 Errores comunes de diseño
- 15.6.3 Preguntas de repaso
- 15.6.4 Notas complementarias para los estudiantes
- PARTE VIII Consumo de SAP Build
- 16 Automatización del proceso de SAP Build: flujo de trabajo sobre la columna vertebral de datos
- 16.1 Posicionamiento de la automatización del proceso de SAP Build en Data Spine
- 16.1.1 Componentes básicos y lo que cada uno puede hacer
- 16.1.2 Proyectos, lanzamientos y por qué el control de versiones se encuentra en la columna vertebral de datos
- 16.1.3 Destinos, identidad y la ruta de escritura única
- 16.2 Flujos de trabajo de aprobación
- 16.2.1 Por qué el disparador se basa en la sugerencia aceptada, no en la sugerencia original
- 16.2.2 Derivación de la cadena de aprobadores a partir del contexto del proceso
- 16.2.3 La separación de funciones como propiedad estructural
- 16.2.4 Qué se registra tras la aprobación y cómo
- 16.2.5 Un proceso de aprobación de referencia anotado
- 16.2.6 Formularios de aprobación: lo que muestran y lo que nunca deben recabar
- 16.2.7 La anatomía de un disparador vinculado a un veredicto
- 16.2.8 Bandas de riesgo y la estructura de la cadena de aprobadores
- 16.2.9 Ejemplo práctico: un cambio de secuencia entre regiones
- 16.2.10 Tiempo, escalamiento y el problema del aprobador permanente
- 16.3 Flujos de excepciones y correcciones
- 16.3.1 Una excepción es un evento tipificado y clasificado por banda de gravedad
- 16.3.2 Tres rutas de corrección reguladas
- 16.3.3 Ejemplo práctico: una validación fallida en una puerta de control
- 16.3.4 El esquema del evento de excepción
- 16.3.5 La corrección automática es una regla regulada, no una ruta de código
- 16.3.6 El caso de corrección como un objeto de la columna vertebral de datos
- 16.3.7 Reconciliación entre el estado del flujo de trabajo y la verdad de Data Spine
- 16.3.8 Ejemplo práctico: corrección impulsada por telemetría
- 16.4 Recomendaciones asistidas por IA
- 16.4.1 La recomendación es de carácter consultivo por diseño
- 16.4.2 Lo que debe incluir el panel de recomendaciones
- 16.4.3 Un contrato de tareas humanas anotado
- 16.4.4 El veredicto registra lo que la persona hizo con el consejo
- 16.4.5 Por qué el panel no puede prellenar la decisión
- 16.4.6 Ejemplo práctico: una recomendación dentro de una tarea de aprobación
- 16.4.7 Análisis de la disposición: la primera señal del controlador
- 16.5 Gobernanza y manejo de auditorías
- 16.5.1 Cada instancia de flujo de trabajo es una fila de auditoría
- 16.5.2 La reconstrucción con una sola consulta
- 16.5.3 Las excepciones de gobernanza son de primera clase, no errores
- 16.5.4 Lo que realmente pregunta un auditor y la forma de la respuesta
- 16.5.5 Dónde reside el estado del flujo de trabajo y por qué es importante para la auditoría
- 16.5.6 El libro mayor de rechazos
- 16.5.7 El catálogo de controles: asignación de los controles del flujo de trabajo a los marcos de auditoría
- 16.5.8 Manejo de la auditoría en distintos programas y regiones
- 16.5.9 Un cambio, de principio a fin
- 16.6 Resumen
- 16.6.1 Puntos clave de aprendizaje
- 16.6.2 Errores comunes de diseño
- 16.6.3 Preguntas de repaso
- 16.6.4 Notas complementarias para los estudiantes
- 17 Zona de trabajo de SAP Build: Experiencias de usuario orientadas a los procesos
- 17.1 Posicionamiento de SAP Build Work Zone en Data Spine
- 17.1.1 Componentes y lo que cada uno puede hacer
- 17.1.2 Por qué la capa de experiencia no contiene datos
- 17.1.3 La ruta de lectura única y la ausencia de ruta de escritura
- 17.1.4 Qué puede alojarse en SAP Build Work Zone y qué no
- 17.2 Navegación impulsada por procesos
- 17.2.1 La navegación es una consulta, no un menú
- 17.2.2 La correspondencia entre procesos y espacios
- 17.2.3 La búsqueda es una proyección con alcance, no un índice
- 17.2.4 Ejemplo práctico: el recorrido del centro de costos a la posición
- 17.2.5 Enlaces profundos, marcadores y el problema de las URL obsoletas
- 17.3 Vistas de tareas basadas en roles
- 17.3.1 Una vista de tareas es un conjunto con ámbito de rol
- 17.3.2 De dónde provienen las tareas: automatización del proceso de compilación de SAP
- 17.3.3 La separación de funciones es visible, no solo se impone
- 17.3.4 Delegación y sustitución sin escalamiento de ámbito
- 17.4 Presentación de insights de IA
- 17.4.1 Una idea es una referencia, no una respuesta
- 17.4.2 Joule en la zona de trabajo de SAP Build
- 17.4.3 El contrato de la tarjeta de insight, con anotaciones
- 17.4.4 Tarjetas con múltiples sugerencias y la trampa de la comparación
- 17.4.5 Cuando el paquete está desactualizado: caducidad de los insights y reanálisis
- 17.5 Límites de la interacción del usuario
- 17.5.1 La interfaz de usuario ofrece solo lo que permite la columna vertebral de datos
- 17.5.2 El control ausente es el control más poderoso
- 17.5.3 La opción de emergencia es una ruta separada, autenticada por el usuario
- 17.5.4 El caso de dispositivos móviles y sin conexión
- 17.5.5 Una sola interacción, de principio a fin: más allá de los límites
- 17.6 Resumen
- 17.6.1 Puntos clave de aprendizaje
- 17.6.2 Errores comunes de diseño
- 17.6.3 Preguntas de repaso
- 17.6.4 Notas complementarias para los estudiantes
- PARTE IX Operaciones, seguridad y extensibilidad
- 18 Operación de la plataforma integrada
- 18.1 El modelo operativo de la plataforma integrada
- 18.2 Monitoreo y observabilidad
- 18.2.1 Tres clases de señales
- 18.2.2 Las señales de referencia por capa
- 18.2.3 Objetivos de nivel de servicio y presupuesto de errores
- 18.2.4 El modelo de gravedad y la postura de guardia
- 18.2.5 Correlación: una identidad para el estado y la evidencia
- 18.2.6 El modelo de datos de observabilidad
- 18.2.7 Los tableros como artefactos operativos, no como decoración
- 18.2.8 Ejemplo práctico: el ciclo de vida de la respuesta a incidentes
- 18.3 Gestión de la calidad de los datos
- 18.3.1 La calidad es una propiedad operativa
- 18.3.2 El modelo operativo del administrador
- 18.3.3 La economía de la cuarentena
- 18.3.4 La IA como detector de patrones de calidad y sus límites
- 18.3.5 El ciclo de vida de las reglas de validación
- 18.3.6 Ejemplo práctico: la conciliación es el motor del cuadro de mando
- 18.4 Desviación de versiones y resincronización
- 18.4.1 La taxonomía de la deriva, llevada adelante
- 18.4.2 El flujo de decisión de resincronización
- 18.4.3 La desviación nunca muta en el lugar
- 18.4.4 Repetición forense
- 18.4.5 Reinicio en caliente y reajuste
- 18.4.6 La cadencia de reconciliación, en funcionamiento
- 18.4.7 Aspectos económicos de la retención de instantáneas
- 18.4.8 Ejemplo práctico: un evento de desviación, de principio a fin
- 18.5 Escalabilidad entre programas
- 18.5.1 Tenencia de programas en grupos de recursos
- 18.5.2 Topología multirregional y replicación limitada por jurisdicción
- 18.5.3 El ciclo de vida de la incorporación de programas
- 18.5.4 Verificación del aislamiento de los inquilinos
- 18.5.5 Escalabilidad del nivel de IA
- 18.5.6 El equipo federado y sus responsabilidades
- 18.5.7 Ejemplo práctico: el linaje de costos y el nivel de IA como elemento controlable
- 18.6 Resumen
- 18.6.1 Puntos clave de aprendizaje
- 18.6.2 Errores comunes de diseño
- 18.6.3 Preguntas de repaso
- 18.6.4 Notas complementarias para los estudiantes
- 19 Seguridad, controles y auditorías
- 19.1 Acceso a los datos y autorización
- 19.1.1 La identidad es el primer control, no un requisito previo para este
- 19.1.2 La defensa en profundidad como propiedad arquitectónica
- 19.1.3 El vocabulario de la autorización: ámbitos vinculados a operaciones canónicas
- 19.1.4 Las cuatro operaciones canónicas en detalle
- 19.1.5 Ejemplo práctico: un agente de IA alcanza su límite
- 19.1.6 Segmentación basada en roles de la columna vertebral de datos
- 19.1.7 Los agentes de IA como actores nombrados
- 19.1.8 Ejemplo práctico: una cuestión sobre la residencia de datos
- 19.2 Eficacia del control
- 19.2.1 La eficacia es la adecuación del diseño multiplicada por la evidencia operativa
- 19.2.2 Las tres clases de control
- 19.2.3 Por qué el registro de rechazos es la evidencia más valiosa
- 19.2.4 El catálogo de controles como un registro generado
- 19.2.5 Las dimensiones de una entrada en el catálogo
- 19.2.6 Ejemplo práctico: cómo demostrar un control preventivo a lo largo de un trimestre
- 19.2.7 La efectividad es una propiedad de la arquitectura, no del esfuerzo
- 19.3 Rastros de auditoría y evidencia
- 19.3.1 El evento de auditoría encadenado mediante hash
- 19.3.2 El linaje como ruta de consulta de primera clase
- 19.3.3 Lo que el auditor realmente pregunta
- 19.3.4 Ejemplo práctico: la pregunta sobre la variación del controlador, paso a paso
- 19.3.5 Ejemplo práctico: Reproducción forense de una decisión pasada
- 19.3.6 Retención, anclaje y reproducción forense
- 19.4 Consideraciones de cumplimiento
- 19.4.1 Obligación, control, evidencia
- 19.4.2 Por qué es importante la correspondencia con las consultas en lugar de con los carpetas
- 19.4.3 Ejemplo práctico: Descomposición de una obligación de cumplimiento
- 19.4.4 Por qué los mismos mecanismos satisfacen regímenes independientes
- 19.4.5 Jurisdicción, residencia y cumplimiento multirregional
- 19.4.6 La postura de cumplimiento es continua, no periódica
- 19.5 Resumen
- 19.5.1 Puntos clave de aprendizaje
- 19.5.2 Errores comunes de diseño
- 19.5.3 Preguntas de repaso
- 19.5.4 Notas complementarias para los estudiantes
- 19.6 Conclusión: La empresa integrada y preparada para la IA
- El autor
- Índice
Integrating Architecture, Processes, and AI on SAP BTP
Planning to implement AI and automation? Start by preparing your foundation. Most organizations document processes and architecture, but don’t connect them in a way that’s useful for AI models and automation workflows. This book shows you how to use SAP Signavio, SAP LeanIX, and WalkMe to transform your architecture and process data into a unified execution layer on SAP BTP. You’ll learn to model processes, map applications to process steps, capture adoption telemetry, design integration flows, and prepare data for AI and automation. Move from static documentation to an execution-ready SAP architecture!
- Integrate SAP Signavio, SAP LeanIX, and WalkMe data using SAP BTP
- Build an execution-ready canonical data spine for AI and automation
- Implement execution services, workflows, and SAP AI capabilities using the unified data model
You'll learn about:
- Designing the Canonical Data Spine:
Discover why point-to-point integrations fail and how to implement a normalized canonical model on SAP BTP. Define stable identifiers, ownership rules, versioning strategies, and audit mechanisms that support execution-grade automation and AI.
- Integrating Process and Architecture Data:
Structure process and architecture data for downstream consumption using SAP Signavio and SAP LeanIX. Map L4/L5 process steps to applications and interfaces, design ingestion flows, and build reusable execution services for process lookup, context enrichment, and change impact analysis.
- Enabling AI and Automation:
Prepare enterprise data for SAP’s AI services. Define eligibility rules, role-based scoping, grounding constraints, and human-in-the-loop validation. Deploy AI services on top of a secure, integrated foundation.
Key Highlights:
- SAP Signavio
- SAP LeanIX
- WalkMe
- AI execution
- SAP AI Core
- Generative AI Hub
- Automated workflows
- SAP Build Process Automation
- SAP Build Work Zone
- Security
- Monitoring
View Full Table of Contents
- Preface
- PART I Technical Context and Integration Principles
- 1 Why Enterprise Architecture and Business Process Architecture Data Must Be Integrated for AI Execution
- 1.1 The Structural Failure of Most Transformation Programs
- 1.1.1 Design, Delivery, Telemetry, and Improvement
- 1.1.2 The Enterprise Execution Pyramid
- 1.1.3 Why AI Amplifies Both Coherence and Fragmentation
- 1.2 Limitations of Isolated Process Repositories
- 1.3 Limitations of Isolated Enterprise Architecture Repositories
- 1.3.1 Architecture Without Execution Semantics
- 1.3.2 Middleware Drift and Disconnected Integration Logic
- 1.3.3 Architecture Describes Systems; Process Describes Execution
- 1.4 Why SAP AI Requires Unified Semantic Context
- 1.4.1 SAP AI Is Layered, Not Monolithic
- 1.4.2 What Each Layer Requires from the Semantic Foundation
- 1.4.3 The Specific Requirements of Generative and Agentic AI
- 1.4.4 AI Grounding Bundles and the Role of the Canonical Layer
- 1.5 The Role of SAP BTP as the Data Spine, Integration Layer, and Extension Layer
- 1.5.1 Three Architectural Roles of SAP BTP
- 1.5.2 Why Canonical Semantics Live on SAP BTP
- 1.5.3 Validation, Publication, and the Role of Boundary Enforcement
- 1.5.4 SAP BTP as the Coordinator of the Design-to-Delivery Loop
- 1.6 Non-Goals: What AI Must Not Automate
- 1.7 Summary
- 1.7.1 Key Learning Points
- 1.7.2 Common Design Pitfalls
- 1.7.3 Review Questions
- 1.7.4 Student Companion Notes
- 2 Reference Integration Architecture
- 2.1 Logical Architecture Overview
- 2.2 Authoritative Systems of Record
- 2.3 Data Ownership and Write Boundaries
- 2.3.1 The Three Write Boundary Rules
- 2.3.2 Why Boundary Enforcement Cannot Be Conventional
- 2.3.3 Worked Example: Tracing a Cost Center Update Across the Architecture
- 2.4 Integration and Extension Responsibilities
- 2.5 Execution and Consumption Layers
- 2.6 Security Architecture Principles for Process- and AI-Driven Integration
- 2.7 Identity, Authentication, and Authorization in SAP Signavio, SAP LeanIX, and SAP BTP
- 2.8 Data Access Segmentation and Role-Based Exposure of the Data Spine
- 2.8.1 Three Dimensions of Segmentation
- 2.8.2 Segmentation in the Token
- 2.8.3 Segmentation for AI Consumers
- 2.8.4 The Scope Vocabulary in Practice
- 2.9 Security Boundaries Between Execution Services, AI Services, and User Interfaces
- 2.10 Auditability, Traceability, and Non-Repudiation by Design
- 2.11 Allocation of Security Responsibilities Across Platforms
- 2.12 Summary
- 2.12.1 Key Learning Points
- 2.12.2 Common Design Pitfalls
- 2.12.3 Review Questions
- 2.12.4 Student Companion Notes
- PART II Configuring SAP Signavio for Execution and AI Readiness
- 3 SAP Signavio Data Model for Integration
- 3.1 L4 and L5 Process Object Requirements
- 3.1.1 L4 Process Step Objects
- 3.1.2 L5 Work Instruction Objects
- 3.1.3 Digital Discovery Assessment as the Source for L4
- 3.2 Process and Activity Identifiers
- 3.2.1 The Identifier Standard
- 3.2.2 Immutability and Renaming
- 3.2.3 Identifier-to-System Mappings
- 3.3 Mandatory Execution Attributes
- 3.3.1 Step Identifier
- 3.3.2 Performing Role
- 3.3.3 System Trigger
- 3.3.4 Application Reference
- 3.3.5 Control Intent
- 3.3.6 Data Objects In and Out
- 3.3.7 Key Performance Indicator Anchor
- 3.4 Roles, Variants, and Localization
- 3.4.1 The Six-Role Taxonomy
- 3.4.2 Swimlane Discipline
- 3.4.3 Variant Classification
- 3.4.4 Localization Markers
- 3.5 Versioning and Lifecycle Management
- 3.5.1 The Version State Machine
- 3.5.2 Change Rules: Major, Minor, Patch, and Variant
- 3.5.3 The Digital Thread: DDA to BPMN to Runtime
- 3.6 What Must Not Be Modeled in SAP Signavio
- 3.7 Summary
- 3.7.1 Key Learning Points
- 3.7.2 Common Design Pitfalls
- 3.7.3 Review Questions
- 3.7.4 Student Companion Notes
- 4 Extending SAP Signavio for Downstream Consumption
- 4.1 Standard Attributes Versus Custom Attributes
- 4.1.1 The Role of Attributes in an Integration-Ready Process Model
- 4.1.2 Standard Attributes: What They Cover and Where They Stop
- 4.1.3 A Disciplined Custom Attribute Strategy
- 4.1.4 Naming Conventions and Dictionary Management
- 4.1.5 Common Pitfalls in Attribute Design
- 4.1.6 Attribute Scoping: Process, Activity, Lane, and Workspace
- 4.1.7 Data Types and Controlled Enumerations
- 4.1.8 Worked Example: Custom Attributes Across Three Process Domains
- 4.2 External Reference Patterns
- 4.2.1 Defining an External Reference
- 4.2.2 Why URL-Based Linking Is Avoided
- 4.2.3 Reference Patterns by Target System
- 4.2.4 Multi-Valued and Qualified References
- 4.2.5 Governance of References Across Lifecycles
- 4.3 Preparing SAP Signavio APIs for Extraction
- 4.3.1 The SAP Signavio API Landscape
- 4.3.2 Authentication, Tokens, and Service Identities
- 4.3.3 Endpoint Inventory for Spine Ingestion
- 4.3.4 Scoping and Permissioning
- 4.3.5 Rate Limits, Pagination, and Backoff
- 4.3.6 Schema Versioning and Compatibility Discipline
- 4.3.7 Sample API Calls and Response Handling
- 4.3.8 Calling SAP Signavio APIs: SAP Integration Suite Versus Direct from SAP BTP
- 4.3.9 Operational Telemetry for the Extraction Flow
- 4.4 Event Versus Batch Export Considerations
- 4.4.1 Two Patterns, Two Failure Modes
- 4.4.2 Batch Export Design
- 4.4.3 Event-Driven Export Design
- 4.4.4 Reconciliation Between Event and Batch Exports
- 4.4.5 Decision Heuristics: Choosing the Right Pattern
- 4.4.6 Worked Example: A Reconciliation Cycle
- 4.4.7 Failure Handling and Operational Runbooks
- 4.5 Validation and Data Quality Checks
- 4.5.1 Where Validation Runs in the Extension Contract
- 4.5.2 Categories of Validation Checks
- 4.5.3 Severity Levels and Outcome Handling
- 4.5.4 Quarantine Versus Reject: Handling Bad Records
- 4.5.5 Closing the Loop with Modeling Teams
- 4.5.6 Worked Example: Validating an Execution-Ready Activity
- 4.5.7 Quality Scoring as a Leading Indicator
- 4.5.8 Worked Example: Validation Across a Process Variant
- 4.5.9 Auditability of the Validation Layer
- 4.6 Summary
- 4.6.1 Key Learning Points
- 4.6.2 Common Design Pitfalls
- 4.6.3 Review Questions
- 4.6.4 Student Companion Notes
- PART III Configuring SAP LeanIX for Dependency and Context Data
- 5 SAP LeanIX Data Model for Integration
- 5.1 The Running Scenario: Cost Center to Position
- 5.2 Application Objects Required for Integration
- 5.2.1 The Integration-Eligible Application
- 5.2.2 The Mandatory Attribute Set
- 5.2.3 Application Versus IT Component
- 5.2.4 Worked Anatomy of an Application Factsheet
- 5.2.5 The Application Inventory Discipline
- 5.2.6 Application Factsheet: Build Specification
- 5.3 Interface and Dependency Modeling
- 5.3.1 What Belongs on an Interface Factsheet
- 5.3.2 Dependency Modeling and Chains
- 5.3.3 Worked Example: Cost Center to Position
- 5.3.4 Hub Interfaces and the Limits of Direct Modeling
- 5.3.5 Interface Factsheet: Build Specification
- 5.4 Lifecycle and Change-Related Attributes
- 5.4.1 The Five-Phase Lifecycle Model
- 5.4.2 The Two Approval Flags
- 5.4.3 Lifecycle Transitions as Governance Events
- 5.4.4 Beyond Phases: Other Change-Related Attributes
- 5.4.5 Phase-to-Consumer Visibility Matrix
- 5.4.6 Lifecycle Attribute Set: Build Specification
- 5.5 Stable Identifiers and Keys
- 5.5.1 The factSheetId as a Primary Key
- 5.5.2 External Identifiers as Resolvable References
- 5.5.3 Identifier Changes as Governance Events
- 5.5.4 Binding Identifiers to Activities
- 5.5.5 SAP Fiori App ID as a Secondary Identifier
- 5.5.6 Identifier Set: Build Specification
- 5.5.7 Cross-Chapter Field Name Glossary
- 5.6 Avoiding Overlap with SAP Signavio
- 5.6.1 The Division of Responsibility
- 5.6.2 Anti-Patterns and Their Costs
- 5.6.3 Worked Example: Boundary: Cost Center to Position Propagation
- 5.7 Summary
- 5.7.1 Key Learning Points
- 5.7.2 Common Design Pitfalls
- 5.7.3 Review Questions
- 5.7.4 Student Companion Notes
- 6 Mapping SAP LeanIX to Process Semantics
- 6.1 Linking Applications to L4/L5 Activities
- 6.1.1 The LEANIX|APPLICATION Reference
- 6.1.2 Cardinality and the Single-Execution Location Rule
- 6.1.3 Activity_Stable_ID as the Owner of the Binding
- 6.1.4 Resolution at Lookup Time, Not at Binding Time
- 6.1.5 Worked Example: Cost Center to Position Application Bindings
- 6.2 Interface-to-Process Relationships
- 6.2.1 The LEANIX|INTERFACE Reference
- 6.2.2 Role Tag Semantics
- 6.2.3 Hub Interfaces and Two-Sided Bindings
- 6.2.4 The Activity-Level Data Flow Statement
- 6.2.5 Worked Example: Cost Center to Position Interface Bindings
- 6.2.6 What the Interface Binding Does Not Carry
- 6.3 Capability and Domain Alignment
- 6.3.1 The Capability Map in SAP LeanIX
- 6.3.2 The Domain Layer Above the Capability Map
- 6.3.3 Capability and Domain Inheritance Through the Data Spine
- 6.3.4 End-to-End Process Views from Inherited Capabilities
- 6.3.5 Worked Example: Cost Center to Position Capability and Domain Inheritance
- 6.4 Change Impact Use Cases
- 6.4.1 Use Case 1: Application Phase-Out
- 6.4.2 Use Case 2: Interface Deprecation
- 6.4.3 Use Case 3: Role Reorganization
- 6.4.4 Use Case 4: Control Intent Change
- 6.4.5 Worked Example: Cost Center to Position Composite Change Impact
- 6.5 Data Preparation for SAP BTP Ingestion
- 6.5.1 Stage 1: Extract
- 6.5.2 Stage 2: Validate
- 6.5.3 Stage 3: Stage
- 6.5.4 Stage 4: Enrich
- 6.5.5 Stage 5: Publish
- 6.5.6 Composition with the SAP Signavio Pipeline
- 6.5.7 Worked Example: Cost Center to Position Bundle Publication Record
- 6.6 Cross-Chapter Vocabulary Continuity
- 6.7 Summary
- 6.7.1 Key Learning Points
- 6.7.2 Common Design Pitfalls
- 6.7.3 Review Questions
- 6.7.4 Student Companion Notes
- PART IV WalkMe for Process-Aware Adoption and Telemetry
- 7 Designing WalkMe for Process-Aware Adoption
- 7.1 Positioning WalkMe in a Process-Driven Architecture
- 7.1.1 Why the Target Distinction Matters
- 7.1.2 WalkMe as a Knowledge Graph
- 7.1.3 WalkMe in the Reference Architecture's Trust Zones
- 7.2 Mapping WalkMe Content to L4/L5 Process Steps
- 7.2.1 Stable Identifiers as the Binding Mechanism
- 7.2.2 The WALKME_ASSET_BINDING Entity and the Data Model
- 7.2.3 Worked Example: Cost Center to Position with WalkMe Overlay
- 7.2.4 Resolution at Render Time
- 7.3 Aligning WalkMe with SAP Signavio and SAP Build Work Zone
- 7.3.1 SAP Signavio: The Authoritative Process Reference
- 7.3.2 SAP Build Work Zone: The Launch Surface
- 7.3.3 WalkMe: The Guidance Surface
- 7.3.4 Joint Operating Cadence
- 7.4 Governance of In-App Guidance and Change
- 7.4.1 The Lifecycle of a WalkMe Asset
- 7.4.2 Approval and Separation of Duties
- 7.4.3 WalkMe as a Target for AI Agents
- 7.4.4 Change Coordination with SAP Signavio and SAP LeanIX
- 7.4.5 Audit Evidence and Retention
- 7.5 Summary
- 7.5.1 Key Learning Points
- 7.5.2 Common Design Pitfalls
- 7.5.3 Review Questions
- 7.5.4 Student Companion Notes
- 8 Using WalkMe Telemetry to Improve Process and Integration Outcomes
- 8.1 Capturing User Interaction Signals
- 8.1.1 The Four Signal Channels
- 8.1.2 Identity Tagging at the Edge
- 8.1.3 The Single Governed Gateway
- 8.2 Linking Adoption Data to the SAP BTP Data Spine
- 8.2.1 The Telemetry Data Model
- 8.2.2 The Five-Stage Ingestion Pipeline
- 8.2.3 The Dead-Letter Queue and Replay
- 8.3 Detecting Friction, Deviations, and Training Gaps
- 8.3.1 Friction Detection
- 8.3.2 Deviation Detection
- 8.3.3 Training Gap Detection
- 8.4 Feeding Adoption Insights into Downstream AI Services
- 8.4.1 WalkMe as a Target for AI Agents
- 8.4.2 The Two Downstream Destinations
- 8.4.3 Adoption Signals in the Knowledge Graph
- 8.4.4 The End-to-End Loop
- 8.5 Summary
- 8.5.1 Key Learning Points
- 8.5.2 Common Design Pitfalls
- 8.5.3 Review Questions
- 8.5.4 Student Companion Notes
- PART V The Data Spine on SAP BTP
- 9 Designing the Canonical Data Spine
- 9.1 Why Point-to-Point Integrations Fail
- 9.2 Canonical Data Spine Entities and Relationships
- 9.2.1 Domain Model Overview and Architectural Boundaries
- 9.2.2 From Domains to Canonical Entities
- 9.2.3 Execution Context as the Structural Pivot
- 9.2.4 Logical Consolidation of the Canonical Model
- 9.3 Process, Activity, Application, and Interface Keys
- 9.3.1 Stable Identity and Version: Process and Activity
- 9.3.2 Architecture Keys and Identity: Applications and Interfaces
- 9.3.3 Mapping Tables: Process-to-Architecture and System Involvement
- 9.3.4 Execution Context: Ownership Clarity in Multisystem Processes
- 9.3.5 Master Data Referencing (Not Replication)
- 9.3.6 Adoption and Telemetry: WalkMe
- 9.3.7 Configuration Objects and Activity Mapping
- 9.3.8 Governance Overlay: Validation and Publication
- 9.3.9 AI Artifacts: Separated from Canonical Truth
- 9.4 Use Case: Creation of a New Position
- 9.4.1 Sample Data Set
- 9.4.2 Business Context and SAP Best Practice Alignment
- 9.4.3 End-to-End Cross-System Flow
- 9.4.4 Execution Context as Structural Control
- 9.4.5 Master Data Referencing in the Data Spine
- 9.4.6 Configuration Dependencies
- 9.4.7 Validation and Publication Discipline
- 9.4.8 AI-Governed Suggestion Flow
- 9.4.9 Architectural Outcome
- 9.5 Versioning and Lineage Strategy
- 9.5.1 Structural Identity and Version Separation
- 9.5.2 Version Graph and Lineage Modeling
- 9.5.3 Temporal Validity and Runtime Resolution
- 9.5.4 Publication as an Execution Structural Boundary
- 9.5.5 Dependency Revalidation on Structural Change
- 9.5.6 AI Grounding and Bundle Immutability
- 9.5.7 Managing Variant and Regulatory Branches
- 9.5.8 Versioning as an Operational Control System
- 9.6 Ownership and Lifecycle Rules
- 9.6.1 Entity Ownership Boundaries
- 9.6.2 Identity and Mutability Boundaries
- 9.6.3 Lifecycle State Model
- 9.6.4 Validation and Publication Authority
- 9.6.5 Cross-Domain Change Discipline
- 9.6.6 Separation of Duties and Access Control
- 9.6.7 AI Consumption Boundaries
- 9.6.8 Governance as Structural Integrity
- 9.7 Summary
- 9.7.1 Key Learning Points
- 9.7.2 Common Design Pitfalls
- 9.7.3 Review Questions
- 9.7.4 Student Companion Notes
- 10 Implementing the Data Spine on SAP BTP
- 10.1 Persistence Options on SAP BTP
- 10.1.1 SAP HANA Cloud as the Canonical Relational Core
- 10.1.2 Object Store for Raw Telemetry and Archival Payloads
- 10.1.3 Document Store for Schemaless and Variant Payloads
- 10.1.4 SAP HANA Cloud Vector Engine for AI Grounding Embeddings
- 10.1.5 Event Mesh for Change Propagation
- 10.1.6 SAP Build Process Automation for Workflow States
- 10.1.7 Choosing the Right Store for Each Canonical Concern
- 10.2 Table and Schema Design
- 10.2.1 Process and Activity Tables
- 10.2.2 Architecture Tables
- 10.2.3 Execution Context: Where Process Meets Architecture
- 10.2.4 Master Data and Adoption References
- 10.2.5 Audit and AI Consumption Tables
- 10.3 Data Extension Patterns
- 10.3.1 Why the Canonical Core Stays Closed
- 10.3.2 The Extension Side-Table Pattern
- 10.3.3 The Anti-Pattern That Destroys the Data Spine
- 10.3.4 Industry Variants and Vertical Extensions
- 10.3.5 AI-Derived Extensions
- 10.3.6 Extension Discoverability
- 10.4 API Design for Ingestion and Access
- 10.4.1 The Ingestion API: Idempotent Writes from Upstream Sources
- 10.4.2 The Access API: Read with Role and Version Context
- 10.4.3 The Governance API: State Transitions Through Workflow
- 10.4.4 AI Grounding Endpoints
- 10.4.5 Event Mesh Integration
- 10.4.6 Versioning the API Surface
- 10.4.7 Alignment with SAP API Policy v.4.2026a
- 10.5 Governance and Auditability
- 10.5.1 Hash-Chained Audit Events
- 10.5.2 Lineage as a First-Class Query Path
- 10.5.3 Separation of Duties Through SAP Authorization and Trust Management Service Scopes
- 10.5.4 Retention Tiering and Cryptographic Anchoring
- 10.5.5 Compliance Evidence Chain
- 10.6 Summary
- 10.6.1 Key Learning Points
- 10.6.2 Common Design Pitfalls
- 10.6.3 Review Questions
- 10.6.4 Student Companion Notes
- PART VI Integration Flows and Execution Services on SAP BTP
- 11 Integration Flows from SAP Signavio and SAP LeanIX
- 11.1 SAP Signavio to SAP BTP Ingestion Flows
- 11.1.1 Reference Architecture for SAP Signavio Ingestion
- 11.1.2 Event-Driven and Batch Ingestion Patterns
- 11.1.3 End-to-End SAP Signavio Ingestion Flow
- 11.1.4 Payload Mapping into the Canonical Data Spine
- 11.1.5 Adapter Implementation Notes
- 11.1.6 Authentication and Credential Rotation
- 11.2 SAP LeanIX to SAP BTP Ingestion Flows
- 11.2.1 SAP LeanIX as the Architecture System of Record
- 11.2.2 Dependency-First Ingestion Order
- 11.2.3 Capability and Domain Alignment
- 11.2.4 SAP LeanIX Webhook Semantics and Bulk Export Sizing
- 11.2.5 Data Classification and Sensitive Attribute Handling
- 11.3 Synchronization and Reconciliation
- 11.3.1 States and Transitions
- 11.3.2 Daily Reconciliation Cycle
- 11.3.3 Drift Classification: Material Versus Immaterial
- 11.3.4 Snapshot Retention and Forensic Replay
- 11.3.5 Watermarks and Hot Restart Semantics
- 11.3.6 Operational Cadence and On-Call Posture
- 11.4 Error Handling and Retries
- 11.4.1 Error Classification
- 11.4.2 Idempotency Discipline
- 11.4.3 Retry, Backoff, and Dead-Letter Routing
- 11.4.4 Observability Tied to Failures
- 11.4.5 Service-Level Objectives and Alerting Thresholds
- 11.4.6 Poison Messages and Circuit Breakers
- 11.5 Data Consistency Validation
- 11.5.1 Four-Tier Validation Model
- 11.5.2 Validation Rules Catalog
- 11.5.3 Validation Log as the Audit Spine
- 11.5.4 Rule Lifecycle and Versioning
- 11.5.5 Validation Discipline and Financial Reporting Trust
- 11.5.6 Worked Example: A Single Activity Through the Pipeline
- 11.6 Summary
- 11.6.1 Key Learning Points
- 11.6.2 Common Design Pitfalls
- 11.6.3 Review Questions
- 11.6.4 Student Companion Notes
- 12 Process-Aware Execution Services
- 12.1 Process Lookup Services
- 12.1.1 Service Boundaries and Read-Only Contract
- 12.1.2 Latency Budget and Throughput Target
- 12.1.3 Worked Example: A Single Process Lookup Call
- 12.1.4 Filter Predicates and Their Cost
- 12.2 Context Enrichment APIs
- 12.2.1 The Three Distinguishing Properties
- 12.2.2 Latency Budget and Caching
- 12.2.3 Why Context Enrichment Is the Source for AI Grounding
- 12.2.4 Enrichment Output Schema
- 12.3 Change Impact Resolution Services
- 12.3.1 Forward Impact
- 12.3.2 Reverse Impact
- 12.3.3 Performance and Caching of Graph Walks
- 12.3.4 Graph Traversal Patterns by Use Case
- 12.3.5 Worked Example: Retiring an Interface
- 12.3.6 Edge Cases the Service Handles Explicitly
- 12.4 Reusable Integration Services
- 12.4.1 The Action Library
- 12.4.2 Versioning and Deprecation of Actions
- 12.4.3 Contract Stability
- 12.4.4 Action Definition Format
- 12.4.5 Service Contract: Process Lookup View
- 12.5 Performance and Scalability Considerations
- 12.5.1 Latency Budgets and Throughput Targets
- 12.5.2 Three-Tier Caching
- 12.5.3 Cache Invalidation and Stale Reads
- 12.5.4 Service Composition and Versioning
- 12.5.5 Capacity Planning
- 12.5.6 Failure Modes and Graceful Degradation
- 12.5.7 Multiregion Deployment
- 12.5.8 Cost and Resource Considerations
- 12.5.9 Financial Planning and Analysis Drilldown and the Controller’s Trace
- 12.5.10 AI Grounding Bundle Shape
- 12.6 Summary
- 12.6.1 Key Learning Points
- 12.6.2 Common Design Pitfalls
- 12.6.3 Review Questions
- 12.6.4 Student Companion Notes
- PART VII SAP AI Consumption of the Data Spine
- 13 Introducing SAP AI Architecture
- 13.1 SAP AI Core Execution Model
- 13.1.1 Scenarios, Executables, Deployments, and Serving
- 13.1.2 Resource Groups and Tenancy
- 13.1.3 Scaling Policy and Capacity Reasoning
- 13.1.4 Inference Lineage and INFERENCE_EVENT
- 13.1.5 Worked Example: Deployment Manifest
- 13.2 SAP AI Launchpad and Model Access
- 13.2.1 Provider Categories and Their Governance Properties
- 13.2.2 Generative AI Hub and the Foundation Model Interface
- 13.2.3 Catalog Dimensions and the Deployment Decision
- 13.3 AI Lifecycle and Governance
- 13.3.1 Lifecycle States and What They Promise
- 13.3.2 Gates and Their Verdicts
- 13.3.3 Continuous Evaluation: Why the Gate Is Not a One-Time Check
- 13.3.4 Lifecycle Verdicts and the Financial Planning and Analysis Trace
- 13.4 Joule as the Interaction Layer
- 13.4.1 Joule Studio and Agent Authoring
- 13.4.2 The Agent Capability Matrix
- 13.4.3 Joule’s Tool Catalog Is the SAP Build Process Automation Action Library
- 13.5 Integrating AI with SAP BTP APIs
- 13.5.1 AI Grounding Endpoints: The Consumer Contract
- 13.5.2 AI Consumption Pathways and Their Audit Signatures
- 13.5.3 End-to-End Trace: The Controller’s Variance Question
- 13.5.4 Cost Lineage: INFERENCE_EVENT as a Controllable
- 13.6 Summary
- 13.6.1 Key Learning Points
- 13.6.2 Common Design Pitfalls
- 13.6.3 Review Questions
- 13.6.4 Student Companion Notes
- 14 Preparing Data for SAP AI
- 14.1 Data Eligibility for AI Consumption
- 14.1.1 The Eligibility Policy
- 14.1.2 Three Eligibility Classes
- 14.1.3 The Ineligibility Default
- 14.1.4 Review Cadence and Reevaluation
- 14.1.5 The Eligibility Decision Matrix
- 14.1.6 Worked Example: A German Payroll Master-Data Row
- 14.2 Filtering and Role-Based Scoping
- 14.2.1 Why Prepared Data Sets Are Never Reused Across Actors
- 14.2.2 The Role-Scoped Assembly Algorithm
- 14.2.3 The Composite-Role Case
- 14.2.4 Refusal Rather Than Partial Return
- 14.3 Version Control and Approvals
- 14.3.1 The PROCESS_VERSION Pin
- 14.3.2 The AS-OF Semantic
- 14.3.3 The Approval Chain
- 14.3.4 Worked Example: Approval
- 14.3.5 Freshness Budgets and Their One-Way Property
- 14.4 Grounding Rules and Constraints
- 14.4.1 Grounding as a Property of the Prepared Data Set
- 14.4.2 Manifest Signing and Immutability
- 14.4.3 The Citation Contract
- 14.4.4 Grounding Constraints: What May and May Not Be Bound
- 14.5 Preventing Hallucination and Drift
- 14.5.1 Hallucination Prevention as Structural Property
- 14.5.2 Drift as an Ongoing Concern
- 14.5.3 Drift Detection in Practice
- 14.5.4 A Worked Drift Detection Cycle
- 14.6 Summary
- 14.6.1 Key Learning Points
- 14.6.2 Common Design Pitfalls
- 14.6.3 Review Questions
- 14.6.4 Student Companion Notes
- 15 Generating Process Suggestions Using AI
- 15.1 Definition of Process Suggestions
- 15.1.1 The Suggestion Artifact
- 15.1.2 The Suggestion Table
- 15.1.3 The Suggestion Lifecycle
- 15.1.4 Enforcing the Stated AI Boundary
- 15.1.5 Where the Suggestion Pipeline Sits Operationally
- 15.2 Pattern Detection and Similarity Analysis
- 15.2.1 Worked Example: A Harmonization Suggestion
- 15.2.2 The Reference Corpus Is Itself a Governed Artifact
- 15.2.3 Failure Modes the Discipline Is Designed Against
- 15.3 Scoring and Prioritization Logic
- 15.3.1 The Four Factors in Detail
- 15.3.2 Worked Example: Scoring a Control-Gap Suggestion
- 15.3.3 Weights Are Configuration, Not Learning
- 15.3.4 Rescoring and the Stability Guarantee
- 15.4 Explainability and Traceability
- 15.4.1 The SUGGESTION_EXPLANATION Table
- 15.4.2 What the Validator Sees
- 15.4.3 The Explanation Under Adversarial Review
- 15.5 Human-in-the-Loop Validation
- 15.5.1 The VALIDATION_VERDICT Table
- 15.5.2 The Governed Commit Chain
- 15.5.3 Hybrid and Non-SAP Agents Submit Through the Same Path
- 15.5.4 What the Verdict Does Not Settle
- 15.6 Summary
- 15.6.1 Key Learning Points
- 15.6.2 Common Design Pitfalls
- 15.6.3 Review Questions
- 15.6.4 Student Companion Notes
- PART VIII SAP Build Consumption
- 16 SAP Build Process Automation: Workflow on Top of the Data Spine
- 16.1 Positioning SAP Build Process Automation on the Data Spine
- 16.1.1 Building Block and What Each Is Allowed to Do
- 16.1.2 Projects, Releases, and Why Versioning Lives in the Data Spine
- 16.1.3 Destinations, Identity, and the Single Write Path
- 16.2 Approval Workflows
- 16.2.1 Why the Trigger Is Keyed to the Accepted Suggestion, Not the Raw Suggestion
- 16.2.2 Deriving the Approver Chain from Process Context
- 16.2.3 Separation of Duties as a Structural Property
- 16.2.4 What the Approval Writes Back, and How
- 16.2.5 An Annotated Reference Approval Process
- 16.2.6 Approval Forms: What They Display and What They Must Never Collect
- 16.2.7 The Anatomy of a Verdict-Keyed Trigger
- 16.2.8 Risk Bands and the Shape of the Approver Chain
- 16.2.9 Worked Example: A Cross-Region Sequencing Change
- 16.2.10 Time, Escalation, and the Standing Approver Problem
- 16.3 Exception and Remediation Flows
- 16.3.1 An Exception Is a Typed, Severity-Banded Event
- 16.3.2 Three Governed Remediation Paths
- 16.3.3 Worked Example: A Failed Control-Gate Validation
- 16.3.4 The Exception Event Schema
- 16.3.5 Auto-Remediation Is a Governed Rule, Not a Code Path
- 16.3.6 The Remediation Case as a Data Spine Object
- 16.3.7 Reconciliation Between Workflow State and Data Spine Truth
- 16.3.8 Worked Example: Telemetry-Driven Remediation
- 16.4 AI-Assisted Recommendations
- 16.4.1 The Recommendation Is Advisory by Design
- 16.4.2 What the Recommendation Panel Must Carry
- 16.4.3 An Annotated Human Task Contract
- 16.4.4 The Verdict Records What the Human Did with the Advice
- 16.4.5 Why the Panel Cannot Prefill the Decision
- 16.4.6 Worked Example: A Recommendation Inside an Approval Task
- 16.4.7 Disposition Analytics: The Controller’s Earliest Signal
- 16.5 Governance and Audit Handling
- 16.5.1 Every Workflow Instance Is an Audit Row
- 16.5.2 The One-Query Reconstruction
- 16.5.3 Governance Exceptions Are First Class, Not Errors
- 16.5.4 What an Auditor Actually Asks, and the Answer’s Shape
- 16.5.5 Where Workflow State Lives, and Why It Matters for Audit
- 16.5.6 The Refusal Ledger
- 16.5.7 The Control Catalog: Mapping Workflow Controls to Audit Frameworks
- 16.5.8 Audit Handling Across Programs and Regions
- 16.5.9 One Change, End to End
- 16.6 Summary
- 16.6.1 Key Learning Points
- 16.6.2 Common Design Pitfalls
- 16.6.3 Review Questions
- 16.6.4 Student Companion Notes
- 17 SAP Build Work Zone: Process-Aware User Experiences
- 17.1 Positioning SAP Build Work Zone on the Data Spine
- 17.1.1 Components and What Each Is Allowed to Do
- 17.1.2 Why the Experience Layer Holds No Data
- 17.1.3 The Single Read Path and the Absent Write Path
- 17.1.4 What May Live in SAP Build Work Zone and What May Not
- 17.2 Process-Driven Navigation
- 17.2.1 Navigation Is a Query, Not a Menu
- 17.2.2 The Process-to-Space Mapping
- 17.2.3 Search Is a Scoped Projection, Not an Index
- 17.2.4 Worked Example: The Cost Center to Position Journey
- 17.2.5 Deep Links, Bookmarks, and the Stale URL Problem
- 17.3 Role-Based Task Views
- 17.3.1 A Task View Is a Role-Scoped Assembly
- 17.3.2 Where the Tasks Come From: SAP Build Process Automation
- 17.3.3 Separation of Duties Is Visible, Not Just Enforced
- 17.3.4 Delegation and Substitution Without Scope Escalation
- 17.4 Surfacing AI Insights
- 17.4.1 An Insight Is a Citation, Not an Answer
- 17.4.2 Joule in SAP Build Work Zone
- 17.4.3 The Insight Card Contract, Annotated
- 17.4.4 Multi-Suggestion Cards and the Comparison Trap
- 17.4.5 When the Bundle Is Stale: Insight Expiration and Regrounding
- 17.5 User Interaction Boundaries
- 17.5.1 The User Interface Offers Only What the Data Spine Would Permit
- 17.5.2 The Absent Control Is the Strongest Control
- 17.5.3 Break-Glass Is a Separate, Human-Authenticated Path
- 17.5.4 The Mobile and Offline Case
- 17.5.5 One Interaction, End to End: Across the Boundaries
- 17.6 Summary
- 17.6.1 Key Learning Points
- 17.6.2 Common Design Pitfalls
- 17.6.3 Review Questions
- 17.6.4 Student Companion Notes
- PART IX Operations, Security, and Extensibility
- 18 Operating the Integrated Platform
- 18.1 The Operating Model of the Integrated Platform
- 18.2 Monitoring and Observability
- 18.2.1 Three Signal Classes
- 18.2.2 The Golden Signals per Layer
- 18.2.3 Service-Level Objectives and the Error Budget
- 18.2.4 The Severity Model and On-Call Posture
- 18.2.5 Correlation: One Identity for Health and Evidence
- 18.2.6 The Observability Data Model
- 18.2.7 Dashboards as Operated Artifacts, Not Decoration
- 18.2.8 Worked Example: The Incident Response Lifecycle
- 18.3 Data Quality Management
- 18.3.1 Quality Is an Operated Property
- 18.3.2 The Steward Operating Model
- 18.3.3 The Quarantine Economy
- 18.3.4 AI as a Quality Pattern Detector and Its Boundary
- 18.3.5 The Validation Rule Lifecycle
- 18.3.6 Worked Example: Reconciliation Is the Engine of the Scorecard
- 18.4 Version Drift and Resynchronization
- 18.4.1 The Drift Taxonomy, Carried Forward
- 18.4.2 The Resynchronization Decision Flow
- 18.4.3 Drift Never Mutates in Place
- 18.4.4 Forensic Replay
- 18.4.5 Hot Restart and Regrounding
- 18.4.6 The Reconciliation Cadence, Operated
- 18.4.7 Snapshot Retention Economics
- 18.4.8 Worked Example: A Drift Event, End to End
- 18.5 Scaling Across Programs
- 18.5.1 Program Tenancy on Resource Groups
- 18.5.2 Multiregion Topology and Jurisdiction-Bounded Replication
- 18.5.3 The Program Onboarding Lifecycle
- 18.5.4 Verifying Tenant Isolation
- 18.5.5 Scaling the AI Tier
- 18.5.6 The Federated Team and Its Accountabilities
- 18.5.7 Work Example: Cost Lineage and the AI Tier as a Controllable
- 18.6 Summary
- 18.6.1 Key Learning Points
- 18.6.2 Common Design Pitfalls
- 18.6.3 Review Questions
- 18.6.4 Student Companion Notes
- 19 Security, Controls, and Audits
- 19.1 Data Access and Authorization
- 19.1.1 Identity Is the First Control, Not a Prerequisite to It
- 19.1.2 Defense in Depth as an Architectural Property
- 19.1.3 The Authorization Vocabulary: Scopes Bound to Canonical Operations
- 19.1.4 The Four Canonical Operations in Detail
- 19.1.5 Worked Example: An AI Agent Reaches Its Boundary
- 19.1.6 Role-Based Segmentation of the Data Spine
- 19.1.7 AI Agents as Named Actors
- 19.1.8 Worked Example: A Data Residency Question
- 19.2 Control Effectiveness
- 19.2.1 Effectiveness Is Design Adequacy Multiplied by Operating Evidence
- 19.2.2 The Three Control Classes
- 19.2.3 Why the Refusal Ledger Is the Most Valuable Evidence
- 19.2.4 The Control Catalog as a Generated Register
- 19.2.5 The Dimensions of a Catalog Entry
- 19.2.6 Worked Example: Evidencing a Preventive Control Over a Quarter
- 19.2.7 Effectiveness Is a Property of the Architecture, Not the Effort
- 19.3 Audit Trails and Evidence
- 19.3.1 The Hash-Chained Audit Event
- 19.3.2 Lineage as a First-Class Query Path
- 19.3.3 What the Auditor Actually Asks
- 19.3.4 Worked Example: The Controller Variance Question, Step by Step
- 19.3.5 Worked Example: Forensic Replay of a Past Decision
- 19.3.6 Retention, Anchoring, and Forensic Replay
- 19.4 Compliance Considerations
- 19.4.1 Obligation, Control, Evidence
- 19.4.2 Why Mapping to Queries Rather Than Binders Matters
- 19.4.3 Worked Example: Decomposing a Compliance Obligation
- 19.4.4 Why the Same Mechanisms Satisfy Independent Regimes
- 19.4.5 Jurisdiction, Residency, and Multiregion Compliance
- 19.4.6 The Compliance Posture Is Continuous, Not Periodic
- 19.5 Summary
- 19.5.1 Key Learning Points
- 19.5.2 Common Design Pitfalls
- 19.5.3 Review Questions
- 19.5.4 Student Companion Notes
- 19.6 Conclusion: The Integrated, AI-Ready Enterprise
- The Author
- Index
