Le Customer Journey est une tâche de 7 fois 24 heures

Stefan Oltmanns (voir table ronde) et ses collègues Marcus Banner et Cengiz Varol répondent de manière concise aux principales tendances du commerce électronique.

"L'un des principaux défis auxquels sont confrontées les entreprises est la vitesse à laquelle le marché évolue en ce qui concerne les exigences numériques centrées sur le client, et la pression d'adaptation qui en résulte".

définit Stefan Oltmanns au début.

Les exigences des clients finaux nécessitent une réaction rapide des entreprises et le développement de solutions numériques (sur les points de contact ...) pour une expérience d'achat "parfaite" et "personnalisée".

Parallèlement, pour conserver leur avantage concurrentiel, les entreprises doivent relier et évaluer intelligemment des données de masse de plus en plus importantes (par exemple pour proposer des gammes de produits plus optimisées, faire des offres plus personnalisées aux clients, etc.)

Seuls ces deux défis ne peuvent plus être résolus directement à partir du noyau stable de l'ERP. Souvent, des paysages de systèmes informatiques parallèles sont nés/apparus, qui doivent résoudre les exigences numériques et relier les masses de données de manière profitable.

Défi : Comment le commerce parvient-il à intégrer la diversité toujours plus grande des solutions de point de contact client personnalisées et non personnalisées disponibles avec les systèmes/processus back-end dans des cycles toujours plus courts ?

Les applications dites d'expérience client ne s'intègrent généralement pas de manière optimale avec les systèmes ERP en back-end. Cela entraîne

• à des thèmes d'interface très complexes qui ne sont pratiquement plus maintenables et doivent toujours être adaptés individuellement
• des masses de données qui sont envoyées d'un système à l'autre et qui sont généralement conservées de manière redondante
• à des incohérences de données entre les systèmes
• aux processus non intégrés de la chaîne d'approvisionnement

Stefan Oltmanns s'exprime à ce sujet :

"Pour relever ces défis, SAP a créé ces dernières années une architecture d'application qui permet à un commerçant de répondre à la vitesse requise pour des solutions toujours nouvelles aux points de contact à partir d'un noyau ERP stable, et qui constitue la base pour mettre en œuvre des services omnicanal de manière flexible et efficace".

En outre, cette nouvelle architecture globale offre au commerçant la possibilité non seulement d'analyser et d'utiliser ses propres données, mais aussi de les enrichir avec des données externes (par exemple des données de médias sociaux) ou de connecter des systèmes tiers.

L'architecture moderne permet ainsi aux commerçants de ne pas s'occuper uniquement du cœur de l'ERP, mais de pouvoir continuer à mettre en œuvre les exigences requises en matière de commerce électronique et de big data.

Marcus Banner décrit SAP comme suit :

"SAP a non seulement l'architecture omnicanale systémique et procédurale comme portefeuille de solutions, mais aussi la plate-forme technologique, par exemple avec l''architecture orientée microservices'".

Cette architecture permet un découplage entre, par exemple, les architectures cloud SAP ou multicloud et les systèmes back-end ERP, ce qui permet de faire évoluer l'environnement des processus et des systèmes à deux vitesses. L'intégration des processus s'effectue via SAP CPI et l'intégration des données via le DATA HUB.

Les applications personnalisées de plus grande envergure, qui ont une influence importante sur le standard, peuvent être développées de manière découplée du système ERP (SAP Extension Factory, il est possible ici d'avoir recours à des technologies modernes telles que Kubernetes). Ainsi, l'exploitation informatique à deux vitesses sera également possible à l'avenir.

En complément, Marcus Banner explique

"Approche technologique : dans une architecture ainsi découplée, le commerçant peut développer et déployer plus rapidement et de manière plus flexible des services clients (sous forme de microservices ou de cas d'utilisation) pour ses clients".

Des combinaisons de microservices (solutions) SAP et non SAP sont également possibles. Ceux-ci peuvent également être intégrés au sein de SAP SCP avec des technologies de courtier en messages.

Le commerçant n'a pas besoin de tout programmer lui-même ou de tout intégrer à son ERP. Il doit simplement savoir comment intégrer les applications via les technologies cloud.

Cengiz Varol souligne la cohérence de la feuille de route :

"Une fois que l'on a compris que c'est par le biais de cette architecture technologique que l'on peut continuer à mettre en œuvre les exigences du marché, la question cruciale est la suivante :

En tant que commerçant, comment aborder la migration vers la nouvelle architecture de processus et omnicanal SAP ? Approche par processus : de notre point de vue, il est nécessaire de considérer à cette occasion la stratégie et les exigences dans l'entreprise de manière globale et de verser les résultats dans un plan d'avenir stratégique - Roadmap !"

Les processus de vente au détail "classiques" à l'origine se retrouvent sous forme de fonction dans SAP CAR ou dans les apps de consommation dans les nouveaux composants d'architecture (création/planification de promotions, planification de quantités supplémentaires ou /-forcast, tarification centrale, tables de répartition, stocks en ligne, réservations de commandes en ligne ...).

Les systèmes de marketing et leurs processus doivent être considérés de manière intégrative (association des données, segmentation, parcours client, planification stratégique du marketing, personnalisation, etc.

Pour conclure, Stefan Oltmanns explique : "Le client veut une expérience d'achat cohérente, quel que soit le canal. Cela signifie que les processus du commerce doivent être identiques ou très étroitement imbriqués dans les processus de back-end et de supply chain".

C'est la seule façon de travailler efficacement pour un distributeur et d'éviter un surcroît de travail par canal. Nous pouvons ainsi constater qu'il ne s'agit pas d'un sujet isolé, mais que cela nécessite une planification de tous les composants architecturaux SAP et non-SAP ; jusqu'à la considération d'une migration/transformation SAP-S/4HANA et de la voie à suivre (par exemple uniquement technique ? avec avant-projet ? Greenfield ? Brownfield ?).
Stefan Oltmanns :

"En tant que RealCore, nous avons mené ces discussions avec de nombreux clients au cours des 18 derniers mois et, grâce à notre modèle d'approche, nous sommes parvenus avec certains d'entre eux à des schémas architecturaux cibles qui sont désormais mis en œuvre.

Il ne s'agit plus ici uniquement de lancer des projets individuels (les essais isolés sur le terrain échouent souvent), mais d'évaluer clairement et individuellement pour chaque client l'architecture de référence SAP Retail (et ses composants), l'intégration entre les applications SAP et non-SAP, de déterminer les valeurs ajoutées commerciales et les priorités, afin d'orienter et de décider sur cette base ce qui peut être mis en œuvre et en quelles étapes judicieuses, pour finalement introduire la nouvelle architecture SAP et ses composants en fonction des processus et pouvoir ainsi réagir de manière pérenne à la vitesse vertigineuse du marché et des clients - et ce, si possible, avec très peu de restrictions."

Profil de l'entreprise

Le groupe RealCore est un groupe d'entreprises spécialisé dans le conseil en processus et en technologie dans le secteur du commerce.

Conformément à la devise "Where Technology meets Business", RealCore projette les modules SAP du noyau numérique de la solution SAP la plus récente, y compris les composants de la nouvelle architecture omnicanale SAP- CAR pour tous les canaux de distribution du commerce.

Pour ce faire, nous utilisons les technologies les plus modernes, telles que SAP S/4HANA, PI/PO/CPI, SCP ou UI5, pour proposer des solutions innovantes qui profitent à nos clients.