John Ezzell, vicepresidente ejecutivo del proveedor de servicios gestionados BIAS Corp., comparte los factores clave a la hora de decidir qué módulos de ERP trasladar a SaaS y explica las ventajas de la pila de Oracle en la nube.
Cualquiera que se plantee una migración a la nube de Oracle debe sopesar las ventajas y desventajas de pasar de un ERP local a un SaaS multi-inquilino, o a alguna forma híbrida de nube que siga ofreciendo muchas de sus ventajas, como la escalabilidad, la flexibilidad y el menor costo.
Pero con Oracle invirtiendo miles de millones en su pila en la nube y actualizándola con frecuencia, se plantea otra cuestión: ¿Deberían las aplicaciones de Oracle ejecutarse también en Oracle Cloud Infrastructure (OCI)?
Para obtener respuestas, pedí a John Ezzell, cofundador y vicepresidente ejecutivo de BIAS Corp., que compartiera su experiencia con la migración a la nube de Oracle y la OCI. Con sede en Roswell (Georgia), BIAS ofrece servicios de migración a la nube de Oracle y servicios gestionados para el ERP local y otros tipos de nube, incluida la nube privada. BIAS es un socio de Oracle entre cuyos clientes se encuentran Wells Fargo, Office Depot y los gobiernos federales y estatales de Estados Unidos.
¿Quién necesita OCI?
Oracle parece ciertamente orgullosa de su nube, probablemente con razón. OCI se extiende desde la capa base de servidores bare-metal, máquinas virtuales y almacenamiento, hasta la base de datos de Oracle, la conectividad de red, la seguridad, las herramientas de desarrollo y el middleware. Las tecnologías emergentes, como la IA y el blockchain, también forman parte de ella.
Luego están las aplicaciones ERP SaaS multi-inquilino, especialmente Oracle Fusion Cloud ERP. Muchos observadores, incluida la firma de investigación Gartner, lo consideran el ERP SaaS más amplio y funcional en una industria que ha luchado por reescribir los sistemas locales heredados para la nube.
Según muchos informes, incluido el de Oracle, estas aplicaciones SaaS no son técnicamente parte de la OCI. Las empresas también pueden ejecutarlas en uno de los dos hiperescaladores de nube pública –y competidores de OCI–: Amazon Web Services (AWS) y Microsoft Azure. A la inversa, pueden ejecutar ERP de otros proveedores en OCI, aunque la oferta de hiperescala de Oracle es sustancialmente menos popular que las tres grandes de AWS, Azure y Google Cloud Platform.
Ezzell dijo que la mayoría de las implementaciones de Oracle sobre Oracle son para clientes que tienen un sistema ERP de Oracle –por ejemplo, JD Edwards o PeopleSoft– y quieren «un cuello que abrazar», dijo, utilizando una versión más humana de la vieja expresión sobre las virtudes de un solo proveedor. Los entornos de servidores de aplicaciones en clúster y el software desarrollado con el lenguaje de programación Java de Oracle también deberían ejecutarse en OCI, en opinión de Ezzell.
¿Pero no hay ocasiones en las que tiene sentido no comprar la pila OCI y limitarse a utilizar las aplicaciones SaaS de Oracle? Ezzell dijo que esto puede suceder cuando las «aplicaciones basadas en el borde» de otros proveedores de la nube son una parte clave de la mezcla, como la búsqueda de Google, o una importante aplicación SaaS como Salesforce, ServiceNow o Workday, tal vez junto a Oracle Cloud Financials.
Se trata de un entorno multinube, que conlleva sus propios problemas, especialmente de integración. Pero la multinube es cada vez más fácil porque los proveedores de SaaS han reducido los costos de la transferencia de datos y cooperan más, en parte exponiendo sus API, dijo Ezzell. También existen pasarelas multinube de proveedores de red como Equinix, socio de BIAS, que funcionan casi como firewalls para añadir aplicaciones plug-and-play.
Mitigar las desventajas del SaaS
El ERP SaaS multi-inquilino suele ser más genérico que el local y a menudo menos rico en funciones. Por lo general, las empresas deben estar dispuestas a deshacerse de sus personalizaciones de ERP, pero los proveedores suelen decir que a cambio obtienen las mejores prácticas del sector que están programadas en la aplicación SaaS.
¿A qué más se renuncia? El control de sus propios ciclos de actualización y la coordinación de los parches entre las aplicaciones terciarias, dijo Ezzell. «Pero sí tienes la oportunidad de hacer un análisis de las deficiencias y evaluar realmente todas esas personalizaciones que has desarrollado a lo largo de los años».
Muchas organizaciones deciden que la compensación vale la pena. Están dispuestas a renunciar a la «naturaleza a medida» de sus aplicaciones personalizadas a cambio de la capacidad de conectar diferentes aplicaciones que les ayuden a ser más ágiles en su negocio, dijo.
Pero incluso la falta de personalización asociada al SaaS multi-inquilino está empezando a marchitarse.
«Puede que esa funcionalidad ya esté incorporada en la aplicación, por lo que no hay que volver a preocuparse por ese parche», dijo Ezzell.
Las empresas podrían conformarse con obtener el 80 % de lo que tenían y buscar el 20 % restante en una capa de integración y desarrollo de OCI de plataforma como servicio (PaaS). «Con el tiempo, cuando esa funcionalidad se convierta en algo intrínseco al producto SaaS, podré cerrar esa [extensión PaaS]. Ese es el objetivo final», dijo.
Las antiguas y complejas aplicaciones personalizadas se están modernizando, y sus funciones se integran en el SaaS o se programan en las herramientas de desarrollo de bajo código que ofrecen cada vez más los proveedores de ERP.
«Eso nos está permitiendo, desde la perspectiva de PaaS, integrarnos en esas aplicaciones de bajo código y consolidar la funcionalidad de esas aplicaciones en un número cada vez menor», dijo Ezzell. «No son tan costosas de mantener como las aplicaciones personalizadas tradicionales. Empezará a verlas encenderse y apagarse en lugar de crear una aplicación personalizada y mantenerla durante décadas».
Por David Essex
-
-
-
-
