Guy-Laurent Arpino, LDC: «Dans notre métier, l’IT doit être réactive et flexible»

1ère partie: Transformation du back office, intégration du front office et analytics

Vous menez à bien une vaste initiative de transformation. Quelles en sont les dimensions?
Louis Dreyfus Company (LDC) mène une transformation stratégique de ses affaires qui se traduit par une transformation de son IT, à commencer par l’optimisation du back-office. Nous quittons une constellation de systèmes divers utilisés dans le groupe pour la finance et les achats, par exemple, pour les remplacer par S/4HANA – en gros l’ensemble du back-office à l’exception de la trésorerie et des RH qui sont déjà sur des solutions unifiées (Quantum et Workday). Nous repartons donc avec une plateforme et un modèle unique, ainsi que des plans comptables alignés et des processus redéfinis qu’il s’agisse de procure- to-pay, des achats de matériel, des inventaires, de la comptabilité, etc. Nous comptons ainsi gagner en efficacité et être en mesure de développer des analyses plus poussées sur nos opérations.

Comment faites-vous pour mener à bien cette vaste standardisation?
Le projet est clair et bénéficie du soutien de toute la direction. C’est ce qui nous permet d’avoir une approche volontariste: le mot d’ordre est l’adoption du modèle par toutes les entités, pas son adaptation. Il leur faut se battre pour justifier une différence par rapport au modèle. La solution S/4HANA a été pensée pour être déployée dans toutes nos entités. Nous avons démarré et conçu le modèle avec la France et l’Allemagne. Nous avons ensuite poursuivi avec l’Uruguay où nous avons connu notre premier moment de vérité. Vu l’importance des activités que nous y avons, la Suisse constituera sans doute un autre moment clé dans cette transformation digitale. Aujourd’hui, nous pouvons déjà nous féliciter des premiers déploiements qui correspondent à 85% au modèle et au standard SAP – et les réactions sont encourageantes. Le déploiement global devrait s’achever en 2023.

Qu’en est-il des systèmes métiers de front-office?
Le deuxième pilier de notre stratégie IT concerne nos systèmes front-office, que nous utilisons pour le trading et l’origination, c’est-à-dire la gestion de toute la vie d’un contrat, des négociations avec les producteurs jusqu’à l’expédition de la marchandise. Ces plateformes sont plus ou moins hétérogènes, avec des solutions souvent différentes selon la région et la commodité, c’est-à-dire le produit. Contrairement au back-office, il n’y a pas ici de volonté de standardiser à tout prix mais plutôt d’employer le meilleur outil pour chaque commodité: café, céréales, oléagineux, etc., et de trouver des synergies où elles apportent une vraie valeur. L’objectif est d’être le plus agile possible et de s’adapter aux spécificités de notre métier de négoce. Nous exerçons un vrai métier de marchands, en permanence à l’affût d’opportunités. Dans cette optique, l’IT doit être réactive, flexible, et faire aussi bien appel à des solutions du marché qu’à des outils sur mesure en fonction des besoins.

Nous avons désormais pour principe de pousser toutes les données sur un data lake. Il est essentiel de bâtir un historique.

Comment relevez-vous le challenge de l’intégration entre des solutions métier très disparates et ce back-office bientôt standardisé?
Il faut une frontière très stable pour l’échange de données entre le front et le back-office. Nous recourons à une plateforme d’intégration hybride, constituée d’un ensemble d’API et d’un Enterprise Service Bus. Nous l’avons déployé sur la base d’un modèle de données canonique, donc standardisé au point de pouvoir faire du plug and play d’un système à l’autre. Le challenge est désormais de faire coïncider l’arrivée de S4 dans les différentes entités avec l’évolution de leurs systèmes de front-office.

Allez-vous faire de l’analytics sur les données émanant de ces systèmes métiers?
C’est le troisième volet de cette transformation digitale. Pour la BI et les analyses descriptives, nous nous appuyons sur l’entrepôt de données de SAP HANA dans lequel nous poussons les données du front. Séparément, nous avons mis en place une plateforme d’analyse prédictive basée sur Azure pour le support au trading et pour la recherche. Nous collectons en permanence des informations sur le terrain qui viennent alimenter cette plateforme et nos data scientists travaillent à affiner les modèles pour toujours mieux prédire et anticiper les déséquilibres entre la production agricole et la demande – c’est là que réside le cœur même de notre business. Nous avons désormais pour principe de pousser toutes les données sur ce data lake. Il est essentiel de bâtir un historique.

2ème partie: Automatisation, RPA et low code

