Le processus d'automatisation : Équipes, les workflows, Succès

Dayle Hall : 

Bonjour et bienvenue dans cette nouvelle édition d'Automating the Enterprise. Je suis votre animatrice, Dayle Hall. Ce podcast est conçu pour donner aux organisations les idées et les meilleures pratiques sur la façon d'intégrer, d'automatiser et de transformer leur entreprise.

L'invité d'aujourd'hui est un vétéran de la technologie avec plus de 16 ans d'expérience dans tous les domaines de l'intégration et de l'automatisation. Il a fait ses débuts dans l'organisation informatique et a accru sa présence et ses responsabilités dans cette entreprise où il a aujourd'hui des attributions très étendues, et il a gravi les échelons en devenant vice-président de la technologie d'Atrium. Nous avons le privilège d'accueillir aujourd'hui Leon Kallikkadan dans notre podcast. Leon, bienvenue dans l'émission.

Leon Kallikkadan :

Je vous remercie. C'est un plaisir d'être ici. Je me réjouis de cette conversation.

Dayle Hall : 

Oui, moi aussi. Avant d'aborder certains de vos domaines de responsabilité sur les sujets que nous avons abordés aujourd'hui, donnez-nous un aperçu de votre expérience au sein d'Atrium. Je ne dirais pas que vous avez eu des débuts modestes, mais vous avez commencé au rez-de-chaussée de l'organisation des TI. Parlez-nous donc un peu de vos débuts, de votre évolution et dites-nous ce que fait Atrium en tant qu'organisation pour donner un peu de contexte aux auditeurs.

Leon Kallikkadan :

J'ai donc commencé chez Atrium en tant que support informatique traditionnel, si l'on peut dire. J'aidais les utilisateurs finaux à résoudre des problèmes de type " hey, j'ai un problème avec mon ordinateur, laissez-moi courir jusqu'à votre bureau et vous aider ". J'ai donc commencé là il y a plus de 16 ans, comme vous l'avez dit.

Au cours de ces 16 années, j'ai eu l'occasion, on m'a donné l'occasion, et on m'a confié la direction et le travail sur divers projets. Je ne me suis jamais vraiment concentré sur les technologies de l'information traditionnelles, comme la mise en réseau, la sécurité du matériel, qui sont des domaines qui m'intéressent beaucoup, mais j'ai également été exposé au support et à l'application d'applications, ce qui m'a permis, lentement mais sûrement, d'accéder à davantage de projets technologiques.

L'équipe dirigeante d'Atrium m'a confié le soin de développer mon équipe. Donc chaque fois qu'il y avait une opportunité de créer, de reprendre ou de diriger une équipe, je l'ai saisie à bras le corps. Et en 2020, nous avons lancé notre troisième équipe, l'équipe d'automatisation, qui est responsable de la transformation numérique, pour ainsi dire, et de l'aide à l'efficacité. Et puis, au début de cette année, nous avons lancé notre équipe d'intégration et d'applications et notre équipe d'intégration et de web. J'ai donc quatre équipes sous ma responsabilité. Donc maintenant je supervise - je ne suis plus l'informaticien, l'informaticien traditionnel, mais maintenant je supervise, j'ai quatre équipes sous moi et quatre leaders sous moi qui aident à fournir tous les résultats finaux à l'entreprise.

Dayle Hall :

C'est vrai. C'est intéressant. Vous avez donc maintenant ces quatre équipes. Et corrigez-moi si je me trompe, il s'agit de l'informatique traditionnelle, de l'équipe des applications d'entreprise, de l'intégration et du web, de l'automatisation et de la transformation numérique. Est-ce exact ?

Leon Kallikkadan :

Correct.

Dayle Hall :

C'est vrai. D'accord, vous avez donc ces quatre différents types d'équipes. Ce que j'aime faire dans les podcasts, et les gens qui nous écoutent, c'est de nous expliquer pourquoi ces quatre équipes disparates, mais surtout, comment vous - quels sont les projets ou les initiatives où elles travaillent ensemble ?

Leon Kallikkadan :

Oui, c'est vrai. J'ai donc intentionnellement découpé ces équipes pour que chacun puisse se concentrer sur ses compétences de base, n'est-ce pas ? Chacune de ces équipes a un ensemble d'applications ou de technologies sur lesquelles elle se concentre. Ils sont considérés comme des experts en la matière, et ils apportent d'immenses connaissances et de la valeur à la table. C'est là qu'ils commencent à travailler ensemble - surtout au cours de l'année ou de l'année et demie qui vient de s'écouler - que je me suis assis et que je les ai vus tous les quatre se développer et devenir d'excellents membres d'équipe qui commencent à collaborer les uns avec les autres.

