Entre agilité et stabilité

Par "numérisation", nous n'entendons pas la conversion de contenus analogiques (livres, musique, films) en médias numériques.

Nous entendons par là une méga-tendance favorisée par plusieurs nouvelles technologies telles que les capteurs, la communication mobile et le traitement ultra-rapide des données, qui se résume finalement à une synchronisation en temps réel de la réalité physique et numérique.

Cette évolution n'est pas motivée par des fans de technologie ou des bricoleurs, mais par des avantages économiques tangibles. Le traitement automatique des données en temps réel crée des avantages qui peuvent être mesurés en euros et en centimes.

Un cas d'entreprise classique de SAP dans le domaine de la maintenance préventive : des capteurs dans le boîtier d'une pompe mesurent la température, l'humidité et les vibrations et transmettent ces données en temps réel à un système analytique.

De puissants algorithmes statistiques prédisent, à l'aide de règles basées sur l'expérience, la probabilité qu'une pompe donnée tombe en panne dans les prochaines 24 heures.

Si nécessaire, des messages ou des ordres de maintenance sont immédiatement créés. Le technicien mandaté sur place signale en retour l'état réel de la pompe et permet à l'application analytique d'apprendre à partir de prévisions erronées ou correctes.

Les avantages potentiels sont évidents : moins de temps d'arrêt pour les pompes, moins de fausses alertes et de pompes défectueuses et des coûts d'exploitation nettement plus faibles.

Le ROI ne tombe pas du ciel

Les potentiels sont énormes, mais le retour sur investissement visé ne tombe pas du ciel. Les services spécialisés et les services informatiques ont besoin de nouvelles architectures de solutions, de nouvelles qualifications et de nouveaux modes de pensée.

Notre scénario de pompage se compose de plusieurs sous-systèmes (voir illustration) 1) la pompe avec ses capteurs, 2) un Event Stream Processor (comme SAP ESP) qui calcule les probabilités de défaillance et crée des avis de maintenance, 3) une solution ERP pour le traitement des ordres de maintenance et la réception des données de confirmation et 4) un Rule Detection Engine qui génère les algorithmes dans l'ESP et les améliore en permanence.

Traitement des flux d'événements

Les flux d'événements - comme dans notre exemple - fournissent de grandes quantités de données dont la qualité est souvent incertaine. Avant d'être traitées, les données doivent être complétées et/ou nettoyées.

L'art de concevoir une architecture de solution consiste à trouver un équilibre entre un débit de données élevé et une grande tolérance aux erreurs. Des modèles d'architecture spécifiques (par exemple l'architecture lambda) ainsi que des paradigmes de programmation particuliers sont utilisés.

Circuits de rétroaction fermés

Les données de l'ESP et de l'ERP sont réunies dans le Rule Detection Engine pour y être analysées plus en détail et, sur cette base, améliorer les règles dans l'Event Stream Processor.

Les données historiques influencent donc indirectement les ordres de travail futurs. Il en résulte une boucle de rétroaction en soi.

Tout cela se fait automatiquement, en continu et - plus ou moins - sans retard ni latence. L'ensemble du système est donc en mesure de réagir de manière flexible lorsque de nouvelles connaissances sont acquises ou lorsque le "comportement" des pompes change (pour quelque raison que ce soit).

Les boucles fermées de contrôle ou de rétroaction ne sont pas nouvelles en soi, de nombreux systèmes de contrôle de processus les utilisent. L'innovation réside dans des modèles commerciaux entièrement numérisés :

De tels circuits de régulation n'existent pas seulement pour les étapes de processus dans la fabrication, mais pour des processus commerciaux complets. Les règles sous-jacentes ne sont pas rigides, mais peuvent être conçues de manière auto-apprenante.

Nouvelles qualifications

Le traitement des flux d'événements et les boucles de contrôle auto-apprenantes sont déjà en soi un défi pour les développeurs Abap chevronnés. À cela s'ajoute le fait que : Les solutions utilisent souvent des algorithmes statistiques sophistiqués (réseaux bayésiens, Arima/Armax, modèles de variables latentes).

Tant pour SAP BW que pour S/4, SAP a ouvert en grand la porte au monde des statistiques avec HAP (Hana Analysis Process), SAP PAL (Predictive Analysis Library) et l'intégration du langage R.

Les programmeurs expérimentés seront remplacés à l'avenir par des data scientists, et de nombreuses universités proposent déjà des masters dans ce domaine. Leurs diplômés travailleront dans cinq à dix ans soit pour vous, soit pour vos concurrents.

L'induction plutôt que la déduction

Les organisations opèrent aujourd'hui dans un environnement instable. Les comportements des clients et les règles de décision qui en découlent dans les processus commerciaux ne changent plus à un rythme annuel, mais quotidiennement, à l'heure ou à la minute.

Les architectures décrites ci-dessus doivent donc être extrêmement flexibles, tout en gardant une vue d'ensemble en matière de gouvernance et de conformité.

Cela ne fonctionne que si a) on se concentre uniquement sur les corrélations plutôt que sur l'explication des relations de cause à effet et b) on se laisse guider par les données plutôt que d'imposer sa propre vision du monde aux données (induction plutôt que déduction).

