Vipin Gupta a passé près de huit ans en tant que CIO de Key Bank avant de rejoindre Toyota Financial Services en 2018. Alors qu'il dirige tous les aspects de la transformation numérique et des technologies de l'information, en tant que CIO de TFS, il constitue une main-d'œuvre plus avertie en matière de numérique. Récemment, j'ai parlé avec Gupta de la transformation qu'il a aidé à mener, de la stratégie derrière la nouvelle architecture et de la façon dont il a ajouté des compétences numériques à son équipe. Ce qui suit est une version modifiée de notre entretien.
Martha Heller : Pouvez-vous décrire la transformation numérique de Toyota Financial Services ?
Vipin Gupta : L'industrie automobile s'est transformée en une entreprise de mobilité, qui va au-delà de la fabrication et de la vente de voitures pour fournir des services pour déplacer les personnes et le matériel en toute sécurité d'un point A à un point B. Donc, trois ans il y a quelques années, nous avons commencé à nous poser la question : « Si Toyota Financial Services était né aujourd'hui, comment le concevrions-nous ? »
Notre réponse était de devenir une plate-forme de financement de la mobilité en tant que service et de passer d'un financement captif pour Toyota et Lexus à la fourniture de services financiers pour d'autres entreprises de mobilité. Nous voulions offrir les mêmes services de qualité que nous livrons à nos propres marques à d'autres constructeurs automobiles et entreprises de mobilité.
En avril 2020, sept mois seulement après la signature d'un partenariat avec Mazda, nous avons lancé notre première entreprise de marque privée sous le nom de Mazda Financial. Services sur une nouvelle plate-forme de financement de la mobilité multi-locataires construite à partir de zéro à l'aide de technologies modernes, le tout dans le cloud.
Comment avez-vous transformé l'entreprise si rapidement ?
La clé de notre déménagement si rapide est venue de renverser la logique de transformation. Oui, nous devons transformer la technologie pour transformer notre entreprise, mais avant cela, nous nous sommes concentrés sur la transformation de nos comportements pour évoluer plus rapidement avec les nouvelles pratiques commerciales numériques. Notre concentration initiale sur les comportements et les habitudes a d'abord changé la donne.
L'une des clés du changement de comportement consistait à déplacer notre modèle opérationnel des projets aux usines de produits numériques. Nous savions que le modèle de projet traditionnel limité dans le temps était inefficace, avec des frais généraux administratifs. Les usines numériques de produits, quant à elles, disposent d'une équipe dédiée, ou « usine », responsable de l'amélioration continue des capacités d'un produit.
Deuxièmement, nous avons adopté l'idée de créer un produit logiciel comme nous construisons des voitures. Nous avons appliqué les pratiques d'ingénierie et de fabrication automobile de classe mondiale de Toyota à l'ingénierie logicielle. Nous avons conçu chaque usine numérique avec une capacité fixe qui fournit des modifications logicielles à une cadence fixe toutes les deux semaines. En fixant la capacité et la cadence de sortie, chaque équipe d'usine a été naturellement obligée de donner la priorité pour fournir ce qui compte le plus au moment où cela est nécessaire, inspiré par le principe du juste-à-temps. Cela a permis de fournir les capacités de valeur commerciale les plus élevées au début et à un coût de livraison inférieur.
Troisièmement, nous avons intégré les principaux décideurs de l'entreprise dans des équipes d'action de direction, qui se réunissent régulièrement, comme une mêlée, et répondent à une seule question : quelle est la obstacle aux livrables d'une usine? L'objectif de l'équipe d'action de leadership est de supprimer cet obstacle avec la conviction que lorsque les obstacles sont supprimés, les propriétaires d'usine habilités conduiront leurs équipes à leurs objectifs rapidement. Cela nous a donné une vitesse incroyable.
Une source importante de gaspillage dans l'informatique provient du délai de prise de décision à l'intérieur et à l'extérieur de l'informatique. La vitesse du leader est la vitesse de l'équipe. Le gaspillage de la prise de décision commence au sommet de l'organisation. Une fois que nous avons la clarté de la décision au sommet, les équipes livrent rapidement.
Comment avez-vous abordé la nouvelle architecture ?
Notre premier principe directeur était qu'au lieu de moderniser les systèmes existants un par un, nous concevions une toute nouvelle architecture dans le cloud, comme si nous étions nés aujourd'hui, ce qui nous a libérés des conversations sur la mise à niveau des systèmes.
Deuxièmement, notre architecture pour chaque système serait une conception multi-locataire liée par un identifiant de locataire commun. à travers tous les systèmes. Cela nous permettrait de fournir des services aux clients via une infrastructure partagée, tout en gardant les données séparées. Cet équilibre – partager l'infrastructure mais pas les données – signifie que chaque système que nous introduisons dans le nouvel écosystème est conçu pour être multilocataire, ce qui a influencé nos modèles de données et la conception de la chaîne d'approvisionnement des données. API first" mais "API must" pour que chaque système interagisse les uns avec les autres et pour que les partenaires externes utilisent nos services. Les API n'étaient pas une option, un choix ou un point de décision. Les API et les microservices doivent être un mode de vie.
Fourth concevait pour l'analyse agile, où les données, quel que soit leur emplacement, seront disponibles pour nos équipes d'analyse et de science des données. Nous appelons cela une chaîne d'approvisionnement de données, où plutôt que de créer une interface de données système pour pousser les données dans l'entrepôt de données, nous avons créé un nuage de données intégré pour extraire continuellement les données de nos systèmes. Nous avons non seulement rationalisé le flux de données pour l'analyse, mais nous avons également réduit les interfaces système point à point et libéré nos systèmes opérationnels de la responsabilité de pousser les données.
Enfin, pour l'expérience client, nous sommes allés au-delà de l'omnicanal pour « sur mon canal », qui donne la priorité au point de vue du client dans la façon dont nous concevons les expériences.
Ces éléments, le tout dans le cloud, les systèmes multilocataires, " L'API doit », la chaîne d'approvisionnement de données basée sur l'extraction et les expériences « sur mon canal » – sont devenus les principes directeurs de chaque système que nous avons construit ou acheté. Cette approche standardisée nous a permis d'avancer rapidement dans la construction de la nouvelle architecture.
Quels conseils donnez-vous aux autres DSI pour concevoir une nouvelle architecture ?
Un conseil est de ne pas se concentrer autant sur le fonctionnel exigences de l'architecture que vous ignorez les éléments opérationnels de la technologie, tels que les capacités de surveillance, de détection et d'auto-réparation. Si je devais le refaire, nous aurions réfléchi davantage aux éléments opérationnels de l'écosystème et les aurions conçus de manière proactive plutôt que réactive, comme nous le faisons actuellement.
De plus, une nouvelle architecture numérique et un nouveau modèle de fonctionnement nécessitent que les équipes se développent de nouvelles compétences. En plus d'acquérir des talents de l'extérieur dans ce marché de talents tendu, nous nous sommes concentrés sur le développement de nos équipes existantes. Nous avons donc créé la TFS Digital Academy autour de l'idée « apprendre, faire, enseigner, faire » afin que nous puissions tous développer nos compétences numériques ensemble. Notre pensée est que l'enseignement est la clé de l'apprentissage, et il n'y a pas de meilleurs enseignants que nos propres experts. Que vous soyez salarié TFS ou consultant, vous êtes formé aux mêmes pratiques. En plus d'affiner nos compétences, cela a renforcé la cohérence de nos comportements et de nos pratiques, réduisant davantage le gaspillage et augmentant la vitesse.
En fonction du rôle que vous jouez chez TFS, comment voyez-vous évoluer le rôle du DSI ?[19659004]Le rôle du DSI à l'avenir est d'être l'architecte de la future version de l'entreprise. Les DSI disposent d'un point de vue global sur l'entreprise pour influencer non seulement la conception de la plate-forme, mais également le modèle organisationnel, le modèle commercial et les modèles de processus. Les bons DSI transforment l'informatique de l'intérieur, mais les grands DSI utilisent le design thinking et l'inclusivité pour transformer l'informatique en changeant ce qui se passe en dehors de l'informatique.
Source link