El reto de la gestión de licencias SAP

El debate sobre el uso indirecto no es nuevo ni específico de SAP. De la definición de uso de las CGC de SAP (véase el recuadro de la página 47) se desprende que no sólo hay que conceder licencias a los usuarios de aplicaciones de terceros, sino que puede ser necesario adquirir otros derechos de uso para la aplicación que se comunica con SAP.

Uso indirecto - sin datos específicos de SAP

Yendo un paso más allá, la definición de uso puede interpretarse en el sentido de que no se hace ninguna distinción fundamental entre uso directo e indirecto. Como ya se ha indicado, el seguimiento del uso indirecto debe considerarse con más detalle, y no sólo en el caso del SAP.

Esta cuestión ya existía hace más de diez años: Microsoft, IBM, Oracle y otros fabricantes llevan tiempo persiguiéndola. Entre los clientes de Microsoft, por ejemplo, la situación se conoce como multiplexación: un proceso que utiliza hardware y software para agrupar las conexiones a los programas, redirigir la información o reducir el número de dispositivos o usuarios que acceden a ella directamente.

Las cuestiones a este respecto también son repetidamente objeto de auditorías de software. Para abordar con fiabilidad la cuestión de las licencias SAP, también hay que distinguir entre una infracción pura y simple de la licencia y un aumento de la exigencia de licencia debido a un uso indirecto.

Indicios como los múltiples inicios de sesión de un usuario podrían apuntar a un uso indirecto si la cuenta de un usuario tiene un número extremadamente elevado de accesos paralelos, ya que entonces sería posible extraer conclusiones sobre los accesos automatizados.

Por ejemplo, la cuenta de un desarrollador de software que trabaja para la empresa en cuestión no sólo podría utilizarse para él, sino también para todos los clientes de la tienda web programada por él, que accede a las funcionalidades de SAP.

El mismo ejemplo podría surgir del hecho de que se pueda demostrar que el usuario tiene una carga de trabajo elevada o un uso continuo (24 horas al día, 7 días a la semana). O la medición podría dar indicios del correspondiente uso cruzado de componentes. Todos ellos no son necesariamente válidos al 100%, pero al menos son posibles indicios para dar pie a un análisis más profundo de las conexiones y el uso.

Por supuesto, en caso de múltiples inicios de sesión, alta carga de trabajo o largas horas de trabajo, también podría tratarse de una "simple" infracción de la licencia, es decir, compartir la cuenta o que un usuario técnico haya sido clasificado erróneamente como usuario de diálogo, por ejemplo.

El uso indirecto puede producirse de la siguiente manera: Un usuario (con o sin licencia) accede, por ejemplo, a funcionalidades SAP o a la información almacenada en el entorno SAP a través de una aplicación de terceros que no es SAP.

De este modo, el sistema ascendente no SAP proporciona acceso indirecto a los datos de SAP CRM, ERP u otros componentes. Lo importante no es solo el acceso a través de una aplicación no SAP, sino también cómo se produce el acceso:

¿Disponen los usuarios de la aplicación externa de las licencias necesarias de usuario designado de SAP? En función de las condiciones de licencia aplicables al escenario, también puede influir si los datos se transfieren en tiempo real o diferido, así como algunos otros criterios, dependiendo de si SAP proporciona una solución correspondiente que pueda sustituir a las funcionalidades externas.

¿En qué dirección tiene lugar la transferencia de datos (unidireccional, bidireccional, entrante, saliente, etc.)? ¿Hay una retirada masiva de datos (bulk)? Debería llevarse a cabo una evaluación para cada escenario de uso indirecto en el panorama corporativo y parece ser especialmente útil si se puede identificar un margen de interpretación a partir de posibles condiciones contractuales que podrían evitar licencias adicionales innecesarias.

Por ejemplo, en las construcciones contractuales más antiguas (interacción de contrato pertinente, PKL, CGC y SUR) se encuentra a menudo información según la cual el uso de la información, siempre que no se produzca en tiempo real, por ejemplo, y se cumplan algunos otros criterios, puede asignarse a través de los derechos de uso existentes.

Así pues, las cláusulas contractuales de los contratos heredados pueden ser posibles soluciones que, por ejemplo, sólo exijan la concesión de licencias a los usuarios de aplicaciones de terceros, pero no a la propia aplicación de terceros.