Par exemple, avant de commencer un projet, nous avons cette partie de notre équipe de leadership technologique, qui est mon équipe de leadership, nous avons des conversations autour d'un projet dont nous pensons qu'il peut avoir un impact organisationnel, mais aussi qu'il peut avoir ou se connecter à d'autres équipes. Nous partageons donc les informations, les résultats possibles, les défis ou les impacts possibles pour les équipes des autres. Nous essayons de voir comment les quatre équipes peuvent se soutenir mutuellement et, bien sûr, moi aussi. Mais nous essayons tous de voir comment nous pouvons nous soutenir les uns les autres, en nous demandant par exemple si nous pouvons apporter un regard neuf ou si vous avez pensé à cela. Nous essayons de nous renforcer, de nous remettre en question. J'aime les gens qui se remettent en question de manière respectueuse. C'est ainsi que nous parvenons à un meilleur résultat ou à une meilleure infrastructure de projet.

Dayle Hall :

J'adore l'idée d'avoir des discussions ou d'examiner des projets qui, à première vue, ne semblent pas avoir d'impact sur les responsabilités de tout le monde ou d'autres personnes. Mais je pense qu'avec la plupart des technologies de l'information, la plupart des applications de données aujourd'hui, nous réalisons tous qu'il y a un impact important sur plusieurs personnes, sur plusieurs organisations. L'une des choses que j'ai apprises de ces podcasts au cours des six derniers mois environ, c'est que l'un des principaux conseils que m'ont donné certains de ces responsables informatiques, c'est de commencer à parler tôt, de commencer à partager des idées et d'obtenir un retour d'information avant de faire des choix, avant d'aller en appel d'offres, avant d'examiner les technologies, et de s'assurer que tout le monde se concentre sur le véritable résultat et sur la nature exacte de certaines de ces implications. Et je pense que plus vous en parlerez dès le départ, plus la mise en œuvre se fera en douceur. Faites-vous le même constat avec vos équipes ?

Leon Kallikkadan :

Absolument, oui. Il est extrêmement important, surtout parce que chacun est dans sa propre voie, que ces canaux de communication soient ouverts, n'est-ce pas ? Et vous ne savez pas - pour une véritable transparence et un véritable impact, vous devez savoir, vous devez avoir ces discussions bien avant de vous lancer dans un projet, et ensuite essayer de comprendre ce qui se passe dans les autres équipes.

L'autre chose qu'il faut garder à l'esprit, c'est qu'il est important, du point de vue de la largeur de bande de chaque équipe, de savoir que les quatre équipes peuvent avoir établi leur liste de priorités et qu'il est important de comprendre sur quoi quelqu'un travaille en ce moment et comment votre projet, qui peut être très important, pourrait l'emporter sur un autre. Il est donc important, du point de vue de la largeur de bande, de la programmation et des ressources, que ces conversations aient lieu très tôt.

Au cours de mes 16 années d'expérience, j'ai vraiment pris conscience de la nécessité de comprendre les attentes de l'entreprise. Une entreprise ne veut pas d'un produit où l'on commence à dire, eh bien, cela ne fait pas partie de mes responsabilités, cela fait partie des responsabilités informatiques, alors adressez-vous à quelqu'un d'autre. Donc, du point de vue de l'utilisateur professionnel, ce n'est pas l'expérience que je veux lui montrer, ou que je veux lui donner, donc je veux qu'il soit en interface avec une seule équipe informatique ou technologique. Et ce qui se passe derrière les rideaux, ce qui se passe dans les coulisses, c'est notre propre flux de travail, notre propre communication qui nous mène au succès.

Dayle Hall : 

Oui, non, c'est un bon conseil. Si nous regardons quelques domaines qui sont très chauds sur le marché d'aujourd'hui, ou très chauds en ce qui concerne les exigences informatiques, il y a ce concept de passer d'interactions dirigées par des développeurs à des interactions à faible code, sans code, très populaire, les analystes en parlent, nous en parlons. Les analystes en parlent, nous en parlons. La croyance est que cela vous permet de mieux soutenir l'entreprise, que vous avez besoin de moins de développeurs, de moins de codage.

