Big Bang ou évolution ?

Que recommandez-vous pour aller vers S/4 ? Faut-il une stratégie de groupe ou commencer par la comptabilité avec S/4 Finance ?

Hinrich Mielke : Pour réaliser le potentiel du passage à S/4 Hana, la conversion d'ECC 6.0 à S/4 Hana est un projet d'optimisation des processus commerciaux, voire de refonte des processus commerciaux.

Les cas d'utilisation possibles et rentables sont spécifiques à chaque client et nécessitent toujours une stratégie de groupe concernant les objectifs et l'intention du projet. Ensuite, il peut être abordé de manière ciblée.

La concertation avec le côté professionnel conduit aux premiers cas d'utilisation. On commence alors par exemple avec la comptabilité ou avec un secteur de l'entreprise qui fait office de phare. Le credo est toujours : "Think big, start small". Le big bang sera plutôt rarement adapté à la situation du client.

La roadmap S/4 en ce qui concerne les processus commerciaux adaptés et nouveaux est un chantier, quand et comment une roadmap Fiori voit-elle le jour ?

Mielke : La feuille de route Fiori personnalisée suit la stratégie du groupe et de S/4 Hana. Si de nouvelles couches d'utilisateurs sont envisagées (par exemple dans l'usine d'un constructeur automobile), Fiori doit être conçu différemment que si, par exemple, un acheteur doit recevoir une interface Information Worker pour ses tâches et pour améliorer son efficacité. Dans ce cas, l'intégration d'éléments Fiori et d'informations provenant d'un SharePoint peut être la bonne solution.

Quel est le plus grand défi pour les nouveaux utilisateurs de S/4-Hana : les processus commerciaux adaptés ou une nouvelle interface utilisateur ?

Mielke : Si l'on suit les nouveaux paradigmes et que l'on met en œuvre S/4 Hana dans son intégralité, le processus commercial et le processus de travail changent en soi. Ces nouveaux processus ne sont plus orientés sur les transactions, mais sur le processus et les exigences des utilisateurs :

Un changement de mentalité est ici nécessaire, en particulier pour les utilisateurs expérimentés. Cette nouvelle approche est représentée par Fiori. Le SAPGui peut continuer à être utilisé pour les transactions existantes, ce qui permet d'organiser un processus de changement continu pour les utilisateurs.

La plateforme pour S/4 est toujours Hana ou Hana 2 - quelles sont les différences ?

Mielke : SAP Hana 1 recevra des corrections d'erreurs, mais n'aura pas de nouvelles fonctionnalités. C'est en quelque sorte la "stable release". Hana 2 est ici la prochaine étape et amène la plateforme Hana à un nouveau niveau, prête à répondre à de nouvelles exigences commerciales comme l'IoT et à l'efficacité technologique comme les scénarios Active-/Active-read-enabled. Le très intéressant Hana Cockpit 2.0 est livré avec Hana 2 et constitue, selon les recherches d'Alegri, une avancée significative.

Que recommande Alegri et pourquoi - Hana ou Hana 2 ?

Mielke : Pour Suite on Hana, il faut actuellement utiliser Hana 1. Les projets actuellement en cours avec S/4 Hana se basent en général encore sur Hana 1 et ne changeront pas de base stable à court terme sans raison impérative.

Mais comme il n'y aura pas de SPS13 pour Hana 1, les clients seront de toute façon tenus de passer à Hana 2 à moyen terme. Hana 2 devrait donc être le choix pour les projets S/4 Hana qui démarrent. Dans les futures versions de S/4 Hana, Hana 2 sera nécessaire comme base.

Peut-on également passer de Hana à Hana 2 ? Quels sont les avantages ? Inconvénients ?

Mielke : Hana 2 est la prochaine étape technologique, elle se base sur SAP Hana 1 et est compatible en amont. Le changement se déroule de la même manière que la mise à niveau d'un nouvel API pour la base de données Hana. Les risques et les étapes technologiques sont identiques, tout comme les tests.

Pour les systèmes sources plus anciens, une étape intermédiaire vers SAP Hana 1 SPS12 peut toutefois s'avérer judicieuse. Mais comme les "Datacenter Service Points" sont supprimés, il faut déterminer individuellement, pour les environnements productifs, le bon moment et le bon paquet pour la transition.

Quelles sont les différences de licence entre Hana et Hana 2 et comment le client SAP existant peut-il prendre une décision ?

Mielke : Les licences SAP Hana dépendent du type d'utilisation et des fonctions utilisées de la base de données et de l'application SAP. SAP Hana 2 ne nécessite en soi aucune autre licence que SAP Hana 1, mais Hana 2 introduit de nouvelles possibilités d'utilisation dans le domaine de l'intégration - qui peuvent nécessiter des licences supplémentaires.

En règle générale, ce qui est inclus dans Hana 1, API12, ne nécessitera pas de licence supplémentaire pour Hana 2. Les besoins et l'utilité des licences pour Hana 1 ou 2 peuvent être déterminés sur la base d'une étude préliminaire correspondante.

