Vínculo entre la estrategia y la actividad operativa

Términos como Systems of Engagement (sistemas de compromiso) y Systems of Records (sistemas de registros) abordan los diferentes requisitos informáticos para el "nuevo" mundo de sistemas, que debe adaptarse a los planteamientos de digitalización de forma ágil y flexible, y para el "antiguo" paisaje de sistemas de conjuntos empresariales probados.

Sin embargo, ambos mundos no deben considerarse por separado para evitar soluciones aisladas. Por el contrario, las empresas necesitan un concepto holístico de TI que asigne las herramientas informáticas tanto a los cambios estratégicos como a las operaciones.

Desfase entre la estrategia y los procesos de cambio

Además, en la práctica empresarial a menudo existe una brecha entre la estrategia corporativa al más alto nivel, la gestión de proyectos para la implementación de la estrategia, el desglose a procesos de cambio conformes con ITIL -si se requieren adaptaciones de software en un proyecto- y la referencia de un proceso de cambio a cambios de código detallados individuales en un punto del panorama del sistema.

Aquí falta la integración vertical. Sin transparencia, sin embargo, es difícil comparar el éxito y los costes de los proyectos de digitalización y demostrar el éxito de la aplicación de la estrategia.

Otros retos se plantean en los ámbitos de la conformidad y la gobernanza, que esperan una documentación completa de los ajustes del software con referencia a las solicitudes de cambio subyacentes.

Los entornos de sistemas SAP, en particular, aportan un grado especial de complejidad a las adaptaciones de software, que deben comprobarse para detectar incoherencias de muy diversas maneras antes de que puedan importarse al entorno productivo. Las palabras clave en este caso son los entornos de 4 sistemas, los sobrescriptores y los sobresupervisores, así como los objetos críticos y dependientes.

La gestión del software empresarial (ESM) cierra esta brecha de dos maneras:

Por un lado, las herramientas ESM se integran con las aplicaciones de gestión de proyectos y los sistemas de ticketing y, por tanto, crean un flujo que va de la estrategia corporativa a los planes de proyecto y los cambios ITIL.

Por otro lado, gestionan las solicitudes de transporte recogidas en los procesos de cambio, realizan comprobaciones, advierten de incompatibilidades en el sistema de destino y documentan el curso de cada cambio para auditorías internas y fiscalización.

Este servicio de integración permite el funcionamiento eficaz de los Sistemas de Registro y, al mismo tiempo, crea libertad para la planificación y ejecución de proyectos de digitalización, cuyas adaptaciones de software controlan al igual que hacen con las tareas de mantenimiento. De este modo, también contribuyen a la integración de los Sistemas de Registro en el paisaje informático.

Retos para las TI

El término transformación digital resume multitud de aspectos de un mundo cada vez más digitalizado en el que las empresas establecidas tienen que trabajar en un reajuste fundamental de sus productos, servicios, procesos y modelos de negocio para sobrevivir en un entorno de mercado cada vez más dinámico [1].

Agilidad: debido a la drástica velocidad a la que cambian las condiciones del mercado y la competencia, la adaptabilidad de las TI es un factor crucial para el éxito. El panorama óptimo del sistema informático sustituye durante mucho tiempo a los prototipos de los proyectos de digitalización, que el equipo del proyecto complementa, sigue desarrollando y amplía con flexibilidad en caso de éxito.

Capacidad para innovar: en la era de la transformación digital, las prioridades empresariales están pasando de las mejoras incrementales de las ofertas existentes a ideas radicalmente nuevas y un comportamiento similar al de una start-up.

Las TI deben adaptarse a este cambio, por ejemplo con enfoques iterativos en modelos de procesos de desarrollo de software como Scrum y con DevOps para acelerar el desarrollo, la provisión y el desarrollo posterior de aplicaciones y servicios.

Simplicidad: no sólo los clientes esperan interfaces de usuario intuitivas y una experiencia de cliente coherente. El back office, que tiene que mantener en funcionamiento los complejos y difíciles de mantener sistemas heredados debido a ajustes, ampliaciones y conexión en red, también necesita apoyo informático para un control de procesos y una comunicación sencillos y rápidos. El funcionamiento eficaz de los sistemas heredados crea el tiempo necesario para los experimentos de digitalización.

