François NGUYEN, Directeur du Système d'Information Interne de SFR
François NGUYEN : Je parlerai de l’analyse des processus et de la BI in Memory Associative. SFR est une entreprise qui propose à la fois des téléphones mobiles, ADSL et accompagne chaque entreprise et chaque particulier pour lui offrir le meilleur du monde numérique.
Étant directeur du SI interne, je vous parlerai de mon service. Mon patron cherchait un terme français pour « SI Corporate » et a fait une traduction qui n’est peut-être pas très heureuse. Le SI interne couvre tout ce qui est achat, finance et logistique. Il comprend le SI RH, l’intranet et les services généraux, ainsi qu’une dernière entité appelée SharePoint Factory, qui concerne le collaboratif et les réseaux sociaux. Voilà ce qu’est le SI interne.
A l’intérieur de ces trois départements, nous utilisons diverses solutions de Business Intelligence (BI). Nous en sommes arrivés là grâce au rachat de Neuf Cegetel, à l’héritage, à une approche best of breed. Prend-on une solution unique ? Nous allons commencer à réfléchir, mais nous souhaitons rester sur trois thématiques.
⎯ Nous n’allons pas nous organiser en fonction de nos contraintes, mais en fonction de nos clients internes. Nous en sommes également là parce que certains besoins sont exprimés. Je ne crois pas à la plateforme unique. Cela étant, il y en a peut-être un peu trop. C’est le premier point de réflexion.
⎯ Le deuxième point de réflexion est que, selon le retour des utilisateurs, c’est complexe, il y a beaucoup d’outils et il faut se former. L’une des réflexions est donc aussi de voir comment faciliter la vie des utilisateurs. Car chaque outil signifie formation et accompagnement du changement.
⎯ Le troisième point concerne l’innovation, dont je parlerai ultérieurement. Mais il est clair que, compte tenu de tout ce qui se passe aujourd’hui, des solutions vont émerger, des possibilités que nous n’avions pas forcément il y a une ou deux années.
Étant directeur du SI interne, je vous parlerai de mon service. Mon patron cherchait un terme français pour « SI Corporate » et a fait une traduction qui n’est peut-être pas très heureuse. Le SI interne couvre tout ce qui est achat, finance et logistique. Il comprend le SI RH, l’intranet et les services généraux, ainsi qu’une dernière entité appelée SharePoint Factory, qui concerne le collaboratif et les réseaux sociaux. Voilà ce qu’est le SI interne.
A l’intérieur de ces trois départements, nous utilisons diverses solutions de Business Intelligence (BI). Nous en sommes arrivés là grâce au rachat de Neuf Cegetel, à l’héritage, à une approche best of breed. Prend-on une solution unique ? Nous allons commencer à réfléchir, mais nous souhaitons rester sur trois thématiques.
⎯ Nous n’allons pas nous organiser en fonction de nos contraintes, mais en fonction de nos clients internes. Nous en sommes également là parce que certains besoins sont exprimés. Je ne crois pas à la plateforme unique. Cela étant, il y en a peut-être un peu trop. C’est le premier point de réflexion.
⎯ Le deuxième point de réflexion est que, selon le retour des utilisateurs, c’est complexe, il y a beaucoup d’outils et il faut se former. L’une des réflexions est donc aussi de voir comment faciliter la vie des utilisateurs. Car chaque outil signifie formation et accompagnement du changement.
⎯ Le troisième point concerne l’innovation, dont je parlerai ultérieurement. Mais il est clair que, compte tenu de tout ce qui se passe aujourd’hui, des solutions vont émerger, des possibilités que nous n’avions pas forcément il y a une ou deux années.
En appui de votre lecture, vous pouvez télécharger le support de cette présentation sur http://www.forumdecideo.com/file/97845//
Je parlerai de l’analyse des processus. Dans ma direction, nous nous occupons de tout ce qui concerne l’achat, la finance et la logistique, ce qui implique forcément des processus. Pourquoi l’analyse des processus est-elle compliquée ?
⎯ Tout d’abord, pour un processus x, plusieurs variantes existent (avec une possibilité de passer par le haut, par le bas…). Elles viennent compliquer l'analyse.
⎯ Le deuxième point de difficulté est que ce qui se passe à l’étape finale peut être lié à un problème sur l’étape 1. Chaque étape du processus est liée. Ainsi, ce qui se passe à l’étape 4 n’est pas forcément lié à l’étape 4, mais peut-être à ce qui s’est passé avant. L’analyse est difficile et suppose de disposer de l’historique et des étapes du processus.
⎯ Le troisième point est que chaque occurrence du processus est unique avec ses propres caractéristiques, son histoire et sa vie, et ce, même si cette chose est réalisée 500 ou 600 000 fois dans une année. Pour prendre un exemple, nous réalisons 8 millions de livraisons de téléphones mobiles par an, cela ne se passe jamais exactement de la même façon.
⎯ Enfin, chaque occurrence est importante. Ainsi, l’opération a peut-être été réalisée 99 fois très bien, si la dernière fois, vous avez livré vos clients deux mois en retard, c’est principalement cette dernière occurrence qui sera importante. La qualité d’un processus n’est donc pas une moyenne. Toutes les occurrences du processus sont importantes en termes de qualité. D’un point de vue Business Intelligence, ceci est compliqué à analyser.
Quid de la BI in Memory Associative ? J’y retrouve des fonctions BI, qui sont de calculer des choses à la volée, de calculer les indicateurs, de pouvoir sélectionner les attributs. Ces fonctions BI se retrouvent dans toute solution. Mais vous souhaitez travailler avec toutes les occurrences du processus et non sur un jeu de données ou sur un échantillon. Il est important de travailler aussi bien au global qu’avec l’occurrence qui fait mal. C'est véritablement l’apport du « BI In Memory Associative » :
⎯ L’interactivité est maximale : il est possible d’être au global, ou sur une période donnée. Ceci est important car, pour l’analyse de processus, vous serez davantage dans l’exploratoire et dans l’interactivité.
⎯ L’associatif va permettre de relier chaque étape du processus. Le paiement réalisé au terme sera relié à telle facture, telle réception et telle commande. Pour chaque occurrence du processus, nous avons, dans un ERP classique, des évènements qui sont, en fin de compte, associés mais disjoints. La solution associative permet de remettre tous ces évènements ensemble au sein d’une occurrence qui représente le processus.
J’ai, supposons bien sur, des problèmes avec les factures de certains fournisseurs, qui commencent à appeler le PDG, l’informant qu’ils souhaitent arrêter de travailler avec nous dans la mesure où les factures ne sont pas réglées en temps et en heure. Que fait-on ?
Classiquement, un audit, une interview, un diagramme du processus sont réalisés. Des recommandations sont émises, souvent basées sur des idées reçues : toutes vos factures doivent être jointes à la commande, vous devriez scanner toutes vos factures, etc. Généralement, on ne dispose d’aucun indicateur chiffré. Pour avoir travaillé avec SAP pendant dix ans, SAP n’apporte pas un monitoring du pilotage de vos processus. C’est à vous de le créer. Des décisions sont prises, de même que des recommandations mais l’on ne dispose pas forcément de visibilité sur la manière dont le processus se déroule réellement. On n’obtient donc pas d’amélioration substantielle. Plusieurs mois après la recommandation, le processus ne s’améliore toujours pas. Avec le projet Qlikview, nous avons repris nos factures, nos paiements, toutes les dates du processus pour analyser réellement ce qui se passait sur ce processus.
Les indicateurs de délai sont calculés à la volée sur 450 000 factures qui sont chargées dans l’application. Cela permet de comprendre effectivement, étape par étape, ce qui se passe. Il est intéressant de savoir que derrière cela, en mémoire, j’ai les 450 000 factures. Que trouve-t-on et comment interagit-on ? Une valeur est très importante, les 12,16.
A un moment, le fournisseur vous envoie la facture. Il y a déjà une variante : soit vous l’enregistrez directement dans SAP, soit vous la scannez. La question est de savoir ce qui prend le moins de temps, scanner ou enregistrer la facture. Le résultat nous montre que vous êtes à peu près à 35 jours vs. 38 jours en direct. C’est une première surprise car l’on pense généralement que scanner une facture prendra plus de temps. De plus, lorsqu’elle était dans SAP, il ne restait plus que 12,16 jours avant la date d’échéance calculée, ce qui est très peu. C’est une moyenne, au global des 450 000 factures. Il convient d'analyser chaque retard. On s’aperçoit que l’on fait deux paquets de factures : les factures touchées avant et après 60 jours. La vision du process est alors complètement différente. Sur les 450 000 factures, 400 000 sont dans les délais et 50 000 sont très, très en retard. Les 81 jours masquent une réalité beaucoup plus complexe que celle que l’on a.
L’application permet de faire des tests. Vous pouvez sélectionner un fournisseur ou une période, demander le nombre de retards dans la saisie des factures. Tout est possible. A chaque sélection, l’ensemble du processus va être recalculé à la volée pour avoir une analyse de ce qui s’y passe. À gauche, vous disposez de tous les critères susceptibles d’influencer votre processus (le fournisseur, le fait qu’il y ait ou non une commande influe-t-il sur la longueur du processus ?). Simplement en cliquant, vous avez la possibilité de voir si des facteurs favorisent ou défavorisent la qualité du processus. Un bouton très important pour l’interactivité est le bouton « recherche ». En tapant « supérieur à 30 » ou « inférieur à 60 », vous pouvez chercher tous les délais de paiement qui sont entre 30 et 60 jours.
Finalement, nous avons trouvé des factures qui étaient très en défaut. Sur tout le reste, la situation était plutôt bonne. Nous nous sommes vraiment focalisés sur ce qui était en défaut plutôt que d’émettre de grands principes généraux qui s’appliquent à la grande masse, car, finalement, sur celle-ci, nous étions assez bien situés. Entre 2009 et 2010, nous avons gagné quasiment 9 jours. Même si ce n’est pas très visible, nous avons beaucoup gagné en qualité de facture. Voici une première représentation qui permet de voir ce qui se passe au niveau de votre processus et des délais.
Ceci est la deuxième représentation. Elle est appelée « calendrier associé des évènements ». Le fournisseur émet une facture, selon un calendrier. Ainsi, il en envoie 2500 le 31 janvier, 4500 le 1er février et ainsi de suite. Nous indiquons combien nous en avons saisi le même jour. Combien restent encore à payer et à quel moment on les a payées. Ce sont les quatre grandes étapes de notre processus.
Ceci nous permet de voir que le calendrier n’est pas aligné : les fournisseurs envoient, en effet, beaucoup de factures sur la fin du mois, les factures du 30 et 31 janvier forment un gros pic. Voici comment nous nous sommes adaptés, nous les avons saisies sur février, mais également sur mars et avril. Cela permet de voir l’adaptation du rythme de nos équipes vs. le rythme d’entrée des documents. C’est un calendrier associé. Pour un jour donné, vous savez ainsi ce qui se passe d’un point de vue émission de factures par vos fournisseurs et d’un point de vue saisie par vos équipes, mais aussi ce que vous avez payé ce jour-là. Cela permet vraiment de sortir des problématiques de rythme et d’adaptation entre la saisonnalité des factures reçues et la saisonnalité des équipes de travail. À partir de cela, avec la responsable de la comptabilité fournisseurs, un seuil a été fixé à 1000. A moins de 1000 factures saisies par jour, nous avons immédiatement remarqué que nous l’avions « payé » derrière, à savoir que les factures qui arrivaient étaient saisies encore plus en retard sur les périodes suivantes. Aujourd’hui, une alerte se déclenche lorsque pendant plusieurs jours, nous sommes en dessous de 1000 factures saisies par jour. Nous nous remettons alors en mouvement, car nous savons que nous allons devoir compenser ensuite.
⎯ Tout d’abord, pour un processus x, plusieurs variantes existent (avec une possibilité de passer par le haut, par le bas…). Elles viennent compliquer l'analyse.
⎯ Le deuxième point de difficulté est que ce qui se passe à l’étape finale peut être lié à un problème sur l’étape 1. Chaque étape du processus est liée. Ainsi, ce qui se passe à l’étape 4 n’est pas forcément lié à l’étape 4, mais peut-être à ce qui s’est passé avant. L’analyse est difficile et suppose de disposer de l’historique et des étapes du processus.
⎯ Le troisième point est que chaque occurrence du processus est unique avec ses propres caractéristiques, son histoire et sa vie, et ce, même si cette chose est réalisée 500 ou 600 000 fois dans une année. Pour prendre un exemple, nous réalisons 8 millions de livraisons de téléphones mobiles par an, cela ne se passe jamais exactement de la même façon.
⎯ Enfin, chaque occurrence est importante. Ainsi, l’opération a peut-être été réalisée 99 fois très bien, si la dernière fois, vous avez livré vos clients deux mois en retard, c’est principalement cette dernière occurrence qui sera importante. La qualité d’un processus n’est donc pas une moyenne. Toutes les occurrences du processus sont importantes en termes de qualité. D’un point de vue Business Intelligence, ceci est compliqué à analyser.
Quid de la BI in Memory Associative ? J’y retrouve des fonctions BI, qui sont de calculer des choses à la volée, de calculer les indicateurs, de pouvoir sélectionner les attributs. Ces fonctions BI se retrouvent dans toute solution. Mais vous souhaitez travailler avec toutes les occurrences du processus et non sur un jeu de données ou sur un échantillon. Il est important de travailler aussi bien au global qu’avec l’occurrence qui fait mal. C'est véritablement l’apport du « BI In Memory Associative » :
⎯ L’interactivité est maximale : il est possible d’être au global, ou sur une période donnée. Ceci est important car, pour l’analyse de processus, vous serez davantage dans l’exploratoire et dans l’interactivité.
⎯ L’associatif va permettre de relier chaque étape du processus. Le paiement réalisé au terme sera relié à telle facture, telle réception et telle commande. Pour chaque occurrence du processus, nous avons, dans un ERP classique, des évènements qui sont, en fin de compte, associés mais disjoints. La solution associative permet de remettre tous ces évènements ensemble au sein d’une occurrence qui représente le processus.
J’ai, supposons bien sur, des problèmes avec les factures de certains fournisseurs, qui commencent à appeler le PDG, l’informant qu’ils souhaitent arrêter de travailler avec nous dans la mesure où les factures ne sont pas réglées en temps et en heure. Que fait-on ?
Classiquement, un audit, une interview, un diagramme du processus sont réalisés. Des recommandations sont émises, souvent basées sur des idées reçues : toutes vos factures doivent être jointes à la commande, vous devriez scanner toutes vos factures, etc. Généralement, on ne dispose d’aucun indicateur chiffré. Pour avoir travaillé avec SAP pendant dix ans, SAP n’apporte pas un monitoring du pilotage de vos processus. C’est à vous de le créer. Des décisions sont prises, de même que des recommandations mais l’on ne dispose pas forcément de visibilité sur la manière dont le processus se déroule réellement. On n’obtient donc pas d’amélioration substantielle. Plusieurs mois après la recommandation, le processus ne s’améliore toujours pas. Avec le projet Qlikview, nous avons repris nos factures, nos paiements, toutes les dates du processus pour analyser réellement ce qui se passait sur ce processus.
Les indicateurs de délai sont calculés à la volée sur 450 000 factures qui sont chargées dans l’application. Cela permet de comprendre effectivement, étape par étape, ce qui se passe. Il est intéressant de savoir que derrière cela, en mémoire, j’ai les 450 000 factures. Que trouve-t-on et comment interagit-on ? Une valeur est très importante, les 12,16.
A un moment, le fournisseur vous envoie la facture. Il y a déjà une variante : soit vous l’enregistrez directement dans SAP, soit vous la scannez. La question est de savoir ce qui prend le moins de temps, scanner ou enregistrer la facture. Le résultat nous montre que vous êtes à peu près à 35 jours vs. 38 jours en direct. C’est une première surprise car l’on pense généralement que scanner une facture prendra plus de temps. De plus, lorsqu’elle était dans SAP, il ne restait plus que 12,16 jours avant la date d’échéance calculée, ce qui est très peu. C’est une moyenne, au global des 450 000 factures. Il convient d'analyser chaque retard. On s’aperçoit que l’on fait deux paquets de factures : les factures touchées avant et après 60 jours. La vision du process est alors complètement différente. Sur les 450 000 factures, 400 000 sont dans les délais et 50 000 sont très, très en retard. Les 81 jours masquent une réalité beaucoup plus complexe que celle que l’on a.
L’application permet de faire des tests. Vous pouvez sélectionner un fournisseur ou une période, demander le nombre de retards dans la saisie des factures. Tout est possible. A chaque sélection, l’ensemble du processus va être recalculé à la volée pour avoir une analyse de ce qui s’y passe. À gauche, vous disposez de tous les critères susceptibles d’influencer votre processus (le fournisseur, le fait qu’il y ait ou non une commande influe-t-il sur la longueur du processus ?). Simplement en cliquant, vous avez la possibilité de voir si des facteurs favorisent ou défavorisent la qualité du processus. Un bouton très important pour l’interactivité est le bouton « recherche ». En tapant « supérieur à 30 » ou « inférieur à 60 », vous pouvez chercher tous les délais de paiement qui sont entre 30 et 60 jours.
Finalement, nous avons trouvé des factures qui étaient très en défaut. Sur tout le reste, la situation était plutôt bonne. Nous nous sommes vraiment focalisés sur ce qui était en défaut plutôt que d’émettre de grands principes généraux qui s’appliquent à la grande masse, car, finalement, sur celle-ci, nous étions assez bien situés. Entre 2009 et 2010, nous avons gagné quasiment 9 jours. Même si ce n’est pas très visible, nous avons beaucoup gagné en qualité de facture. Voici une première représentation qui permet de voir ce qui se passe au niveau de votre processus et des délais.
Ceci est la deuxième représentation. Elle est appelée « calendrier associé des évènements ». Le fournisseur émet une facture, selon un calendrier. Ainsi, il en envoie 2500 le 31 janvier, 4500 le 1er février et ainsi de suite. Nous indiquons combien nous en avons saisi le même jour. Combien restent encore à payer et à quel moment on les a payées. Ce sont les quatre grandes étapes de notre processus.
Ceci nous permet de voir que le calendrier n’est pas aligné : les fournisseurs envoient, en effet, beaucoup de factures sur la fin du mois, les factures du 30 et 31 janvier forment un gros pic. Voici comment nous nous sommes adaptés, nous les avons saisies sur février, mais également sur mars et avril. Cela permet de voir l’adaptation du rythme de nos équipes vs. le rythme d’entrée des documents. C’est un calendrier associé. Pour un jour donné, vous savez ainsi ce qui se passe d’un point de vue émission de factures par vos fournisseurs et d’un point de vue saisie par vos équipes, mais aussi ce que vous avez payé ce jour-là. Cela permet vraiment de sortir des problématiques de rythme et d’adaptation entre la saisonnalité des factures reçues et la saisonnalité des équipes de travail. À partir de cela, avec la responsable de la comptabilité fournisseurs, un seuil a été fixé à 1000. A moins de 1000 factures saisies par jour, nous avons immédiatement remarqué que nous l’avions « payé » derrière, à savoir que les factures qui arrivaient étaient saisies encore plus en retard sur les périodes suivantes. Aujourd’hui, une alerte se déclenche lorsque pendant plusieurs jours, nous sommes en dessous de 1000 factures saisies par jour. Nous nous remettons alors en mouvement, car nous savons que nous allons devoir compenser ensuite.