SAP lleva años enfrentando una paradoja conocida por prácticamente cualquier organización que haya adaptado profundamente su ERP: cuanto más se personaliza el sistema para responder a las particularidades del negocio, más difícil puede resultar mantenerlo, actualizarlo y evolucionarlo.
Una parte de la respuesta estratégica de SAP a este problema es clean core, un enfoque que busca mantener el ERP preparado para evolucionar reduciendo modificaciones difíciles de mantener y favoreciendo mecanismos de extensibilidad e integración desacoplados.
Zoho está planteando una propuesta interesante alrededor de esa misma necesidad: utilizar Zoho Creator como plataforma low-code para construir aplicaciones conectadas con SAP sin trasladar necesariamente cada personalización al núcleo del ERP.
La posibilidad técnica existe. La cuestión relevante es otra: ¿puede Zoho Creator funcionar realmente como una capa de extensión de SAP compatible con los principios de clean core, o simplemente traslada la complejidad de un lugar a otro?
La documentación disponible apunta a una respuesta matizada.
Qué significa realmente “no tocar el core”
Clean core no significa operar SAP sin ninguna personalización.
SAP describe clean core como un enfoque para mantener el ERP ágil y preparado para evolucionar, reduciendo los problemas asociados con código personalizado y modificaciones difíciles de mantener. Entre sus principios se encuentran la extensibilidad desacoplada del core y el uso de APIs modernas para integración.
Esto cambia el problema arquitectónico. En lugar de preguntarnos simplemente si SAP puede personalizarse, necesitamos decidir dónde debe vivir cada personalización.
SAP contempla distintos mecanismos de extensibilidad dependiendo del requerimiento. En S/4HANA Cloud distingue, entre otras alternativas, extensiones para usuarios clave, extensibilidad de desarrollo y extensibilidad side-by-side. Esta última permite construir aplicaciones y extensiones desacopladas del ERP.
SAP promueve su propio Business Technology Platform (BTP) como entorno para este tipo de arquitectura y recomienda utilizarlo para determinadas extensiones complejas.
Este punto es esencial para evaluar a Zoho Creator con rigor. Creator puede perseguir un principio arquitectónico similar —desacoplar determinadas aplicaciones del core—, pero eso no convierte automáticamente una implementación con Creator en una arquitectura clean core recomendada o certificada por SAP. Son afirmaciones distintas.
Lo que Zoho propone alrededor de SAP
Zoho presenta actualmente Creator como una plataforma para modernizar entornos SAP mediante aplicaciones conectadas.
Su propuesta contempla construir nuevas aplicaciones conectadas con SAP, extender funcionalmente aplicaciones existentes y reemplazar aplicaciones heredadas que interactúan con el ERP. También plantea casos relacionados con manufactura, inventarios, recursos humanos, finanzas, ventas, aplicaciones móviles y portales para clientes, socios y proveedores.
Alrededor de S/4HANA, Zoho propone trasladar determinadas personalizaciones a Creator para facilitar la evolución del entorno y mantener el núcleo SAP más limpio.
Conceptualmente, esto permitiría que la experiencia o aplicación específica del negocio viva en Zoho Creator, mientras SAP conserva las funciones y transacciones que corresponden al ERP. La diferencia frente a incorporar toda la experiencia, personalización y lógica específica dentro de SAP puede ser significativa.
Sin embargo, Creator no es una única pieza tecnológica. Para comprender hasta dónde puede llegar esta arquitectura es necesario introducir un componente que a veces queda escondido detrás de la etiqueta low-code: Deluge.
Deluge: donde low-code deja de significar “sin código”
Deluge —Data Enriched Language for the Universal Grid Environment— es el lenguaje de scripting de Zoho.
Zoho Creator permite construir formularios, interfaces, estructuras de datos y workflows mediante herramientas visuales. Cuando el comportamiento requerido se vuelve más específico, Deluge permite incorporar lógica, automatización e integración.
Esta capacidad cobra especial importancia cuando SAP entra en la arquitectura. Deluge puede utilizarse para validar y transformar información, aplicar reglas, ejecutar workflows, consultar y actualizar datos y consumir servicios externos mediante APIs.
Creator dispone además de Connections, una capa para gestionar autenticación y autorización frente a servicios externos. Estas conexiones pueden utilizarse desde las funciones de integración y mediante invokeUrl en Deluge.
Una arquitectura posible podría, por tanto, seguir una secuencia como aplicación Creator → workflow → Deluge → Connection/API → SAP.
Esto amplía considerablemente lo que puede hacerse con Creator, pero también revela uno de los límites de la etiqueta low-code: reducir la cantidad de código que un equipo necesita escribir no elimina la arquitectura de integración. Siguen existiendo contratos de API, autenticación, permisos, transformaciones, manejo de errores, dependencias, observabilidad y gobierno del ciclo de vida.
Zoho Flow abre otra ruta de integración
Deluge tampoco tiene que resolver todas las integraciones.
Zoho ofrece Zoho Flow como plataforma de integración y automatización entre aplicaciones, y publica integraciones relacionadas tanto con SAP S/4HANA como con SAP HANA.
En el caso de Zoho Creator y SAP S/4HANA, la documentación pública de Flow muestra triggers provenientes de Creator y acciones relacionadas con objetos de negocio de S/4HANA. Flow incorpora además webhooks, lógica condicional y funciones personalizadas.
Esto permite considerar una arquitectura Zoho Creator → Zoho Flow → SAP S/4HANA, además de configuraciones híbridas donde Creator, Deluge, Flow y APIs participen según las características del proceso.
La decisión entre estas alternativas no debería depender únicamente de cuál herramienta permita construir una demostración con mayor rapidez. Volumen, criticidad, latencia, complejidad de transformación, recuperación ante errores, trazabilidad y responsabilidad operativa son factores más relevantes para una integración de producción.
SAP HANA no es lo mismo que SAP S/4HANA
La distinción es importante porque Zoho Flow también publica una integración con SAP HANA y documenta operaciones relacionadas con filas y tablas.
Pero SAP HANA y SAP S/4HANA no son términos intercambiables. HANA es una plataforma de base de datos sobre la que, entre otras soluciones, funciona S/4HANA. S/4HANA es un ERP con sus propios objetos de negocio, procesos, reglas y mecanismos de integración.
Que una herramienta pueda acceder a datos relacionados con HANA no implica que esa deba ser la ruta para ejecutar cualquier proceso transaccional de S/4HANA. La interfaz debe elegirse de acuerdo con el objeto y proceso de negocio, no simplemente según el lugar donde residan físicamente los datos.
La existencia de una integración específica de Zoho Flow para S/4HANA refuerza precisamente esa distinción.
¿Dónde podría tener sentido colocar Creator?
La documentación de SAP sobre extensibilidad side-by-side ayuda a identificar escenarios donde una plataforma externa puede tener sentido. SAP contempla patrones como aplicaciones de conveniencia, aplicaciones sustitutas, preprocesamiento, postprocesamiento y aplicaciones analíticas que pueden consumir APIs o eventos mientras funcionan de manera desacoplada del ERP.
Desde esa perspectiva, existen varios escenarios donde vale la pena evaluar Zoho Creator.
Experiencias de usuario específicas
Una organización puede necesitar una aplicación para técnicos, distribuidores, proveedores, personal de campo u otros usuarios cuya experiencia no justifique construir toda la interfaz dentro de SAP. Creator puede proporcionar esa capa de experiencia mientras SAP conserva el procesamiento transaccional que corresponda.
Procesos periféricos al ERP
Solicitudes, capturas, aprobaciones y otros procesos departamentales pueden comenzar fuera de SAP y terminar generando una operación dentro del ERP. En estos escenarios, Creator puede funcionar como capa de proceso y experiencia sin necesidad de trasladar toda la lógica al núcleo.
Aplicaciones que combinan SAP con otros sistemas
Una aplicación puede necesitar información procedente de SAP, CRM, fuentes externas y datos propios. Creator contempla expresamente aplicaciones conectadas y compuestas capaces de combinar sistemas SAP y no SAP. Este escenario puede resultar particularmente relevante cuando la necesidad de negocio rebasa las fronteras funcionales de un solo sistema.
Sustitución de aplicaciones heredadas
Una aplicación antigua que existe únicamente para conectar un proceso específico con SAP puede ser candidata para reconstruirse sobre una plataforma low-code. Éste es también uno de los escenarios que Zoho propone expresamente para Creator.
Aplicaciones móviles y portales
Los casos de campo, proveedores, clientes o colaboradores externos pueden beneficiarse de una capa diseñada específicamente para su experiencia, mientras SAP continúa siendo responsable de las transacciones que deben permanecer dentro del ERP.
El riesgo de construir un “SAP paralelo”
Desacoplar no significa duplicar indiscriminadamente.
Una arquitectura mal diseñada podría terminar copiando maestros de clientes, productos, inventarios, precios, órdenes y estados en Creator sin establecer claramente cuál es la fuente autoritativa. En ese momento, el problema deja de ser únicamente tecnológico y aparece una cuestión fundamental de gobierno del dato: cuál de los sistemas contiene la verdad para cada objeto de negocio.
La respuesta debe establecerse objeto por objeto y proceso por proceso. Es necesario determinar quién crea el dato, quién puede modificarlo, quién lo valida, dónde vive la transacción oficial, cómo se comporta el proceso cuando falla una integración, cómo se evitan operaciones duplicadas y qué sistema conserva el historial necesario para auditar lo ocurrido.
Sin estas definiciones, sacar código del ERP no necesariamente reduce la deuda técnica. Puede simplemente distribuirla entre más componentes.
Clean core no equivale a “todo afuera”
La propia estrategia de SAP no prescribe que toda extensión deba abandonar el ERP.
SAP diferencia los mecanismos de extensibilidad según las características del requerimiento. Determinados cambios pueden resolverse mediante opciones low/no-code; nueva lógica de negocio puede requerir desarrollo profesional o extensiones side-by-side; y existen situaciones en las que ciertas capacidades necesitan permanecer dentro del entorno SAP.
Por ello, la posibilidad de construir algo en Creator no constituye por sí misma una razón arquitectónica suficiente para hacerlo allí. La decisión debe comenzar por el proceso, sus dependencias, su criticidad y su ciclo de vida.
La prueba decisiva: reducir complejidad o trasladarla
Supongamos que una empresa reemplaza una personalización SAP por una aplicación desarrollada en Creator. El core podría quedar menos intervenido, pero la organización incorpora ahora una aplicación adicional, permisos, integraciones, mappings, automatizaciones, posiblemente código Deluge, Flows, gestión de errores, dependencias de APIs y quizá datos replicados.
Esto no invalida la arquitectura. Demuestra que clean core y simplicidad arquitectónica no son sinónimos.
Una extensión externa puede mejorar considerablemente la mantenibilidad del ERP y, al mismo tiempo, aumentar la superficie total de integración. Por eso la evaluación no debería limitarse a contar cuántas personalizaciones desaparecieron de SAP. Debe comparar el costo, riesgo, flexibilidad y mantenibilidad del ciclo de vida completo de ambas alternativas.
Deluge debe gobernarse como código
También sería un error tratar Deluge como si no pudiera generar deuda técnica por pertenecer a una plataforma low-code.
Un script que contiene una regla crítica del negocio sigue siendo software.
Si una aplicación Creator conectada con SAP utiliza Deluge para transformar órdenes, aplicar condiciones, determinar estados o decidir qué información enviar al ERP, esa lógica necesita documentación, pruebas, manejo de excepciones, control de cambios y responsables.
La misma disciplina aplica a las automatizaciones creadas mediante Flow. La facilidad para construirlas puede acelerar una implementación, pero también puede acelerar la proliferación de lógica distribuida si no existe una arquitectura clara.
La ventaja del low-code aparece cuando reduce la fricción de construcción sin reducir la disciplina de ingeniería.
Entonces, ¿es Zoho Creator una alternativa viable?
La evidencia disponible permite sostener que Zoho Creator es una alternativa técnicamente plausible para determinadas extensiones externas alrededor de SAP.
La propuesta coincide conceptualmente con uno de los principios asociados con clean core: desacoplar determinadas extensiones del estándar del ERP y conectarlas mediante interfaces definidas. Zoho ofrece Creator para construir esas aplicaciones, Deluge para incorporar lógica e integración personalizada y Flow para determinados escenarios de integración.
Sin embargo, de la evidencia disponible no se desprende que utilizar Creator convierta automáticamente una solución en una implementación clean core conforme a las recomendaciones arquitectónicas de SAP. SAP mantiene su propio ecosistema de extensibilidad e integración, incluyendo BTP y sus mecanismos asociados.
Por eso, plantear la decisión como Zoho Creator contra SAP resulta poco útil. La pregunta arquitectónica es qué capacidades deben permanecer en el ERP, cuáles conviene desacoplar y qué plataforma ofrece la combinación adecuada de velocidad, mantenibilidad, integración, gobierno, riesgo y costo para cada extensión.
En algunas organizaciones la respuesta será una tecnología del propio ecosistema SAP. En otras, Creator puede resultar especialmente interesante cuando ya existe un ecosistema Zoho, cuando se necesitan aplicaciones departamentales o externas con rapidez, cuando deben combinarse fuentes SAP y no SAP o cuando construir determinadas experiencias dentro del entorno SAP no se justifica.
También existirán procesos donde sacar la lógica de SAP sea una mala decisión.
Siete preguntas antes de construir
- ¿Qué proceso queremos extender y por qué no debe resolverse mediante funcionalidad estándar de SAP?
- ¿SAP seguirá siendo el sistema de registro para los objetos involucrados?
- ¿Qué API, evento o interfaz soportada utilizará la integración?
- ¿La orquestación pertenece en Deluge, Zoho Flow, middleware SAP u otra capa?
- ¿Qué sucede cuando alguno de los sistemas no está disponible?
- ¿Cómo se monitorean, recuperan y auditan las transacciones fallidas?
- ¿La arquitectura disminuye realmente la deuda técnica a lo largo de varios ciclos de actualización?
Cuando estas respuestas son sólidas, low-code puede representar algo más que desarrollar aplicaciones rápidamente: puede convertirse en una estrategia válida para desacoplar determinadas capacidades del ERP manteniendo fronteras claras entre sistemas.
Cuando no lo son, “no tocar el core” corre el riesgo de convertirse simplemente en una nueva forma de acumular complejidad fuera de él.
Fuentes
- SAP: documentación sobre clean core y extensibilidad.
- Zoho Creator: extensión de SAP con Creator.
- Zoho Deluge: documentación oficial.
- Zoho Flow: integración Zoho Creator y SAP S/4HANA.
- Zoho Flow: integración Zoho Creator y SAP HANA.
Nota metodológica: las afirmaciones comerciales de los proveedores se utilizan como evidencia de las capacidades que éstos declaran ofrecer, no como prueba independiente de resultados reproducibles en cualquier organización.
