SAP Build Process Automation

El trabajo en SAP Build Process Automation se organiza en proyectos:

1. Un creador crea un proyecto de proceso de negocio en el SAP Build lobby.
2. Dentro del proyecto, el creador modela un proceso y añade artefactos: formularios y formularios de aprobación para las personas, tablas de decisión para las reglas, automatizaciones para el trabajo repetitivo de escritorio o de sistema, acciones que llaman a API, y subprocesos.
3. Un desencadenante inicia el proceso: un formulario, una llamada a una API, un evento de negocio, una planificación o una cola.
4. El creador libera el proyecto, lo que crea una versión numerada, y despliega esa versión para ejecutarla en productivo. Las versiones pueden transportarse entre tenants con SAP Cloud Transport Management.
5. En tiempo de ejecución, las personas reciben sus tareas en My Inbox en SAP Build Work Zone o en SAP Task Center, y las automatizaciones se ejecutan en un agente de escritorio en modo asistido o desatendido.
6. Las herramientas de supervisión y los escenarios de visibilidad muestran el estado de las instancias de proceso.

SAP Build Process Automation convierte un proceso en un artefacto desplegable y versionado en SAP BTP.

SAP Build Process Automation consolidó en 2022 dos servicios anteriores de SAP BTP: SAP Workflow Management y SAP Intelligent Robotic Process Automation. Desde entonces, SAP ha discontinuado SAP Intelligent RPA, y ambos motores siguen vivos dentro del nuevo servicio con una experiencia de usuario rediseñada. Los workflows construidos con la anterior funcionalidad de workflow pueden seguir ejecutándose y reutilizarse como subprocesos, de modo que los clientes existentes pueden migrar a su propio ritmo. Algunos documentos de SAP todavía usan el nombre anterior SAP Process Automation. Desde abril de 2025, SAP Build Process Automation también se ofrece como parte de SAP Build con el plan de servicio build-default. El material más antiguo describe los mismos conceptos bajo SAP Workflow Management y su "workflow capability", un nombre que todavía aparece en la documentación de integración de SAP Build Process Automation.

• Varios estilos de automatización en una herramienta: los workflows humanos, los formularios, las tablas de decisión, los bots y la visibilidad de procesos comparten un proyecto y un ciclo de vida.
• Low-code para equipos mixtos: los business technologists inician un proceso y los desarrolladores profesionales pueden añadir acciones y lógica avanzada al mismo proyecto.
• Diseñado para la integración con SAP: el contenido predefinido, las acciones basadas en API de SAP, los desencadenantes por eventos y la conectividad nativa desde SAP S/4HANA reducen el esfuerzo de integración.
• Encaje con clean core: los procesos se ejecutan side-by-side en SAP BTP, de modo que el ERP queda libre de la lógica de la extensión.
• Gestión real del ciclo de vida: los estados editable, liberado y desplegado, las versiones semánticas y los transportes dan a los procesos construidos por citizen developers el mismo control de cambios que al resto del software desplegado.

Para los procesos que abarcan varios sistemas o amplían el estándar de SAP en SAP BTP, SAP Build Process Automation es la opción low-code propia de SAP.

• Un runtime separado. Los procesos se ejecutan en SAP BTP, no dentro de SAP S/4HANA. Cada interacción con documentos de negocio pasa por destinos, communication arrangements, API o eventos que alguien debe configurar y mantener.
• Las licencias condicionan el diseño. Los participantes y los diseñadores necesitan entitlements de usuario distintos, y los escenarios con uso intensivo de API o de gran volumen pueden requerir cuota adicional de llamadas a API o de almacenamiento.
• Los bots dependen de la pantalla. Las automatizaciones de escritorio dependen de las interfaces de usuario que manejan, de modo que los cambios de UI requieren mantenimiento de los bots.
• La visibilidad cubre lo que está instrumentado. Los escenarios de visibilidad muestran los eventos que envían los sistemas participantes; los pasos que no envían nada quedan a oscuras.
• La gobernanza es tarea del cliente. El low-code reduce la barrera de entrada; la responsabilidad, la nomenclatura, la reutilización y la retirada de proyectos siguen necesitando reglas.
• Cobertura de centros de datos. El servicio se ejecuta en los centros de datos que SAP indica para él, y las funciones de IA generativa en un subconjunto menor, así que revise la lista antes de elegir la región de una subcuenta.

Estos límites se derivan del diseño: SAP Build Process Automation es un servicio de plataforma que amplía los sistemas SAP desde fuera.

SAP documenta varias vías de integración:

• Iniciar y controlar desde el lado ABAP: SAP S/4HANA, incluida Cloud Public Edition mediante un communication arrangement, puede llamar a una API para iniciar y controlar instancias de proceso en SAP BTP.
• Integrar en SAP Business Workflow: en la plataforma ABAP, una tarea estándar genérica pasa un paso a SAP Build Process Automation y espera a que se complete.
• Eventos de negocio: el asistente de extensibilidad de SAP S/4HANA Cloud vincula un evento de negocio de una aplicación estándar a un proceso, que se inicia cada vez que se produce el evento.
• Acciones: los proyectos de acciones llaman a API de SAP S/4HANA, por ejemplo servicios OData, desde los pasos del proceso.

Elegir la vía de integración de SAP Build Process Automation es una decisión de diseño en sí misma, porque determina dónde se inicia el proceso y qué sistema contiene la verdad sobre su estado.

Aplique una prueba sencilla: ¿dónde reside el proceso?

Un error habitual es reconstruir en SAP BTP una aprobación entregada: el estado del documento, la lógica de contabilización y la pista de auditoría pasan entonces a residir en dos lugares. El error contrario es forzar un proceso entre sistemas dentro de un único workflow de back-end. SAP Build Process Automation encaja mejor allí donde ningún sistema SAP es responsable del proceso completo.