Caminos hacia la hoja de ruta de SAP

Según mi experiencia, la incertidumbre se debe a que muchos de los programas e instrucciones tienen una orientación demasiado técnica. Están demasiado orientados hacia el producto o la aplicación. El problema es que así apenas dan respuesta a las preguntas de quienes deciden un proyecto de esta envergadura.

Muchos directores de TI o CIO se enfrentan así a un reto: primero tienen que convencer a su consejo o dirección de que es necesario un cambio. Sin embargo, los responsables de la toma de decisiones no suelen preocuparse por las cuestiones técnicas.

¿Verde, marrón o azul? Las diferencias entre las vías y las herramientas no suelen conocerse a nivel directivo. Y las diferencias no se pueden comunicar de forma significativa o son de especial interés. Además, desde un punto de vista técnico, todos los "colores" son siempre posibles de todos modos.

Es crucial que un programa de hoja de ruta ofrezca respuestas adecuadas. No se trata únicamente de la viabilidad técnica. Según mi experiencia, seis aspectos desempeñan un papel central. Todo aquel que emprenda el camino hacia el S/4 debe tenerlos en cuenta.

Estrategia

Al principio de toda consideración y análisis está la cuestión de los objetivos estratégicos de una empresa y cómo pueden alcanzarse con la ayuda de las TI. En este punto, es crucial formular objetivos mensurables.

Así que no se trata de palabras de moda como "digitalización" o "preparación para la nube". Se trata de objetivos concretos como "aumentar el rendimiento de la producción en un x por ciento utilizando escenarios optimizados para una planificación detallada". Cuanto más precisos sean los objetivos, mejor.

Además de fijar los objetivos, es indispensable nombrar también los puntos fuertes de una empresa. Uno de esos puntos fuertes podría ser: "posibilidad de cambiar el pedido de un cliente hasta x días antes de la expedición o entrega". Tener claros los puntos fuertes y registrarlos sirve para mantener las ventajas competitivas.

Para averiguar y formular los objetivos mensurables y los puntos fuertes, son adecuadas las entrevistas breves "a la altura de los ojos". Deben realizarse con profesionalidad. Estas entrevistas pueden ser realizadas por consultores con experiencia en el trato con altos ejecutivos.

Paisaje objetivo

Cada empresa vive y desarrolla sus propios procesos. Primero hay que entender estos procesos. Para ello suele bastar con la documentación existente. Una evaluación de los procesos y funciones que se utilizan en la actualidad proporciona más información. También son útiles las breves sesiones informativas de los empleados. Suelen ser los que mejor conocen las particularidades de la empresa.

Los asesores cotejan estos conocimientos con los objetivos previamente elaborados. De este modo pueden diseñar una arquitectura del sistema objetivo. En mi opinión, aquí hay dos aspectos especialmente importantes: en primer lugar, el paisaje objetivo no solo debe desarrollarse pensando en SAP.

Por otro lado, debe comprobarse la disponibilidad real en S/4, por ejemplo, de los componentes que sólo están disponibles en el denominado modo de compatibilidad. Como parte de estos análisis, los expertos deben instalar y ejecutar el SAP Readiness Check. A continuación, pueden estudiar y evaluar los resultados de la comprobación.

Además, se recomienda realizar una comparación aproximada del entorno previsto con los procesos de mejores prácticas de SAP. De este modo, es posible averiguar cuál es la cuota del estándar SAP en el entorno informático previsto.

También sería perfecta una comparación en vivo con los expertos en procesos de la empresa en un sistema S/4 sandbox. De este modo, se puede aclarar la cuestión de cómo se pueden mapear los requisitos estratégicos y operativos.

Escenario y opciones de cambio

Básicamente, siempre hay más de un camino que conduce a la meta. Si quiere identificar el camino correcto para su empresa, tiene que tener en cuenta multitud de criterios.

Entre ellos figuran los factores de influencia sistémico-técnicos u organizativos. Pero los criterios también incluyen los costes, la complejidad de la implantación o la disposición de la empresa a asumir riesgos. Los catálogos de criterios y las listas de comprobación son adecuados para el análisis y la evaluación.

A menudo, las opciones se reducen a tres escenarios: nueva implantación (Greenfield), conversión del sistema (Brownfield) o migración selectiva (Bluefield).

En mi experiencia, sin embargo, esto no es muy útil. El motivo es que los "colores" sólo reflejan las diferencias en la configuración técnica del sistema y la migración de datos, y eso sólo de SAP ECC 6.0 a S/4.

