Sur site, dans le nuage ou hybride ?

En matière de transformation, plusieurs chemins mènent à Rome. L'inverse du sage proverbe n'est guère utile : si l'on sait d'où l'on vient et où l'on se trouve, on sait aussi où l'on va. En fait, il existe plusieurs possibilités d'architecture système pour la transformation de chaque groupe cible SAP.

En amont de la préparation stratégique et de l'élaboration des critères factuels pour une aide à la décision, l'expérience montre que la priorité est d'abord donnée aux thèmes émotionnels. Dans le cas du cloud, par exemple, la philosophie de l'entreprise qui s'y oppose est avancée avant même la question de la sécurité, les différents points de vue des générations entrant souvent en ligne de compte. On voit ainsi quels soft skills peuvent influencer un sujet factuel et rationnel par des critères de décision multiples et inattendus. Il ne faut pas sous-estimer cette circonstance dans le contexte global.

La stratégie actuelle de l'entreprise et la stratégie informatique qui en découle constituent la base du processus de décision pour l'architecture système adéquate. En se basant sur ces piliers, les spécialistes informatiques du groupe de travail peuvent se pencher sur les détails nécessaires. 

Notre propre expérience nous a appris que la longue prise de décision concernant l'architecture du système se déroule au même niveau que la définition des processus. De nombreux participants investissent beaucoup de temps dans divers modèles, accompagnés de critères peu clairs et sans culture de décision suffisante. Au lieu de cela, l'expérience montre que la méthode des paramètres est beaucoup plus efficace pour choisir la bonne architecture de système. Le premier défi consiste à trouver ceux qui concernent réellement l'entreprise. Ce processus prend du temps, mais il se termine par la base de décision la plus importante pour la phase suivante.

Le travail de fond commence toutefois avec la répartition des paramètres en niveaux (par exemple général, IT/SAP, infrastructure et technique). Pour cela, les participants doivent être réduits à l'équipe centrale des spécialistes. Les paramètres définis par niveau doivent être classés par ordre de priorité et pondérés dans le cadre de diverses réunions à intervalles rapprochés. Ces évaluations permettent de limiter les architectures de système techniquement nécessaires et judicieuses via un arbre de décision ou une matrice et de les présenter à la direction. La décision finale est généralement prise sur la base d'un calcul de rentabilité.

En raison de sa complexité, le processus décrit brièvement ci-dessus pour trouver une architecture de système adaptée n'est possible que de manière très théorique dans le cadre de cet article. Néanmoins, certains détails doivent être abordés, au moins à titre d'exemple. Comme nous l'avons mentionné, le choix des paramètres, répartis en niveaux, est au cœur du processus. Voici une sélection de paramètres généraux : Secteur d'activité, commerce et/ou production, grande, moyenne ou petite entreprise et structure de l'entreprise, nationale ou internationale - la liste pourrait s'allonger à l'infini.

Par la suite, les paramètres spécifiques à l'informatique et à SAP sont examinés et sélectionnés. Il s'agit notamment de répondre à des questions telles que : Est-ce que je possède une informatique centralisée ou décentralisée ? Suis-je un nouveau client SAP ou un client existant ? Utilisons-nous ou souhaitons-nous à l'avenir recourir à l'internalisation ou à l'externalisation ? Cloud standard ou cloud privé ? Processus standard ou processus individuels ? Qu'en est-il de la sécurité, de l'évaluation des risques, du personnel, des licences et de bien d'autres aspects ? Les niveaux inférieurs devraient condenser de plus en plus les paramètres pour obtenir les informations détaillées nécessaires. Dans cet exemple, le troisième niveau prévoirait les détails du niveau de l'infrastructure, du matériel et des logiciels. Il faut absolument veiller à ne pas se disperser dans des détails inutiles en raison d'un trop grand nombre de niveaux et de paramètres, ce qui rendrait la prise de décision plus difficile. Moins, c'est plus !

Cette méthode est relativement simple, a fait ses preuves et contribue à trouver la meilleure architecture de système possible pour la transformation.