Maintenant, il y a certaines choses qui nécessitent encore ce niveau de codage. Mais si vous pensez à ce concept, low-code, no-code, beaucoup d'applications, vous avez ces quatre équipes, comment aborderiez-vous un projet qui est, eh bien, soit pour soutenir l'entreprise, donc il n'y avait pas beaucoup de codage lourd, soit pour le développeur ? Comment aborderiez-vous ce projet avec ces quatre équipes ? Expliquez-moi ce que serait un bon processus, comment vous l'évalueriez, comment vous iriez de l'avant, qui en serait responsable.

Leon Kallikkadan :

Oui, c'est vrai. Ce sont toutes de bonnes questions. Lorsque nous recevons un projet, ce qui se passe, c'est que nous avons mûri en tant qu'organisation. Nous disposons désormais d'un référentiel ou d'une sorte de processus d'admission où tout le monde peut déposer une demande, et une fois que cette demande arrive, au niveau de la surface, nous l'examinons pour voir si elle a cette importance et quel est le niveau de la demande. Sur la base de tout cela, nous nous associons à notre équipe de gestion de projet qui nous aide à prendre ces exigences brutes de l'utilisateur final et à les convertir en exigences commerciales. Une fois que ces exigences sont rédigées, elles sont très différentes de la demande initiale, elles sont plus réfléchies, il y a des histoires d'utilisateurs, des ruptures, des phases supplémentaires, ce qu'il faut absolument avoir, ce qu'il est bon d'avoir, des choses comme ça. Ces éléments sont ensuite transmis à notre équipe. Un analyste s'en charge et le convertit en exigences techniques commerciales.

C'est à ce moment-là que nous commençons à trouver des solutions et que nous examinons l'application réelle ou ce que nous fournissons. Nous ne nous contentons pas de trouver des solutions à la volée. C'est un jeu très, très dangereux. Les utilisateurs professionnels écoutent et se disent que c'est facile. Mais ce n'est pas le cas. Il se passe beaucoup plus de choses en coulisses. Nous avons donc essayé de nous éloigner de la recherche de solutions à la volée pour nous concentrer sur les exigences techniques, ce qui nous mène à la solution ou à la conception et à ce qu'il faut faire pour construire l'application.

Dayle Hall : 

Oui, c'est vrai. Compte tenu de ce que vous avez dit sur le fait d'essayer de s'assurer que vous soutenez l'entreprise, de ne pas trouver de solutions à la volée, vous rencontrez probablement davantage non seulement vos responsables informatiques, mais aussi les lignes d'activité. Quelle est la part des demandes de soutien pour les nouvelles applications, les différents amalgames de données, quelle est la part des demandes qui sont faites par vos lignes d'affaires et quelle est la part de vous, dans les organisations informatiques, qui pensez, ce sont des données, ce sont des choses que nous devrions fournir directement à l'entreprise parce que nous savons qu'elles ont de la valeur ? Comment se présente ce mélange ?

Leon Kallikkadan :

Au départ, c'est moi et mon équipe de direction qui avons commencé à pousser, à essayer de faire en sorte que l'entreprise prenne conscience du problème, n'est-ce pas ? C'est le plus grand défi. Si l'entreprise n'est pas consciente de nos capacités et de ce qu'il y a dans notre boîte à outils, elle ne sait jamais, ces conversations peuvent avoir lieu dans le vide. Nous avons donc commencé à nous engager, à nous adresser à notre population d'utilisateurs. Nous avons commencé à parler à différentes équipes pour comprendre, à un niveau élevé, quels sont certains des défis que nous avons, et comment cette équipe ou la combinaison de cette équipe peut être utile.

Il faut donc du temps pour faire la preuve du concept, développer ces applications et les présenter à l'entreprise. Mais une fois que c'est fait, il faut commencer à impliquer davantage l'entreprise dans ces conversations. Il faut donc leur montrer ce dont on est capable ou ce qu'on est capable de faire, puis commencer à avoir une conversation constante avec l'entreprise. Cette année, nous avons développé une conversation avec un chef d'entreprise. Je lui ai demandé de me parler de ce processus, de me dire ce qu'il fait et pourquoi il ne le fait pas ici. Cela a débouché sur une conversation fructueuse que nous avons élaborée à partir du POC pour qu'ils puissent le voir. Et maintenant, cela nous aide vraiment et nous a permis de poser les bases pour en faire beaucoup plus.

