Influence des types d’organisation sur les performances d’un SAMU

Influence des types d’organisation sur
les performances d’un SAMU

Dans ce chapitre, nous étudions les données des SAMU afin d’en extraire de l’information et de la connaissance, utiles à l’établissement d’un état des lieux organisationnel objectif. Ce chapitre correspond à la partie droite du cadre (cf. figure 4.1).Nous appliquons d’abord la première étape de la méthodologie présentée dans la section 3.2.1 à propos de la récupération des données et de leur pré-traitement. Nous présentons ensuite la deuxième étape de la méthodologie présentée dans la section 3.2.2 à propos de l’interprétation des données. 

Étape 1 : Collecter et préparer les données 

Grâce à nos SAMU pilotes de l’Aveyron (SAMU 12), du Tarn (SAMU 81) et de la Haute-Garonne (SAMU 31), nous avons pu avoir accès à des données de téléphonie réelles à l’échelle de l’appel. Les données ont été récoltées entre le 1er février 2018 et le 1er mars 2018 pour l’Aveyron et le Tarn. Pour la Haute-Garonne nous disposions uniquement des appels du 25 mars 2018 qui est un dimanche. Bien qu’une journée soit un échantillon d’une taille très faible, le fait que ce soit un dimanche rend cette journée significative. En effet, le dimanche est la journée où les SAMU reçoivent le plus d’appels. Il existe une quantité considérable de données de téléphonie par exemple, un appel peut générer à lui seul plusieurs dizaines de lignes de logs. Toutefois ces données ne sont pas faciles à obtenir, et encore moins à exploiter. Les SAMU n’ont pas directement la main dessus, ils ne disposent généralement pas des compétences nécessaires pour extraire et traiter les registres de téléphonie. Il a donc fallu faire appel au prestataire du logiciel de téléphonie pour qu’il fasse l’extraction et le prétraitement du registre (notamment l’anonymisation des numéros de téléphone) de manière à ce qu’il soit possible de l’exploiter dans le cadre de cette recherche. Quoi qu’il en soit, le fait d’avoir des données de février à mars est particulièrement intéressant. En effet, ce sont des mois d’hiver durant lesquels l’épidémie saisonnière de grippe traverse la France. Durant cette période, le nombre d’appels au SAMU augmente. Ainsi ce sont des mois difficiles où les performances des SAMU sont mises à rude épreuve.

Les approches pour la découverte et la cartographie des processus 

Lorsqu’on cherche à modéliser un système, on va bien souvent passer par la découverte des processus de l’organisation afin de savoir qui fait quoi, quand ? Pour découvrir les processus, cela nécessite d’obtenir de l’information à propos des activités du système. Pour faire cela, (Dumas et al., 2013) considèrent trois techniques de récupération et de création de processus : — Les approches Interview-based qui réfèrent à des méthodes basées sur des entretiens auprès des experts du domaine pour leur demander comment sont effectués les processus. La difficulté étant que les processus sont bien souvent multi acteurs, ainsi pour avoir une vision globale du système il faut croiser les vues de chacun de manière à ne pas perdre d’information. L’avantage de cette technique est qu’elle permet d’avoir une vue très détaillée des processus de l’organisation. Toutefois, l’humain étant faillible par nature, les experts auront tendance à expliquer les processus dans le fonctionnement normal lorsque tout va bien ou au contraire à se focaliser sur les cas exceptionnels qui ont marqué les esprits. Ainsi, il est possible que les cas particuliers qui peuvent poser problème soient occultés.— Les approches workshop-based process discovery. Cette technique consiste à former des ateliers de travail afin de rassembler tous les acteurs pour qu’ils puissent confronter leurs visions du processus et leurs places dans ce dernier. Cette méthode demande à être capable de réunir l’ensemble des rôles à une même réunion. Pour avoir une vision complète et satisfaisante du processus, plusieurs ateliers de ce type seront nécessaires. — Les approches Evidence-based qui se basent sur l’étude d’éléments de descriptions tangibles d’un processus. Cela peut prendre la forme de documents écrits, d’organigrammes, de procédures. Toutefois, les documents de description édités par des humains peuvent être limités et oublier une partie du processus. C’est pourquoi il est intéressant de les croiser et de les compléter avec d’autres méthodes. Parmi les approches Evidence-based, on trouve aussi la découverte automatique de processus (Process Mining), qui elle se base sur les enregistrements faits dans le système d’information. Si les registres sont complets et que chaque événement peut être relié à un cas individuel du processus, à une activité et à un moment précis dans le temps, alors on peut reconstruire le processus dans son intégralité. Cette méthode implique d’avoir accès à ces données, ce qui n’est pas toujours évident. Chacune de ces méthodes a donc des avantages et des limites. Le tableau 4.1 résume les caractéristiques de chaque méthode selon plusieurs critères (vu par (Dumas et al., 2013)) : l’objectivité, la richesse en information, le temps passé, et le retour des experts. L’objectivité correspond à quel point on peut croire à la donnée récoltée comme étant la réalité. Il y aura plus de biais dans des données transmises par des humains que par des systèmes d’information. Par richesse, on entend la qualité et la précision de l’information que l’on va pouvoir avoir. La compréhension d’un système d’information peut être limitée là où un humain peut expliquer précisément un écart dans les données, car il sera capable de relier des données chiffrées à une situation complexe. Le temps d’une méthode à l’autre ne sera pas le même. Il sera plus long de réussir à réunir plusieurs acteurs à des ateliers que d’analyser des données, si on fait l’hypothèse que l’accès aux données est simple. Or dans notre domaine, nous l’avons vu, l’accès aux données est plutôt long et fastidieux. Selon la méthode il sera plus ou moins facile d’avoir un retour rapide des experts sur le modèle construit. Lors d’atelier ou d’entretien, le modèle de processus peut être construit de manière itérative rapidement, l’analyse des données rend l’échange avec les experts moins direct.

