Roadmapping Hana - Le piège des données

Dans cet article, nous présentons un modèle de roadmapping pour une entrée progressive. Outre les logiciels, le matériel et les collaborateurs correspondants, l'entrée dans le beau nouveau monde de la numérisation et du big data nécessite avant tout une chose : des données.

Avec la collecte de données brutes non comprimées dans l'Universal Journal, le Central Finance et le One Exposure from Operations Hub ou avec le nouveau modèle d'architecture LSA++ fortement virtualisé, SAP crée actuellement des contenants appropriés pour l'évaluation de grandes quantités de données. Il est toutefois dommage que leur contenu soit souvent inutilisable pour des analyses statistiques.

La raison : d'une part, les processus commerciaux existants ne sont pas orientés vers cet objectif et, d'autre part, la pertinence de pratiquement toutes les méthodes statistiques dépend de la taille et de la qualité de l'échantillon. En d'autres termes, celui qui ne réfléchit pas maintenant à son objectif en matière de numérisation et à la manière de l'atteindre se retrouvera les mains vides dans dix ans en termes de données.

1ère migration

Pour les clients SAP, l'entrée dans la gestion numérique de l'entreprise commence par une migration d'une base de données classique comme Oracle ou MaxDB vers Hana. Cette migration pure de la base de données a pour effet d'accélérer considérablement les rapports et les fonctions sélectionnées (par exemple les transformations ou les activations dans BW).