Ainsi, lorsque vous commencez à avoir ces conversations, cela devient comme si l'entreprise elle-même vous demandait et vous mettait au défi, hé, pouvez-vous faire ceci pour moi, pouvez-vous faire cela pour moi ? C'est comme si vous deviez planter cette graine dans chaque entreprise avec le chef d'entreprise, pour qu'il commence à penser à l'automatisation, et votre équipe technologique a juste plus qu'un blocage traditionnel ou un soutien, il y a plus qu'un soutien.

Dayle Hall : 

J'entends certainement des commentaires similaires de la part d'autres organisations, c'est-à-dire, comme vous l'avez dit, aller tôt vers les fonctions, les lignes d'affaires, s'assurer qu'ils savent que vous êtes là en tant que partenaire. Et alors, il y a des chances qu'il y ait moins de frustration parce qu'ils sauront que vous êtes dans le même bateau, et alors vous pourrez leur permettre de mieux réussir, et je pense que je crois qu'il y a - l'informatique est en train de changer pour être moins un obstacle pour l'entreprise et être considérée comme un facilitateur, mais je pense que cela vient de différentes choses. Cela vient de vous et de votre équipe et de la façon dont vous abordez les choses. Cela vient des personnes et des processus que vous mettez en place, et aussi clairement, des outils, des plates-formes, des choses que vous sélectionnez, des choses que vous choisissez pour vous assurer que vous pouvez aider l'entreprise.

Leon Kallikkadan :

Je voudrais juste ajouter que pour nous, cette conversation a évolué vers la question suivante : comment l'informatique peut-elle être un catalyseur de revenus ? Je veux que nous nous concentrions sur les initiatives, sur les demandes, que nous identifiions les opportunités où l'équipe informatique au sens large peut aider plus que simplement, hé, faire fonctionner les choses de manière efficace. Ce n'est plus le cas aujourd'hui. Nous avons accès à toutes les données. Nous avons accès à toutes les technologies. Nous comprenons les processus. D'un point de vue opérationnel, nous recevons des tickets, nous savons donc que les gens ont des problèmes, nous comprenons ce qui se passe en coulisses. Comment pouvons-nous utiliser ces données pour présenter une solution à l'entreprise et lui dire : "Regardez, c'était votre processus avant. Avec notre recommandation, votre processus peut maintenant aller de A à B. Et dans le processus, vous pouvez économiser X, Y et Z. Ou essayons d'apporter ce flux de données dans votre flux de travail afin que vous ayez une meilleure visibilité ou que vous ayez plus de capacités à vendre ou quoi que ce soit d'autre. Nous essayons donc de changer notre approche, de ne pas nous contenter d'être une équipe informatique traditionnelle, mais d'être davantage en mesure de générer des revenus.

Dayle Hall : 

Oui, je pense que c'est une excellente approche. Si nous pensons - juste avant d'aborder les processus et les outils, mais si nous pensons aux personnes et à l'aspect gestion, il y a - évidemment, vous avez des processus en place. Vous avez déjà parlé un peu de la nécessité de s'adresser très tôt aux lignes d'activité et aux chefs d'entreprise, ce qui me semble très bien, et vous avez également parlé de l'importance de s'engager très tôt dans le processus avec vos propres équipes. Mais comment gérez-vous les lignes d'activité ? Combien de temps consacrez-vous à la planification, à la discussion par rapport à la construction, à l'exécution, aux tests continus et à votre carnet de commandes ? Et quels sont les processus que vous avez mis en place pour vous assurer que vous réussissez ?

Leon Kallikkadan :

Le meilleur moment, c'est maintenant, n'est-ce pas ? Par exemple, si nous commençons à planifier tous nos projets pour l'année prochaine, toutes les initiatives pour l'année suivante, nous commençons à avoir ces conversations dès maintenant. Dans le passé, je commettais l'erreur de ne pas avoir ces conversations avec l'entreprise. J'avais l'habitude d'avoir une liste de 30 projets pour l'année prochaine, et j'ai réalisé que ce n'était pas la bonne façon de faire les choses, que c'était un échec, parce que vous essayez de fixer des objectifs et vous essayez de travailler sur des choses pour lesquelles l'entreprise est comme, nous ne nous soucions pas nécessairement de ces choses, ou nous avons ces problèmes, et vous ne travaillez pas sur ces problèmes.