Sous-étape 1.a : Collecter et nettoyer les données

Format des données récupérées Les données ainsi récoltées, nous ont été transmises sous forme de registres d’événements (logs). Avant d’exploiter ces données, un traitement est nécessaire pour enlever les doublons, les données incomplètes et obtenir un format qui puisse être exploité. La figure 4.2 présente les deux grandes étapes appliquées et des extraits des logs à chacune des étapes. Un premier travail de pré-traitement a été fait par le prestataire de téléphonie qui nous a fourni les données. En effet, sans cela les données se présentaient sous la forme d’un fichier de texte difficilement exploitable. Le premier traitement appliqué permet d’obtenir une table de données avec différentes colonnes (cf. figure 4.3). Nous présentons ci-dessous les significations des éléments que nous avons utilisés par la suite. Afin d’illustrer le contenu de chaque colonne nous proposons un exemple dans la figure 4.4. : — EventNo : Le numéro de l’événement qui est un identifiant unique de l’événement. Dans l’exemple, nous avons 23 événements différents, chacun avec son propre identifiant. — EventName : Le nom de l’événement. On constate qu’il y a deux types d’événements, ceux qui commencent par « Event », et ceux qui commencent par « Request ». Ces derniers sont des demandes d’information faites par le serveur, nous ne les utiliserons pas dans la suite, car ils ne nous apportent pas d’information pertinente. Nous reviendrons juste après sur les différents événements et leurs significations. — Localtime1 : Le jour de l’événement au format DD-MM-AAAA. Ici notre appel date du 31 janvier 2018. — LocalTime2 : L’heure de l’événement au format HH :mm :ss,ms. L’appel arrive enregistre son premier événement à 23 :43 :30 et il sera raccroché à 23 :46 :59. — ThisDN : Le code du poste de travail, DN correspond à Directory Number. Dans notre exemple on constate 2 codes différents 25954 et 25009. Le code 25954 correspond à la file d’attente et 25009 correspond au code d’un poste de travail d’ARM. — OtherDN : Le DN d’un autre poste de travail impliqué dans la gestion de l’événement courant. Cela peut par exemple être le numéro du poste du travail auquel l’appel est transféré. Typiquement sur l’événement numéro 107 EventRouteCall on a un OtherDN qui vaut 25009, cet événement nous indique que l’appel provient de la file d’attente ThisDN dont l’identifiant est 25954. — ThisQueue : File d’attente dans laquelle est l’appel. Dans l’exemple on retrouve le code correspondant à la file d’attente soit 25954. — ThirdPartyDN : Identifiant (DN) du poste de travail d’un troisième intervenant sur l’événement courant concernant l’appel. — ConnID : Identifiant de l’appel, plusieurs événements vont être reliés à un même appel, afin de pouvoir regrouper ces événements l’appel à un identifiant unique. L’identifiant unique de notre appel est 006f02a790028c34. C’est bien le même code qu’on retrouve pour chaque événement. — TransferConnID : Identifiant de l’appel vers lequel la communication a été transférée. Lorsqu’un appel est transféré, par exemple, d’un ARM à un MR, il se peut que l’identifiant de l’appel change, car l’ARM peut mettre l’appel du patient en attente, composer un nouvel appel vers le MR puis transférer le patient sur ce nouvel appel avec le MR. Les deux appels ont alors des identifiants différents et ce champ permet de les relier. Il n’y a pas d’appels transférés dans notre exemple. — PreviousConnID : Cet identifiant est utilisé dans le cas d’un transfert d’appel avec changement d’identifiant. Il correspond à l’identifiant de l’appel précédant depuis lequel le nouvel appel courant a été transféré (appel de consultation, par exemple lorsqu’un ARM appelle un MR afin de lui résumer l’appel). Dans notre exemple il n’y en a pas. — CallID : Cet attribut contient l’identification de l’appel fournie par le commutateur, qui identifie un appel de manière unique. Contrairement au ConnID attribué par le serveur, le CallID est créé par le commutateur lorsque l’appel entrant arrive, ou lorsque les appels sortants de l’agent/du système sont créés. L’attribut doit être présent si le commutateur génère et distribue le paramètre correspondant au serveur (CallID est égal à zéro tant que le commutateur ne fournit pas cette information au serveur). — ANI : Cela signifie Automatic Number Identification C’est le numéro de l’appelant. Dans notre exemple, les numéros des appelants ont été anonymisés c’est pourquoi nous avons un numéro sous la forme « HV3O1V2O1 ». — DNIS : Cela signifie Directory Number Identification System, c’est le canal d’entrée utilisé par le numéro appelant, le numéro qu’il a composé pour joindre le centre d’appels. Ici le code est le 25601, qui correspond aux appels qui arrivent en ayant composé le 15. — AgentID : L’identifiant de la ressource qui gère l’événement. L’appel a été géré par l’agent avec l’identifiant 25528. Si on fait le lien avec les tables de signification, on voit que cela correspond à un ARM.

