Des silos repliés sur eux-mêmes

Les problèmes classiques de contrôle des processus, tels que les dépassements, les processus individuels confus et les interventions manuelles spontanées, existent dans le monde S/4 sans solutions satisfaisantes. Le Software-as-a-Service ou Platform-as-a-Service est aujourd'hui incontournable et remplace désormais chez SAP de manière généralisée les anciens produits et concepts d'exploitation. Les avantages tels que l'évolutivité et l'externalisation de tout un niveau d'exploitation ne sont pas à négliger. Une filiale peut rapidement être transférée dans le S/4 Public Cloud et ainsi se connecter à S/4 Core. Il faut mentionner ici IBP (Integrated Business Planning) qui remplace APO (Advanced Planner and Optimizer) ainsi que SuccessFactors et Concur pour SAP HCM.

Avec des API web ouvertes et des protocoles de communication tels que Rest, Soap ou A2S/A2A, il est désormais possible de se connecter à l'ERP de SAP et l'intégration dans ITSM ou les produits de bus de service est reconnaissable. Cela permet aux clients existants de SAP d'intégrer également des produits alternatifs dans l'ERP. Pour que les nouveaux services agissent ensemble, des interfaces sont nécessaires. Ce qu'une interface autorise et si cela est suffisant d'un point de vue technique est laissé à l'appréciation de chaque équipe de produits et rappelle en fin de compte l'ancienne époque de Bapi. Il existe au moins une série de produits pour l'intégration des données et SAP a déjà abordé le thème du contrôle des flux de données avec l'Application Interface Framework.

Cette vision SAP "vers l'intérieur" de chaque service est particulièrement perceptible au début du cycle de vie. Par conséquent, les interfaces sont régulièrement étendues. Il n'existe généralement pas de norme uniforme, par exemple pour le contrôle des tâches, et les mises à jour arrivent parfois à l'improviste. Du fait de cette souveraineté du prestataire de services, le client existant ou l'intégrateur court derrière les fabricants. Dans le pire des cas, la situation peut même s'enliser si les changements ne sont pas communiqués. Ce qui est donc très pratique pour la flexibilité et le dynamisme des différents services peut devenir un calvaire pour l'intégrateur.

Mais il y a aussi des développements réjouissants : SAP s'efforce de créer des scénarios plus homogènes au niveau de la communication avant le contrôle. Ainsi, le scénario de communication SAP_COM_0326 apparaît déjà dans plusieurs produits. Ceux-ci se limitent toutefois pour l'instant essentiellement à BTP (SAP Business Technology Platform), car celle-ci offre une base unifiée, à l'instar du NetWeaver vieillissant. En tant que bloc monolithique, SAP BTP s'oppose toutefois au concept de (micro-)services.

La question de savoir comment les données doivent circuler entre les produits est donc largement abordée. En ce qui concerne la question de savoir si et quand il faut le faire, la situation est très différente. Certains produits offrent déjà des possibilités de contrôle avec des flux de travail complexes, d'autres ne réagissent qu'à une commande temporelle ou à des événements. Mais tous ont en commun le fait que la réflexion est généralement orientée "vers l'intérieur", afin de maîtriser leurs propres processus. Même lorsque des possibilités de contrôle existent, la question de savoir "par qui" n'est pas toujours claire du point de vue de la gouvernance, lorsque les processus sont attachés "quelque part" au produit. Un pilotage global ainsi qu'un suivi des processus de bout en bout, comme c'est le cas pour les processus ERP de base, s'avèrent difficiles.

Le besoin de voir l'état des processus de manière centralisée, d'intervenir en cas d'urgence ou de procéder à des adaptations ad hoc, n'est toujours pas satisfait. Les thèmes tels que les cycles spéciaux, les fenêtres de maintenance ou les scénarios Re-do ne peuvent de toute façon pas vraiment être représentés avec des commandes de silos. Honico s'occupe depuis plus de 25 ans déjà du thème de la commande d'installations en silo. Que ce soit à partir de NetWeaver avec BatchMan ou dans BTP et Cloud avec Easy Workload Scheduler. En fin de compte, les besoins n'ont pas beaucoup changé. Ce qui a changé en matière de SaaS, c'est qu'il n'est plus possible de "hacker" via la base de données ou le codage : C'est l'interface qui fait la loi. C'est ainsi que nous relions l'ancien monde de NetWeaver aux nouvelles techniques SaaS comme IBP, SAC ou BTP, afin de permettre un pilotage inter-ERP. Un outil de contrôle des processus ne sert pas seulement ici de capitaine sur le pont et crée de la transparence, il sert aussi à établir un standard.

Les avantages du SaaS sont indiscutables, mais les entreprises devraient se préparer à d'éventuelles restrictions dans le nouveau monde des interfaces, surtout en ce qui concerne l'orchestration des processus commerciaux. En particulier, les processus de base devraient au moins correspondre à l'ancien standard ; en outre, la résilience des interfaces augmente considérablement, car des scénarios de reprise plus complexes peuvent être conduits automatiquement et arrêtés immédiatement en cas de véritable catastrophe, afin d'éviter des dommages critiques pour l'entreprise.

Vers l'inscription du partenaire :