Nous commençons donc par là, nous avons ces conversations avec les entreprises, nous leur demandons leur avis avant de commencer quelque chose. Ensuite, nous nous associons à notre équipe de gestion de projet, qui présente tous ces projets avec les entreprises, avec le groupe de partenaires, dans ce cas, dans notre cas, et nous établissons des priorités. Nous regardons laquelle de mes équipes sera la plus utilisée, s'il s'agit d'une équipe d'automatisation ou d'intégration, ou d'une équipe d'application commerciale. En fonction de la priorité définie par l'entreprise, nous créons une carte de tous les efforts à fournir. Nous regardons quels projets démarrent en même temps, où nous pouvons les déplacer. Nous passons donc par tout le processus d'approbation, nous classons les projets en trois catégories : élevé, moyen et faible. Et nous nous engageons à réaliser tous les projets les plus importants. Sur cette base, nous dialoguons avec l'entreprise.

En ce qui concerne le temps que nous passons le plus souvent, en particulier au cours des derniers mois, voire de l'année écoulée, nous avons constaté que beaucoup de temps est consacré à l'analyse, comme prendre les exigences, les convertir en exigences commerciales, mais aussi s'assurer que l'équipe de développement travaille sur ces exigences, en faisant - en mariant les deux, n'est-ce pas ? En ce qui nous concerne, nous passons beaucoup de temps sur la [flèche B], nous recevons beaucoup de nouveaux projets. Et la dernière chose que vous voulez faire, c'est d'avoir tous ces projets qui sont dans un backlog, vous voulez avoir ces conversations avec l'entreprise, vous voulez les préparer autant que possible.

Nous constatons donc qu'il faut de plus en plus de temps aux analystes commerciaux et de moins en moins aux développeurs, car ils sont prêts à l'emploi. Nous changeons donc un peu notre approche, nous essayons de recruter plus d'analystes commerciaux plutôt que d'augmenter le nombre de ressources du côté des développeurs parce que c'est quelque chose que nous pouvons contrôler. Si nous avons besoin de plus de ressources de développement, sur la base de notre stratégie actuelle, nous pouvons ajouter et supprimer des ressources en fonction des besoins.

Dayle Hall : 

C'est donc un concept intéressant. Et je pense que si vous demandiez à 100 dirigeants différents comment ils décriraient un analyste d'entreprise, ils auraient probablement une description légèrement différente. Mais j'aime bien ce que vous dites ici, à savoir qu'il faut consacrer plus d'efforts à la planification et à l'analyse avant de se lancer dans la création d'un tas de choses. Parlez-moi donc un peu de ce que vous définissez comme un analyste commercial, de ce qu'il fait, du type de compétences qu'il apporte à l'organisation pour vous aider, vous et vos équipes, à mieux réussir.

Leon Kallikkadan :

Bien sûr. Pour moi, un analyste commercial est quelqu'un qui connaît bien la technologie ou les outils disponibles, mais qui n'est pas un développeur. Il s'agit donc essentiellement d'une personne qui comprend quelles sont vos capacités. Il est donc important qu'il ait une compréhension complète et approfondie de ce qui peut être fait et de ce qui ne peut pas être fait. Il s'agit de quelqu'un qui est en contact avec l'entreprise, qui comprend ce qu'elle demande et qui est capable de la mettre en contexte, car la dernière chose que nous voulons faire, c'est d'extraire les exigences de l'entreprise et de les confier à vos développeurs en leur disant d'aller développer, parce que cela ne sera pas fait de manière très, très efficace. 

Nous voulons donc quelqu'un qui comprenne l'entreprise mais aussi la boîte à outils technologique, et quelqu'un qui ait une très bonne compréhension et une bonne maîtrise des projets, comme la bande passante, ce qui se passe dans les coulisses. Comme notre équipe informatique est relativement petite, j'essaie de maximiser l'utilisation de chaque personne dont nous disposons. C'est pourquoi notre BA est aussi celui qui parle constamment aux entreprises. Comprendre ce qui se passe en coulisses du point de vue de la bande passante, de la charge de travail, nous aide également à gérer les attentes, n'est-ce pas ? Pour moi, ces trois domaines sont donc les plus importants.