Tout client SAP existant peut probablement se séparer de certaines extensions Abap. Mais qu'en est-il des indispensables fonctions Z ?

Mielke : D'après notre expérience, jusqu'à 85% des programmes Z/modifications ne sont pas utilisés ! Dans ce cas, il est judicieux de les arrêter temporairement, puis de les développer. Les autres sont modifiés et adaptés.

C'est pourquoi une analyse automatisée de l'utilisation est très utile, de sorte que les travaux indispensables soient effectués en priorité. C'est pourquoi Alegri propose une analyse automatisée de l'utilisation des développements propres dans le cadre du "Hana Readiness Audit" - de même qu'une "analyse d'impact" des transactions utilisées.

Dans quelle mesure la "conversion" tient-elle compte de l'espace de noms Z et des modifications Abap ?

Mielke : La conversion emporte avec elle tous les programmes Z et les modifications. Le bon fonctionnement est assuré dans le cadre du projet et peut nécessiter des adaptations. Le besoin d'adaptation qui en résulte peut être identifié et réalisé à l'avance, d'où l'importance de l'analyse préalable de l'utilisation.

Quelle est l'expérience d'Alegri en matière de temps et de coûts de projet pour la conversion S/4 ?

Mielke : Cela dépend toujours de l'ampleur de l'extension ou de la modification d'un système. Dans un projet client actuel, nous convertissons un système ECC 6.0 existant à S/4 Hana en l'espace de trois mois. Ce système est proche du standard et peut donc être converti avec un total de 15 personnes-mois.

Outre les processus d'entreprise, les données doivent également être transférées : Que doit savoir et prendre en compte le client SAP existant en matière de convergence des données ?

Mielke : La simple conversion des données vers S/4 Hana n'est pas critique, les futurs processus et sources d'informations inter-systèmes sont plus passionnants. Pour une utilisation compréhensible et transparente, de nouvelles méthodes sont nécessaires et devraient être implémentées en même temps que la mise en œuvre des nouvelles possibilités.

La gestion de l'information d'entreprise jouera un rôle essentiel dans les entreprises ; il convient ici de mettre en lumière les données, les processus et également les conditions organisationnelles.

Dans quelle mesure l'architecture S/4 doit-elle être prise en compte pour la convergence des données ?

Mielke : Une question importante ! Les interfaces pour l'échange de données vont changer et auront une influence sur l'architecture optimale. Il convient d'en tenir compte suffisamment tôt. L'architecture sur laquelle l'intégration sera réalisée devrait être déterminée le plus tôt possible.

Il peut s'agir par exemple de la HCI, il est possible d'utiliser des moyens de bord Hana (par exemple des tables virtuelles) ou un PO sur site peut s'avérer être une bonne solution. De même, un mélange de ces possibilités peut être optimal.

Quelles sont les principales différences en termes de gestion des données entre une base de données classique et le concept d'informatique en mémoire de Hana ?

Mielke : Une différence essentielle (en plus du concept connu d'In-Memory) est que le Dynamic Tiering permet de différencier les données en "Hot", "Warm" et "Cold". En d'autres termes, c'est la base de données qui détermine l'emplacement de stockage des données.

Pour l'application, c'est transparent : il y a un tableau et il n'est pas nécessaire de faire la distinction entre les lieux de stockage physiques. C'est un moyen simple et élégant d'optimiser les coûts, par exemple pour les données qui ne peuvent pas être archivées même après des années.

D'autre part, en raison de la compression interne transparente, une dénormalisation des structures de la base de données peut être effectuée.

Dans une future architecture S/4 Hana : Hana ou Hana 2 sont-elles suffisantes ? Ou faut-il aussi Sybase IQ, Hadoop, etc.

Mielke : Les futures architectures S/4 Hana seront en principe basées sur Hana et l'objectif devrait être de ne pas avoir d'autres systèmes de base de données en service. Selon le paysage, l'objectif d'utilisation et les capacités, un paysage réel chez les clients utilisera généralement d'autres pots de données, par exemple il y a APO avec le LiveCache. Pour les grands volumes de données, Hadoop s'impose. Hadoop est déjà utilisé par certains clients, indépendamment de l'ERP.

Et en résumé, la gestion des données de référence sous (Hana) S/4 sera-t-elle plus simple ou plus complexe par rapport à une SAP Business Suite 7 sur AnyDB ?

Mielke : Afin d'exploiter le potentiel de S/4 Hana, les exigences des utilisateurs et donc les efforts de coordination pour la gestion des données de base vont augmenter. Elle sera donc plutôt complexe, car MDM touchera désormais encore plus de domaines qu'auparavant.

Hana est la base technologique de nombreuses nouveautés et améliorations dues à une meilleure performance, comme la recherche et la comparaison de fiches ou l'analyse de similarité.