¿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” 😉

openSAP – febrero 2019: ¿qué tenemos por ahí?

Después de la escueta entrada de ayer, hoy os voy a comentar los cursos de openSAP que están ahora mismo activos, por si alguno de ellos os fuera de interés.

Esto probablemente os ayudaría a adquirir algún tipo de conocimiento y sería beneficioso para mi salud… porque con cosas como la de ayer, ¡a mí un día de estos me da algo!

Tenéis la posibilidad de ver de qué va esto del SAP Data Hub y además podéis probarlo sobre un sistema trial con SAP Cloud Appliance Library.

Este es un curso que no es específico de SAP, pero os cuenta alguna cosa para poder mejorar el mundo, que es algo que no está mal, ¿no?

Ya sabéis que una de las grandes apuesta de SAP de este año es el tema de C/4HANA, aquí os explican de qué va todo esto.

Si empezaste a desarrollar en HANA XS, va siendo hora de que te recicles y empieces a pegarte con el XSA. Si ni siquiera has empezado, estás tardando.

Aquí os dan una visión general de una de las piezas que forman parte de SAP C/4HANA.

Una nueva oportunidad de conocer las herramientas de un proceso de conversión a S/4HANA, ¿o te vas a esperar a 2025?

Este acaba de empezar y se suponen que nos van a contar cómo facilitar la transición al cloud a la gente de HCM. No puedo comentar nada porque ha empezado hoy, pero prometo hacer una entrada más adelante.

Este comienza en marzo y como ya he hecho una edición anterior, os puedo comentar que es curioso. Te enseñan cómo comunicar de una manera más clara tus ideas, algo a lo que a veces no se le da toda la importancia que merece.

¿Y hay que hacerlos todos? Bueno, es evidente que no, aunque tampoco está de más, que te suene al menos de qué va todo esto, para evitar escribir barbaridades como la mostrada en la entrada de ayer.

En cualquier caso, sé que todo esto en la mayoría de vosotros va a producir el conocido “efecto gimnasio”…  ya os aviso, que sólo con apuntaros no vale… hay que dedicarle tiempo 😉

SAP S/4HANA es una nueva línea de productos

Hace casi 4 años escribí un artículo intentando explicar ¿qué es S/4HANA?

Desde entonces, como no podía ser de otra forma, el producto ha ido evolucionando y ampliando/mejorando su funcionalidad, convirtiéndose en uno de los pilares de la empresa inteligente. Ya sabéis:

  • Suite Inteligente: S/4HANA.
  • Plataforma Digital: SAP Cloud Platform y SAP Data Hub.
  • Tecnologías Inteligentes: SAP Leonardo.

Bien, pues lo primero que hay que tener claro es que S/4HAHA NO es la nueva versión de R/3; S/4HANA es una nueva línea de productos. Y no es que lo diga yo (que también lo digo), lo dicen ellos:

Y deberíais ir pensando en qué vais a hacer con lo que tenéis ahora… ¿migrar o reimplantar?

Sí, ya sé que si recordáis lo “bien” que lo pasasteis en la implantación del sistema actual, tenéis clara la respuesta, pero… ¿estáis seguros de que vuestros procesos no han cambiado nada en los últimos años?

Realmente, la pregunta anterior no está bien formulada, porque es muy posible que vuestros procesos no hayan cambiado nada en los últimos años, pero eso no quiere decir que no debieran haberlo hecho…

Puede que algunos de ellos, los hayáis ido mejorando con el tiempo, pero probablemente, en la gran mayoría de ellos, habréis utilizado la conocida metodología SFNLT: Si Funciona No Lo Toques 😉

Creo que este es un buen momento para aprovechar a revisar nuestros procesos, con el objeto de optimizarlos y adaptarlos al momento tecnológico que vivimos.

Los que habéis ido haciendo los deberes año a año y haciendo mejora continua, puede que optéis por la opción de convertir el sistema existente, pero no tengo yo muy claro que haya mucha gente en este bando.

En cualquier caso, aquí tenéis los distintos escenarios que podéis contemplar:

Lo que está claro es que habrá que hacer una serie actuaciones técnicas y otras a nivel de procesos de negocios.

Si optamos por la opción de convertir el sistema, habrá una serie de adaptaciones que tendremos que hacer sí o sí,  y además tendremos que decidir si queremos hacer varios proyectos o hacerlo todo de una vez, en un “Big Bang”.

Cuando nos planteamos una nueva implantación, los modernos hablar de un “Greenfield”, que sería el escenario recomendado para aquellos que tienen muy tocado su SAP… o que vienen de otro sistema, por supuesto.

El escenario de transformación nos lo deberíamos plantear a la hora de tener un sistema donde consolidar información de distintos sistemas o traspasar ciertos datos a un nuevo sistema, por ejemplo.

Y para cada una de estas opciones, SAP nos facilita una serie de herramientas, como SAP Software Update Manager y SAP S/4 Migration Cockpit; herramientas que, por supuesto, ya conocéis de cuando os pusisteis manos a la obra con S/4HANA

¿Cómo? ¿Que no os apuntasteis al curso que os comenté? Ah, que sí que os apuntasteis, pero que hicisteis nada más… pues tenéis una nueva oportunidad de apuntaros e incluso hacerlo, gracias a los amigos de openSAPSystem Conversion to SAP S/4HANA (Repeat)

Y si queréis ver algo más resumido, a modo de introducción, os aconsejo que perdáis una horita de vuestra vida viendo esta sesión: CNA101 Overview of Transition Paths to SAP S/4HANA

