Interviews

Ryan Snyder, Thermo Fisher Scientific : « dans la data, IT et métiers doivent s'impliquer ensemble »

Ryan Snyder, DSI de Thermo Fisher Scientific : « la stratégie data doit viser à résoudre de petits problèmes immédiatement, apportant une valeur à l’entreprise, en les intégrant dans une vision d'ensemble. » (Photo :D.R.)

Le DSI du géant du matériel de recherche et d'analyse médicale détaille l'architecture d'exploitation de données qu'il a mis en place. Un modèle à plusieurs niveaux où métiers et IT doivent s'impliquer conjointement.

PublicitéSpécialiste du matériel de recherche et de diagnostics médicaux, Thermo Fisher Scientific est né de la fusion de Thermo Electron et de Fisher Scientific au milieu des années 2000. La multinationale, dont le siège est situé à Waltham (Massachusetts), a réalisé 44 Md$ de chiffre d'affaires en 2022, dont environ un quart en Europe, au travers de marques comme Thermo Scientific, Applied Biosystems, Invitrogen, Fisher Scientific, Unity Lab Services, Patheon ou PPD. Le groupe emploie plus de 125 000 personnes.

Chez le fabricant d'équipements et d'instruments de laboratoire, les capacités en matière de données et d'analyse ne peuvent pas naître uniquement d'une stratégie informatique ou commerciale. La technologie et l'organisation de l'entreprise étant profondément impliquées dans l'ensemble des aspects relatifs aux données, des équipes interfonctionnelles sont indispensables pour en tirer le meilleur parti. Ryan Snyder, le DSI de Thermo Fisher Scientific, et ses collègues ont donc construit un modèle en couches permettant à l'IT et aux métiers d'agir comme une seule et même équipe.

Quels sont les motivations de l'entreprise à l'origine de l'architecture de données que vous êtes en train de construire chez Thermo Fisher Scientific ?

Ryan Snyder : Pendant longtemps, les entreprises se sont contentées d'embaucher des Data Scientists, de les diriger vers leurs données et de s'attendre à des résultats étonnants. Cette stratégie est vouée à l'échec. La meilleure façon de démarrer une stratégie de données est d'établir des facteurs de valeur réels que l'entreprise peut soutenir. Chez Thermo Fisher Scientific, ces facteurs se répartissent en trois domaines distincts. Le premier consiste à rationaliser notre propre back-office, et les deux autres s'appliquent aux activités de nos clients, qui consistent à faire progresser la découverte scientifique et à accélérer les résultats cliniques.

Quels sont les exemples de solutions analytiques que vous construisez dans chacun de ces domaines ?

En ce qui concerne le back-office, le secteur de la fabrication est un domaine très intéressant pour nous. Contrairement à beaucoup d'autres industries, le manufacturing dans les sciences de la vie implique beaucoup d'activités spécifiques et non reproductibles, de sorte que nous pouvons nous retrouver avec une énorme variabilité en termes de fabrication des produits. Historiquement, nous avons stimulé la productivité grâce à la méthode Lean Six Sigma et à l'optimisation des flux. Avec l'avènement de l'Industrie 4.0, nous plaçons désormais des capteurs dans nos processus de fabrication, qui nous fournissent de vastes quantités de données que nos dirigeants utilisent pour repenser ces processus.

PublicitéSur le volet découverte scientifique et résultats cliniques, de nombreux instruments que nous vendons deviennent numériques. La microscopie et le séquençage des gènes, par exemple, génèrent une très grande quantité de données que nos clients tentent d'analyser. Plus nous créerons de plateformes pour les connecter et simplifier ces analyses, plus il leur sera facile d'accéder aux données importantes. C'est particulièrement vrai lorsqu'ils disposent d'ensembles de données provenant de plusieurs instruments. Comment rassembler toutes ces données ? C'était auparavant à la charge de chaque client. Mais en tant que fournisseur, nous pouvons accélérer la recherche et l'analyse en connectant ces différents ensembles de données.

Vous avez parlé de votre plateforme de données comme d'un gâteau à plusieurs couches. Quelles sont ces couches ?

En informatique, nous parlons souvent des couches d'une pile technologique. La métaphore du gâteau à étages fait passer la discussion sur les données d'une discussion purement IT à une réflexion se situant à l'intersection de la stratégie d'entreprise et de la technologie. Il s'agit donc de la façon dont nous créons des couches à partir des concepts métiers, comme l'avancement des découvertes, jusqu'à une solution technologique, comme un outil de visualisation.

La première couche est donc celle du concept métier : nous organisons délibérément des sessions avec nos partenaires des business units pour discuter de l'endroit où les données de notre entreprise créent de la valeur. Cette démarche n'est pas différente de celle d'une organisation RH qui développerait une stratégie de gestion des compétences pour étayer une stratégie d'entreprise. L'élaboration de ces idées fait donc partie intégrante de la première couche.

La deuxième couche est la couche consommable, où les clients, internes et externes, peuvent accéder aux données et les utiliser. C'est ici que nous sélectionnons les outils de visualisation, par exemple. La troisième couche, la plus complexe, est celle de l'architecture et de la gouvernance, que nous avons regroupées en une seule composante.

Avec les deux premières couches, les métiers jouent un rôle moteur et l'informatique se positionne en support, mais sur la couche de gouvernance et d'architecture des données, l'IT et les métiers sont côte à côte et prennent ensemble des décisions complexes sur ces sujets.

La dernière couche est celle des données brutes, où nous extrayons les données des systèmes sources, les organisons, les sécurisons et déterminons les datalakes à utiliser. Il ne s'agit généralement pas de discussions métiers, mais plutôt de considérations purement IT.