Uso inteligente de los datos: la recopilación, el almacenamiento y la evaluación en tiempo real de los datos con algoritmos de evaluación inteligentes aportan valor añadido a las empresas y constituyen el requisito previo para la optimización de los procesos, la mejora de la toma de decisiones y las innovaciones empresariales.

El planteamiento de operar un paisaje de sistemas en dos partes no es más que una solución transitoria. Solo mediante la integración de los mundos de sistemas pueden las empresas evitar soluciones aisladas y, si tienen éxito, transferir sucesivamente prototipos maduros a la cartera de productos y servicios, así como a los conocidos procesos de mantenimiento y desarrollo posterior.

ESM para medir la eficiencia económica

Con cada planteamiento de digitalización, las empresas deben preguntarse si el proyecto cumple las expectativas, si aplica adecuadamente la estrategia corporativa y si los beneficios compensan los costes.

Para responder a estas preguntas, deben documentar e integrar de forma transparente todos los niveles de gestión de la empresa. Por regla general, la decisión de digitalizar parte de la dirección de la empresa, que aclara la imagen de sí misma y los principios básicos en la declaración de objetivos de la empresa.

Una forma electrónica de visión y misión, por ejemplo como Modelo de Motivación Empresarial (BMM), ayuda a comunicar la dirección de la estrategia en la empresa y hace visibles las diferencias entre los objetivos y propósitos, por un lado, y los medios y formas necesarios para alcanzarlos, por otro.

Como ejemplo de herramienta para la modelización de BMM, se menciona un prototipo creado en la Universidad de Ciencias Aplicadas de Mannheim, en la Facultad de Informática, como parte de un proyecto estudiantil y que ya ha sido probado en la práctica [3].

La transición al nivel táctico de la aplicación de la estrategia la forman los sistemas de medición del rendimiento, por ejemplo los cuadros de mando integral (CMI), que asumen los objetivos y definen medidas para su consecución, por ejemplo en forma de proyectos.

Los proyectos en el BSC pueden referirse a estructuras de desglose del trabajo, redes y paquetes de trabajo en sistemas de gestión de proyectos en los que los jefes de proyecto planifican, organizan y controlan los proyectos.

Mientras que algunos paquetes de trabajo pueden procesarse sin referencia a los sistemas informáticos, otros requieren cambios en el mundo informático. El personal del proyecto abre tickets en los sistemas de gestión de incidencias para estos ajustes, por ejemplo.

Estos, a su vez, están estrechamente vinculados a la gestión de servicios de TI, que a menudo controla los procesos de cambio basados en ITIL a través de solicitudes de cambio (RFC).

La integración termina en este nivel empresarial operativo con la referencia informática como muy tarde. La gestión del transporte sigue en el nivel técnico de TI en los entornos SAP, pero no existe ningún vínculo con los niveles empresariales.

Enterprise Software Management (ESM) cierra esta brecha (véase la figura) y contribuye así a la alineación empresa-TI. ESM asume las RFC de la gestión de servicios de TI y gestiona al detalle los procesos de cambio con las solicitudes de transporte que se les asignan.

Esto permite rastrear en cualquier momento qué RFC fue el motivo de qué cambio de código en qué sistema y qué solicitudes de transporte lo suministraron al sistema productivo.

Con la integración de todos los niveles, la dirección puede ver con sólo pulsar un botón qué objetivo estratégico debía alcanzarse a través de qué proyectos, qué ajustes informáticos eran necesarios para ello y quién implementó el cambio a través de qué solicitudes de transporte [4].

Si se sigue pensando en la relación coste-beneficio de una estrategia de digitalización, el ESM puede constituir la base de la evaluación basada en el esfuerzo de las adaptaciones del software. Para ello, hay que recoger en el BSC todos los objetivos vinculados a la visión y la misión de la estrategia y evaluar los proyectos almacenados.

Todos los paquetes de trabajo de proyectos relacionados con TI conducen a RFC o tickets vinculados y, en última instancia, a procesos de cambio. Gracias a la integración con el ESM, por fin es posible rastrear qué cambios de código se realizaron en el entorno del sistema.

El esfuerzo de cambio, por ejemplo sobre la base de la estimación del esfuerzo en días-persona, puede compararse con una evaluación del alcance funcional de las ampliaciones, por ejemplo según la medición del tamaño funcional en el marco de un análisis de puntos de función.

