Feuille de route privée S/4


L'un des meilleurs connaisseurs de SAP en matière de stratégie, de planification et d'opérations est Hinrich Mielke d'Alegri. Il est un auteur occasionnel de E-3 et s'occupe intensivement des roadmaps Hana et S/4 on-premise et off-premise.
Pour de nombreux clients SAP existants, il a déjà personnalisé S/4 et l'a également fait passer avec succès sur la plate-forme cloud Azure de Microsoft. A la fin de l'année, Hinrich Mielke, directeur SAP chez Alegri, a trouvé le temps de s'entretenir une nouvelle fois avec le rédacteur en chef de E-3, Peter M. Färbinger.
Peter M. Färbinger, E-3 Magazin : Monsieur Mielke, vous vous entretenez avec de nombreux clients - qu'est-ce qui touche les DSI à ce sujet, comment "aborder la question" et quels sont les pièges à éviter ?
Hinrich Mielke, Alegri : Le voyage vers S/4 Hana est l'un des sujets les plus complexes de l'informatique. En raison de la superposition avec le thème du cloud, il va de la mise à disposition de l'infrastructure, de la base de données, de l'application modifiée et de la collaboration avec les spécialistes qui en découle, à un modèle de support modifié, au développement logiciel agile et à une fusion croissante entre l'analyse et le traitement transactionnel des données.
Le front-end pour l'utilisateur final est modernisé et mobilisé avec Fiori. De ce fait et en raison des possibilités de code push down, les exigences en matière de gestion des droits au sein de Fiori et de la base de données ainsi que les approches hybrides dans l'administration en général s'élargissent.
Comme toujours avec les sujets complexes : Il est utile d'y apporter une structure et de considérer chaque aspect de manière pragmatique. L'important est de ne pas se perdre dans les détails - mais d'avoir une vision globale.
Färbinger : Plus facile à dire qu'à faire - comment démarrer ?
Mielke : Avec un inventaire propre : quels systèmes et services sont actuellement exploités et comment ? L'application, la criticité, les données techniques de base et leur évolution dans la série chronologique ainsi que le modèle d'exploitation sont importants.
A cela s'ajoutent les changements prévisibles pour les un ou deux ans à venir. Comment les systèmes seront-ils exploités, qu'est-ce qui est en interne et qu'est-ce qui est externalisé ou sous-traité ?
Toujours important : quel est l'état de mes licences, quels systèmes ai-je achetés, quand et à quelles conditions ? Ensuite, il faut regarder du côté des clients de l'IT :
Quels sont les domaines spécialisés desservis jusqu'à présent et comment, existe-t-il des accords formels et des conditions-cadres ? Quel est le niveau de connaissance de mes utilisateurs clés - quel est le degré de maturité en cas de changement ? Quels sont les cas de test existants ? Comment sont-ils documentés ? Les tests sont-ils déjà automatisés ? Comment les interfaces sont-elles documentées ?
Maintenant, la partie créative : quels seront les changements dans mes domaines d'expertise ? Quels nouveaux modèles commerciaux la transformation numérique permettra-t-elle à mon entreprise de mettre en place ?
Färbinger : Cela semble vaste - peut-on l'abréger ?
Mielke : Malheureusement pas vraiment, mais on peut s'y prendre petit à petit, mais le bon ordre est important - car tôt ou tard, tous ces aspects deviennent indispensables. En effet, beaucoup de ces informations existent déjà, parfois seulement dans les têtes.
Ici, une collection et une documentation sont incontournables. Bonus : Cela facilite énormément la procédure ultérieure et réduit les coûts. Les lacunes qui apparaissent maintenant peuvent être comblées sans contrainte de temps et avec une bonne qualité, des avant-projets peuvent être mis en place.
Färbinger : Des avant-projets ?
Mielke : Nous rencontrons régulièrement des clients qui ne sont pas encore passés à Unicode. C'est un super avant-projet : après le passage à Unicode, on dispose d'une description d'interface à jour, de cas de test documentés et, typiquement, d'un environnement techniquement à jour et optimisé.
D'autres avant-projets sont par exemple l'automatisation des tests, le passage à des partenaires commerciaux et un nouveau grand livre. Il est également possible de procéder à l'inspection préalable du code des développements internes et de réduire ainsi la portée du projet principal.
Cela permet également d'acquérir un savoir-faire en matière d'Abap et de Hana et S/4 - indispensable pour des développements performants avec SAP Hana. Il est important que la mission commerciale de l'IT soit définie, que l'image cible soit claire et qu'à partir de là, une stratégie globale soit développée et un plan directeur élaboré.
Färbinger : Parlons de l'objectif : où doit aller le client sur le plan technique ? Sur site ou dans le cloud ? Dans quel nuage ? Et pourquoi ?
Mielke : La tendance au cloud est de plus en plus forte. Chez tant de clients, le Digital Core restera on-premise dans un avenir prévisible. Cependant, de plus en plus de clients ont une stratégie "cloud first", dans laquelle il faut justifier pourquoi une nouvelle application n'est pas exploitée dans le cloud.
Il faut distinguer entre SaaS, PaaS et IaaS. Parlons d'abord de IaaS : IaaS peut faire valoir ses points forts, en particulier pour les systèmes Hana, car les modifications de dimensionnement peuvent être effectuées en peu de temps.
Färbinger : Pouvez-vous être plus précis sur ce point ?
Mielke : Avec plaisir. Techniquement, un système peut être réinitialisé en quelques minutes. Mais avec l'arrêt et le redémarrage et le chargement de la base de données Hana, cela peut prendre des heures, selon la capacité de l'infrastructure, la taille de la base de données et la complexité de votre environnement système.
Le choix du cloud doit être bien réfléchi. Un changement est possible, mais il est coûteux. Cela signifie qu'il faut limiter les coûts de changement et choisir ensuite le cloud qui convient. Peut-être que l'on a déjà d'autres services en cours d'utilisation par le fournisseur, il est alors judicieux d'y rester.
Par exemple, avec Office 365, les clients ont déjà réglé les contrats, les aspects de protection des données et les questions du comité d'entreprise avec Azure. Ici, l'obstacle est minime. Les clients du commerce ne veulent en aucun cas avoir un concurrent direct comme fournisseur.
Avec le "New Kid on the Block", il est possible d'obtenir de bons accords en tant que client précoce et d'avoir ainsi un avantage.
Färbinger : Pourquoi passer au cloud IaaS ?
Mielke : Même si tous les systèmes restent sur site à l'avenir : Pour la période de transition, IaaS est imbattable en termes de flexibilité et, s'il est bien géré, il est également économique.
Les systèmes de projet, de test et de formation peuvent être utilisés de manière optimale en termes de coûts dans le modèle Pay-as-you-go et les Capex peuvent alors être transformés en Opex - qui peuvent également être facturés selon le principe de causalité.
Färbinger : Un bon mot-clé : qu'est-ce que le côté métier retire du passage à S/4 Hana, à part beaucoup de travail et des processus modifiés ?
Mielke : Eh bien, normalement, SAP ferait ici une publicité - maintenant, je vais le faire brièvement : les premières améliorations sont venues dans FI/CO :
L'élimination des tableaux et des index a permis de réduire le volume et la complexité des données, tout en accélérant les analyses. Ceci n'est pas seulement dû aux possibilités techniques de la base de données In-memory-Computing, mais aussi à une large dénormalisation de la base de données.
La convergence de FI et CO réduit les rapprochements en fin de mois entre le contrôle de gestion et la comptabilité financière. Des changements comparables ont lieu dans la logistique, qui conduisent à des optimisations. Quelques points de pourcentage d'amélioration dans la logistique donnent rapidement des potentiels d'économie très importants.
En outre, la satisfaction des clients peut être augmentée grâce à l'amélioration des processus logistiques. Les changements peuvent être consultés en détail dans la "Simplification List". Elle compte aujourd'hui plus de 1000 pages, mais elle est tout de même disponible en allemand.
Färbinger : Et le côté professionnel aura une nouvelle interface ERP, n'est-ce pas ?
Mielke : Le front-end est complété par Fiori, une interface modernisée et flexible. Avec Fiori, même l'utilisateur occasionnel peut utiliser SAP et, au-delà des transactions, surveiller les statuts des workflows, s'informer sur les KPI et configurer un suivi des délais.
Färbinger : Ça a l'air bien, quel est le revers de la médaille ? Est-ce que cela fonctionne aussi sans Fiori ?
Mielke : Dans le cas de Fiori, il faut prendre une décision architecturale sur la manière dont le back-end Fiori sera exploité. En outre, une extension de la gestion des droits est nécessaire.
Si les Fiori standard ne suffisent pas, il faut développer. Les développeurs doivent acquérir le savoir-faire correspondant et, le cas échéant, le rôle de concepteur d'interface utilisateur doit également être rempli.
À mon avis, ce dernier n'a toutefois pas d'alternative, car la génération Z exige des interfaces qui correspondent à son expérience de vie, et SAP ne propose plus certaines fonctionnalités qu'avec Fiori.
Il y a aussi des clients qui, en raison du marketing interne, veulent utiliser Fiori le plus tôt possible. À ceux-là, nous offrons, avec la méthodologie Fiori Booster, la possibilité d'utiliser n'importe quel S/4 Fiori standard avec ERP/ECC 6.0.
Färbinger : Maintenant, à propos du passage - d'abord à Hana puis à S/4, ou Big Bang ?
Mielke : La plupart des clients procèdent en deux étapes pour l'ERP, d'abord ERP/ECC avec Hana, puis le passage à S/4. L'implication indispensable des métiers lors de la transformation vers S/4 prend du temps.
Le passage à Hana est plutôt un projet propre à l'informatique. La base de données et, le cas échéant, le système d'exploitation sont changés - tout le reste reste inchangé. Il est alors possible d'acquérir de l'expérience avec Hana et le système d'exploitation et d'établir et d'affiner les processus d'exploitation.
N'oubliez pas le cloud, l'intégration d'IaaS doit également être établie, idéalement, l'endroit où le système fonctionne n'est pas pertinent non seulement pour l'utilisateur, mais aussi pour l'administrateur. Le big bang est souvent choisi pour les systèmes avec peu ou pas de développements propres.
Färbinger : Mais peut-on calculer un business case pour la première étape "Suite on Hana" ?
Mielke : Maintenant, cela devient fondamental. Si chaque projet informatique doit avoir une analyse de rentabilité, l'innovation devient difficile. Les premières voitures étaient également plus chères et moins fiables que les voitures à cheval - visiblement pas de business case.
Une entreprise qui laisse le CIO justifier séparément chaque projet comme étant rentable se prive de sa force d'innovation. Je suis sûr que les entreprises qui ne s'approchent pas activement et à bras ouverts de la force d'innovation en matière de contenu avec Hana, S/4, Fiori, etc. auront des difficultés à moyen terme.
Nous le constatons chez certains clients : Au fil des années et des décennies, on n'a pas rénové en profondeur, mais, comme un oignon, on a ajouté de nouvelles couches autour de l'existant.
Maintenant, comme Gulliver chez les Lilliputiens, on est prisonnier d'une multitude de systèmes et d'applications et on ne peut presque plus bouger. SAP S/4 Hana, avec sa possibilité d'intégration, est une opportunité de consolider et de moderniser les processus de base.
Il est alors possible de relier de nouvelles applications et innovations passionnantes au système central. Car, et c'est là que nous revenons à l'analyse de rentabilité, les innovations doivent elles aussi apporter une contribution à l'entreprise, et celle-ci est réalisée dans l'ERP.