Le changement des mentalités correspondantes nécessite plus de temps que la simple migration technique d'ERP 6.0 vers S/4.

L'informatique en tant que compositeur

Le DSI peut jouer un rôle décisif dans ce processus et accélérer le développement de l'organisation. Que ce soit avec ou sans externalisation :

Il ne s'agit plus d'effectuer soi-même tous les travaux de développement mais de faire évoluer l'organisation de manière à ce qu'elle puisse gérer efficacement l'externalisation des travaux et la surveiller en fonction des résultats.

Par "axé sur les résultats", on n'entend pas les niveaux de service ITIL. "Orienté résultats" signifie que les prestataires de services informatiques sont évalués sur la base de critères de qualité pour la performance d'algorithmes (exemple : "précision en termes de défaillance d'une pompe").

Le fonctionnement détaillé de tels algorithmes joue un rôle secondaire et doit, dans le meilleur des cas, pouvoir être compris par les propres collaborateurs.

Les portails de crowdsourcing comme www.kaggle.com pour le développement d'algorithmes ou le propre Idea Marketplace de SAP (ideas.sap.com) montrent la voie à suivre.

L'équilibre entre agilité et stabilité ne peut être atteint que si les experts informatiques en interne évoluent de "musiciens" à "compositeurs". Au lieu de placer toutes les fonctionnalités possibles dans des programmes Z ou des BAdI, il est possible d'utiliser l'ouverture d'une plateforme comme Hana pour intégrer d'autres solutions, par exemple via les Extended Application Services (XS).

Ainsi, des tâches simples (par exemple : reporting via Tableau) ou des étapes de travail très spécifiques (calcul des temps de trajet dans le cadre d'une segmentation de la clientèle en temps réel) peuvent être externalisées vers d'autres applications.

En même temps, lors de la mise en place des flux de données, il faut clarifier où des structures persistantes sont nécessaires (par exemple la nouvelle Adso dans le BW basé sur Hana) ou ce qui doit être représenté par des structures virtuelles (par exemple Open ODS View) ou hybrides (par exemple Composite Provider).

En fin de compte, c'est au DSI qu'incombe la responsabilité de veiller à ce que son organisation puisse prendre de telles décisions et organiser de manière souveraine des instruments tels que le crowdsourcing ou le SaaS.

Comprendre les probabilités

Les systèmes ERP classiques sont organisés de manière déterministe. Il est bien sûr possible d'enregistrer des probabilités de commande au niveau des postes d'offre dans SAP CRM.

Mais à l'étape suivante, l'offre devient ou non une commande client. Les étapes suivantes (telles que la planification des besoins en matériaux) ne sont pas contrôlées par des probabilités.

Pour Hana - une plate-forme dotée de multiples fonctions stochastiques - c'est une grave limitation. À l'avenir, il s'agira donc de prendre des décisions partiellement automatisées, non pas sur la base d'hypothèses (probablement erronées), mais sur la base de probabilités calculées (beaucoup plus proches de la réalité). E

e scénario de pompage en est un exemple : avec un nombre limité de techniciens de service, les avis de maintenance ne sont déclenchés qu'au-delà d'un certain seuil de probabilité - déterminé par la machine et adapté en permanence.

Conclusion

Hana est un instrument d'une valeur inestimable pour la conception numérique des processus commerciaux. Pour exploiter ce potentiel, les architectures, les exigences posées aux collaborateurs et les modèles de pensée traditionnels doivent être fondamentalement remaniés.

L'accent de l'IT se déplace de la négociation des niveaux de service vers la composition d'une symphonie d'applications et de partenaires.

Dans le prochain article de notre petite série, nous nous pencherons sur la détection de cas d'entreprise à valeur ajoutée pour la "numérisation" avec Hana.