Sin embargo, esto debe examinarse críticamente en cada caso y presupone en cada caso que SAP no proporciona las funcionalidades correspondientes. Así pues, la interposición de middleware puede ser una solución acertada, pero esto sólo se aplica a casos específicos y presupone la validez de las condiciones de licencia correspondientes.

También en este caso, el análisis de los contratos es indispensable para garantizar el cumplimiento de las condiciones de licencia y la conformidad necesaria. Cabe mencionar en este punto que el middleware puede ser una solución técnica siempre que las funcionalidades del software ascendente no SAP no sean ya ofrecidas por SAP.

Por ejemplo, una solución de registro de tiempos de desarrollo propio que no comunique los datos en tiempo real y por deducción masiva al sistema SAP correspondiente a través de un middleware de colas de mensajes no sería una solución adecuada, ya que el propio SAP ofrece las funcionalidades correspondientes. Sin embargo, la situación podría ser diferente en el caso de soluciones muy específicas del sector que actualmente no están incluidas en el programa de software de SAP.

Para la correcta concesión de licencias de aplicaciones de terceros, necesaria por tanto al menos para la mayoría de los casos de uso, SAP incluyó en 2010 en el programa la licencia "SAP NetWeaver Foundation for Third-Party Applications", que puede adquirirse según métricas de usuario nominal o de núcleo.

El compromiso con una de las métricas sólo es posible una vez, antes de la primera compra. Esto significa: es aconsejable examinar los derechos y condiciones de los contratos antiguos y aprovechar al máximo el margen de interpretación existente.

También puede observarse que existe una tendencia hacia una gama más amplia de licencias para hacer frente a los diversos y cada vez más complejos escenarios de uso indirecto. El gráfico ilustra algunos de estos escenarios, con opciones de licencia alternativas que SAP está desarrollando actualmente.

Por ejemplo, como se comunicó en el Sapphire de este año en Orlando, SAP ha abordado los escenarios más comunes (Procure-to-Pay, Order-to-Cash y Static Read) y proporciona a los clientes métricas de licencia con los correspondientes derechos de uso, como en el ejemplo anterior, para asignar licencias correctas de forma rentable.

Siempre que, por lo demás, los clientes estén correctamente autorizados, SAP también demuestra comprender las necesidades actuales de los clientes comunicándoles las concesiones en el contexto de las mejoras necesarias.

Siempre es aconsejable, independientemente del fabricante, analizar si existen escenarios de uso indirecto en la empresa y evaluarlos desde el punto de vista de la ley de licencias. Esta es la única forma de garantizar el cumplimiento de la licencia, que es responsabilidad del licenciatario.

Compañero de progreso

Hace sólo dos décadas, los sistemas SAP, entonces principalmente en forma de componentes ERP, con su completa cartera de oportunidades empresariales, eran el frente ideal para que los clientes dieran el paso hacia el futuro.

De repente, existía la posibilidad de diseñar procesos empresariales más eficientes y acortar drásticamente los tiempos de producción. También se podían automatizar parcial o totalmente varios flujos de trabajo.

Así, la introducción del software ERP fue el prestigioso y a la vez valiente paso hacia un mundo de procesos y aplicaciones empresariales caracterizado por la digitalización, con el fin de seguir el ritmo de las crecientes estructuras competitivas internacionales.

Era una época de agitación y de posibilidades técnicas aparentemente infinitas, pero no el momento de prever y prestar atención a los riesgos asociados en materia de licencias y, por tanto, de cumplimiento de la normativa.

Con el paso del tiempo y el desarrollo de las posibilidades técnicas actuales, como la virtualización, las aplicaciones en la nube, los dispositivos de almacenamiento que cumplen los requisitos normativos y las soluciones de bases de datos de alto rendimiento, surgió el primer gran reto para todas las partes implicadas, tanto licenciantes como usuarios.

Los licenciantes tenían que anticiparse a las posibilidades técnicas futuras a la hora de diseñar sus modelos de licencia, mientras que los licenciatarios estaban expuestos a la cada vez más compleja variedad de modelos de licencia, métricas y condiciones de licencia.

Ecosistema SAP

