Construimos flujos, agentes IA y aplicaciones dentro de SAP

En SAP Build actual, la diferencia se define por roles y capacidades habilitadas. Un base user suele consumir apps, workspaces y tareas. Un premium user suma funciones de authoring, administración o monitoreo según el servicio activo, por ejemplo en Work Zone, Apps o Process Automation. Un SAP Build developer agrega herramientas de desarrollo y despliegue, incluyendo BAS y roles técnicos. Si el caso usa Joule Studio, además se requiere tenant y entitlements específicos.

La referencia general en SAP Build es por usuario identificado y medido como active user. SAP factura según el rol más alto usado por cada persona durante el mes. Para un piloto o despliegue interno, la planificación de licencias conviene hacerla por usuario asignado. Existen escenarios puntuales con otras métricas, por ejemplo algunas conexiones externas en Work Zone estándar, por lo que siempre revisamos el servicio específico antes de confirmar el esquema final.

Incluyen relevamiento del caso, análisis funcional y técnico inicial, chequeo de prerequisitos, definición del escenario piloto, construcción o adaptación de una demo, una iteración breve con feedback y una devolución final con hallazgos y próximos pasos. En la propuesta actual, ese bloque inicial contempla 70 horas del primer mes para ordenar, construir evidencia y decidir continuidad.

Puede hacerlo KOR o puede hacerlo el cliente con nuestra guía. Técnicamente, en SAP Build Process Automation y otros escenarios de SAP Build, las conexiones se administran en SAP BTP cockpit mediante destinations y roles de conectividad. Si KOR las configura directamente, necesitamos acceso técnico suficiente. Si el cliente prefiere no abrir ese acceso, trabajamos acompañando, documentando y validando lo que ejecute su equipo interno.

Para la etapa de descubrimiento y definición del caso no siempre. Para construir una demo conectada o validar técnicamente el escenario, sí hace falta al menos acceso guiado al tenant donde corre SAP Build, a la subcuenta correspondiente y a la información necesaria sobre destinations, autenticación y sistemas fuente. Sin ese contexto técnico, solo se puede avanzar en una definición preliminar o en una demo más desacoplada.

La práctica recomendada es construir en development, validar en test y recién después promover a producción. SAP documenta transporte entre tenants o subcuentas para Build Apps y Process Automation usando SAP Cloud Transport Management y servicios asociados. Eso significa que el trabajo no termina cuando la demo funciona en dev: también hay que preparar transporte, validar en cada ambiente y revisar dependencias técnicas antes de pensar en productivo.

En la mayoría de los casos, sí. Aunque parte del contenido pueda transportarse, cada ambiente suele necesitar sus propias destinations, credenciales, URLs o validaciones porque apunta a tenants o sistemas distintos. SAP también documenta destinos específicos por tenant objetivo en Work Zone y contenido transportado entre entornos. En términos de esfuerzo, esto impacta horas de setup técnico en DEV, TEST y eventualmente PROD.

Incluye análisis aplicado, validación de prerequisitos y demos funcionales dentro del alcance acordado. Si después del piloto se decide avanzar hacia testing formal, transporte y productivo, esa etapa requiere alcance adicional, licencias confirmadas, accesos técnicos y un nuevo bloque de trabajo. El piloto sirve para tomar esa decisión con evidencia funcional y técnica.

Depende del producto y del esquema de IA contratado por el cliente. SAP distingue Base AI y Premium AI. Base AI incluye capacidades básicas dentro de suscripciones cloud elegibles; Premium AI agrega capacidades avanzadas y puede cobrarse por usuario o por consumo según la función. Antes de definir alcance, revisamos la suscripción, el tenant y los entitlements activos para confirmar qué capacidades de Joule están realmente disponibles.

Sí, siempre que exista una necesidad de negocio clara y un sponsor para priorizar el caso. Se puede iniciar la etapa de análisis, ordenar opciones y hasta definir una demo objetivo aunque el landscape todavía esté en definición. La demo conectada y cualquier despliegue formal requieren confirmar tenant, accesos, licencias y sistema fuente. El primer mes ayuda justamente a cerrar esas definiciones.