Temps de consolidation HFM vs FCC, partie 2

Les responsables financiers de Cardtronics et Allegis Group avec plus de trois ans d’expérience combinée dans l’utilisation d’Oracle Financial Consolidation and Close ont rejoint Perficient et Oracle pour une table ronde concernant leur parcours dans le cloud.

Richard Ng, directeur, Systèmes financiers, Cardtronics, et John Oliphant, responsable du développement financier chez Allegis Group, ont partagé les histoires de la migration de leurs organisations d’Hyperion Financial Management (HFM) vers Oracle Financial Consolidation and Close. Dans le premier article de blog d’une série en quatre parties, Richard et John discutent Oracle Cloud bénéficie du point de vue d’un client. Dans ce deuxième article de blog, Richard et John abordent les temps de consolidation, un sujet qui intéresse au plus haut point les clients d’Oracle qui envisagent de passer à FCC.

Pour visionner la vidéo phare sur ce sujet, cliquez sur le lien ci-dessous. Pour voir l’intégralité du webinaire, cliquez sur ici.

Par rapport à HFM, que pensez-vous de FCC et de la performance en termes de consolidations ?

[Richard Ng] Je pense que c’est mieux que HFM d’un point de vue temporel, mais je dois obtenir une part équitable de HFM.

Je pense que nous avons vu un temps de consolidation de 20 minutes (25-30 minutes) dépend de la quantité de modifications apportées aux données. À ce stade, nous commençons à voir une certaine détérioration, s’il y a beaucoup de changements dans la cellule de données, cela atteint parfois 40 minutes, mais nous n’avons rien vu de plus de 45 minutes environ. De temps en temps, il peut y avoir un hoquet qui ralentira les choses. Nous pouvons voir des temps un peu plus longs, mais en moyenne, il s’agit d’un temps de consolidation d’environ 30 minutes et c’est à peu près comparable à HFM.

[John Oliphant] La consolidation temporelle est presque identique. Et cela a en fait un peu augmenté, mais cela a vraiment à voir avec notre conception et notre mouvement de levage et de changement de vitesse. Mais notre voyage était comme ça, nous avons commencé le processus de migration des données, et nous avons immédiatement vu un problème avec la taille de l’ensemble de données, en utilisant quatre dimensions personnalisées et en ayant toutes ces données. C’est une application très lourde, nous avons donc dû utiliser le processus de consolidation par vue. Nous avons donc dû à la fois recharger les données et également reconsolider les données. Nous avons introduit trois ans, puis finalement, juste après notre mise en service, dans un délai de six mois, nous sommes passés au cube DSO, pas à cause des temps de consolidation comme vous l’avez souligné, car encore une fois, ils sont restés à peu près les mêmes que HFM.

Notre cube HFM était très optimisé, je pense que j’ai vécu dans ce guide d’optimisation des performances HFM. Je connais personnellement des administrateurs de base de données que j’appellerais directement sur leur téléphone portable parce que nous avons trouvé un moyen d’ajuster la base de données pour que cela soit fait et bien fait et que pendant la fermeture, nous puissions charger 6, 7, 9 fois par jour. Nous attendons la même performance avec FCC. Nous l’avons eu, mais seulement après une longue route. Ensuite, en ce qui concerne la taille de l’application, c’est là que nous, comme je l’ai mentionné un an et demi plus tard, nous sommes passés à DSO dès que nous le pouvions. C’était un gros projet que nous savions devoir faire parce que la taille de notre base de données était si grande qu’elle avait un impact sur des choses comme une simple restructuration.

Donc, si vous vouliez ajouter un compte, parce que c’était les dimensions denses, vous deviez déclencher une restructuration dense et cela prenait du temps. Nous avons constaté une réduction de 70 %, de 60 à 65 % du calendrier de la restructuration. C’était incroyable ainsi que la fenêtre de maintenance, qui est passée de 1 heure 45 minutes ou deux heures à 45 minutes – là où nous espérions l’avoir. Avec une application globale, nous ne pouvions pas dire aux gens de l’APAC : « Hé, vous avez une fenêtre de deux heures pendant laquelle l’application est en panne ». On pourrait dire : « A l’heure du déjeuner, c’est en panne ». Les temps de consolidation sont restés à peu près les mêmes que ce que nous attendions de HFM, sinon un peu plus. Mais notre fenêtre de maintenance et nos délais de restructuration ou d’actualisation et de restructuration ont diminué. Comme je l’ai dit, 60 % depuis le passage à DSO.

La perspective du parfait

Oracle a introduit Dense Sparse Optimization (DSO) en août 2021. Pour citer Richard Wilke, vice-président du développement de produits, « Nous avons réuni tout un groupe de personnes intelligentes dans une pièce et nous avons essentiellement dit, vous les gars, découvrez comment nous pouvons optimiser les performances. De quelles manières pouvons-nous améliorer les choses ? Comment pouvons-nous, … comme tout ce que John a dit, comment pouvons-nous accélérer la maintenance ? Comment pouvons-nous accélérer les consolidations ? Comment pouvons-nous faire toutes ces choses, réduire la taille de l’application ? Les sauvegardes sont donc plus rapides. Et le résultat de cela a été le DSO.

Selon Richard, toutes les applications sont désormais au niveau ou plus rapides que HFM. Les performances sont vraiment bonnes et ne feront que s’améliorer avec de nouveaux processus améliorés à mesure qu’ils seront déployés au cours des cycles de correctifs mensuels.

Qu’est-ce que l’optimisation Dense Sparse ?

Toutes les nouvelles applications Financial Consolidations sont configurées avec Période et Mouvement comme dimensions denses au lieu que la dimension Compte soit désignée comme la seule dimension dense.

Le principal avantage réside dans les performances de consolidation et la réduction de la taille des applications. Après des tests approfondis de cette nouvelle fonctionnalité, Oracle et certains partenaires, y compris Perficient, ont noté que le temps de consolidation avait été considérablement réduit, dans certains cas, la taille de la base de données et le temps de consolidation avaient été réduits de 75 %. Un autre avantage évident du nouveau modèle est que les dimensions Mouvement et Période ne sont généralement pas mises à jour aussi souvent que les comptes. Vous n’êtes plus obligé d’effectuer des restructurations denses chaque fois que de nouveaux comptes sont ajoutés, ce qui peut vous faire gagner des heures précieuses pendant le cycle mensuel de pré-clôture/maintenance.

Au fur et à mesure que nous effectuons ces implémentations et migrations, nous constatons les immenses avantages des cubes optimisés denses et clairsemés. Toutes les nouvelles applications que nous construisons sont toutes compatibles DSO. Du point de vue d’un partenaire de mise en œuvre, c’est un choix clair.

Comme avec la plupart des implémentations, des calculs/règles personnalisés sont presque toujours nécessaires dans les processus de consolidation, avec l’application DSO, nous pouvons créer des règles personnalisées avec moins d’impact sur les performances globales.

D’autres éléments doivent être pris en compte lors du passage à l’application DSO à partir d’applications FCC héritées, résoudre des commandes, des formules, etc. Ces artefacts peuvent devoir être mis à jour car l’application DSO se comporte différemment de l’application à dimension dense unique. La migration elle-même est automatisée et assez simple. Comme dans toute activité de migration de ce type, beaucoup de temps et d’efforts doivent être consacrés au test de tous les artefacts personnalisés de l’application et à la mise à jour/modification de ces artefacts si nécessaire.