En el caso de SAP, el panorama de sistemas homogéneos que ha crecido a lo largo de dos o tres décadas ha evolucionado desde su antigua importancia como front-end general hacia un ecosistema holístico al que se conectan multitud de aplicaciones especializadas locales y en la nube.

Ejemplos destacados son las funcionalidades CRM de Salesforce.com y la gestión del capital humano de Workday. Ambos ejemplos suelen sustituir o complementar las funcionalidades propias de SAP.

SAP proporciona la tecnología adecuada para la integración técnicamente correcta de estas y otras aplicaciones especializadas. En el pasado, esto tenía lugar en forma del producto Integración de Procesos (PI).

Además de la integración técnica, el uso del ecosistema SAP subyacente puede requerir la adquisición de derechos de uso adicionales. Un ejemplo bien conocido es la licencia "SAP NetWeaver Foundation for Third-Party Applications" ya mencionada.

Un usuario que, por ejemplo, utilice el acceso a las funcionalidades de SAP exclusivamente a través de una plataforma externa puede obtener derechos de uso de conformidad con la licencia mediante la correspondiente licencia de plataforma.

Sin embargo, esto es erróneamente ignorado por muchos clientes, no se considera suficiente licencia, sino que también puede requerir la adquisición adicional de la licencia "NetWeaver Foundation for Third-Party Applications", siempre que el objetivo de la aplicación se base en la plataforma NetWeaver. Por regla general, ni siquiera un sistema PI intermedio cambia esta situación.

A menudo se acusa a SAP de falta de innovación y sus sistemas frontales originales se degradan a un sistema back-end para proveedores de soluciones jóvenes e innovadoras. Sin embargo, una mirada más atenta revela una imagen clara de este cambio y permite verlo como la evolución lógica del panorama de sistemas SAP. Los requisitos empresariales han cambiado y la flexibilidad ha adquirido mayor importancia en las estructuras informáticas globales.

Transparencia holística

Con la creciente heterogeneidad de los ecosistemas SAP utilizados por los clientes y el uso a menudo específico para cada cliente de los productos e interfaces integrados e interconectados, la creación de una transparencia holística ha ido ganando importancia desde hace algún tiempo.

La cuestión de la causa de la a menudo insuficiente transparencia puede explicarse a menudo de forma sencilla. Mientras que hoy en día un gestor de licencias suele ser responsable de todas las licencias de software y de la medición del uso correspondiente, en el caso de las licencias SAP esto no suele ser así o lo ha sido durante poco tiempo.

La razón de ello se encuentra en la frecuente separación entre las unidades organizativas de TI no SAP y SAP. Desde el punto de vista del cliente, al que el sistema SAP proporciona una aplicación crítica para el negocio, esto es bastante comprensible, pero desde el punto de vista de la gestión de licencias es un punto gris en el mapa de las aplicaciones que hay que gestionar.

Así, en el pasado, la medición y la adquisición de licencias se iniciaban también, como es lógico, a través de estas unidades organizativas de SAP. Sin embargo, sin el establecimiento de los correspondientes conceptos de funciones y procesos que desencadenen una acción en caso de que los empleados se incorporen o abandonen la empresa, por ejemplo, es casi imposible que se establezcan de forma rentable.

A estas unidades organizativas también les resulta difícil seguir el ritmo del desarrollo actual de las posibilidades técnicas en su indudable conocimiento de las licencias SAP.

Las infraestructuras informáticas convergentes e hiperconvergentes son males necesarios para garantizar la resistencia mediante el uso de las redes de área extensa (WAN) actuales y complementar el creciente nivel de virtualización.

Sin embargo, comprender el impacto del uso de estas estructuras desde la perspectiva de la gestión de licencias suele estar fuera del alcance de la responsabilidad. La concesión de licencias insuficientes es inevitable cuando se utilizan productos que dependen de la estructura.

Los antiguos acuerdos de licencia de software basados en modelos de licencia de CPU o núcleo, por ejemplo, no suelen estar diseñados para su uso en redes virtuales.

Al revisar los antiguos contratos de Business Objects, esto es muy fácil de determinar y, en lugar de un servidor físico en el que se utilizaba el software en el pasado, ahora se debe obtener la licencia del servidor físico del entorno virtual, que normalmente se configuraba significativamente más grande en términos de núcleos de procesador, CPU y potencia informática.

