¿Integras o implementas?: esa es la cuestión

En la entrada de ayer veíamos cómo Upgrade2Success nos da una serie de pautas para facilitar la transición de mis sistemas HCM on-premise al cloud, algo que probablemente haga de forma paulatina y durante un tiempo (o siempre) tenga que trabajar con un modelo híbrido, combinando información de los dos mundos.

Y ya sabéis, que entre el suelo y el cielo hay algo y que el secreto no está en la masa. Para que todo esto funcione, hay una cuestión clave: la integración.

SuccessFactors, Ariba, Concur, Fieldglass, Hybris… alguna más y lo que quede por venir, son soluciones cloud que SAP ha ido adquiriendo en los últimos año. Soluciones que nacieron cloud y se diseñaron con esa filosofía.

Por otro lado, SAP ha ido transformando la compañía para convertirse en una compañía cloud… lo que no quiere decir que todo tenga que ser cloud, pero sí que puedes tener la posibilidad de tener el ERP en cloud (HANA Enterprise Cloud), suscribirte a una edición de S/4HANA Cloud, tener una plataforma de desarrollo de aplicaciones propia como SAP Cloud Platform, etc…

Aún así, muchos clientes quieren permanecer con los pies en la tierra, como es lógico o ir haciendo esa transición poco a poco. Lo que es evidente es que si quieres seguir avanzando con SAP, algo te vas a tener que llevar al cloud, sí o sí.

Esto nos debería llevar a conocer cómo funcionan esos 2 mundos. Se supone que la parte on-premise ya la conocemos (es mucho suponer a veces) y que con la parte cloud «estamos trabajando en ello» (que esto es suponer mucho más)… y en medio de ambos mundos, tendrá que haber algo para que se entiendan, que podríamos llamar intermediario, relator o algo así… bueno, no, mejor integrador, que luego la cosa se lía… 😉

Imaginemos que tengo un gran equipo de implementadores de soluciones on-premise y otro de todas estas «nuevas» soluciones cloud, si cada uno implementa lo suyo a su aire, sin tener en cuenta las necesidades del otro, ¿pensáis realmente que eso va a terminar funcionando como debería?

Me temo que no, como no tenga alguien que sea capaz de integrar la información entre ambos mundos, me veré abocado a duplicar datos, soportar incongruencias, tener procesos que se solapan, etc…

Todo esto viene a raíz de este artículo que he leído: Integrators who don’t ‘integrate’ and other ERP problems

En dicho artículo, analizan una serie de puntos a tener en cuenta, a la hora de seleccionar un posible proveedor a la hora de acometer un proyecto de este tipo. Merece la pena leerlo, pero aquí os dejo alguna de las conclusiones:

«Software buyers should independently source implementation services and not rely on the ‘partners’ referred to them by software vendors. Of all the deals I’ve seen in 2018 and 2019, no client accepted these service firms and their proposals. Vendors don’t necessarily pick the provider that’s right for your firm. They pick service providers who hired their brother-in-law, who invited them to the Super Bowl, who kick back fees into some joint marketing slush fund, etc. Go ahead and ask a vendor “Exactly how did you come to choose this particular implementer for us?” Prepare to be lied to.»

En España no tenemos Super Bowl, pero tenemos otras cosas y, por supuesto, tenemos cuñados… eso en todos los países 😉

«Don’t be afraid to shun the big firms and go direct with specialists and independents. Many of my clients have gone this route and have saved lots of money, time & aggravation. Remember, you need to buy the people not the brand on this kind of work».

Aunque ya sabemos que las empresas confían en empresas y las personas confían en personas, los proyectos los hacen personas, no los logos.

«Get help developing the services RFP. Yes, you’ll want your in-house counsel and procurement folks involved. But getting an outside specialist in, for example, cloud implementation contracts, could be a real game changer. Cloud contracts are very different from the on-premises arrangements you are quite used to reviewing

He visto RFPs recientes que eran un «corta-pega» de la que sacaron hace 15 años… claro, como las cosas no han cambiado. Si no sabes lo que quieres, ¿por qué no pides ayuda? Y muchas veces no es lo que quieres, es lo que necesitas. No te preguntes el «qué», pregúntate el «para qué».

«Consider using an independent third party to provide quality assurance. Many integrators like to provide their own people to do this role; however, it is a role rife with potential conflicts of interest (e.g., letting the prisoners guard themselves). While it might work with the better implementers, wouldn’t you really want an impartial view of things?»

Los negocios no se van a parar. Es decir, cuando tengas que asumir el proceso de transformación, no vas a poder «parar las máquinas» y dedicar a tu equipo a cambiarlo todo, así que necesitarás ayuda o para dar continuidad al negocio actual y/o para hacer ese cambio.