Nettoyage et préparation des données

L’objectif de cette partie est d’effectuer un prétraitement afin d’avoir une base de données complétée qui nous permette facilement de faire des analyses. Pour ce faire, plusieurs étapes ont été suivies : — Seulement un certaines colonnes ont été conservées (EventNo, EventName, LocalTime,ThisDN, OtherDN, ConnID,DNIS, AgentID, ANI). La colonne CallID n’a pas été conservée, car elle était redondante avec l’identifiant du ConnID. Les colonnes ThisQueue et ThirdPartyDN sont assez peu utilisées et ne nous apportent pas d’information que nous sommes en mesure d’exploiter. De ce fait ces colonnes ont été écartées. — Les données sont triées par ordre chronologique. — On nettoie les données, on supprime les lignes qui n’ont pas de ConnID, celles qui n’ont pas un LocalTime complet ainsi que les événements qui ont été identifiés comme non pertinents (EventCallPartyState et EventAttachedDataChanged) qui sont des événements que nous n’exploitons pas. Enfin on supprime les doublons. Les données brutes sont composées de 69360 appels et 9890976 événements sur les deux mois (pour le SAMU d’Albi). Après traitement des données, on obtient un jeu de données contenant 56918 appels soit 82% des données extraites initialement. Cela nous assure un nombre toujours significatif d’appels qui ne compromet pas la pertinence de notre analyse. — On complète les données avec le jour de la semaine, cela nous permettra par la suite de faire rapidement un tri pour étudier des jours spécifiques de la semaine. — On complète les données avec le rôle de la ressource qui effectue l’action. En effet pour chaque événement nous avons l’identifiant de l’agent qui effectue la ressource, on vient compléter cette information en renseignant si cette ressource est un ARM ou un MR, cela nous permet de donner plus de sens métier aux données. — On transforme les données en log en les regroupant selon leur ConnID.