Pero ése seguiría siendo el caso más fácil de superar. Sin embargo, los entornos virtuales actuales abarcan al menos varios servidores físicos en los que se distribuye la carga de trabajo en forma de clúster. Así, en lo que respecta a la necesidad de licencias, un servidor físico ya son varios. Pero ni siquiera éste es el peor de los casos.

¿En el peor de los casos?

Si utiliza la actual tecnología de virtualización VMware, está en condiciones de distribuir la carga de trabajo entre clústeres mediante determinadas funcionalidades (vMotion).

Con la tecnología NSX, a través de infraestructuras convergentes e hiperconvergentes, es posible incluso cubrir centros de datos enteros con una capa de virtualización.

La necesidad de adquirir los correspondientes derechos de uso resultantes de la obligación de concesión de licencias es difícilmente controlable en este caso, ya que a menudo no se incluyó en el estudio de viabilidad de la decisión estratégica de introducir tales estructuras.

Pero puede cuestionarse la necesidad de esta situación, ya que es precisamente para la evaluación de estos escenarios para lo que la organización de gestión de activos de TI/gestión de licencias está equipada con recursos, conocimientos y competencias para estar disponible como asesor de confianza con asesoramiento y apoyo.

Evitar estos casos es una de las razones de la necesidad de una estructura de gobierno establecida para la gestión de activos informáticos.

Los modelos de concesión de licencias son cada vez más complejos

Sin embargo, este creciente grado de complejidad, unido a unos modelos y condiciones de concesión de licencias cada vez más complejos, no sólo afecta a los productos patentados, como en el caso de SAP.

Debido a la evolución descrita del ecosistema SAP mediante la integración y el uso de productos ajenos a SAP, esto afecta a otros ámbitos de la gestión de licencias.

Esto plantea retos de gran alcance para las organizaciones con un bajo nivel de madurez o falta de gobernanza en la gestión de licencias. Para crear la mayor transparencia posible, es importante reconocer el propio uso entre componentes y conocer las formas en que los usuarios, sistemas, bots y otros actores se comunican entre sí.

Hoy en día, por ejemplo, se están instalando cada vez más módulos de telemetría en las industrias de automoción e ingeniería mecánica como parte de la introducción de la Industria 4.0 y las estructuras IoT, que, por ejemplo, informan al fabricante con mensajes sobre el mantenimiento pendiente o la alerta temprana de una probabilidad previsible de fallo.

A veces, la integración llega tan lejos que se crea la orden de asistencia correspondiente en SAP y se envía a un técnico sin que sea necesaria ninguna otra interacción. Pero la ausencia de interacción humana no significa que estos escenarios no estén sujetos a licencias.

La tarea consiste en utilizar los conocimientos contractuales, técnicos y sobre licencias para analizar cómo puede diseñarse un caso de negocio de la forma más rentable posible y cómo puede planificarse la aplicación respetando las licencias. La correcta concesión de licencias es siempre responsabilidad del cliente.

A más tardar con el uso de los productos correspondientes que se instalan fuera de SAP pero acceden a las funcionalidades de SAP, se reconoce entonces la última razón que habla a favor de que la organización responsable de la gestión de licencias debe participar absolutamente desde el principio de la planificación.

Es necesario e importante bucear en las consolas de gestión de las aplicaciones externas o identificar los grupos de usuarios correspondientes hasta el nivel de carpeta y analizar sus derechos de acceso y permisos.

Estos avances han hecho que la introducción de una estructura de gobernanza, la implicación continua de la organización de gestión de licencias y la comunicación constante de las partes interesadas sean un paso indispensable hacia un futuro en el que garantizar el cumplimiento de las licencias sea más difícil que nunca.

Además del seguimiento de todos los canales de comunicación basados en tecnología RFC entre SAP y sistemas de terceros, todas las conexiones no RFC (por ejemplo, HTTP, IDoc, IPSec, etc.) deben registrarse y evaluarse mediante métodos de recopilación de datos cualitativos y cuantitativos (por ejemplo, documentación, comprobaciones del sistema, etc.).

Recomendaciones para la gestión funcional de licencias

