Comprendre l’ULA Oracle

Alors que s’est achevée le 30 mai dernier l’année fiscale 2015 d’Oracle, les inscrits au Kick-Off Partenaires du 25 juin ont pu appréhender les grandes lignes de la stratégie commerciale de l’éditeur pour cette nouvelle année via l’ULA Oracle.

Le focus sera mis, sans trop de surprise, sur la conquête de nouvelles parts de marché (Applications, Oracle Cloud,…) et la pérennité de la relation commerciale avec les clients existants.

D’un point de vue licensing, cette pérennité passe par la mise en avant des accords de licences pluriannuels, dont l’ULA sera, une fois encore, le fer de lance.

Définition de l’ULA

Sur le papier l’ULA (Unlimited Licence Agreement) est un accord de licences d’une durée pouvant s’étendre de 2 à 5 ans (en général proposé pour 3 ans) concédant au client un usage illimité des logiciels intégrés au contrat (ou quasi illimité, confère le point ci-dessous).

Il convient donc d’expliquer une première segmentation des accords ULA :

  • 1« Capped » ULA : est un ULA qui concède un usage illimité des solutions jusqu’à un certain seuil de déploiement. Au-delà de ce seuil, le besoin en licences additionnels est négocié en fonction du parc existant et de la durée restante du contrat. Cette option, un peu paradoxale, d’accord « illimité » mais « capé » ayant toutefois tendance à disparaître.
  • 2« Uncapped » ULA : est un ULA qui concède un usage illimité des logiciels intégrés au contrat, sans notion de seuil.

Pour la suite de l’article, nous nous focaliseront donc sur l’ULA « uncapped ».

Un accord ULA peut concerner aussi bien les solutions Oracle du groupe Technologies (les solutions de type bases de données, infrastructure et middlewares) que les solutions du groupe Applications (les applications métiers : ERP, CRM,…). Les métriques licences en sein de l’ULA restant d’ailleurs les mêmes que celles d’un contrat Oracle (OLSA) classique :

  • NUP, Processeur pour les solutions du pool Technologies
  • Component/Enterprise pricing utilisateur et usage pour les solutions du pool Applications

Construction et négociation d’un ULA

Le processus de construction d’un ULA est le suivant :

  1. Définition de la durée du contrat (à priori simple)
  2. Définition des logiciels à intégrer dans le contrat (tout aussi simple, l’organisation faisant « ses courses » en fonction de ses besoins actuels et à venir, ou en tout cas dans un avenir proche). Ces logiciels peuvent être déjà intégrés à un contrat Oracle existant ou correspondre à de nouveaux besoins.
  3. Définition d’un tarif « upfront » pour ces logiciels, défini par Oracle (et donc négocié par le client !) en fonction de l’état du parc existant et de l’estimation de l’état du parc au sortir du contrat (c’est donc ici que les choses se compliquent dans la mise en œuvre de l’ULA)
  4. Pour les solutions correspondant à un nouveau besoin dans l’entreprise : intégration de leur maintenance SUSL par annuité, pendant toute la durée de l’ULA
  5. Pour les solutions existantes dans l’entreprise avant la signature de l’ULA, réintégration de leur SUSL par annuité, pendant toute la durée de l’ULA
  6. A l’issu du contrat, le client conserve la propriété du droit d’usage des solutions « certifiées » par Oracle sur le parc. Les solutions certifiées étant les solutions déployées et exécutées sur le parc lors de l’audit de sortie du contrat (nous allons revenir sur cette notion).

 iMUO cycle de vie ULA Oracle 01
Concrètement, il est important de considérer en priorité les éléments suivants lors d’une négociation d’ULA : « Lessons learned » d’un accord ULA

  • La sortie du contrat reste un audit du parc, à considérer et à anticiper comme tel lors de la gouvernance contractuelle de l’ULA.
    • Il est donc essentiel de comprendre le modus operandi de la certification : quels seront les éléments demandés par Oracle ? Quel type d’information sera remonté par le jeu de scripts LMS ? Peut-on réaliser des audits « à blanc » pour anticiper les éventuels écarts tant sur l’usage des logiciels intégrés au contrat que sur l’usage de logiciels non encore couverts ?
    • L’audit Oracle concluant sur les droits d’usage des solutions déployées et exécutées sur le parc, cela signifie qu’il exclut par défaut les droits d’usage de toute solution non exécutée (ex : solution de type DRP passif, architectures en stagging, etc…). Il convient donc là aussi d’anticiper cette règle de sortie du contrat.
  • Il est aussi essentiel de pouvoir répondre aux questions suivantes (liste bien entendu non exhaustive) :
    • Avons-nous une bonne vision de l’augmentation de nos besoins en technologies/licences Oracle sur les trois/quatre/cinq prochaines années ? (car il s’agit bien ici d’une démarche de croissance des besoins)
    • Devons-nous prévoir une négociation sur les technologies non couvertes par le contrat ULA (ex : options et autre management packs de la base de données) ?
    • Quelle valeur de maintenance devons-nous anticiper/négocier au sortir du contrat ULA ? Si augmentation des besoins en licences, si réduction des besoins ?

Il convient aussi de garder à l’esprit la raison d’être de l’ULA du point de vue d’Oracle. Le dispositif permet entre autre pour l’éditeur :

  • De conserver à minima ses revenus sur la maintenance de ses solutions, sur un marché mis à mal par la conjoncture économique et le besoin en décroissance de licences processeurs/cœurs chez les clients existants, dans un contexte affirmé de consolidation des architectures (On Premise, Hostées, Cloud,…).
  • De gagner des parts de marché sur le middleware et les applications : en effet une fois engagé dans un ULA le client a plutôt intérêt (et a souvent tendance) à déployer ses nouveaux projets sur les solutions Oracle intégrées au contrat pour maximiser l’intérêt financier de la démarche. Le premier intérêt de l’ULA est donc de « fermer la porte » aux concurrents potentiels d’Oracle.

Pour l’éditeur comme pour le client, l’ULA peut aussi s’avérer être une piste de sortie « élégante » d’une problématique de conformité, puisqu’il est possible de réintégrer l’ensemble des solutions présentes dans l’accord.

Enfin, dans un principe de veille concurrentielle, il peut être intéressant pour un client n’ayant pas encore fait le choix des technologies (exemple Oracle vs. Microsoft) d’envisager en parallèle un dispositif EAP/SCE (ou NEAP) chez Microsoft. En effet ce type d’accord reprend en partie les mécanismes contractuels de l’ULA sur la stack applicative directement concurrente de l’éditeur : RDBMS, BI, ETL, applications et environnements de développement. Un bon exercice de comparaison technologies/licensing en perspective !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


The reCAPTCHA verification period has expired. Please reload the page.