Les chemins vers la feuille de route SAP

D'après mon expérience, l'incertitude provient du fait que de nombreux programmes et instructions sont trop techniques. Ils sont trop axés sur le produit ou l'application. Le problème est que, de cette manière, ils ne fournissent guère de réponses aux questions de ceux qui décident d'un projet de cette envergure.

De nombreux responsables informatiques ou DSI sont ainsi confrontés à un défi : ils doivent d'abord convaincre leur conseil d'administration ou leur direction de la nécessité d'une migration. Mais les décideurs ne s'occupent généralement pas des questions techniques.

Green, Brown ou Blue ? Les différences de voies et d'outils ne sont généralement pas connues dans les sphères dirigeantes. Et ces différences ne peuvent pas non plus être communiquées de manière judicieuse ou présenter un intérêt particulier. A cela s'ajoute le fait que, d'un point de vue technique, toutes les "couleurs" sont de toute façon toujours possibles.

Il est essentiel qu'un programme de feuille de route apporte des réponses appropriées. Il ne s'agit pas seulement de la faisabilité technique. D'après mon expérience, six aspects jouent un rôle central. Tous ceux qui s'engagent sur la voie de S/4 devraient les prendre en compte.

Stratégie

Toute réflexion et analyse commence par la question des objectifs stratégiques d'une entreprise - et de la manière dont ces objectifs peuvent être atteints à l'aide de l'informatique. Il est essentiel à ce stade de formuler des objectifs mesurables.

Il ne s'agit donc pas de slogans comme "numérisation" ou "cloud readiness". Il s'agit plutôt d'objectifs concrets comme "augmenter le rendement de la production de x pour cent en utilisant des scénarios optimisés pour la planification fine". Plus les objectifs sont formulés de manière précise, mieux c'est.

Outre la fixation des objectifs, il est indispensable de mentionner également les points forts d'une entreprise. Une telle force pourrait être : "la possibilité de modifier une commande client jusqu'à x jours avant l'expédition ou la remise". Définir ses points forts et les consigner permet de conserver son avantage concurrentiel.

Pour trouver et formuler les objectifs mesurables et les points forts, de brefs entretiens "d'égal à égal" sont appropriés. Ils doivent être menés de manière professionnelle. Ces entretiens peuvent être menés par des conseillers habitués à travailler avec des cadres supérieurs.

Paysage cible

Chaque entreprise vit et développe ses propres processus. Il s'agit d'abord de comprendre ces processus. Pour cela, la documentation existante est généralement suffisante. Une évaluation des processus et fonctions actuellement utilisés fournit d'autres informations. De brèves initiations par les collaborateurs sont également utiles. Ce sont souvent eux qui connaissent le mieux les particularités de l'entreprise.

Les conseillers comparent ces connaissances avec les objectifs élaborés précédemment. De cette manière, ils peuvent concevoir une architecture de système cible. Selon moi, deux aspects sont particulièrement importants à cet égard : d'une part, le paysage cible ne doit pas être développé uniquement dans l'optique de SAP.

D'autre part, la disponibilité effective sous S/4 doit être vérifiée - par exemple pour les composants qui ne sont disponibles qu'en mode dit de compatibilité. Dans le cadre de ces analyses, les experts doivent installer et exécuter le SAP Readiness Check. Ils peuvent ensuite étudier et évaluer les résultats du contrôle.

En outre, il est recommandé de comparer sommairement l'environnement cible avec les meilleures pratiques SAP. Cela permet de savoir quelle est la part du standard SAP dans l'environnement informatique prévu.

Une comparaison en direct avec les experts en processus de l'entreprise dans un système S/4 Sandbox serait également parfaite. De cette manière, il est possible de clarifier la manière dont les exigences stratégiques et opérationnelles peuvent être représentées.

Scénario de transition et options

En principe, il y a toujours plus d'une voie qui mène au but. Celui qui veut identifier la bonne voie pour son entreprise doit tenir compte d'une multitude de critères.

Il s'agit notamment de facteurs d'influence liés à la technique du système ou à l'organisation. Mais les coûts, la complexité de la mise en œuvre ou la disposition de l'entreprise à prendre des risques font également partie des critères. Des catalogues de critères et des listes de contrôle conviennent à l'analyse et à l'évaluation.

Souvent, les options sont réduites à seulement trois scénarios - à savoir une nouvelle mise en œuvre (greenfield), une conversion du système (brownfield) ou une migration sélective (bluefield).

D'après mon expérience, cela n'est pas très utile. La raison en est que les "couleurs" ne font que refléter des distinctions dans la configuration technique du système et la migration des données - et ce uniquement de SAP ECC 6.0 vers S/4.