Las recomendaciones para una organización funcional de gestión de licencias son las mismas para SAP que para cualquier otro fabricante, con algunas excepciones.
El principio de todo buen gestor de licencias es conocer los derechos de uso comercial, identificar la información sobre el tipo de uso técnico y el volumen de uso y conciliarlos al final. Además, es importante reconocer los avances y cambios en las normas y métricas de concesión de licencias y aplicarlos en el propio entorno.
De este modo, se puede obtener información sobre el exceso o la falta de licencias existentes. A continuación se resumen brevemente los puntos que deben seguirse en cualquier caso para garantizar la transparencia requerida.

Recomendación: Transparencia en el uso indirecto

El uso indirecto de los sistemas SAP debe considerarse individualmente en el marco de un análisis de escenarios, en función del caso de uso respectivo y de las circunstancias subyacentes. El siguiente proceso de referencia se ha establecido y probado en la práctica: El primer paso consiste en iniciar y llevar a cabo la recopilación inicial de datos de todos los sistemas productivos, de desarrollo o de uso alternativo relevantes para el estudio. Dependiendo del tamaño de la empresa, las compañías tienen varias docenas o incluso cientos de fuentes de datos diferentes. Esta complejidad es una de las principales razones por las que es indispensable planificar y diseñar cuidadosamente la recogida y consolidación de datos y su posterior análisis.

Lo ideal es que una instancia de SAP Solution Manager integrada y gestionada de forma centralizada sea el punto de contacto central para la recopilación de información del lado del sistema sobre las conexiones RFC de los sistemas SAP relevantes para la topografía.

Si no existe ninguna, habrá que buscar una fuente de datos alternativa que tenga un carácter igualmente centralizado. A continuación, los datos y la información recopilados se consolidan, clasifican y priorizan en función de su pertinencia y carácter crítico.

Por último, los sistemas y las conexiones basadas en ellos se preseleccionan para su posterior análisis según criterios individuales.

De este modo, el resultado representa idealmente una visión global coherente de los sistemas SAP relevantes para la topografía cuyas conexiones con sistemas de terceros deben clasificarse como más críticas y -teniendo en cuenta diversos aspectos del uso indirecto- más relevantes.

Los escenarios de uso técnico, también llamados casos de uso, representan un componente elemental del proceso de encuesta y estudio del uso indirecto. Dependiendo del tamaño de la empresa, pueden identificarse unos pocos, pero también cientos de escenarios de uso indirecto diferentes.

Para hacer esta complejidad un poco más manejable, es aconsejable adoptar un enfoque paralelo a la hora de definir los respectivos escenarios de uso. Sin embargo, partiendo de la conexión técnica subyacente y en función de la situación inicial, también se puede optar por un objeto de diversificación diferente.

Por regla general, sin embargo, se distingue entre casos de uso RFC y no RFC.
Tras el examen pormenorizado, en el siguiente paso se recomienda consolidar los casos de uso correspondientes en escenarios globales. Para la consolidación, a menudo se incluye información técnica sobre el hardware y el nivel de virtualización supuestos. Esto garantiza una mayor especificación y facilita el posterior análisis y evaluación.

El resultado de este paso del proceso es una lista de los escenarios de uso más relevantes desde el punto de vista de la minimización de riesgos (en forma de visión lógica holística).

El tercer paso del proceso de referencia, la comparación de licencias SAP, se basa en una base de datos sólida. En primer lugar, es aconsejable enriquecer los datos ya recopilados con datos de uso y las autorizaciones de los usuarios SAP correspondientes en las aplicaciones de destino.

Esto se realiza mediante una extracción de datos basada en el sistema y una evaluación de estos datos asistida por el sistema. En caso necesario, esto se complementa con un análisis de los derechos de acceso y las autorizaciones en el entorno de las aplicaciones de destino (por ejemplo, mediante un análisis dentro del Directorio Activo).

El primer paso consiste en identificar la información relevante para la licencia y diseñar un mecanismo de extracción y evaluación de datos. A continuación, se elaboran perfiles de actividad asociados a partir de los datos reales de uso para poder tomar como punto de partida la base de datos real.

Debe tenerse en cuenta aquí que la descripción de actividad real debe considerarse siempre de forma genérica. Tanto los datos de uso como las descripciones de actividad de los respectivos perfiles de usuario deberían contar idealmente con las autorizaciones técnicas de acceso y los accesos/actividades reales en las correspondientes aplicaciones SAP.