Otra cosa que aconsejo siempre es: fórmate antes de empezar el proyecto. No te enteres de cómo se hace todo, pero sí de qué se puede hacer. Y, por supuesto, que no te forme la misma empresa que te lo va a implantar.

«Ensure you’re getting an integrator not an implementer. The former should tie all your systems together. The latter may only stand up the new system without connecting it anything else in a meaningful manner.»

Este es el párrafo que ha dado origen a este post y puede que el más importante de todos.

Después, hay otra serie de consideraciones sobre el equipo, sus conocimientos, la rotación, la composición del mismo, etc… este creo que también es un punto clave y aunque se supone que muchas veces se hace la realidad es que luego hay variables imposibles de controlar.

Le puedes presentar a un cliente un equipo de 5 personas que van a hacer el proyecto y a la hora de la verdad esas 5 personas pueden abandonar la compañía en cualquier momento. Por supuesto, puedes hacer cosas para «tenerlos contentos», pero en última instancia, no deja de ser una decisión personal de cada individuo.

Bueno, y una cosa es eso, y otra es lo que pasa a habitualmente, que de los curriculums que se presentan a los consultores que aterrizan en el proyecto, suele haber «alguna diferencia».

Y aquí el cliente tiene 2 opciones: protestar o decir lo que dijo la primera visita oficial que hizo un mandatorio extranjero a La Moncloa en el último cambio de Gobierno.

La visita la había concertado con Mariano Rajoy y cuando llegó se encontró con Pedro Sánchez y pensó: «Joer, hay que ver lo que gana este hombre en persona» 😉

La integración es la clave hacia la empresa inteligente

Hace más de 2 años, escribí un post sobre el «difunto» HANA Cloud Integration (HCI), ahora conocido como «servicio de integración de SAP Cloud Platform».

Desde entonces, aparte del cambio de nombre, el producto ha evolucionado y tiene mucha más funcionalidad de la comentada en dicho artículo, pero hoy no toca hablar de eso.

Toca hablar de integración en general y de la importancia que tiene esto a la hora de hablar de la empresa inteligente.

Microservicios, contenedores, tecnologías abiertas, blockchain, machine learning, bots, big data… muy bien, pero todo esto, ¿cómo lo integro con mis procesos?

De nada sirve acumular datos por acumular, ni poner sensores en todos los sitios, si no somos capaces de darle inteligencia a toda esa información y relacionarla entre sí.

Como podéis ver, tenemos integraciones de todo tipo:

  • Out-of-the-box: aplicaciones integradas que cubren procesos de negocio de principio a fin.
  • Abiertas: con un catálogo de API’s públicas que nos permiten integrarnos con aplicaciones no SAP y fuentes de datos diversas.
  • Holísticas: con herramientas que nos permiten diseñar nuestra propia estrategia de integración.
  • De Inteligencia Artificial: utilizando algoritmos embebidos que nos permiten diseñar una nueva generación de servicios.

¿Dónde puedo ver de qué va todo esto? Una vez más, en un curso de openSAPIntegration – The Key to the Intelligent Enterprise

Venga, que ahí tenéis las instrucciones para hacer encajar las piezas del puzzle… lo malo es que el número de piezas empieza a ser excesivo… 😉

Integración SAP HCM – SuccessFactors

Cuando un cliente SAP HCM decide apostar por SuccessFactors, tiene 2 opciones: apostar por un modelo híbrido (parte «en casa» y parte en «la nube») o ir al modelo total (todo en «la nube»).

Tanto para un caso como para el otro, existen (y se están desarrollando muchas más) formas de integrar ambos mundo.

Básicamente, cuando apostamos por el modelo híbrido, lo que hacemos es mantener toda la parte de datos maestros de Administración de Personal (PA), Estructura Organizativa (OM), Tiempos (PT) y Nómina (PY) en SAP; y en SuccessFactors llevaríamos toda la parte de Formación, Selección, Evaluación, Remuneración y Analíticas; con los correspondientes traspasos de información, de un lado a otro.

Talent Hybrid Roadmap

Si nos decidimos por llevarlo todo a «la nube«, el Employee Central se convierte en la piedra angular de todo, desde el que enviaremos información al resto de aplicaciones (incluido el ERP). Por ejemplo, existe un paquete de integración pre-parametrizado para la integración con la nómina on-premise, si no queremos ir todavía a la Employee Central Payroll.

EC to ERP Roadmap

Todo esto nos lo cuenta  al que os recomiendo seguir en Twitter. La información de este post la he cogido de uno suyo: Talent Hybrid And Full Cloud HCM – Current and Planned Integrations

Yo simplemente recolecto 😉