Ya, que tenéis muchas cosas que hacer, pues nada, esperad tranquilos a que llegue el 2025 (antes de lo que pensáis), aunque yo iría haciendo algo… 😉

Revisión de código para migrar a S/4HANA

Tranquilo, esto no es para ti… tú lo tienes todo estándar y no tienes ningún desarrollo a medida. Además, en caso de tener alguno seguro que está perfectamente optimizado y lo hiciste pensando que en unos años iba a aparecer S/4HANA y no hace falta que toques nada.

Pero… como quizás conozcas a alguien que puede que sí que haya tocado algo, sería bueno que le aconsejaras que leyera esto… 😉

Teniendo en cuenta que en S/4HANA se ha modificado y/o eliminado una gran cantidad de código, es muy probable que tengas que revisar tus desarrollos de cliente, ya que muchos puede que ya no tengan sentido o que directamente no funcionen.

Para ello, SAP nos proporciona una serie de herramientas, basada en la Simplification Database, que recoge todos los objetos SAP que han sido modificados, ofreciéndonos notas de soporte para saber qué hacer en cada caso.

Para realizar esos chequeos, necesitamos tener un sistema central, desde el que conectarnos a los distintos sistemas que tengamos para poder realizar dichas verificaciones.

Desde ese sistema central, se lanzará el ABAP Test Cockpit (ATC), que nos ofrecerá como resultado un listado con los problemas detectados y sus posibles soluciones:

Podéis ver más detalle de todo esto aquí: Custom Code Migration Guide for SAP S/4HANA 1809

Y aunque esto realmente está indicado para el paso a S/4HANA, no os engañéis, quizás no sería malo que aunque no tengáis pensado dar el salto en un futuro inmediato, empecéis a revisar ya vuestro código, que luego ya sabemos lo que pasa…

En España nunca hay tiempo de hacer bien las cosas… pero sí de hacerlas 2 veces.

Perdón, vosotros no, que no tenéis nada “zeta”, pero quizás algún amigo… 😉

Extensiones en S/4HANA

Lo primero que tenemos que aclarar es que cuando hablamos de S/4HANA, hablamos de S/4HANA. ¿Está claro? 😉

Lo que quiero decir es que podemos tener una instalación on-premise u optar por la solución cloud, pero ambas serían S/4HANA, que sería la suite inteligente, uno de los 3 pilares (junto con la plataforma y las tecnologías) de la empresa inteligente.

S/4HANA es una cosa y HANA es otra cosa.

“HANA es una base de datos en memoria”… NOOOOOOOOOOOOOOO… HANA es una plataforma de desarrollo, que tiene una base de datos en memoria, aparte de otras muchas cosas.

“S/4HANA es la nueva versión del R/3”… NOOOOOOOOOOOOOOO… S/4HANA es un nuevo producto, en el que se han rediseñado los procesos para optimizarlos aprovechando las bondades de la plataforma HANA, creando nuevos procesos y eliminando otros.

¿Y qué pasa si alguno de mis procesos no se adapta al estándar? No pasa nada, puedes EXTENDER (no he dicho “modificar”) dichos procesos para adaptarlos a lo que necesites, incluso crear soluciones innovadoras o que no están cubiertas por SAP.

¿Entonces puedo hacer lo que quiera? No, puedes extender la funcionalidad, no “perpetrar” la funcionalidad estándar.

Y, evidentemente, no podrás hacer lo mismo en la versión on-premise (yo me lo guiso y yo me lo como) que en una edición cloud (no estás solo en el mundo).

Podemos distinguir entre:

  • Extensiones in-app: hechas en S/4HANA, para crear, por ejemplo, objetos, interfaces de usuario, campos, etc… específicos de cliente.
  • Extensiones side-by-side: hechas en SAP Cloud Platform, como soluciones cloud independientes, que complementen alguna funcionalidad de S/4HANA o para diseñar nuevas, que se podrían consumir como servicios independientes.

Yo que vosotros, iría enterándome de cómo va todo esto (Create and Deliver Cloud-Native SAP S/4HANA Extensions), ¿o pensáis pasaros la vida haciendo “zetas”? 😉

S/4HANA Cloud da inteligencia a tu negocio

Ya sabemos que “en S/4HANA no es todo cloud”, pero podría serlo, o al menos una parte, y no estaría de más qué posibilidades nos ofrece.

Hace un tiempo escribí un artículo sobre las distintas ediciones de S/4HANA, pero esto ha cambiado desde entonces. Estas son las opciones que tenemos para desplegar S/4HANA, a día de hoy:

Si nos centramos en las opciones de cloud pública, vemos que podemos optar por la solución multi-tenant o single-tenant, que se diferencian esencialmente en el número de componentes e industrias soportadas y el ciclo de actualización, como podéis ver en el gráfico anterior.

Tienen características comunes como: posibilidades de configuración y hacer extensiones de funcionalidad (vía SAP Cloud Platform), un menor TCO, un time-to-value más rápido

Ya comenté que íbamos a oír hablar de la empresa inteligente, pero no sólo eso ahora aparecen términos como Intelligent ERP (iERP).

¿Y cómo conseguimos que nuestro ERP sea inteligente? Aquí os dejo alguna de las claves:

Y si queréis saber más, o ver esto con más detalle, os invito a que veáis lo que cuentan en este curso de openSAPIntelligent ERP with SAP S/4HANA Cloud

En próximas entradas, entraré en más detalle en todo esto pero, de momento, ya tenéis deberes 😉