Para ello, es aconsejable analizar las correspondientes solicitudes objetivo a nivel de autorización técnica. Por último, se compara el estado objetivo (el stock de licencias especificado contractualmente) con el estado real. Éste se deriva del uso real.

Los resultados de la comparación de licencias se utilizan en el cuarto paso del proceso de referencia para poder evaluar los casos de uso previamente definidos desde una perspectiva empresarial.

Además de estas consideraciones, también se llevan a cabo evaluaciones de riesgo para poder examinar la evaluación a un nivel más detallado y preciso. Para reducir la complejidad, también es aconsejable dividir los casos empresariales en función de las circunstancias tecnológicas, examinarlos por separado y luego consolidarlos en casos empresariales globales, más generales.

Posteriormente, los casos empresariales globales se someten a una evaluación crítica. Esta evaluación se basa en criterios previamente definidos y ponderados.

Este procedimiento garantiza que sólo se incluyan en el círculo más estrecho de la decisión los casos empresariales que se desprendan del análisis como relevantes. En este contexto, pertinente no sólo significa pertinente desde el punto de vista de la minimización de riesgos, sino más bien pertinente para garantizar la concesión de licencias global comparativamente más rentable que pueda controlarse en el marco de los aspectos de cumplimiento.

En el último paso, se identifican las posibilidades técnicas para minimizar anticipadamente el riesgo, o idealmente evitarlo, del uso indirecto. En este contexto, tiene lugar la evaluación monetaria de las posibles medidas.

Combinando los distintos escenarios en paquetes globales lógicos, se identifican propuestas para la concesión de licencias globales más rentables. En este contexto, se garantiza el cumplimiento (si es necesario, en consulta con el SAP) mediante ajustes técnicos o mediante la adquisición proactiva de las licencias necesarias.

En este caso, la atención no debe centrarse únicamente en la resolución de problemas a corto plazo. Más bien debe crearse una transparencia sostenible, si es necesario en colaboración con especialistas. El objetivo de las soluciones desarrolladas es establecer un conjunto de normas para la identificación y evaluación proactiva del uso indirecto en la empresa.

Caso práctico: Registro de tiempos

Para arrojar más luz sobre el ejemplo del registro del tiempo y comprender cuándo un
propia solución provoca una infracción de conformidad, se dan tres escenarios diferentes
utilizado a título ilustrativo.

Los empleados de una empresa utilizan un software de registro horario propio o de terceros para registrar el tiempo de trabajo. Los datos se transfieren al sistema SAP a través de SAP PI.

1er escenario:

Todos los usuarios que utilicen el software de registro de tiempos deberán tener una licencia. La cantidad exacta de licencias de usuario designado necesarias requeriría un análisis para comprobar si los usuarios del registro de tiempos ya disponen de licencias de usuario designado y si los derechos que contienen son suficientes. Además, se requiere la concesión de licencias de la aplicación interna o de terceros (registro de tiempos) con SAP NetWeaver Foundation for Third-Party Applications.

2º escenario:

Una posible interposición de colas de mensajes, que sólo transmitan datos en bloque y con un retraso de tiempo a través de PI al sistema SAP previsto, podría representar una solución que los usuarios no clasifiquen necesariamente como relevante para la licencia. Sin embargo, esta posible solución técnica requiere al menos dos condiciones previas:

• Los requisitos contractuales deben establecerse en consecuencia.
• Las funciones del software ajeno a SAP no están ya incluidas en las soluciones SAP disponibles.

Sin embargo, este tipo de licencia no está claramente especificado, de modo que en caso de duda existe al menos una obligación de licencia como en el escenario 1 si el software SAP ofrece las mismas funcionalidades. Además, podría haber una licencia correspondiente para la cola de mensajes utilizada. Esto debe analizarse en caso de duda.

3er escenario:

Otra solución podría ser que un empleado de RR.HH. o un empleado de servicios compartidos introdujera manualmente en SAP los datos de los informes de aplicaciones ajenas a SAP. Este empleado tendría que tener una licencia y es importante asegurarse de que se le ha asignado la licencia correcta. Normalmente, para un empleado de RR.HH., se trataría de una licencia de usuario profesional de SAP.

Perspectivas

