Révolution ou évolution ?

En collaboration avec l'entreprise chimique de taille moyenne Zschimmer & Schwarz, Consolut a effectué une migration afin de déterminer les nouveautés que simple Finance offre déjà aujourd'hui.

La possibilité d'effectuer une migration sur un système client loin de toute "condition de laboratoire" constituait à la fois une motivation et un défi. Du côté de Zschimmer & Schwarz, l'accent a surtout été mis sur des possibilités de rapport plus rapides et améliorées, ainsi que sur un accès simplifié aux tables de la base de données, afin de pouvoir concevoir des interfaces plus efficaces dans un environnement système hétérogène.

L'enfant a besoin d'un nom

En juin 2015, le moment était venu. Un système Hana (SAP ERP 6 EHP 7 sFin 1503) a été utilisé comme système de test, créé comme copie du système de production. Parallèlement, un système non Hana correspondant (SAP ERP 6 EHP 7, Windows) a été mis en place pour des tests comparatifs.

C'est là que nous avons remarqué pour la première fois ce qui est devenu une certitude par la suite : Les noms de produits et les désignations des versions sont modifiés par SAP à intervalles rapprochés. Si au début, les termes Smart Financials et Simple Finance existaient encore, en juin, il était toujours question de sFin.

SAP Simple Finance add-on 2.0 for SAP Business Suite powered by SAP Hana" est rapidement devenu "SAP Simple Finance, on-premise edition 1503". Au début, les versions se distinguaient encore par une numérotation classique croissante. Cet été, SAP a décidé de marquer la version par l'année et le mois de livraison (par ex. 1503 = mars 2015).

Il en va de même pour les Support Packages. Du point de vue de SAP, il s'agissait donc d'une migration avec la version "SAP Simple Finance, on-premise edition 1503, SPS 1505".

Les modifications des structures des tables dans le domaine FI/CO constituent le cœur des changements dans sFin. Jusqu'à présent, il existait dans SAP ERP des tables pour les postes individuels et les soldes dans les modules Grand livre, Comptabilité des immobilisations, Débiteurs, Créditeurs et Contrôle de gestion, mais elles sont remplacées par une nouvelle table centrale (ACDOCA, appelée depuis peu "journal universel").

Toutes les écritures de ces domaines doivent être centralisées dans cette table. La comptabilité financière et le contrôle de gestion sont réunis dans la base de données. Voilà pour la théorie. SAP associe ce nouveau concept à l'assurance que la stabilité de tous les programmes d'application sera maintenue.

Cela est garanti par le fait que, selon le nouveau concept, il est possible de continuer à accéder à certaines tables qui ne sont plus nécessaires (par exemple BSID, BSAD, COSP) via des "vues de compatibilité". Les programmes d'application continuent donc d'utiliser les anciennes tables ou vues.

Les données réelles sont toutefois appelées via de nouvelles vues, à partir de la nouvelle table ACDOCA. SAP parvient ainsi à mettre en œuvre un nouveau concept de table sans devoir procéder à des modifications massives dans les programmes d'application.

L'impact de cette approche sur les performances donne quelques résultats surprenants. Toutes les tables ne sont toutefois pas remplacées par des vues de compatibilité. Par exemple, la BSEG et la COEP continuent d'exister et sont remplies parallèlement à l'ACDOCA. Les informations sont ainsi délibérément maintenues redondantes.

Maladies infantiles

Avant d'entrer dans le nouveau monde de "simple Finance", SAP a mis en place un cockpit pour la migration des données. Il est clair et quiconque a déjà effectué une migration vers le nouveau grand livre ou autre s'y retrouvera rapidement.

Une série d'étapes doit permettre de transférer les données des anciennes tables de postes individuels et de soldes dans la nouvelle table universelle ACDOCA. Il y a un peu de Customizing en marge et chaque étape de migration est suivie d'au moins un autre programme de contrôle.

Ainsi, une migration pourrait probablement être réalisée en quelques heures si des messages d'erreur n'apparaissaient pas à un moment donné dans les programmes de contrôle. C'est là que la comptabilité des immobilisations se révèle être un fauteur de troubles.

Cela n'a rien d'étonnant, car les opérations de la comptabilité des immobilisations se répercutent sur plusieurs exercices, en raison de leur durée. Lors d'un contrôle, une modification du Customizing effectuée au cours de la dernière décennie peut tout à fait apparaître aujourd'hui comme erronée, bien que les programmes d'application ne s'en soient pas souciés pendant toutes ces années.

Ce qui complique encore les choses, c'est que la gestion des données dans la comptabilité des immobilisations est généralement un peu plus complexe que dans la comptabilité générale ou le contrôle de gestion. À ce stade, le projet ne pouvait plus avancer sans une déclaration OSS auprès de SAP.

Le soutien de Walldorf a tout d'abord conduit à l'importation de plus d'une centaine de notes, dont la date de validation était généralement proche de la date du jour. Nous étions entre-temps en août et notre hypothèse selon laquelle une version du programme datant de mai de la même année constituait une base suffisante pour la migration s'est avérée être une erreur.