J'essaie également d'utiliser ce que nous avons fait pour notre automatisation dans tous les aspects de notre équipe technologique. Les gens ne pensent peut-être pas que l'informatique a besoin d'un analyste commercial, mais je veux que mon équipe en arrive à un point où chaque demande technologique qui arrive passe par un analyste commercial. Car, comme vous l'avez dit, plus vous investissez en amont, meilleur est le résultat, car il n'y a pas d'ambiguïté : ce que l'entreprise a demandé, vous l'avez répété de dix façons différentes pour vous assurer que c'est exact. Et c'est là que je veux en venir. Nos solutions sont donc plus rapides et plus directes.

Dayle Hall :  

Et pour que les choses soient claires, avez-vous des analystes d'entreprise dans votre équipe ou se trouvent-ils en dehors de votre organisation ?

Leon Kallikkadan :

C'est un mélange. Nous avons donc un analyste commercial, mais nous avons également - pas des analystes commerciaux techniques, mais notre équipe de projet accède également à nos analystes commerciaux. Ils le font donc à un niveau élevé. Et grâce à notre partenariat avec eux et au temps que nous investissons, ils ont également commencé à se rallier à notre cause. Nous disposons donc actuellement d'une bonne solution hybride.

Dayle Hall : 

C'est vraiment une bonne idée. Encore une fois, j'espère que certains des auditeurs qui écoutent cette émission se disent qu'ils sont peut-être en train de suivre cette voie, qu'ils ont peut-être des analystes commerciaux qu'ils n'utilisent pas, mais qu'ils pourraient manifestement faire plus.

Parlez-moi un peu de l'intégration spécifique, de l'automatisation pour l'entreprise elle-même et de ce que vous faites dans ce domaine. Parlez-moi un peu de l'importance de ce que vous automatisez. Et je pense que l'une des choses dont nous avons déjà discuté, c'est de savoir où l'humain et l'intelligence de l'individu qui connaît l'organisation, où ils jouent un rôle dans le processus de réflexion sur l'automatisation dans l'ensemble de l'entreprise.

Leon Kallikkadan :

Bien sûr. Avant de commencer à répondre, il est important de vous expliquer comment j'en suis arrivé à cette conclusion. Lorsque nous avons créé notre équipe, l'équipe d'automatisation, nous étions tellement enthousiastes, nous avons lancé une toute nouvelle équipe, nous avons tous ces outils sophistiqués, et nous nous sommes dit, vous savez quoi, nous pouvons résoudre les problèmes de tout le monde, ou nous pouvons automatiser tous les processus. Et ce n'était pas la bonne chose à faire. On ne peut jamais automatiser à 100 %. Chaque processus comporte de nombreuses possibilités d'automatisation, petites et grandes. Mais ce que nous avons appris, c'est qu'il est impossible d'automatiser à 100 %. Il y a tellement de complexités, la technologie elle-même, le processus lui-même, l'exception se met parfois en travers du chemin, et il peut y avoir un nombre infini d'exceptions.

Ce sont donc les raisons pour lesquelles nous avons choisi de pivoter vers une approche plus hybride où, vous savez quoi, laissez-nous faire là où la tâche est répétable, où vous avez des exceptions non illimitées, infinies, laissez-nous les automatiser, et laissez-nous essayer de voir si nous pouvons passer à travers ces données. Mais nous voulons toujours que notre ressource, dont le temps a été économisé, regarde, valide les données et analyse presque les résultats, s'assure qu'ils sont conformes, qu'ils se situent dans la fourchette normalement attendue, identifie les exceptions ou les domaines où il y a des erreurs, de sorte que la personne qui s'occupait de ces tâches est maintenant l'analyste. Nous avions un processus qui prenait une journée entière à l'un de nos employés chaque semaine. C'était un processus long et fastidieux.

Encore une fois, nous pensions pouvoir l'automatiser à 100 %, mais nous avons appris que ce n'était pas possible. Ce qui prenait sept à huit heures à cette personne prend maintenant deux à trois heures. Mais ce qu'elle a fait, c'est qu'elle est maintenant assise, attendant que le robot lui envoie les données. Une fois que le robot leur envoie les données, ils savent comment appliquer les règles de gestion, qui sont en dehors, que vous ne pouvez pas mettre dans un script d'automatisation, pour ainsi dire. Ensuite, ils travaillent en quelque sorte - une fois qu'ils sont prêts, ils envoient un e-mail au robot et ce dernier termine le reste du processus. L'humain dans la boucle est donc important pour nous en raison des succès que nous constatons. Par ailleurs, nous avons besoin que nos utilisateurs finaux ou les personnes qui exécutent ces tâches soient nos contrôleurs. Nous voulons nous assurer que nos automatismes sont précis, mais aussi, dans le cas contraire, que quelqu'un est capable de dire, vous savez quoi, hé, arrêtez, il y a quelque chose qui cloche.