Ainsi, avec ce modèle du gâteau en couches - ou « layer cake » -, nous organisons un ensemble de discussions en cascade entre l'informatique et nos partenaires métiers, ceux-ci menant les niveaux supérieurs et la DSI ayant la main sur les niveaux inférieurs.

Pouvez-vous nous donner un exemple illustrant ce fonctionnement en couches ?

Prenons par exemple la simplification des rapports sur les ventes dans l'ensemble de l'entreprise, ce qui peut devenir excessivement complexe dans un groupe qui s'est développé par le biais d'acquisitions, dont un grand nombre possèdent leurs propres systèmes financiers. Au niveau du concept métier, la direction financière s'engage dans une série de discussions avec la DSI et l'ingénierie des données pour évaluer le changement de processus nécessaire à la création d'un reporting en libre-service pour l'entreprise. Puis au niveau inférieur, nous décidons de la manière dont les gens consommeront les données sur les ventes. Notre objectif est-il de disposer d'un portail unique ou d'un portail pour les ventes du côté clinique et d'un autre pour nos activités sur les produits ? À ce niveau, nous impliquons les directeurs généraux, qui consomment les données, et quelques informaticiens supplémentaires qui aident à passer la solution à l'échelle. Nous descendons dans l'organigramme au fur et à mesure que nous progressons dans les couches.

Que se passe-t-il au niveau de l'architecture et de la gouvernance ?

Au sein des deux premières couches, nous définissons la solution en termes de contexte métier, celui-ci menant les discussions même si l'équipe informatique reste impliquée. Au niveau de la gouvernance et de l'architecture, c'est la DSI qui pilote la discussion pour décider des normes et des règles s'appliquant aux données qui nous permettront de gérer la couche consommable. Les données se trouvent-elles dans un ou plusieurs cloud ? Souhaitons-nous utiliser les mêmes outils de visualisation pour chaque entreprise ? Qui a accès aux données ?

Enfin, au niveau des données brutes, l'équipe informatique prend des décisions en matière d'ingénierie, de stockage, de sécurité ou de toute autre outillage.

Quels sont les avantages d'une architecture de données et d'une gouvernance réunies en une seule et même couche ?

La rapidité et le fait d'éviter les allers et retours. Lorsque nous avons procédé à une première évaluation de nos capacités en matière de données, nous avons constaté que nous disposions d'un grand nombre de petites équipes, chacune disposant de petites bases de données, où chacun prenait les bonnes décisions concernant ses données en fonction de sa vision propre, mais où personne n'examinait ces environnements dans leur globalité. Nous avions besoin d'une couche qui réunisse les responsables IT et les responsables métier pour qu'ils puissent examiner l'ensemble de ce paysage. Il faut que les deux parties investissent dans la recherche de la meilleure solution au bénéfice de l'entreprise.

Quels sont les avantages de la structure en couches pour votre organisation ?

Elle nous a donné de l'agilité. Nous pouvons donner un sens à des ensembles de données très complexes au sein de l'ensemble de l'entreprise, tout en permettant aux collaborateurs de résoudre des problèmes à un niveau très local, mais de manière orchestrée. Le modèle « layer cake » donne à l'IT une chance d'examiner tous les problèmes métiers que les données pourraient résoudre, et la capacité de résoudre ces problèmes rapidement. Il permet également aux métiers de s'approprier les décisions relatives aux données.

Quels ont été les défis posés par la mise en place de ce modèle ?

Nous avons dû passer d'un modèle de gestion de projet à un modèle de gestion de produit, ce qui était un changement très important car lorsque vous financez la croissance d'une stratégie de données projet par projet, vous vous retrouvez avec un monstre de Frankenstein de raccourcis, parce que vous manquez toujours d'argent ou de temps. Dans un modèle de produit, les équipes ne sont pas limitées dans le temps d'un point de vue architectural ; elles sont guidées par les résultats du produit plutôt que par ceux du projet. Le passage au modèle de produit peut toutefois nécessiter beaucoup de temps et d'efforts.

Un autre problème est venu du fait que j'ai laissé les équipes s'attacher à certaines technologies legacy. Le volume de données progresse si rapidement et il se passe tant de choses dans les communautés de startups que l'on peut se retrouver bloqué si l'on reste trop longtemps attaché à des technologies dépassées.

Le troisième défi consistait à s'assurer que nous avions des objectifs ambitieux en matière de stratégie de données à long terme, y compris sur l'intelligence artificielle, mais que nous pouvions également commencer à petite échelle d'une manière gérable qui créait tout de suite de la valeur. Il faut être capable de résoudre de petits problèmes tout en les intégrant dans une vision d'ensemble. Sinon, vous risquez de passer une année pleine à résoudre de petits problèmes, tout en passant à côté d'une importante opportunité d'investissement.

Quels conseils donneriez-vous aux DSI qui souhaitent mettre en place une structure de données similaire ?

Trouvez quelques partenaires internes qui ont l'envie et la capacité de vous aider à construire le modèle, car les rôles que vous demandez à vos partenaires métiers de jouer ne sont pas ceux qu'ils occupent traditionnellement. Ils veulent les données, mais comprennent-ils ce à quoi ils s'engagent ? Les équipes métiers et informatiques peuvent véritablement fonctionner comme une seule et même entité. Concentrez-vous sur l'identité de vos premiers partenaires, car les meilleurs défenseurs de l'élaboration d'une stratégie de données ne viendront pas nécessairement de la DSI, mais plutôt des métiers.