Même si le support SAP s'est montré très serviable dans le traitement, nous disposions de son point de vue d'une version de programme désespérément obsolète. Lors d'autres entretiens, il s'est avéré que les programmes de migration de la comptabilité des immobilisations de notre Support Package présentaient quelques défauts conceptuels qui ne seraient corrigés que dans le prochain Support Package.

SAP nous a finalement aidés à éviter tous les écueils et à mener à bien la migration. Cela s'est accompagné de l'affirmation que ces erreurs étaient désormais résolues. Tout porte à croire que c'est le cas.

Une fois cette étape franchie, notre intérêt s'est porté sur les nouveautés de l'application. Un constat important : il n'y a pratiquement pas de changements dans SAPGUI. C'est là que SAP est rattrapé par sa stratégie intelligente.

Comme la nouvelle conception n'exige pas d'adaptation des programmes d'application, il n'y a pour l'instant aucun avantage supplémentaire. Qu'en est-il en revanche des applications Fiori, si souvent sollicitées ? Ici, notre conclusion reste indécise pour plusieurs raisons.

Le nombre d'applications Fiori est actuellement encore limité et ne diffère parfois que légèrement de l'interface SAPGUI par une réduction des possibilités de sélection. Dans les portails vidéo et les présentations, SAP présente trop souvent les mêmes processus spéciaux, ce qui renforce l'impression que la valeur ajoutée de Fiori est pour l'instant encore limitée.

Visuellement, les applications Fiori représentent certainement un progrès. Cependant, beaucoup de choses ne semblent pas cohérentes pour le moment et font penser à une évolution des transactions Enjoy bien connues. Il convient d'ajouter que certaines publications donnent l'impression que les fonctions et le nombre d'applications Fiori disponibles augmenteront sensiblement dans un avenir proche.

Toutes les personnes concernées avaient bien sûr de grandes attentes quant aux performances du système Hana. Pour permettre une comparaison, le système de production de Zschimmer & Schwarz (System i) a été copié sur une VM Windows et une VM Hana avec un matériel identique. La comparaison des performances a été effectuée au niveau SQL (voir tableau).

Le test #1 et le test #4 montrent la force du système Hana. Dans les deux cas, on observe une nette amélioration des performances lors de l'accès aux tables. La requête du test #4 est globalement comparable à celle du test #3.

Les résultats des tests #3 et #4 ont été surprenants. L'accès nécessaire sur Hana via la vue de compatibilité réduit nettement la vitesse de l'accès en lecture, de sorte que Hana est ici même plus lent que les deux autres systèmes en comparaison.

Nous attirons votre attention sur le fait que le matériel utilisé pour Hana n'était pas certifié par SAP. On peut s'attendre à ce qu'avec une Hana certifiée (et donc plus performante), les temps d'accès aux tables BSID et BSAD seraient de l'ordre de ceux de SAP ERP sous Windows.

Jusqu'à ce moment-là, nous n'étions pas vraiment satisfaits de nos résultats. Dernièrement, nous nous sommes penchés sur la possibilité d'établir des "rapports en temps réel" avec Hana. Une possibilité est d'utiliser Hana Live.

SAP livre Hana Live Content pour sFin. Il est ainsi possible d'accéder directement aux données de la table ACDOCA avec des outils SAP BI (par exemple BO Analysis for Office ou BO Design Studio).

La deuxième possibilité consiste à utiliser un "embedded BW" dans le système Hana. Pour cela, un client BW supplémentaire est créé dans le système Hana. Là aussi, SAP met à disposition un contenu qui permet d'accéder en temps réel aux données de base et aux données de mouvement de sFin.

Comme l'accès aux données se fait via des InfoCubes virtuels, les rapports peuvent être créés facilement et très rapidement à l'aide d'outils SAP BI standard. Dans les deux cas, aucun chargement de données n'est nécessaire. Les documents sont disponibles pour le reporting immédiatement après leur enregistrement. Les performances d'accès aux données ont été très rapides dans les deux possibilités.

Révolution et évolution

Avec sFin, SAP a introduit dans FICO un design de table orienté vers l'avenir. Au moment de notre projet, les programmes de migration comportaient encore des erreurs. Ces erreurs devraient toutefois être en grande partie éliminées avec un niveau de Support Package actuel.

L'utilité des applications Fiori est actuellement encore limitée. Il existe encore un potentiel dans ce domaine pour les années à venir. Le meilleur était à la fin. Les possibilités de reporting en temps réel sont, de notre point de vue, actuellement l'argument le plus fort en faveur d'une migration vers sFin.

Du point de vue de Zschimmer & Schwarz, la valeur ajoutée est surtout visible pour les clients SAP dont l'ensemble de l'environnement ERP fonctionne sous SAP. Cet avantage n'est pas encore visible pour les systèmes hybrides.

Zschimmer & Schwarz a donc décidé d'attendre la suite des événements et, le cas échéant, de réévaluer ultérieurement la version logicielle alors disponible. Peut-être y aura-t-il alors suffisamment de valeur ajoutée pour effectuer le changement, le cas échéant.