El siguiente caso: El cambio de ECC a S/4 es principalmente un proyecto de TI. Además, la arquitectura de los sistemas de origen y destino es congruente o casi idéntica. En este caso, los métodos técnicamente orientados como Brownfield o Bluefield son los más adecuados, y Greenfield probablemente esté descartado.

En otra empresa, sin embargo, la necesidad de procesos modernos o estandarizados es enorme. En este caso, la decisión estaría probablemente más a favor de Greenfield - y Brownfield y Bluefield más bien descartadas.

El momento en que se toma la decisión también influye. Cuanto más tarde se tome la decisión de pasar a S/4, mayores serán las diferencias entre la arquitectura inicial y la de destino.

Esto se debe principalmente a los avances técnicos de S/4. En tal caso, también sería más probable greenfield, y brownfield y bluefield serían más bien inadecuados. En empresas de crecimiento dinámico, también puede tener sentido fijar objetivos intermedios concretos. Si la empresa alcanza un objetivo de este tipo, ya obtiene un valor añadido cuantificable, independientemente de cuándo continúe el camino hacia el objetivo.

Esfuerzo y costes

Los costes y gastos deben calcularse en una fase temprana y de la forma más completa y transparente posible. Esto se aplica en cualquier caso si no se trata de un encargo ágil y basado en procesos. La atención debe centrarse en los factores determinantes de los costes.

Estos factores incluyen los costes del esfuerzo interno de la propia TI, los costes de licencia o también los costes de explotación de los sistemas durante la duración del proyecto. A veces se plantean varias variantes de una arquitectura de sistema objetivo. A menudo también hay varias opciones para el cambio. En estos casos, es aconsejable preparar cálculos específicos para cada opción.

Minimizar los riesgos

Toda implantación de S/4 implica también riesgos. Esto se aplica, por ejemplo, a los costes y cambios asociados. Los riesgos pueden variar en función, por ejemplo, del tamaño de la empresa o del grado de utilización de SAP. Todos los riesgos deben reconocerse y nombrarse.

Es importante tener en cuenta las preocupaciones de la alta dirección, por ejemplo en relación con los riesgos operativos, la protección de las inversiones o la viabilidad futura de la arquitectura de destino utilizada.

Si no se escuchan las preocupaciones, es posible que no se tomen las decisiones necesarias o que sólo se tomen bajo condiciones estrictas. Por tanto, un concepto de cambio convincente tiene en cuenta las preocupaciones de la dirección. Más aún: hay que demostrar que los riesgos son gestionables mediante medidas adecuadas.

Las empresas deben trabajar con listas de control de riesgos adecuadas. Estas listas pueden complementarse individualmente. En proyectos de mayor envergadura, también puede resultar útil establecer la gestión de riesgos como parte permanente de la organización del proyecto.

Organización del proyecto

La organización profesional de un proyecto S/4 es esencial para el éxito del mismo. Deben describirse claramente las funciones y responsabilidades previstas en el proyecto. Como sugerencia, deberían cubrirse con posibles personas de la empresa respectiva. Ya aquí suelen ponerse de manifiesto los inminentes cuellos de botella en las capacidades.

Esto también se aplica a la delimitación de competencias y a la composición de los comités. Según el tipo y el alcance del proyecto, variarán las funciones o el contenido de las tareas. No obstante, las empresas deben asegurarse siempre de que los representantes de la empresa y de TI estén representados con sus expertos.

Para proyectos de mayor envergadura, es aconsejable pensar en funciones especiales. Entre ellas están, por ejemplo, la gestión de cambios, la gestión de riesgos o la gestión de contratos con proveedores.

Especialmente en el caso de nuevas implantaciones muy centradas en los procesos de mejores prácticas de SAP y los estándares de digitalización, se recomienda incluir otro comité en la organización del proyecto. Este comité debería comprobar y validar los requisitos al margen de la norma de mejores prácticas de SAP.

Para evitar la dependencia de consultorías externas, las empresas pueden crear internamente portadores de conocimientos con know-how sobre S/4. Para ello, la formación sobre lo nuevo debe tener prioridad sobre el uso operativo de los sistemas SAP existentes.

A veces también se producen cuellos de botella de capacidad. En estos casos, se puede recurrir a proveedores profesionales como "backfill" para que se hagan cargo temporalmente de los servicios de gestión de aplicaciones. Garantizan que la propia organización pueda operar y dar soporte al sistema recién instalado de forma profesional e independiente.