Avez-vous automatisé des processus à l’aide de technologies de Robotic Process Automation (RPA)?
Oui, nous avons introduit la RPA en vue de gagner en efficience dans nos trois centres de services partagés, qui couvrent principalement les domaines de l’exécution des contrats et de la finance. Les employés de ces services devaient encore effectuer de nombreuses tâches manuelles et répétitives, à gros volume. Pour automatiser certaines de ces tâches, nous avons déployé une plateforme basée sur la technologie de UiPath, laquelle est gérée centralement par l’IT pour la maintenance, le contrôle des KPI, la définition des polices, etc. Les différentes fonctions sont en revanche développées directement au sein des services, selon leurs besoins, par de petites équipes intégrant deux ou trois développeurs. Les cas d’usage potentiels sont au préalable analysés afin de définir ceux qui promettent un gain en termes d’efficience et de coûts. Une fois le business case validé, un robot peut être déployé de façon plus ou moins autonome par les centres de services.

Pouvez-vous nous décrire l’un des processus aujourd’hui pris en charge par un robot?
Notre centre de services partagés en Inde a développé un robot qui prend en charge un long processus de bout en bout. Un outil de reconnaissance optique de caractères capture les données des factures papier ou scannées. Ces données vont être saisies par un robot qui va ensuite mettre à jour les systèmes front et back-office. Le robot reconnaît le contrat en lien avec la facture pour valider celle-ci, avant d’enregistrer les informations dans le système de comptabilité. Cette automatisation libère du temps pour d’autres tâches plus gratifiantes.

Quels sont les principaux challenges posés par le déploiement de robots logiciels?

La question de la responsabilité des tâches prises en charge par un robot ne doit pas être négligée. Il est nécessaire de suivre des principes de gouvernance, de désigner un parent pour chaque robot et d’anticiper le cas d’un robot devenu orphelin. Nous avons par ailleurs remarqué que bien que les éditeurs vendent ces outils en brandissant l’atout du low-code, le recours aux équipes IT est tout de même plus important que nous le pensions initialement. Il faut en outre éviter de mettre en place un robot là où des interfaces conviennent mieux et peuvent être rapidement développées. Il convient aussi d’avoir conscience que les robots ont un coût et ne sont pas toujours la solution la plus avantageuse. Ceci dit, ces solutions sont rapides à mettre en place et leur potentiel d’évolution est prometteur. Le ROI des robots logiciels reste à nos yeux important. De plus, avec la RPA et les outils low code, l’IT n’est plus un goulot d’étranglement. Les métiers peuvent rapidement mettre en place des solutions qui répondent à certains de leurs besoins sans être freinés par les procédures d’acquisition et de déploiement de logiciels que doit suivre l’IT.

De quelle façon utilisez-vous les outils low code?

Notre plateforme low-code Pega est elle aussi surtout utilisée par les centres de services partagés. Elle permet d’optimiser des workflows en développant des mini- applications. Typiquement pour des processus de validation qui passaient auparavant par e-mail. A l’instar des projets RPA, le développement d’applications low-code est décentralisé mais leur gouvernance et leur contrôle sont les prérogatives de l’IT.

Nous avons défini notre propre framework décisionnel qui motive ou non le recours à un développement Agile.

Suivez-vous une approche de développement Agile?
Je conçois l’Agilité comme un facilitateur dans un contexte charnière. En 2020 et 2021, notre roadmap se caractérise par une accumulation de grosses transformations qui atteignent leur pic d’activité au même moment. Pour y faire face, nous avons défini notre propre framework décisionnel en dégageant plusieurs critères qui motivent ou non le recours à un développement Agile. D’abord, le niveau de certitude concernant une application. Par exemple, couvre-t-elle des besoins fixes ou doit-elle être évolutive? L’avantage compétitif des applications et la question de leur gestion centralisée ou décentralisée entrent également en ligne de compte. A ces critères s’ajoute la notion de cycle de vie d’un produit. Tant que nous sommes en phase de refonte, un développement traditionnel en cascade est en général adapté. En revanche, une approche davantage Agile et orientée DevOps sera plus adaptée une fois le produit lancé à grande échelle. Notre framework repose ainsi sur quatre modèles: le traditionnel, le fast-traditional, le Agile-Dev et le Full DevOps. Le choix du modèle dépend donc à la fois du mode de gestion d’un produit et de l’étape de son cycle de vie. C’est aux managers d’opter pour la bonne approche pour chacun des produits qu’ils ont sous leur responsabilité. Sachant que les coûts additionnels de l’adoption d’un mode Agile devront être justifiés par les bénéfices commerciaux apportés.