Los retos en la gestión de licencias no son un problema específico de SAP. Más bien, como ya se ha descrito, SAP pone a disposición de sus clientes una herramienta de apoyo para la correcta concesión de licencias. ¿Por qué se percibe, sin embargo, la gestión de activos de software como un tema muy complejo que a menudo genera problemas?

La digitalización de los modelos empresariales funciona con software y, en muchos ámbitos, el software es la base del funcionamiento de los procesos y modelos empresariales.

La creciente complejidad en el funcionamiento de las infraestructuras informáticas y las correspondientes aplicaciones de software también aumenta la complejidad de la correcta concesión de licencias del software utilizado. Limitarse a "contar, medir y pesar", como era posible en el pasado, ya no sirve de nada.

Desde que la virtualización y la computación en nube se utilizan cada vez más, los modelos de concesión de licencias de los fabricantes de software han aumentado mucho en complejidad debido a estos avances tecnológicos.

A muchas empresas se les pide ahora que establezcan modelos híbridos en la gestión de licencias que combinen la gestión de licencias originales, por un lado, y la gestión de modelos de suscripción, por otro. Esta tarea apenas la cumple ninguna organización de gestión de licencias.

Además, este tema no ocupa actualmente un lugar destacado en la agenda de la mayoría de los CIO. Según nuestra experiencia en consultoría, las empresas con más de 100.000 empleados sólo cuentan con una persona en la gestión de licencias que se supone que lleva a cabo la gestión de licencias para cientos de productos de software.

No es infrecuente que esto no cuente con el apoyo de una herramienta SAM profesional, sino que la gestión se lleve a cabo con la ayuda de listas de Excel. Si se tiene en cuenta que un solo fabricante de software cambia unas 50 condiciones de licencia cada semana, el resultado de semejante constelación sólo puede ser "no conforme".

Los debates emergentes sobre temas específicos, actualmente por ejemplo sobre el tema del "uso indirecto", aumentan las incertidumbres en la gestión de licencias, aunque este tema ya ha sido abordado por varios fabricantes de software desde hace años.

Debido a las recientes concesiones realizadas por SAP en relación con la puesta a disposición de los correspondientes modelos de licencia para los escenarios más habituales, es aconsejable evaluar con prontitud la situación de la licencia individual para participar de forma proactiva en estas concesiones en lugar de dejar de poder utilizar las opciones ofrecidas o no poder utilizarlas por completo en caso de auditoría de la licencia.

La nube es actualmente un tema candente para todos los fabricantes de software y los clientes esperan un ahorro de costes en comparación con sus costes actuales de licencias y mantenimiento. Pero, ¿cómo va a hacer un cliente un análisis de rentabilidad si ni siquiera sabe si sus licencias actuales son correctas y rentables?

Un caso de negocio debe calcularse sobre una base sólida, y una gestión de activos de software que funcione contribuye a ello. Lo mismo se aplica al tema de la ciberseguridad.

Una SAM en funcionamiento ayuda a una empresa a tener siempre una visión actualizada del software en uso en cualquier versión dada y, por tanto, a poder analizar adecuadamente los riesgos de seguridad específicos de cada versión.

¿Qué deben hacer los responsables de TI, qué se recomienda para afrontar los retos descritos? Una empresa que se ocupe de SAM debe implantar un modelo de gobernanza con funciones, responsabilidades y procesos que permitan una gestión eficaz y eficiente de las licencias.

En las grandes empresas, no es una tarea que puedan realizar uno o dos empleados, sino que la organización de SAM debe reflejar la complejidad de toda la empresa.

Debe utilizarse una herramienta SAM que apoye a los gestores de licencias en sus tareas y les permita controlar la cuestión. El paso a modelos de suscripción no es una solución para subsanar los déficits en la gestión de licencias.

El compromiso de la alta dirección es crucial para el éxito de la gestión de licencias. Para el CIO, SAM debe ser un componente importante de su estrategia global de TI. Una base segura es el prerrequisito básico para calcular los casos de negocio y tomar decisiones de inversión sólidas para las nuevas tecnologías.

Los resultados de un estudio internacional predicen que, en 2017, más del 75% de todas las actividades de transformación en la nube se llevarán a cabo sin conocer los costes reales de las licencias antes de tomar la decisión y sin un control efectivo durante la transformación. ¡Esto da que pensar!

[/av_textblock]