On nous demande souvent quel genre d’atténuation des risques et de mesures préventives nous conseillons à nos clients de prendre. D’abord et avant tout : Nous ne conseillons rien à nos clients ! Nous calculons seulement l’effet coût de chaque option évidente qu’ils pourraient considérer, identifier les options que nous pensons sont également des options viables, et créer une liste de pro et con pour chaque option. En conséquence, nos clients peuvent prendre leur décision eux-mêmes. Nous n’avons aucun rôle dans leur décision finale : c’est la beauté d’être impartial !
Les entreprises veulent généralement payer chaque centime qu’elles doivent pour l’utilisation de logiciels tiers: Nous ne conseillerions jamais aux clients de prendre d’autres mesures. À titre d’exemple, cependant, à un moment donné, nous nous sommes retrouvés dans une situation délicate où un client – pour de nombreuses raisons politiques internes – n’a pas agi en fonction de l’importante conformité que nous avons découverte. Nous en avons discuté avec le chef de projet de notre client et avons même envisagé la résiliation de notre relation à long terme, parce que nous ne voulions pas être associés à un tel cas. Finalement, nous avons envoyé une note de service aux membres du conseil résumant les risques et les difficultés que nous avions rencontrés et leur recommandant d’agir en conséquence. Curieusement, un jour plus tard, toute politique interne a cessé de jouer un rôle et le client a agi sur nos conseils et peu de temps après, ils ont été autorisés correctement. Devenir sous licence appropriée n’implique pas toujours l’achat d’un plus grand nombre de licences. Nous sommes en affaires parce que nous sommes experts pour conseiller des approches efficaces pour l’octroi de licences correctement autres que simplement l’achat de rabais énormes. La réponse peut inclure, mais ne se limite pas nécessairement à l’ajustement des infrastructures, au redéploiement de bases de données sur les mêmes infrastructures, à la migration de la définition de licence A à la définition B, ou à l’achat d’autres options de licence (souvent moins chères) que généralement être proposé par Oracle. Souvent, chacune des options susmentionnées constituera des aspects de la solution optimale. Tromper les auditeurs d’Oracle en modifiant ou en manipulant d’une autre partie les preuves d’audit n’est pas une option.
Au lieu de cela, nous trouvons qu’il est très utile d’utiliser l’information de vérification de façon proactive. Les clients existants seront d’accord que notre valeur n’est pas seulement dans le travail réel que nous livrons, mais aussi en aidant à gérer les attentes d’Oracle / pipeline. Par exemple, dans notre présentation lors de la webémission hébergée par DBTA, nous avons illustré une situation où un client qui a été accusé par Oracle pour avoir utilisé DataPump avec une réclamation associée pour 287 000 $. Dans ce cas, nous avons été contractés «après le fait». Si nous avions été contactés plus tôt, nous aurions reconnu proactivement la présence de DataPump Pour atténuer le problème d’une manière préventive, nous aurions rédigé un e-mail à envoyer à Oracle par le client, expliquant a) à quel point ils étaient surpris de trouver cette fonctionnalité dans une édition de base de données où elle n’appartenait pas, b) la fonctionnalité n’a été testée et s’est avérée pas à la hauteur des attentes et des coûts. Avec cette simple note, envoyée à Oracle avant la collecte des données d’audit réelles, le client peut avoir empêché un LMS opportuniste ou représentant des ventes de prévoir une nouvelle affaire avec une probabilité de 70%. Les tests dataPump n’auraient pas été un problème.
Toutes les mesures d’atténuation des risques que nous prenons visent à assurer la conformité, tout en éliminant les « risques de prévision des ventes ». Par exemple, nous informons les clients que le propre logiciel de contrôle de grille d’Oracle accepte et accepte les cibles de gestion par défaut, signalant que la sortie de l’audit est « Oui/Oui » pour « Licence convenue / accès accordé » dans grid Control (enfin, dans la version 12, le client peut créer un « défaut » pour cette « fonctionnalité » et nous conseillons aux clients d’utiliser cette option !) Avant d’exécuter les scripts d’audit, nous nous assurerions que le client a pris des mesures pour configurer correctement que la sortie Oui/Oui reflète l’utilisation prévue, reflétant ainsi ce qu’il devrait payer. Ce faisant, toutes les discussions et tous les efforts peuvent être ciblés sur des questions qui comptent. Comme autre exemple, nous vérifierions que si l’option Spatial utilise uniquement la fonction Locator et non de véritables données géospatiales, nous informerions Oracle avec précision et activité : le problème est que les scripts d’audit d’Oracle sont incapables de faire la distinction entre les ces deux, et nous aimerions empêcher nos clients de négocier un rabais de 90% avec un opportuniste ventes-rep sur les licences qu’ils n’ont pas besoin en premier lieu. La consultation professionnelle dans ce domaine peut prévenir une perte importante de temps, d’efforts et d’argent.
Il y a toujours beaucoup de considérations lors de l’examen des résultats de la vérification. Après tout, nous analysons quelques centaines de millions de lignes de données d’audit chaque année. Notre but est de toujours utiliser ces données faire la bonne chose au nom de nos clients et de s’assurer qu’ils répondent à leurs obligations légitimes de licence à Oracle. Mais tout aussi important qu’ils sont conçu efficacement et que le client ne paie que ce que le client doit vraiment.