Dayle Hall : 

C'est vrai, c'est vrai. C'est intéressant. Et on dirait que vous avez appris de vos erreurs parce que, encore une fois, vous précédez cette réponse en disant : " Laissez-moi vous dire pourquoi j'en suis arrivé à cette conclusion ". Il y a juste quelque chose - si quelqu'un se dit, oh, nous allons faire la même chose, nous avons tellement de choses que nous pouvons automatiser, y a-t-il un exemple que vous pouvez partager avec nous sans trop dévoiler vos processus internes, mais quelque chose de spécifique, vous dites, nous avons suivi ce processus et il s'est effondré ? Y a-t-il quelque chose que vous puissiez partager avec le public ?

Leon Kallikkadan :

Oui, c'est vrai. L'exemple dont je parlais est la création de rapports. Et quand je dis rapport, je parle de la façon dont nous examinons les performances d'une personne et ainsi de suite, donc de certains de ces rapports de haut niveau. La chose la plus importante que nous avons remarquée, c'est que beaucoup de ces utilisateurs de connaissances n'ont pas les connaissances pour les utilisateurs de connaissances dans leur tête, n'est-ce pas ? Il est donc très difficile pour nous d'extraire toutes ces informations.

Parallèlement à cela, il y a d'autres cas où nous avons redémarré en pensant que nous allions faire ceci, mais la technologie finale n'est pas en mesure de nous soutenir, n'est-ce pas ? Nous avons entamé tout ce processus, puis il s'est effondré en fin de compte. Ce que nous avons donc fait, c'est que si vous avez besoin de le faire, faites-le en plusieurs parties. Si vous voulez l'extraire, laissez l'automatisation démarrer, extrayez-le, mettez-le dans l'état que vous voulez. Mais avant de le télécharger ou quoi que ce soit d'autre, assurez-vous que l'autre système fonctionne. Je sais que vous pouvez mettre en place des contrôles et des équilibres, mais essayez de faire en sorte qu'il soit prêt à être téléchargé, etc. Il y a donc quelques cas où nous avons appris à nos dépens.

Dayle Hall :  

Oui, je pense que tout le monde doit passer par là. Pour conclure cette discussion, comme je l'ai dit, j'ai tendance à constater que les personnes qui nous contactent, lorsqu'elles écoutent des émissions comme ces podcasts, sont à la recherche d'astuces pratiques, de conseils pratiques. Donc, si vous pensez à - vous avez dit que vous ne pouvez pas automatiser à 100%, mais que vous avez un processus en place, que devraient-ils regarder pour identifier les parties de l'entreprise qui sont plus importantes à automatiser par rapport à celles qui le sont moins ? Comment pensez-vous à cela pour votre organisation ?

Leon Kallikkadan :

Oui, c'est vrai. Lorsque nous avons commencé, la façon dont nous avons commencé à rechercher et à identifier les opportunités était de s'attaquer aux fruits les plus faciles à cueillir. Comme toujours, les fruits à portée de main sont les moyens les plus faciles de remporter des victoires et de prendre de l'élan. C'est ainsi que nous avons commencé. Puis nous avons élaboré notre processus. Et je tiens à dire à tous ceux qui se lancent dans cette aventure que le processus se construit au fil du temps, qu'il mûrit au fil du temps. Il change constamment, il évolue. Au fur et à mesure que vous apprenez, que vous mûrissez, que vous vous associez à l'entreprise, les choses changent, n'est-ce pas ? Ce n'est donc pas ce que notre processus était au premier jour, qui était très fin et pas très lourd, mais il est maintenant très différent. Et nous avons coopté cela à nouveau - d'autres équipes l'ont fait.

Maintenant, nous nous demandons quelle est la valeur d'une automatisation. Nous regardons le temps que nous passons ou le devis qui nous amènera du point A au point B. Nous regardons la valeur que cette automatisation nous apporterait si... ce qui nous convient le mieux, c'est quelque chose qui demande peu d'efforts, mais qui a un retour sur investissement vraiment élevé, une grande valeur, n'est-ce pas ? Et surtout si l'on peut chiffrer le montant des économies ou des revenus que l'on peut générer, pour moi, c'est le point idéal. Mais je comprends que toutes les entreprises n'ont pas cette possibilité, alors nous examinons ces paramètres, la quantité d'efforts par rapport à la quantité de retour sur investissement, d'économies, peu importe ce que c'est.

