Mon processus, mon application, mon avantage concurrentiel


Le monde aspire à des réponses simples ! La communauté SAP ne fait pas exception à la règle, surtout lorsqu'il s'agit de discuter de la transformation vers S/4. Du côté des intéressés, on argumente volontiers que S/4 maîtrise tout. La suppression de la prolifération des modifications Abap et des programmes Z, ainsi que le retour au standard, sont considérés - pour utiliser le jargon politique - comme des solutions sans alternative. Et si des souhaits de fonctions ne sont pas encore satisfaits, la communauté tient peut-être une solution adéquate à disposition dans les "magasins" publics d'applications.
Il ne fait aucun doute que S/4 offre un ensemble riche de fonctionnalités et des innovations techniques intéressantes. Il est indéniable que le retour au standard et le paradigme "Keep the Core Clean" disposent d'une grande force de persuasion. C'est particulièrement vrai pour les responsables SAP des entreprises qui sont confrontés quotidiennement à la prolifération de leur environnement applicatif. Mais il est également vrai que S/4 Hana peut beaucoup, mais pas tout. C'est surtout une contradiction dans les termes que de pouvoir générer des avantages concurrentiels à l'aide des meilleures pratiques et d'un ensemble de fonctions standard.
Il en va de même pour les apps issues de répertoires accessibles à tous. Une application du SAP Store, comme par exemple BTC Facility Issue Report pour la déclaration de sinistres, constitue certainement une aide appréciée dans le travail quotidien. Il faut toutefois faire preuve d'une grande imagination pour supposer l'existence d'avantages concurrentiels uniques dans des programmes issus de répertoires accessibles à tous. En forçant un peu le trait, on peut dire que les applications constituent le pendant mobile des fonctionnalités standard de l'application d'entreprise dans le backend.
En résumé, toute entreprise confrontée à la transformation S/4 doit inévitablement se poser la question du choix entre logiciel individuel et logiciel standard, ou se confronter à la question éternelle de l'informatique : "Make or buy ? La réponse à cette question se trouve déjà au cœur de la question - c'est le moins que l'on puisse dire. Il suffit de remplacer le "or" par un "and" et de mettre une minuscule au "make" par rapport au "buy".
Ce dernier terme peut être pris au pied de la lettre. En effet, une solution prometteuse combine le retour systématique au standard SAP et le développement individuel d'applications Fiori afin de réaliser des fonctions concurrentielles. L'avantage est que SAP met à disposition les outils de développement nécessaires, l'environnement d'extension (BTP Extension Suite, Enhancement Framework) et l'environnement d'exploitation (Fiori-Launch-pad). Il est en principe possible de procéder à des ajouts sans modification aux objets de données ou d'ajouter une logique de traitement individuelle.
Une nouvelle application est directement intégrée dans le concept d'autorisation SAP et fonctionne dans tous les scénarios d'exploitation pertinents dans le cloud ou sur site. Les applications Fiori tiennent compte de l'évolution de l'expérience utilisateur grâce au principe "mobile first", mais elles prennent également en charge l'utilisation sur le bureau.

Le must-have plutôt que le nice-to-have
Avant de se lancer dans la reproduction à l'identique des compléments et adaptations individuels de l'ancien système, il convient de mener quelques réflexions fondamentales avant la transformation. Il convient de déterminer avec soin les besoins individuels dont l'utilisation garantit des avantages concurrentiels par rapport aux concurrents. Pour ce faire, il convient de comparer l'étendue des fonctions standard mises à disposition par SAP avec les fonctionnalités souhaitées par l'entreprise, généralement déjà utilisées dans l'ancien système.
La deuxième étape consiste à recenser les fonctions impératives qui n'ont pas d'équivalent dans la norme. Le mot clé dans ce contexte est "impératif". Compte tenu de l'importance des ressources et du temps nécessaires à une transformation S/4, il semble contre-productif de réaliser à nouveau sous forme d'application chaque caractéristique sur mesure ou préférence individuelle en matière de design. Les investissements devraient se concentrer exclusivement sur les fonctions et les processus qui promettent une réelle valeur ajoutée. Pour l'identification, il existe une procédure simple mais fiable. Chaque réponse à la question : "Quelle est la fonction que nous sommes heureux de ne pas avoir comme standard ou que nos concurrents n'ont pas ?
have pour la réalisation. En effet, l'auto-évaluation indique que la fonction apporte une contribution notable au succès de l'entreprise.
Avantage concurrentiel
Comme l'objectif est de réaliser la fonction sous la forme d'une application Fiori allégée, il est interdit, ne serait-ce que pour des raisons d'efforts et de coûts, de choisir une méthode avec des frais généraux de gestion comme Scrum, Kanban ou d'autres. Il est dans la nature des choses ou, pour mieux dire, dans la nature de la tâche, d'accompagner le développement par une approche tout aussi allégée. Pour tester en peu de temps la résistance d'une proposition de fonction, le Design Sprint - une méthode très appréciée des start-ups et initialement proposée par Google Ventures - s'avère être une procédure appropriée. L'idée du Design Sprint est de valider en quelques jours des idées de produits, de réaliser des prototypes et de les faire tester par des utilisateurs, afin de pouvoir évaluer à la fin les chances de succès d'une mise en œuvre complète.
Un tel Fiori-Sprint se compose de quatre épisodes différents, qui durent idéalement une journée. Au début, il s'agit d'identifier les exigences, par exemple selon l'approche décrite dans le paragraphe précédent. La deuxième étape consiste à élaborer ensemble les détails de l'expérience utilisateur d'une application. Le prototype créé ensuite donne aux utilisateurs une première expérience de la mise en œuvre de la fonction sous forme d'application sur un smartphone, une tablette ou un PC. Une fois le test réussi, les responsables reçoivent des consultants une base de calcul solide pour le développement de l'application fonctionnelle et peuvent prioriser sa réalisation de manière appropriée dans le cadre de l'introduction de S/4.
Conclusion
Avec l'approche de solution esquissée, les entreprises ont une chance de premier ordre de continuer à faire valoir leurs points forts individuels en matière de processus sans mettre en péril le paradigme "Keep the Core Clean" du standard SAP. En principe, une sorte d'espace de données Z est reproduit pour la réalisation de fonctions sur mesure sous forme d'application. Celui-ci permet aux entreprises de sauver leur propriété intellectuelle et leurs connaissances sur les processus et fonctions optimisés, dont certaines sont conservées depuis de nombreuses années, dans le nouveau monde SAP - sur une nouvelle base et pour une fraction de l'effort financier et humain.