Le cas suivant : passer d'ECC à S/4 est avant tout un projet informatique. De plus, l'architecture du système de départ et celle du système cible sont identiques ou presque. Dans un tel cas, ce sont surtout les procédures à orientation technique comme Brownfield ou Bluefield qui entrent en ligne de compte - et Greenfield est probablement exclu.

Dans une autre entreprise, par contre, le besoin de processus modernes ou standardisés est énorme. Dans ce cas, le choix se porterait plutôt sur Greenfield - et Brownfield et Bluefield seraient plutôt écartés.

Le moment de la décision joue également un rôle. Plus la décision de passer à S/4 est prise tard, plus les différences entre l'architecture de départ et l'architecture d'arrivée sont importantes.

Dans ce cas, le greenfield serait plus approprié, tandis que le brownfield et le bluefield ne le seraient pas. Pour les entreprises à la croissance dynamique, il peut également être utile de fixer des objectifs intermédiaires concrets. Si l'entreprise atteint un tel objectif, elle réalise déjà une valeur ajoutée mesurable - indépendamment du moment où le voyage vers l'objectif se poursuit.

Effort et coût

Les coûts et les dépenses devraient être calculés très tôt - et si possible de manière complète et transparente. Cela vaut en tout cas s'il ne s'agit pas d'une mise en service agile, par processus. L'accent devrait être mis sur les facteurs générateurs de coûts.

Parmi ces facteurs figurent les coûts des dépenses internes de l'informatique propre, les coûts de licence ou encore les coûts d'exploitation des systèmes pendant la durée du projet. Parfois, plusieurs variantes d'une architecture de système cible entrent en ligne de compte. Souvent, il existe aussi plusieurs possibilités de changement. Dans de tels cas, il est recommandé d'établir les calculs en fonction des options.

Minimiser les risques

Toute mise en œuvre de S/4 comporte également des risques. C'est le cas des coûts et des changements qui y sont liés. Les risques peuvent être différents, par exemple en fonction de la taille de l'entreprise ou de la mesure dans laquelle elle utilise déjà SAP. Tous les risques doivent être reconnus et identifiés.

Il est important de prendre en compte les préoccupations du top management - par exemple en ce qui concerne les risques opérationnels, la protection des investissements ou la pérennité de l'architecture cible mise en place.

Si les inquiétudes ne sont pas entendues, il se peut que les décisions nécessaires ne soient pas prises ou qu'elles soient soumises à des conditions strictes. Un concept de transition convaincant tient donc compte des préoccupations de la direction. Plus encore : les risques doivent être présentés comme maîtrisables grâce à des mesures appropriées.

Les entreprises devraient travailler avec des listes de contrôle des risques appropriées. Ces listes peuvent être complétées individuellement. Pour les grands projets, il peut en outre s'avérer utile d'établir une gestion des risques comme élément permanent de l'organisation du projet.

Organisation du projet

L'organisation professionnelle d'un projet S/4 est essentielle pour sa réussite. Les rôles et les responsabilités prévus dans le projet doivent être clairement décrits. Il est préférable de les attribuer à des personnes potentielles de l'entreprise concernée. C'est à ce stade que l'on constate souvent des goulots d'étranglement au niveau des capacités.

Cela vaut également pour la délimitation des compétences et la composition des organes. Les rôles ou le contenu des tâches varieront en fonction du type et de l'ampleur du projet. Les entreprises devraient toutefois toujours veiller à ce que les représentants du monde de l'entreprise et de l'informatique soient représentés par leurs experts.

Pour les grands projets, il est recommandé de réfléchir à des rôles spéciaux. Il s'agit par exemple de la gestion du changement, de la gestion des risques ou de la gestion des contrats avec les fournisseurs.

Il est recommandé d'inclure un autre comité dans l'organisation du projet, en particulier pour les nouvelles introductions qui mettent fortement l'accent sur les processus SAP Best Practice et les normes de numérisation. Ce comité devrait examiner et valider les exigences en dehors de la norme SAP Best Practice.

Pour éviter de dépendre de sociétés de conseil externes, les entreprises peuvent développer en interne des détenteurs de connaissances sur S/4. Dans ce contexte, la formation à la nouveauté devrait avoir la priorité sur l'exploitation opérationnelle des systèmes SAP existants.

Il arrive aussi que les capacités soient insuffisantes. Dans de tels cas, il est possible de faire appel à des prestataires professionnels pour prendre en charge temporairement les services de gestion des applications. Ils garantissent que la propre organisation peut utiliser et soutenir le système nouvellement installé de manière professionnelle et autonome.