Nous avons institué un comité de pilotage composé de nos chefs d'entreprise, de mon superviseur, et nous apportons ces données, nous apportons les exigences et nous disons, vous savez quoi, ces quatre demandes nous sont parvenues, voici la quantité d'efforts, voici la quantité d'avantages. Parfois, nous demandons même à l'utilisateur de venir s'exprimer au sein d'un comité de pilotage, afin qu'il puisse présenter ses arguments directement. Ensuite, en tant que comité de pilotage, nous décidons de ce qui est considéré comme très important, et nous exécutons, et nous exposons notre approche en disant, nous commencerons à travailler sur ce sprint A ou sprint 1, et il faudra ensuite X sprints pour le terminer.

Nous essayons donc d'impliquer le plus possible les entreprises. Cela ne veut pas dire qu'il y a des petits projets que nous ne ferons pas, que nous voulons faire. Mais nous devons aussi comprendre notre rôle. Si nous essayons de tout automatiser pour tout le monde, nous allons échouer. Nous devons donc nous montrer sélectifs dans les domaines où nous voulons apporter le plus de valeur à l'entreprise, et c'est l'entreprise qui décidera. Par exemple, s'il s'agit d'une activité génératrice de revenus, c'est là que nous voulons que les revenus de l'entreprise augmentent. C'est donc plus facile d'utiliser cette approche.

Dayle Hall : 

Lorsque vous avez parlé du comité de pilotage, celui-ci comprend les responsables fonctionnels ou les chefs d'entreprise qui participent à ce processus. Ils sont donc impliqués dès le premier jour.

C'est un très bon conseil. Je suis certain que nous pourrions parler pendant encore deux ou trois heures. Mais j'ai beaucoup aimé ce que vous avez dit. Nous avons parlé de vos équipes de base. Vous vous assurez qu'elles discutent de tous leurs projets et potentiellement, avant que le travail ne commence, des impacts sur leur organisation. Vous établissez également des priorités entre ces équipes, ce qui me semble important. Ainsi, chaque équipe n'est pas comme, hey, où personne ne se bat pour la chose la plus importante pour elle, c'est vraiment ce que - de l'entreprise, ce que je pense être génial. Vous avez parlé de l'informatique qui va vers les utilisateurs, qui s'assure de comprendre et de s'engager davantage sur leurs besoins, ce qui est, je pense, une excellente façon de gérer l'organisation.

Ce que j'ai préféré, c'est ce que vous avez dit, Leon, comment l'informatique peut-elle être un catalyseur de revenus, c'est un état d'esprit extraordinaire à avoir. Et je pense que ce que vous venez de dire à propos de choses comme le comité de pilotage et le fait de s'assurer que l'entreprise adhère aux priorités, et si c'est le revenu d'abord, je suis sûr que vous obtiendrez le bon type de soutien à travers l'entreprise.

L'autre partie que j'ai trouvée très intéressante est celle de l'analyste commercial, que ce soit au sein de l'IT ou dans d'autres secteurs de l'entreprise, mais quelqu'un qui communique, qui gère les attentes de ces projets avec les chefs d'entreprise, je n'ai pas vu cela dans beaucoup d'organisations directement alors que c'est leur rôle, donc c'est vraiment intéressant que cela fonctionne pour vous. Je suis sûr que certaines personnes qui écoutent le podcast sont en train de se dire, hmm, nous avons été des analystes commerciaux. Je me demande pourquoi ils ne le font pas pour nous.

Mais écoutez, c'est génial. Je pense que vous faites un travail formidable. J'adore la façon dont vous envisagez l'automatisation de l'entreprise, qui est évidemment le mantra de ce podcast. Et Leon, merci beaucoup d'avoir partagé vos réflexions aujourd'hui. Ce fut un excellent épisode.

Leon Kallikkadan :

Je vous remercie. Nous nous sommes bien amusés et nous avons eu une excellente conversation.

Dayle Hall : 

C'est vrai. Merci à tous de vous être joints à nous aujourd'hui, et nous vous retrouverons dans le prochain épisode de Automating the Enterprise with SnapLogic.