Conocer los Oracle Audit Triggers y saber qué puede desencadenar una auditoría de licenciamiento en nuestra empresa, es el primer paso para prepararse de forma efectiva.
Desde hace varios meses, y con relación a las auditorías de licencias de Oracle, estamos comprobando cómo se van consolidando ciertas tendencias que se iniciaron ya en 2020 durante la crisis del Covid 19, como por ejemplo:
- Reducción del número de medianas y pequeñas empresas auditadas (puede deberse en parte a la desaparición de Seven Eighths como JPE Partner de Oracle)
- Quizá mayor flexibilidad, por parte de LMS, en ciertas situaciones relacionadas con la virtualización y la consideración de Soft Partitioning.
- Mantenimiento de la agresividad e imposición de plazos y obligaciones no contempladas en el contrato.
- Uso de la nueva cláusula contractual de auditoría por la que se obliga al cliente a ejecutar los scripts proporcionados por Oracle.
En todo caso, las auditorías de software continúan siendo un foco potencial de riesgos financieros: sigue siendo el instrumento favorito de Oracle para forzar negociaciones comerciales (cuando otras vías convencionales fracasan) con la excusa de tener que resolver una “supuesta” situación de incumplimiento detectada que, en muchos casos, en más que discutible.
En este artículo, exploraremos los principales Oracle Audit Triggers que pueden desencadenar una auditoría de licenciamiento de Oracle, ya que comprender las causas y cómo funcionan nos permite facilitar considerablemente el proceso:
Trigger #1 Cambios en el entorno tecnológico
El cliente puede situarse bajo el radar de Oracle si hace algún cambio que pueda impactar en la cantidad de licencias necesarias sin que exista paralelamente ninguna adquisición. Algunos ejemplos son:
- Cambio de hardware: si se incrementan los cores o el core factor aplicable es menos benévolo, aumenta también el número de licencias Processor requeridas.
- Uso de ciertas tecnologías de virtualización: el uso de ciertas tecnologías de virtualización calificadas como Soft Partitioning (ej. VMware) puede llevar a tener que licenciar cores de servidores (o clusters de servidores) en los que Oracle no se está utilizando.
- Migraciones (por ejemplo a cloud) pueden generar situaciones temporales de duplicidad en las que se multiplique el requerimiento de licencias.
Trigger #2 Cambios societarios en el cliente
Oracle no es ciego ni sordo. Ciertos cambios societarios o empresariales pueden tener impacto en licenciamiento y ésta es oportunidad que Oracle puede no dejar pasar:
- Fusiones, adquisiciones y desinversiones: es imprescindible tener claro qué está contemplado en la definición contractual de cliente. Puede tener también especial impacto si tiene lugar durante la vigencia de un ULA White Paper).
- Incrementos en el número de empleados/usuarios (White Paper)
Trigger #3 “Jugar” con el soporte
El soporte es una de las gallinas de oro de Oracle y con eso no se juega.
El soporte (OpEx) es el 22% del precio de la licencia (CapEx) y se actualiza anualmente (Inflationary Adjustment Rate o IAR): si bien el incremento históricamente estaba en torno al 4%, en la actualidad ha llegado al 8% por lo que es fácil entender que por efecto del interés compuesto, es un concepto que tiende a descontrolarse al mismo tiempo que Oracle gana cada vez más y más (a costa del cliente, claro).
Es por ello que, en aquellos supuestos en los que el cliente quiere controlar este concepto bien reduciéndolo (por ejemplo adaptándolo al uso real y necesario del software), bien eliminándolo (por ejemplo optando por una solución de soporte de terceros), Oracle puede tratar de defenderse notificando una auditoría al cliente.
Trigger #4 No cumplir con sus expectativas comerciales
Oracle tiene grandes planes comerciales para sus clientes, el problema es que los clientes rara vez pueden seguirle el ritmo (en la mayoría de casos ni lo quieren ni necesitan).
Esto puede provocar que si el comercial de Oracle no ha podido convencer al cliente de las bondades de su producto (por ejemplo migrar a OCI), se decida por alternativas menos convencionales como pedir que se le notifique una auditoría en la esperanza de que se detecte alguna situación de incumplimiento que le permite ofertar su producto como opción para solventarla.
Trigger #5 Venganza
En más de una ocasión hemos asistido a cómo la adjudicación de ciertos proyectos a la competencia, ha sido respondido por Oracle con su correspondiente carta de notificación de auditoría.
Ha sido, por ejemplo, una situación que no ha resultado extraña en el ámbito del sector público.
Trigger #6 Métricas antiguas o inconsistencias en licenciamiento
Definitivamente, supone entrar en el radar de Oracle disponer de métricas antiguas de producto (por ejemplo Concurrent Device, Named User Single Server, etc.) o incurrir en cierto tipo de inconsistencias como:
- Mayor número de licencias de opciones de base de datos que de base de datos.
- Disponer de licencias de base de datos sin tener licencias de Enterprise Edition.
- Mayor número de licencias de ciertos productos (por ejemplo Tuning Packs) que de otros de los que dependen y sin los cuales no pueden utilizarse (Diagnostics Packs).
Trigger #7 Información no controlada
Decíamos que Oracle no es ciego ni sordo y sus “requerimientos de información” pueden llegar a cualquier persona de nuestra organización con cualquier excusa: proporcionar datos aparentemente anodinos sobre entornos de Disaster Recovery (White Paper) o accesos de usuarios vía internet, puede tener un fuerte impacto en licenciamiento.
No controlar información sensible o revelar cierto tipo de situaciones incluso durante una reunión informal tomando un café con el comercial, puede colocarnos en el punto de mira de una auditoría para “aclarar” la situación detectada.
Trigger #8 Malas regularizaciones pasadas
Si en el pasado pasaste por una auditoría y pagaste, Oracle ya ha olido sangre y eso nunca es bueno.
Sobre todo cuando es una práctica habitual en Oracle, ofrecer como parte de la solución de la “supuesta” situación de incumplimiento detectada en la auditoría, la adquisición de productos (ej. OCI) que nada tiene que ver con el gap detectado.
Una vez que saben que la solución que propusieron, en verdad no soluciona nada, es más fácil volver para ver qué encuentran esta vez.
Trigger #9 No renovación del ULA
A Oracle le encanta que los clientes renueven sus ULAs: el incremento sucesivo tanto del derecho temporal de despliegue ilimitado (CapEx) como de su soporte consolidado (OpEx) bajo un mismo contrato (CSI) es una prioridad para los comerciales ya que Oracle les recompensa particularmente bien por ello.
Vender que los ULAs son una especie de “espanta auditorías” es una práctica habitual del equipo comercial de Oracle, como también lo es llevar a cabo una en caso de certificación con el objetivo de detectar alguna situación de incumplimiento que requiera de la renovación del ULA como mal menor para proceder a su regularización.
Trigger #10 BONUS
Si antes el criterio temporal era uno de los principales Oracle Audit Triggers (era de hecho frecuente que las auditorías se repitieran periódicamente cada 3 o 4 años), lo cierto es que en la actualidad estamos viendo cómo parece que ciertas empresas (que por sus características antes habrían sido auditadas), están pasando de momento desapercibidas desde sus últimas auditorías en 2019-2020, quizá por la nueva tendencia de LMS a dirigirse a objetivos mucho más definidos.
Conclusión
Una auditoría de Oracle es siempre un proceso disruptivo que entraña un riesgo financiero del que hay que ocuparse.
Conocer los Oracle Audit Triggers que pueden activar una auditoría, es solo el inicio de la preparación para poder hacer frente a este tipo de acciones del fabricante y que nuestros intereses terminen prevaleciendo sobre los de Oracle.
En Evergreen Compliance somos antiguos auditores del fabricante y sabemos qué buscan, cómo, dónde y para qué. Y a nuestros clientes, eso les encanta.
Consúltenos sin ningún compromiso y conozca de primera mano cómo hemos ayudado a decenas de organizaciones que están su misma situación.