De plus, de nouvelles interfaces (par exemple vers des systèmes de traitement d'événements ou vers Hadoop) sont disponibles. Mais en l'absence de nouveaux processus commerciaux, ces interfaces restent d'abord en friche.

Le retour sur investissement d'une simple migration de base de données ne se produit que dans le cas où l'accélération des fonctions logicielles génère à elle seule des avantages.

Si, par exemple, grâce à une activation plus rapide et à la suppression de certaines étapes de processus (par exemple : suppression et reconstruction d'index, statistiques de base de données et roll-up), les processus de chargement dans BW sont 50 ou 75% plus rapides, cela peut avoir deux conséquences :

Les goulots d'étranglement dans le traitement par lots disparaissent et les données importantes pour la prise de décision sont disponibles pour les spécialistes tôt le matin et non l'après-midi. Le premier permet peut-être d'éviter de nouveaux investissements en matériel, le second peut conduire à de meilleures décisions.

2. nouvelles fonctions

Une fois la conversion de la base de données effectuée, les nouvelles solutions "Simple" de SAP peuvent être activées facilement via le Switch Framework (SFW5).

Résultat : d'autres processus commerciaux sont accélérés grâce à des structures de tables allégées et au code push-down, et des fonctions entièrement nouvelles sont mises à disposition (par exemple la nouvelle gestion des comptes bancaires dans la gestion de trésorerie).

Après la migration, il est également temps de rendre les solutions spécifiques aux clients prêtes pour Hana. Logiquement, on se concentrera d'abord sur les processus commerciaux critiques en termes de vitesse.

3. nouvelles méthodes

En tant que plateforme et hub central pour la mise à disposition des données, Hana ouvre des portes vers les flux d'événements (mot-clé : ESP Plug-in for Hana Studio) et les données faiblement structurées/non structurées (mots-clés : HDFS/MapReduce ou NoSQL).

Seulement voilà : les processus commerciaux ERP classiques n'ont aucune utilité pour de telles données. Les potentiels de valeur correspondants ne peuvent être exploités que par la transformation des processus existants.

Il serait par exemple envisageable d'utiliser les données des réseaux sociaux pour prévenir les fraudes et mettre en évidence les propositions de paiement douteuses en vue d'une analyse plus approfondie.

Pour ce faire, il faut toutefois mettre en place des applications (SAP Fraud Management, Business Rules Framework) et éventuellement étendre les applications existantes (par exemple : le programme de paiement/F110). Le client est donc encore plus sollicité que pour le "tuning" des rapports ou des processus de chargement.

4. nouveaux algorithmes

L'accélération obtenue grâce à Hana permet d'utiliser des algorithmes connus différemment qu'auparavant ou d'utiliser pour la première fois des algorithmes nouveaux et gourmands en performances.

Exemple : une segmentation des clients en fonction de leur sensibilité au prix peut désormais avoir lieu non pas une fois par mois, mais pratiquement en continu. Au lieu de fixer des prix différents pour les marques de base et les marques haut de gamme avec des groupes cibles clairement définis, comme c'était le cas jusqu'à présent, il est désormais possible de proposer un seul et même produit à des prix différents en fonction de l'heure.

Avec l'introduction généralisée d'un affichage numérique des prix, le commerce stationnaire, après les compagnies aériennes et les boutiques en ligne, est maintenant en train de créer les conditions techniques pour une segmentation de la clientèle orientée vers le temps.

5. nouvelles stratégies

Les données de capteurs fournissent rapidement de grandes quantités de données, parfois erronées ou lacunaires. Cela représente à lui seul un défi de taille pour les organisations informatiques classiques.

Mais il y a un autre problème : l'Internet des objets a en outre la propriété extrêmement désagréable - du point de vue de la gouvernance - de se modifier constamment sur le plan structurel.

Une voiture de taille moyenne peut actuellement fournir des données provenant d'environ 100 à 150 capteurs. À chaque changement de modèle, de nouveaux sont ajoutés, d'anciens sont supprimés ou leurs caractéristiques techniques changent.

Il en va de même pour les unités de mesure d'un smartphone ou d'un boîtier de pompe. Les flux de données et les fonctions qui reposent sur l'hypothèse de données d'entrée stables sont donc obsolètes avant même la mise en service.

Pour pouvoir faire face à des conditions générales instables, il faut de nouveaux modèles d'architecture dans l'informatique. Au plus tard à ce stade, une refonte fondamentale des architectures et des flux de données s'impose.

6. nouveaux paradigmes

Avec les étapes de développement 4 et 5 (dans le graphique), les circuits de rétroaction fermés - usuels depuis longtemps dans les systèmes de contrôle des processus - font leur entrée dans la commande des processus commerciaux.

Mais alors qu'un parc de machines dans la production offre un cadre relativement stable pour la définition de règles, les décisions dans les processus commerciaux sont prises dans un environnement qui change radicalement toutes les heures ou toutes les minutes.

La tentative de reproduire les règles du jeu de cet environnement dans des règles rigides (et des paramètres de customisation) doit inévitablement échouer. Tôt ou tard, les organisations seront donc contraintes de déléguer les décisions à des algorithmes qui s'adaptent d'eux-mêmes (auto-adaptatifs).

Cela peut paraître inhabituel, voire effrayant. Mais si nous sommes honnêtes, dans notre vie quotidienne, nous laissons depuis longtemps les décisions à des algorithmes dont nous ne savons plus comment ils fonctionnent en détail.

Rares sont les personnes qui vérifient chaque instruction de leur système de navigation sur la carte, rares sont les planificateurs qui sauront comment fonctionne la planification des besoins dans SAP ERP, et rares sont les passagers aériens qui hésitent à monter dans un avion dont l'atterrissage est géré par l'ordinateur et non par l'équipage lorsque la visibilité de la piste est mauvaise.

Les données, un facteur de réussite critique

Les cas d'entreprise avec reconnaissance des formes et prise de décision automatique ne sont souvent pas réalisables avec les données actuelles. Les algorithmes de reconnaissance des formes dans la prévention des fraudes, par exemple, ont besoin de données propres et granulaires provenant de plusieurs centaines, voire de milliers de cas bien documentés et clairement structurés.

Pour disposer d'un tel trésor de données dans une, deux ou trois décennies, il faut commencer dès aujourd'hui à concevoir l'architecture et à collecter. Les géants de l'Internet comme Amazon ou Google l'ont compris depuis longtemps. Pour les pionniers du Big Data, il s'agit en premier lieu de collecter la plus grande quantité possible de données et de les gérer de manière flexible et structurable.

Ce que l'on pourra faire plus tard avec ces données, on pourra encore y réfléchir dans dix ans. C'est dans ce contexte qu'il faut voir l'entrée de Google dans l'industrie automobile, la robotique ou la domotique.

Dans les trois cas, il ne s'agit pas en premier lieu de vendre du matériel informatique, mais de dominer les stocks de données produits par le matériel.

Conclusion

Lorsqu'on construit une maison, on n'attend pas la pose des tuiles pour commencer à planifier. L'architecture et le design du bâtiment sont définis bien avant que la première pelleteuse n'arrive sur le terrain. Il se peut même que la vision naisse avant l'achat du terrain.

Bien sûr, il y aura des ajustements pendant la réalisation des plans de construction. Le terrain de construction lui-même réserve l'une ou l'autre surprise ou une fenêtre doit être déplacée de quelques centimètres pour une meilleure vue.

Mais tout comme pour la construction, une architecture de données ne doit pas nécessairement être rigide. Pour les clients et les personnes intéressées, Horváth & Partners propose à partir de décembre 2015 un roadmapping bootcamp avec des vidéos et des webinaires.

À cette occasion, nous nous pencherons plus intensément sur la question de savoir à quoi peuvent ressembler des architectures de données flexibles pour la numérisation.