Riesgos de transporte controlables

Una mirada detallada a nivel informático deja claro que incluso los cambios de código de pequeño alcance pueden desplegar enormes complejidades y suponer un riesgo para el entorno productivo.

El panorama de 3 sistemas con adaptaciones de software en el sistema de desarrollo, transporte al sistema de garantía de calidad y pruebas allí, y, si tiene éxito, liberación e importación al sistema de producción, representa sólo el escenario más simple.

Cuando la urgencia de los cambios de software varía, por ejemplo en el caso de proyectos de desarrollo, migración o actualización que llevan mucho tiempo en marcha, por un lado, y de correcciones de errores que son necesarias a corto plazo, por otro, muchas empresas amplían el paisaje de 3 sistemas a uno de 4 o incluso 5, en el que un segundo sistema de desarrollo y posiblemente otro de pruebas llevan los resultados del mantenimiento rápidamente al sistema productivo.

La planificación, la documentación y el mantenimiento de los componentes del entorno del sistema en un sistema de gestión del ciclo de vida de las aplicaciones como SAP Solution Manager pueden conducir a la transparencia de la infraestructura del entorno, pero las herramientas no cubren el análisis y la comprobación de los cambios de código en las solicitudes de transporte individuales y con respecto a su interacción con otras solicitudes.

Supervisión de la cadena de procesos

Para ello, las empresas necesitan también un Enterprise Software Management (ESM). El ESM supervisa toda la cadena de procesos de cambios de objetos desencadenados por un cambio en todos los sistemas afectados del entorno del sistema y los gestiona o controla de forma centralizada. Un proceso de cambio puede generar un gran número de solicitudes de transporte a nivel de TI, que deben llegar al sistema productivo en el orden correcto.

El ESM realiza un seguimiento de los efectos de todos los ajustes de código que surgen en relación con un proceso de cambio y supervisa las interacciones entre las solicitudes de transporte de todos los cambios relevantes para TI.

Un posible riesgo son, por ejemplo, las sobreescrituras, en las que el sistema de gestión del transporte proporciona primero al sistema productivo la versión actual de un objeto, que más tarde es sobrescrita por la importación de una versión de código más antigua del objeto.

Por ejemplo, dos solicitudes de transporte pueden contener el mismo objeto, como un método de la clase Z_CL_A, que, por un lado, se modificó en el contexto de un proyecto de ampliación y para el que, por otro, hubo que realizar una corrección urgente de errores.

Por motivos organizativos y/o técnicos, los probadores pudieron completar la prueba de la corrección de errores más rápido que la prueba del proyecto de ampliación.

No obstante, la versión 13 del método no debe entrar en el sistema productivo hasta que se haya importado la versión 12, ya que, de lo contrario, la versión 12 más antigua sobrescribiría la versión 13 más reciente en el sistema productivo. En este caso, el error que se creía solucionado volvería a estar presente en el entorno productivo.

Riesgo: Adelantamiento

Otro peligro proviene de los "overtakers". En este caso, los objetos contienen partes de desarrollos cuyas contrapartidas sólo llegan al sistema de destino en transportes importados posteriores, de modo que en el sistema productivo la adaptación es incompleta y la aplicación puede reaccionar incorrectamente. Por ejemplo, la ejecución de un programa requiere otro objeto, quizá porque el programa llama a un módulo de función o a un método.

Si las adaptaciones del objeto y sus llamantes llegan al sistema productivo con un retraso de tiempo, es posible que la aplicación no funcione como se esperaba. Si la interfaz cambia de un modo que no es compatible hacia arriba, por ejemplo porque se añade un parámetro de transferencia obligatorio, todos los programas llamantes deben seguir el cambio.

Un desfase temporal al importar las peticiones de transporte, en las que se encuentran el objeto y el llamante, da lugar entonces a un volcado. La misma situación se produce cuando un objeto ha sido creado recientemente, sus llamadores ya han llegado al entorno productivo, pero él mismo todavía está en camino. También en este caso, el programa realiza un volcado durante el intento de ejecución.

Escenario de adelantamiento

Un escenario de adelantamiento se produce, por ejemplo, cuando un informe Z_REPORT_B contiene una llamada al módulo de funciones Z_FUNC_C en el código, pero no transporta el módulo en sí porque fue creado e introducido en el sistema de control de calidad por otro equipo de proyecto como parte de otro proyecto de ampliación.

Detectar a los que adelantan es mucho más difícil que enumerar los posibles peligros de sobrescritura, porque los objetos adelantados no son visibles en la petición de transporte. Sólo un análisis exhaustivo del código puede ayudar en este caso.

Con cientos de solicitudes de transporte y miles de objetos en ellas debido a correcciones de errores, desarrollos propios, ampliaciones o actualizaciones, estas dependencias y comprobaciones ya no pueden gestionarse manualmente y deben ser supervisadas por una herramienta ESM.

El factor decisivo aquí es que la herramienta ESM actúa en gran medida de forma automática y supervisa todos los transportes de forma estándar para aumentar la estabilidad del sistema de destino, ya sea el sistema de aseguramiento de la calidad, que se beneficia de bases de pruebas mejoradas, o el sistema productivo, donde el impacto de las importaciones defectuosas es mucho más doloroso de notar.

Idealmente, el ESM crea una lista de transportes críticos y emite advertencias sobre los peligros latentes en ellos. Un ejemplo de solución ESM con amplias rutinas de comprobación es Enterprise Software Management de Solutive.

En última instancia, una herramienta ESM para las partes interesadas con requisitos de gobernanza, riesgo y cumplimiento (GRC) también es útil más allá de medir el éxito de los riesgos de digitalización y gestionar las operaciones operativas de TI.

ESM para Gobernanza, Riesgo y Cumplimiento (GRC)

En ocasiones, las normas internas de la empresa también abordan la gestión técnica de las adaptaciones de software y exigen el cumplimiento transparente del principio de los cuatro ojos para los cambios de código, la separación de responsabilidades en materia de desarrollo y pruebas en términos de personal, y la limitación de las autorizaciones a lo adecuado para la función del usuario.

Las auditorías y revisiones encuentran en el ESM pruebas comprensibles de los procesos que cumplen las normas a nivel informático. El ESM también es importante para las auditorías externas. Los auditores piden cada vez más ver los procesos de cambio y las responsabilidades aplicables.

Si una empresa utiliza una herramienta ESM, puede crear informes claros sobre los ajustes del entorno productivo con sólo pulsar un botón y ponerlos a disposición de quien los solicite con poca antelación.

La documentación y evaluación de los cambios de código relevantes para la auditoría son estándar en varias herramientas ESM, incluida la solución de gestión de software empresarial de Solutive. Sin embargo, la integración de los niveles de negocio y TI en el sentido de alineación negocio-TI descrito al principio sigue siendo un reto.

Proyecto de prueba de concepto para estudiantes

Por este motivo, un proyecto estudiantil de la Universidad de Ciencias Aplicadas de Mannheim va a llevar a cabo un análisis de costes y beneficios de proyectos de digitalización mediante la integración de todos los niveles de gestión empresarial con el nivel de TI a través de la gestión de software empresarial como prueba de concepto en el próximo semestre de verano de 2018.

Está previsto utilizar como solución ESM el software de gestión empresarial Solutive, que ya proporciona las interfaces necesarias para la integración en sistemas de gestión de proyectos, sistemas de emisión de tickets y soluciones de gestión de servicios informáticos.

Literatura:

[1] Kreutzer, R. T., Neugebauer, T. y Pattloch, A., Liderazgo empresarial digital. Wiesbaden, 2017.
[2] Châlons, C. y Dufft, N.: The Role of IT as an Enabler for Digitalisation, en: Abolhassan, F. (ed.): ¿Qué impulsa la digitalización? Wiesbaden, 2016.
[3] Gröschel, M. y Roth-Dietrich G.: Modeling the Business Model and Business Strategy - Conception and Implementation of OMG's Business Motivation Model in a Software Prototype, en: Hertweck, D. y Decker, C. (eds.): Informática digital para empresas 2016, Lecture Notes in Informatics (LNI). Bonn, 2016.
[4] Roth-Dietrich, G.: Innovative Digitalisierungsstrategien, en: ERP-Management, Heft 4 2017, S. 32-34, Berlín, 2017.