Automatisation du reporting des statistiques sécurité du groupe

Compagnie des Salins du Midi et des Salines de l'Est (CSME)
Automatisation du reporting des statistiques sécurités du groupe

Mémoire

Réalisé par : LAKHDHAR Amira

Etudiante en Master 1 Méthodes Informatiques
Appliquées à la Gestion des Entreprises

Formation en apprentissage
Année 2020/2021

Maitre d'apprentissage en entreprise :
PLANCQUEEL Frédéric

Tuteur pédagogique :
CAILLOUX Olivier

Chargée de mission :
LAVAGNA Patricia

1

SOMMAIRE

Remerciements 2

Introduction 3

I. Compagnie des Salins du Midi et des Salines de l'Est (CSME) 3

I.1.Présentation du groupe 3

Structure du groupe 3

But de l'entreprise 4

Différents projets de modernisation maintenus par la DSI 5

I.2. La Sécurité à Salins 8

Indicateurs Sécurité 8

Environnement de la problématique 9

I.3 Problématique et mission 16

II. Automatisation de la remontée des indicateurs Sécurité 18

II.1. Analyse de l'existant 18

Enquête sur l'acheminement des données 18

Réflexion et analyse des informations récoltées 21

Véracité de la donnée exploitée 24

II.2. Descriptif des solutions 26

Enoncés des solutions et définitions des outils nécessaires 26

Comparaison des avantages et des inconvénients des deux méthodes proposées 38

Solution préconisée pour la problématique 40

Conclusion 41

Liste des annexes 43

2

Remerciements

Je remercie dans un premier temps, mon maitre d'apprentissage Monsieur Frédéric Plancqueel, Directeur des opérations et de la sécurité du groupe Salins, pour son habituelle collaboration et compréhension, tout en m'accordant sa confiance et une large indépendance dans la réalisation intégrale de l'étude.

Je voudrais également remercier mon tuteur enseignant, Monsieur Olivier Cailloux, maître de conférences en informatique au LAMSADE à l'université Paris Dauphine, pour le suivi de ma mission et les conseils apportés pour la rédaction de ce mémoire.

J'adresse mes remerciements à toute l'équipe pédagogique de l'université de Paris Dauphine pour leur partage de connaissances, ainsi que les intervenants responsables de ma formation pour m'avoir accompagnée et soutenue tout au long de celle-ci.

Je tiens aussi à remercier les collaborateurs à la Direction des systèmes d'information du groupe
Salins, Monsieur Eugene Botella, Monsieur Vincent Pasquazzo et Monsieur Cyrille Meslin-Clement,
pour leur patience et le temps qu'ils m'ont accordé pour répondre à mes questions sur le
fonctionnement de certains outils. Ils ont été d'un grand soutien dans la résolution de la
problématique posée dans ce mémoire.

Enfin, c'est avec le coeur ému que je remercie chaleureusement mes très chers parents, Ahmed et
Najiba, pour leur affection et leur soutien inépuisables, leurs précieux conseils, les encouragements
réguliers et pour avoir toujours été là pour moi, malgré les milliers de kilomètres qui nous séparent.
Je remercie aussi ma soeur Eya et mon frère Nidhal pour leur soutien inconditionnel.

A tous ces intervenants, je présente mes remerciements, mon respect et ma gratitude.

Avec honneur, je dédie ce modeste travail à mes défunts grands-parents, qui m'ont beaucoup appris.

3

Introduction

A l'instar de la majorité des entreprises qui aujourd'hui investissent pour tirer parti des nouvelles technologies dans un objectif d'amélioration des services, le groupe Salins s'est engagé aussi dans cette démarche. C'est dans ce cadre que le groupe a décidé de moderniser ses techniques de travail, dont un des projets objet de mon mémoire : trouver les méthodes informatiques adéquates pour automatiser la remontée des indicateurs de sécurité depuis des sources de donnée différentes.

Ayant une appréciation spécifique du pouvoir qu'admet la donnée dans le développement de plusieurs domaines du monde professionnel, j'ai pris en charge le projet avec la ferme conviction de le mener à bon.

Pour mieux présenter la problématique, une présentation du groupe CSME et de certains de ces projets informatiques en cours est importante. Une présentation détaillée de par la suite, la problématique suivra (Chapitre I).

Pour mieux traiter les données, il faut assurer leur cohérence et souvent procéder à des corrections.

L'enquête détaillée sur l'existant, l'étude de l'environnement informatique du groupe ainsi qu'une analyse du besoin sont à mener pour connaitre les tenants et aboutissants du problème technique à aborder et construire une solution à la problématique (Chapitre II, partie 1).

Enfin les solutions préconisées et les outils nécessaires au bon fonctionnement de la solution choisie seront détaillés et bien analysées dans un tableau pour comparer les avantages et les inconvénients de chacune des solutions proposées (Chapitre II, partie 2).

Toute nouvelle mise en place d'une solution informatique doit être obligatoirement suivie par des instructions et recommandations pour la maintenance et les moyens nécessaires pour son évolution.

I. Compagnie des Salins du Midi et des Salines de l'Est (CSME)

I.1.Présentation du groupe

Structure du groupe :

C'est en 1856, qu'à Aigues-Mortes, commune du Gard, un groupe de propriétaires de salins décident de s'associer et de former la société Renouard et Cie. Douze ans plus tard, en 1868, elle devient la Compagnie des Salins du midi et possède un siège social à Montpellier. En 1890, la société est en plein développement et dépasse le seuil des 80 000 tonnes de sels produites. A cette même période, les salins de Giraud sont récupérés par la Compagnie des Salins du Midi, anciennement aux mains d'une société appelée Péchiney. L'expansion ne s'arrête pas là et en 1960 la Compagnie des Salins du Midi va racheter la Société Salinière de l'Ouest qui représente les principaux distributeurs de Sel à l'Ouest de la France, ce qui leur octroie le contrôle sur les deux-tiers de la commercialisation du sel guérandais. Enfin en 1968, la Compagnie des Salins du Midi et des salines voit le jour après sa fusion avec la

4

Société des Salinières de l'Est et du Sud-Ouest et la saline de Dax, ce qui donnera au groupe une dimension nationale.

Fort de ses expertises, la capacité de production du Groupe s'élève à quatre millions de tonnes de sel par an, dans ses installations industrielles de France, Espagne, Italie, Slovénie, Portugal, Tunisie, Sénégal et très prochainement, le Danemark, la Suède et les Pays-Bas (voir la figure suivante).

Figure 1 : Implantation industrielle

Le siège social du groupe Salins est implanté à Clichy, compte approximativement 150 personnes. Plusieurs directions telles que les Ressources Humaines, le Marketing et autres, sont hébergées dans ce siège.

Actuellement, j'appartiens au pôle sécurité dirigé par Mr Frédéric PLANCQUEEL et je suis en charge de l'étude du reporting de la sécurité du groupe avec une mission principale d'étudier l'automatisation de la remonté des indicateurs Sécurité.

But de l'entreprise :

Le Groupe Salins compte aujourd'hui plus de 1800 collaborateurs, et c'est dans une démarche de développement responsable qu'il opère quotidiennement pour offrir un sel de grande qualité, et contribue au succès de ses clients industriels afin de garantir au mieux la satisfaction des consommateurs. Le Groupe Salins est l'un des principaux saliniers européens et le seul pur salinier, en effet il se consacre uniquement à la production et

5

commercialisation du sel. Il est également le seul Groupe européen à utiliser les 3 techniques de production du sel : La méthode agricole pour le sel de mer, le process thermique pour le sel igné ou ignigène et la technique minière pour le sel gemme.

Le succès de l'entreprise revient aux collaborateurs qui accordent beaucoup de temps acharnés à leur travail. Pour les soulager et les encourager à continuer à travailler en ayant plus de temps à consacrer aux tâches les plus importantes aux fonctionnements des services de l'entreprise et pour profiter et s'adapter à l'évolution des techniques informatiques modernes utilisées dans le monde professionnel, les équipes de la direction du groupe travaillent sur différents projets de modernisation pouvant faire gagner du temps et de l'énergie aux collaborateurs.

Par exemple, un projet impliquant la mise en place d'interface permettant aux équipes de maintenance de faire du reporting et de l'audit sans utiliser de paperasse ni de document spécifique à chaque activité. Cela permet à la fois aux agents sur terrain de gagner du temps en remplissant tout sur une tablette et aussi aux gestionnaires des données transmises grâce à l'interface d'en faire usage de manière rapide et plus efficace, en ayant toutes les informations centralisées dans une même base de données ou dans un même serveur.

Le groupe Salins attache la plus grande importance à la sécurité de ses collaborateurs. Le travail engagé doit permettre de réduire le temps à la construction des indicateurs pour consacrer plus d'énergie à la réduction des risques d'accident pour l'ensemble du groupe.

Différents projets de modernisation maintenus par la DSI : Voici deux projets très intéressants parmi ceux en cours à Salins :

ALTAIR

Le projet « Altair » est exploité par la DSI en collaboration avec les responsables de la maintenance. Il repose sur un logiciel de maintenance Altair (GMAO : Gestion de Maintenance assistée par Ordinateur) développé par le groupe DSD System, il propose un module QHSE et un logiciel QHSE qui a été acheté par Salins et que nous avons pour objectif de déployer.

DSD System accompagne depuis 2003 les entreprises de tous secteurs d'activité dans leur projet de déploiement de logiciel GMAO et QHSE. Avec plus de 200 références clients et des projets suivis sur plus de dix ans, la société a pu mettre son expertise à l'épreuve des projets les plus simples comme les plus complexes. Le projet voit un franc succès et rapidement le logiciel et la société prennent de l'ampleur avec une liste de client qui ne cesse de s'allonger.

Un module de QHSE pouvant être utilisé depuis le logiciel de GMAO (Altair) pour les clients a vu le jour en 2011. Son exploitation étant assez limitée et ne permet pas la couverture de tous les aspects du QHSE. En 2013, la société sort deux nouveaux logiciels, un logiciel de Altair SAV et le logiciel de Themis QHSE qui vont intéresser beaucoup de clients utilisant le module QHSE de la GMAO.

6

Le logiciel Themis QHSE était initialement un module d'Altair GMAO. Dans son panel de possibilités on retrouve :

· Suivi des événements HSE (accident, presqu'accident, anomalies...)

· Règlementation et habilitation (gestion documentaire)

· Gestion du document Unique

· Tableau de bord et indicateurs

· Intégration complète des sites (les emplacements, les postes, les sites)

Ce dernier propose une interface attractive et très accessible, comme schématisé sur la figure ci-dessous, ce qui rend son utilisation très accessible à tout le monde.

Figure 2: Interface Themis QHSE

Le logiciel Themis QHSE fonctionne via le Web. Il suffit d'utiliser un lien pour se connecter à un profil personnel suivant un niveau hiérarchique bien défini au préalable. Lorsque le logiciel est ouvert, toutes les possibilités sont visibles, mais ne sont pas toutes accessibles. Les autorisations sont accordées selon le profil de chaque utilisateur.

Une fois sur le logiciel, on peut déclarer tous type d'événement HSE, comme les accidents, incidents et les anomalies avec des champs paramétrables.

La principale différence entre les événements HSE et les anomalies est la cible de la déclaration : Les événements désignent les dégâts humains et les anomalies, les dégâts matériels.

Les informations sont ensuite enregistrées et archivées ce qui permet de les garder en mémoire dans une base de données.

Il est aussi possible de communiquer le rapport par mail à une liste de diffusion suite à l'enregistrement des informations sur le serveur.

7

L'accueil du site met en avant sur un Dashboard toutes les informations importantes sur le site en question. On peut visualiser tous les événements HSE, avec la possibilité d'ajouter des filtres comme les années, ou le type d'événement non souhaité ENS, etc...

Figure 3: Interface d'accueil du logiciel

(Source : https://www.inoteam.fr/solution-gmao-altair-entreprise/)

L'objectif d'utiliser le logiciel proposé par la société Themis serait de faciliter un bon nombre de missions des correspondants Sécurité afin qu'ils puissent être opérationnels.

Avec l'assistance de ce site beaucoup de missions qui sont longues pourraient être drastiquement raccourcies, comme la veille règlementaire.

Il permet de gagner beaucoup en travail en coopération. Dans l'optique ou se serait possible, il permettrait aux différents sites de travailler les uns avec les autres et améliorer la communication inter-sites.

Les déclarations des événements HSE représente une fonctionnalité qui pourrait être utilisée pour les déclarations d'ENS puisque l'interface rassemble tous les critères actuellement utilisés et il est possible de les archiver pour les garder en référentiel sur les années suivantes.

Altair va donc permettre de déclarer les ENS d'une manière centralisée et pratique à la communication et au traitement des déclarations de sécurité du groupe. L'interface qui permet de déclarer un accident est présenté sur l'annexe 2.

L'intégration de SAP SuccessFactor:

Le projet consiste à une profonde transformation du SIRH du groupe avec la mise en place de la solution SAP SuccessFactor.

SAP SuccessFactors est un module SAP qui représente une solution RH intégrée et basée dans le cloud. Tous les outils nécessaires y sont fournis, ainsi que la meilleure technologie, pour faire briller le potentiel des collaborateurs à l'entreprise grâce à des best practices de gestion RH et de gestion des talents. SAP SuccessFactors est mondialement opérationnel et

8

aide à l'amélioration de l'expérience de travail. Il se base sur des processus de bout en bout et des données intégrées pour permettre une excellente gestion des ressources humaines. Il aide les collaborateurs à réaliser leur mission en s'assurant de leur satisfaction au travail pour atteindre rapidement les objectifs du groupe.

Pour le réaliser, on doit d'abord décider des indicateurs sur lesquels le service des ressources humaines veut se baser afin d'améliorer différents aspects et tâches de leur métier. Ensuite, il est aussi préconisé de mettre en place des modèles de données pour créer des Dashboards attractifs dans l'objectif de mettre en valeur ses indicateurs qui seront à construire avec des données portant sur le personnel du groupe.

Il est géré par le directeur de la RH. Il impliquera l'intervention de différents acteurs, notamment des responsables à la DSI pour la gestion du côté technique du projet et le personnel RH pour la distinction du besoin métier afin de construire les indicateurs adéquats. Ce projet a pour objectif la mise au point avec les nouveaux sites intégrant le groupe qui utilisent la solution SAP SuccessFactor.

Il est encore en phase de préparation et je ferai partie de l'équipe technique en charge de sa réalisation au sein de la DSI.

I.2. La Sécurité à Salins

Indicateurs Sécurité

Pour assurer la sécurité des 1800 collaborateurs, la direction des opérations industrielles a mis en place un suivi mensuel des événements non souhaités ENS qui peuvent avoir lieu dans les lieux de travail.

Les ENS peuvent être des accidents avec arrêt AAA, des accidents sans arrêt ASA ou des incidents INC. Quand un ENS a lieu, le responsable du site, lieu de l'événement, rempli un formulaire avec les informations nécessaires pour en informer la direction du non souhaité. Par la suite, le nombre de jours perdus en cas d'AAA ou en cas de rechute, en plus du nombre d'accidents ayant eu lieu sur un même site ainsi que le nombre total d'heures travaillées sur le site forment des données utiles et nécessaires à la construction des indicateurs suivants :

- Taux de fréquence TF : « le rapport entre le nombre total d'accidents (sur le lieu du travail) ayant entraîné la mort ou une incapacité totale d'un jour au moins (hors jour de l'accident) et le nombre d'heures d'exposition au risque, multiplié par 1 000 000 (afin d'obtenir des chiffres exploitables) ».

- Taux de gravité TG : « le rapport entre le nombre de jours calendrier réellement perdus à la suite d'accidents de travail (sur le lieu du travail) et le nombre d'heures

d'exposition au risque, multiplié par 1 000 ». (Source : https://urlz.fr/gkpq).

Ces taux, calculés tous les mois pour chacun des sites et unités du groupe permettent de construire tout au long de l'année fiscale, des tableaux de synthèse et des courbes de variation permettant au service de gestion de mieux visualiser la variation des taux par rapport aux objectifs fixés chaque juillet par le responsable Sécurité du groupe.

Les graphiques construits servent au service de gestion qui présente au Comité de Direction CODIR tous les mois, le tableau de graphique TG et TF comparés à la moyenne glissante, ce qui permet d'étudier la tendance de la fréquence et de la gravité des accidents ayant eu lieu sur tous les sites du groupe ou au niveau du CSME à la fin de l'année fiscale.

9

Ces informations sont partagées sur un document de synthèse des résultats qui est aussi partagé sur le SharePoint accessible par la direction. Il est visité lors des réunions de clôture de l'année fiscale qui ont lieu en fin juin de chaque année.

En plus, le service de gestion suit l'évolution des TG et TF par rapport au budget du CSME sur le graphique (voir la figure 4). Cette évolution est très importante car elle affecte directement la prime d'intéressement, c'est à dire, si le taux de fréquence explose, la prime d'intéressement subit une baisse conséquente et vice-versa. Cette prime d'intéressement et de participation intéresse aussi le comité social et économique CSE du groupe.

Figure 4: Slide présenté par les contrôleurs de gestion au CODIR

Les indicateurs Sécurité sont aussi communiqués dans le reporting banque que le service de gestion construit et émet aux banques. En effet, comme le groupe Salins tient une ligne de crédit chez les banques choisies, ces dernières ont besoin de certaines statistiques, notamment les TF et TG du groupe de l'année écoulée et avec le budget prévu au 30 juin, date de fin de l'exercice annuel du groupe.

Les graphiques représentant l'évolution de ces indicateurs sur l'année de l'exercice, comparés à la moyenne glissante sur les mois précédents et aux budgets fixés par la direction sont donc primordiales pour le reporting fait aux banques à la fin de chaque exercice.

Environnement de la problématique

Pour décrire l'environnement de la problématique, il est important de préciser la structure informatique existante chez Salins ainsi que la méthode de reporting actuellement utilisée pour la remontée des indicateurs sécurité.

Structure informatique existante :

La structure complète des projets de développement informatique du groupe est décrite dans le schéma sur annexe 1. Pour cette étude, on s'intéresse à une partie de l'iceberg :

10

Figure 5 : Partie de la cartographie de la structure existante (SAP et hors SAP)

Sur cette sous-partie du schéma, on peut voir le coeur de la structure informatique de l'entreprise : l'outils SAP. « SAP est l'un des plus grands éditeurs de logiciels de gestion de processus métier au monde ; SAP offre des solutions qui permettent un traitement des données et des flux d'informations efficaces au sein des entreprises. » (Source : https://www.sap.com/france/about/company/what-is-sap.html)

Pour certains projets et bien que les modules SAP soient multiples et divers, il est souvent nécessaire de créer des connexions avec des outils, serveurs ou systèmes hors SAP (voir figure précédente). C'est le cas pour le projet Altair. En effet, son développement a nécessité une liaison d'échange de donnée et d'accès valide dans les deux sens depuis l'outil GMAO vers SAP et inversement, tandis que aucun lien ne relie encore la GTA, logiciel de gestion des activités et des absences, avec le progiciel SAP.

Description de la méthode existante de reporting Sécurité :

Partant du principe que ma mission au sein de Salins est de communiquer les indicateurs sécurité du groupe à tous les sites pour les informer de tous les événements survenus, le préalable étant la récupération et le traitement de tous les événements et les incidents du groupe.

La collecte de ses informations passe par plusieurs étapes et l'utilisation de différents moyens détaillés comme suit :

1) Le tableau récapitulatif des évènements non souhaités ENS

Les événements non souhaités ou ENS sont tous les faits survenus au sein du groupe Salins. Ils sont recensés sur un tableau pour pouvoir communiquer à propos des éléments pertinents concernant l'événement aux autres sites.

Pour le remplir, on se base sur les déclarations des événements que remplissent les correspondants des sites quand un non souhaité a lieu. Il existe pour ça un modèle de rapport d'alerte sécurité (voir annexe 6).

La déclaration regroupe un maximum d'informations récupérées par la personne ayant rédigée la déclaration. On y trouve toutes les informations concernant l'accident (unité concernée, date, heure, personne avertie, etc..) puis les informations concernant la personne

11

victime de l'événement (si accident avec ou sans arrêt, accident de trajet ou presqu'accident) suivi de la description de la manière dont se sont produits les faits.

Les informations intéressantes pour la construction des rapports et des indicateurs sont essentiellement l'unité, le site et le nombre de jours d'arrêt s'il s'agit d'une déclaration d'accident avec arrêt.

Une fois les déclarations reçues, elles sont classées dans des dossiers selon l'année, le mois, la nature de l'événement et le site d'occurrence. Des photos peuvent être jointes aux déclarations pour illustrer les faits.

Les déclarations classées sont aussi recensées dans un tableau Excel qui reprend toutes les catégories que l'on trouve sur la déclaration en plus des catégories qu'on a reprises, comme les causes et les origines de la cause. Le tableau recense les accidents des exercices précédents et permet une centralisation de l'information pour tous les sites.

2) Rapport hebdo de sécurité

Le RH Sécurité est un condensé de toutes les informations concernant les accidents Sécurité de la semaine. Il permet d'avoir un accès rapide à l'information et i indique également le comparatif par rapport à l'année précédente ce qui permet de souligner des points nécessitant une attention plus particulière que d'autre.

Une fois que le rapport sur accident est reçu par le responsable des opérations, il est rajouté à l'ensemble des autres informations reportées par les autres pôles et le rapport final est renvoyé aux correspondants sécurité de chaque site, afin qu'ils puissent se tenir informés des informations sécurité de l'intégralité du groupe, ce qui leur permet après d'échanger, si besoin, sur certains points évoqués dans le rapport.

On trouve un certain nombre d'informations comme tous les ENS qui sont survenus dans la semaine (voir le document sur la figure suivante). Ce rapport est également rédigé pour tous les autres pôles de la Direction des opérations.

Figure 6: Rapport hebdomadaire sur accidents

12

Le maintien de ce tableau à jour de manière hebdomadaire et le préparer tous les ans en reprenant les résultats de l'année précédente et le budget de l'année actuelle peut prendre du temps qui peut être gagné en automatisant la construction et le remplissage du rapport hebdomadaire des accidents.

3) Statistiques mensuelles sécurité :

Le rapport des statistiques de sécurité mensuelles est un ensemble de tableaux compris dans un fichier Excel. On y trouve un bon nombre d'informations concernant la sécurité et qui permettent entre autres de calculer le taux de fréquence et le taux de gravité.

Le taux de fréquence est un taux calculé à partir du nombre d'accidents avec arrêt AAA, survenus au cours d'une période, pour une tranche d'un million d'heures travaillées. Il s'agit de la fréquence d'apparition des accidents avec arrêt par mois, c'est pour ça qu'il est nécessaire de connaitre le nombre d'AAA du mois ainsi que les heures travaillées HT. Le taux de gravité correspond au nombre de journées indemnisées, soit les jours perdus pour arrêts de travail ou accident de trajet, pour 1000 heures travaillées. Ce taux communique des informations sur l'impact des accidents sur les salariées, en effet un accident grave entrainera beaucoup de jours d'arrêt ce qui fera augmenter considérablement le taux de gravité et inversement.

Pour créer ce fichier Excel, il est donc primordial de récupérer toutes les données citées précédemment, c'est-à-dire, les heures travaillées HT, tous les accidents AAA et ASA, ainsi que les jours perdus JP pour les accidents avec arrêts.

Au début de chaque mois, les statistiques du mois écoulé sont calculées et envoyées au contrôle de gestion puisque c'est un critère au calcul de la prime d'intéressement et de participation.

En ce qui concerne les accidents et les jours d'arrêts, ces données se trouvent dans les déclarations d'ENS où l'on va trouver la nature de l'événement, soit les accidents avec arrêt, et le nombre de jour d'arrêt associés.

Il existe un tableau Excel (voir le tableau 1) dans lequel sont recensés tous les accidents ayant entrainé des jours d'arrêts, avec la personne impliquée, l'unité et le site dans lesquels il travaille et le nombre de jours perdus.

Ce tableau permet de connaitre sur un mois la quantité de jours d'arrêt par sites concernés. Puisque selon les accidents, les jours à indemniser peuvent être étalés sur plusieurs mois, ça permet de ne pas oublier les jours d'arrêt sur le mois suivant.

Tableau 1 : Tableau des jours perdus JP

Les heures travaillées HT sont récupérées par mail depuis différents collaborateurs selon le pays du site. Concernant les sites français, les heures travaillées sont comptabilisées par la GTA, un logiciel de gestion des heures mis en place sur tous les anciens sites français sauf ceux de Distrisel et Sotrasel qui renvoient leurs nombres d'HT en se basant sur le système de paie utilisé par les ressources humaines pour la paie.

13

La GTA centralise toutes les HT selon les matricules et selon les sites et les unités dans une base de données et un fichier Excel est extrait et envoyé automatiquement tous les mois à une liste de distribution prédéfinies par le responsable du logiciel. Le résultat de l'extraction repose sur une requête qui filtre les données selon certains critères pour que les chiffres communiqués soient corrects et complets. Malgré cela, on arrive à trouver des données aberrantes dans la donnée extraite.

Le fichier transmis de la GTA est ensuite traité par un tableau croisé dynamique Excel (voir figure suivante) pour avoir le total des HT répartis par unités et par sites.

Figure 7 : Tableau dynamique croisé avec la donnée de la GTA

Concernant les sites étrangers, ils n'ont pas de GTA pour la comptabilisation des HT. Les responsables de Sécurité des différents sites reçoivent les données de collaborateurs qui synthétisent les informations nécessaires à la construction des indicateurs sécurité dans des tableaux Excel que je traite par la suite pour centraliser toutes les informations du groupe dans un même classeur Excel.

Il existe deux tableaux servant à répertorier toutes les heures travaillées, ainsi que les accidents avec et sans arrêts, et enfin les jours perdus. Le premier répertorie toutes ces informations par sites (voir les tableaux 2 et 3) et l'autre par unité de travail. Les deux possèdent exactement la même structure et leur total est identique et sont classés par mois de l'année fiscale en cours.

Ces deux tableaux permettent de construire les indicateurs sécurité et de calculer le TF et le TG par catégorie (site ou unité).

14

Tableau 2 : Tableau des statistiques sécurité des sites

Avec les informations citées au-dessus, on remplit les onglets réservés aux données des sites. Ensuite, ces données sont automatiquement transmises pour remplir les onglets correspondants au mois.

Tableau 3 : Onglet correspondant à un site

Le tableau concernant les unités fonctionne de la même manière.

Les données seront introduites dans un autre tableau qui est transféré ensuite aux personnes concernées. Ce tableau est une mise en forme différente des informations précédemment citées. Pour les premiers onglets, on retrouvera la même mise en forme que sur le tableau 2. Ensuite, un onglet de comparaison entre la réalité et le budget des indicateurs est présenté avec un comparatif visuel qui permet de faire ressortir les décalages pouvant être important entre la réalité et le budget. Ce tableau est partagé fréquemment par les responsables dans les réunions. Avec l'aspect visuel frappant qu'il donne (voir la figure suivante), il est très efficace lors des présentations des résultats sécurité.

15

Tableau 4 : Comparatif réalité et budget

Un tableau de synthèse très utile en matière de sécurité est sur un autre onglet appelé « Nombre de jours sans accident » (voir tableau 5). Il reprend les dates des derniers accidents AAA et ASA par sites et unités. Avec la mise en place d'un système de récompense basé sur l'atteinte de seuil par rapport à des nombres de jours sans accidents avec arrêt, ce tableau sert à distinguer les sites qui méritent des récompenses selon le nombre de tranches de 500 jours sans accidents accumulés. Les salariés et personnels encadrant sont d'autant plus impliqués dans la vigilance au travail pour éviter les accidents au maximum.

Tableau 5 : Nombre de jours sans accidents par site et par unité

16

Les onglets suivants répertorient toutes les informations précédemment citées (AAA et ASA, HT, TF et TG) par site et par mois. Ce qui permet d'avoir un cumul par an et de garder un comparatif par rapport aux autres années et mois. On trouve aussi des courbes et des histogrammes mettant en évidence les informations de l'année fiscale en cours.

Tableau 6 : Récapitulatif des informations sécurité par site et par unité

Figure 8 : Graphique des informations sécurité par site

I.3 Problématique et mission

Depuis des années, les données nécessaires à la construction des indicateurs de sécurité du Groupe Salins proviennent de différentes sources de données spéciales aux sites et aux pays avec des formats différents.

Comme énoncé précédemment, les données communiquées sont principalement les heures travaillées HT par le personnel, le nombre d'accident avec ou sans arrêt (AAA ou ASA), les jours perdus JP par accidents et les jours perdu sans rechute JPSR.

17

L'envoi est effectué par mail au responsable du pôle sécurité à la fin du mois, à des dates différentes. Les informations reçues sont centralisées et regroupées sur des classeurs Excel présentés précédemment afin de déterminer les indicateurs (taux de fréquence TF et taux de gravité TG des accidents) et de comparer les résultats avec ceux de l'année précédente. Cette méthode de remontée de données n'est pas fiable et fait sortir plusieurs contraintes.

D'abord, il est important de s'assurer de la solidité et complétude de ces données pour permettre au service de gestion de réaliser des études réelles de la situation de sécurité du groupe. Il faut donc assurer une vérification intelligente et adéquate des données collectées avant de les traiter.

Comme celles-ci sont remontées depuis différents pays, le contrôle à distance de la véracité et complétude des données ne peut se faire que grâce à une méthode informatique personnalisée et spécifique à chaque site.

Ensuite, le problème d'absence de liaison entre les données des ressources humaines et celles dans les systèmes de comptabilisation des heures travaillées est contraignant vu que les informations concernant les changements du personnel du groupe (les licenciements, départs, recrutements et changements de postes sur sites des salariés, notamment des intérimaires) ne sont pas remontées aux responsables des bases de données pour des mises à jour.

Le calcul des indicateurs est rapide à réaliser mais la saisie des données nécessaires reçues par mail de différents sites et unités engendre une perte du temps et d'énergie importante en plus du risque d'erreurs très fréquent lors de la saisie.

Un autre problème d'optimisation se présente lors de la mise en page des différents documents en adaptant les informations à l'année fiscale de chaque exercice, les changements des nominations des responsables des sites, des données à sélectionner par période pour permettre une meilleure visualisation de l'état de sécurité du groupe par le service de gestion, etc.

En cas d'absence, départ ou retard d'un des collaborateurs, l'envoie des données n'est pas réalisé à temps et engendre forcément un retard sur la génération des indicateurs et en conséquence déclenche une problématique lors des réunions « Business Review » (BR) organisées par les responsables chaque mois dans le cadre d'un suivi continu des différentes Directions et usines du groupe.

Au cas où des nouveaux sites viennent s'ajouter au groupe, le processus de rajout des informations exige la présence d'un chargé de sécurité par site pour remonter toutes les informations nécessaires et d'une répétition des mêmes tâches faites pour les autres sites, ce qui exige du temps.

Un système de remontée automatique de ces données devient une exigence pertinente pour alléger le processus actuel, diminuer la charge de travail, et fiabiliser les données transmises pouvant être importante pour les responsables de sécurité.

Pour éviter ces contraintes et améliorer la qualité de la donnée, il est nécessaire d'étudier l'existant en entreprise et identifier la méthode informatique adéquate pour automatiser la remontée des données depuis les différentes sources de données.

18

C'est le sujet de la problématique de ma mission principale au sein des Salins.

Le projet nommé Altair maintenu par la DSI est en cours de test. Il traite l'automatisation d'une partie des données nécessaires à la sécurité. Ce projet a pour objectif de numériser rapidement les déclarations, rapports d'activité et plus essentiellement les rapports des accidents. Ces derniers sont aujourd'hui remplis sur un document sous format Word. Grâce à Altair, une interface sur tablette (voir annexe 2) va permettre le remplissage des mêmes informations dans une base de données pour une meilleure exploitation et archivage de la donnée. Il a pour objectif la mise en production et l'installation sur tous les sites français du Groupe avant la fin de l'année en cours.

Travailler sur le projet Altair HSE fait partie de ma mission et va me permettre de mieux étudier la donnée collectée pour l'utiliser dans mon projet d'automatisation de construction de donnée Sécurité.

II. Automatisation de la remontée des indicateurs Sécurité

II.1. Analyse de l'existant

Avant de chercher les méthodes adéquates pour relier différentes bases de données à un outils de BI à des fins de reporting, il est important d'analyser l'existant afin de déterminer les modifications à faire avant l'application de la méthode. Pour assurer un résultat cohérent avec la réalité, il faut avoir une base sûre pour construire la solution à la problématique et répondre au mieux au besoin métier exprimé.

Suivant ces objectifs, on commencera par enquêter sur l'acheminement des données à exploiter, s'assurer de la véracité de la donnée à collecter et analyser le format actuel de cette donnée ainsi que tous les éléments rassemblés pour définir les points importants que doivent respecter nos solutions afin d'avoir une idée plus claire du besoin à couvrir et pouvoir mieux traiter le problème technique posé.

Enquête sur l'acheminement des données :

Dans l'objectif de relier les sources d'informations nécessaires au reporting sécurité à un outil de reporting, il est primordial d'enquêter sur l'acheminement des données depuis la source aux collaborateurs responsables de sécurité des sites qui les communiquent à la direction des opérations.

Pour cela, l'idée de mettre en place une requête à mes correspondants sécurité pour la transmission de la demande d'information sur la source des données à leurs correspondants en respectant l'acheminement de l'information de manière à ce qu'elle arrive au bout de la chaine pour chacun des sites.

19

Les échanges ont permis de construire ce schéma représentatif de l'acheminement des données :

Figure 9 : Acheminement des données sécurité (HT et ENS) des sites du Groupe Salins

Le rapport mensuel sécurité du groupe est envoyé au service de gestion tous les mois après la réception et le traitement des données reçues des différentes sources indiquées sur le schéma. Sur la base que chacun de mes correspondants m'envoient tous les mois le résultat sécurité de son site, le format de la donnée reçu par mail est soit un classeur Excel pour la majorité des sites ou bien une information écrite par mail comme c'est le cas pour les deux nouveaux sites français Sotrasel et Distrisel. Les HT de ces sites sont envoyées par leur responsable de la paie (voir la capture d'écran qui suit).

Figure 10 : Nombres d'heures travaillées sur Distrisel et Sotrasel, transmis par mail

Les chiffres transmis pour ces deux sites ne correspondent pas exactement aux HT du mois écoulé, mais aux HT utilisés en paie, c'est-à-dire avec un décalage de 15 jours de chaque mois, contrairement aux autres sites français, pour lesquels la GTA est mise en place pour comptabiliser les heures travaillées du 1^er au dernier jour de chaque mois grâce à une requête qui filtre la donnée suivant cette condition avant son extraction de la base. Il faut

20

remarquer que les données de la GTA précisent à chaque numéro de matricule d'un ouvrier, à quelle unité et site il appartient, devant le nombre d'heures de travail journalières, comme illustré sur le tableau suivant :

Tableau 7 : Aperçu du tableau extrait automatiquement tous les mois de la GTA

Concernant le Sénégal, le DGA du site SNSSS reçoit tous les mois le tableau statistiques sécurité du chef du personnel. Il est construit en procédant de la manière suivante :

· Pour reporter les heures travaillées par les cadres, ouvriers permanents et saisonniers SNSSS, le chef du personnel compile les fiches de pointages que lui remettent les chefs de service ainsi que les fiches de paie qu'il établit.

· Concernant les heures travaillées des employés journaliers employés par SNSSS, il récupère le journal de caisse mensuel (données comptabilité) sur lequel figure les heures travaillées par jour.

· Quant aux heures travaillées par les journaliers de la société externe GIS, cette dernière remet au chef du personnel un journal de caisse similaire à celui de SNSSS sur lequel figure les heures travaillées par jour.

Quant à l'Espagne, les HT et ENS sont remontés mensuellement par le responsable du service de sécurité des sites espagnols du groupe qui interroge les commerciaux, les salines et les collaborateurs des ressources humaines et construit le tableau Excel (voir annexe 3). Les heures travaillées par les intérimaires sont communiquées par les sociétés externes qui les envoient.

21

Figure 11 : Aperçu de la donnée reçue de l'Espagne

Concernant l'Italie, le responsable RH et IT à Milan est le seul à avoir accès à une base de données qui calcule les HT par les salariés des sites italiens à Porto Viro et Rozzano. Il rapporte les HT réparties par statut des ouvriers et ce sur un tableau Excel qu'il remet au manager QSA pour la communication mensuelle à la direction des opérations. Les ENS ne sont pas mentionnés sur le tableau (Voir annexe 5).

Quant aux cinq sites en Tunisie, le nombre d'HT et les ENS sont synthétisés sur un tableau renvoyé par le responsable comptabilité des sites. Les HT sont comptabilisées et inscrites sur une base de données exploitée au travers du système de paie par les DRH des sites. (Voir annexe 4)

De nouveaux sites vont bientôt rejoindre le grand Groupe Salins. Ces sites utilisent la GTA pour compter les HT. Il faut donc réfléchir à une solution commune permettant d'intégrer, dans quelques mois, les données des nouveaux sites du nord de l'Europe.

Réflexion et analyse des informations récoltées :

Comme décrit dans la partie I, un ensemble de tableaux Excel est construit tout au long de l'année fiscale avec les informations reçues par mail pour réaliser le reporting des indicateurs sécurité et plus précisément les taux de gravité et les taux de fréquences correspondants aux unités et aux sites.

En observant les classeurs en détails, il est facile de remarquer que l'ensemble des classeurs reprennent les mêmes informations, c'est-à-dire, les HT, le nombre de AAA, ASA, les JP et les taux construits en fonction de ces données. La méthode de remplissage des différents classeurs peut donc être simplifiée et raccourcie au moyen d'une centralisation des informations sur un même stock de donnée et la mise en place des requêtes constructives des taux que l'on souhaite communiquer tout en mémorisant les indicateurs pour le suivi de la sécurité du Groupe, notamment le tableau qui énonce toutes les informations décrivant les ENS avec les JP qui peuvent éventuellement s'étaler sur plusieurs mois.

22

Il est aussi nécessaire de souligner l'importance des statistiques de l'exercice précédent dans l'analyse des résultats du nouvel exercice. Il est souhaité d'avoir une base permettant l'archivage de l'historique des statistiques de l'année précédente pour la comparaison des exercices.

La solution adéquate doit inclure la possibilité au responsable du service sécurité du Groupe de renseigner tous les ans le budget à respecter sur chacun des sites. Ces données devront être vérifiées par le responsable de contrôle de gestion avant d'être prises en compte dans le reporting sécurité et communiquées aux différents intervenants des services Sécurité des sites. Il serait donc préférable que l'outil choisi puisse communiquer le budget validé et inscrit par le responsable grâce à une liste de diffusion de manière simplifiée et pratique. Les informations sur budget sont aussi nécessaires à la construction des schémas et courbes comparatifs sur lesquels reposent les analyses du service de gestion.

Ils sont donc à considérer dans la méthode à trouver et ce en tant que donnée nécessaire à la construction des rapports sécurité.

Après une étude poussée sur les données et leurs sources et après nombreux échanges avec les responsables des données concernées, la découverte de certaines contraintes techniques et éthiques à respecter fait que l'on ne peut pas permettre la liaison directe de certaines sources de données à un outil existant en exploitation par le Groupe en France. Parmi ces contraintes, je cite le respect de la RGPD dans la manipulation des données provenant de l'Italie. En effet, d'après le responsable IT bénéficiant de tous les droits sur la base de données utilisée par nos sites en Italie, il est impossible d'attribuer l'accès au serveur à d'autres utilisateurs puisque la maison du logiciel ne l'autorise pas en respect du RGPD. On est donc amené à utiliser, comme source directe de données provenant de l'Italie, les informations reçues sur un tableau Excel communiqué.

En plus, en vérifiant les informations reçues du Sénégal sur un classeur Excel, on constate que le rapport réalisé est nécessaire pour d'autres finalités et exigences. Certaines informations comme le nombre d'heures travaillées par les intérimaires ou par les employés de la société externe GIS sont des informations de sources externes aux Groupe qui sont donc confidentielles. Aucun droit ne nous est permis de rendre la source accessible par nos outils informatiques adoptés chez Salins. On ne peut donc créer la liaison directe avec ces sources inaccessibles, ce qui amène à conclure que seule l'implication du chef du personnel permet de récupérer les informations nécessaires à la construction des indicateurs sécurité du SNSSS.

23

Figure 12 : Aperçu du rapport sur HT à la SNSSS

Pour les mêmes raisons et pour éviter d'enfreindre des règles pouvant exister ou être mise en place dans les années qui suivent et pour pouvoir proposer une solution valide à long terme, la décision de considérer les tableaux Excel de synthèse d'activité mensuelle de chaque site doit être prise en compte dans la solution de la problématique énoncée. Une alternative à cette décision aurait été de mettre en place une interface WEB commune à tous les sites, permettant de saisir, modifier et supprimer si besoin les informations nécessaires à la place du reporting fait sur tableau Excel. C'est en effet une idée qui permettrait de centraliser les données des sites étrangers sur une même base de données pouvant être exploitée.

La mise en place de ce site Web peut être couteuse et nécessiterait un changement des habitudes maintenues par les différents intervenants. Elle n'améliorera ni la charge de temps subie par les collaborateurs pour la cause, ni le nombre des erreurs de saisies lors du remplissage des informations.

Cette hypothèse est donc intéressante pour la collecte des données mais elle est écartée pour raisons économiques et fonctionnelles. Il est donc à préciser qu'avec les contraintes apparentes, seule la liaison directe avec les sources de données en France peut être opérée. Pour le restant des sites étrangers, et avec la structure actuelle des outils IT développés dans ces pays pour le ressourcement des informations sécurité, il est naturel de se contenter des documents Excel transmis mensuellement et de se baser sur leurs contenus pour arriver à un objectif qui change légèrement de celui souhaité par le responsable sécurité du groupe,

24

c'est-à-dire, trouver une solution au problème pour faire gagner du temps au responsable, puisqu'aucun changement ou allègement ne peut être fait pour l'instant pour les autres intervenants.

Véracité de la donnée exploitée

Avant toute opération sur les sources de données, il faut s'assurer de la véracité de la donnée extraite du système de GTA tout comme celles transmises par les collaborateurs sécurité.

En particulier, on s'intéresse aux nombres d'heures travaillées par site, puisque pour le nombre d'accident et des éventuels jours d'arrêt, les rapports transmis sur les faits prouvent la véracité de ces informations.

Quant aux HT, elles sont comptabilisées par des systèmes de gestion des temps de travail et des activités. Une attention particulière doit être apportée pour savoir si tous les sites prennent en compte les HT par tous les employés, notamment les intérimaires. Pour cela, et suite aux signalements d'incohérence sur la donnée de la GTA avec la réalité qui ont été réalisés par les responsables des sites, il était indispensable de revoir en détails toutes les étapes par lesquelles passe la donnée avant d'être exploitée.

Après vérifications et suite à l'enquête menée sur l'acheminement de la donnée, tous les sites français et étrangers considèrent les HT par tous les employés dans leurs rapports mensuels mais certains ne prêtent pas très attention aux mutations que peuvent subir les intervenants des entreprises externes sur les sites.

Après une vérification en détail sur les données, il a aussi été remarqué que les mutations du personnel de Salins, notamment des responsables, sur les sites ou unités n'étaient pas pris en compte en temps réel. Si un employé travaille aujourd'hui chez l'unité A et demain chez l'unité B (ou que plusieurs responsabilités sur différents sites sont assignées à un cadre), ses heures travaillées sur les deux jours seront comptabilisées à l'unité A (respectivement sur le site de rattachement principal). Ceci résulte du fait qu'aucun suivi n'est assuré pour détecter ces changements sur la GTA.

Le souci des HT par les responsables de plusieurs sites peut être évité en joignant la donnée de la GTA aux dernières données mise à jour par les ressources humaines et ce tous les mois avant l'extraction de la donnée de la GTA. Cependant, le souci persiste pour les intérimaires employés sur terrain puisque les changements ne sont pas permanents et ne sont donc pas dans le besoin d'être notés par la RH.

Avec les responsables des sites, nous cherchons encore une solution à ce problème. Il est à considérer après l'application de la nouvelle méthode qui sera préconisée pour le reporting sécurité.

Pour détecter les incohérences sur les données, une idée sur l'effectif de chacun des sites a servi pour estimer les intervalles d'HT totales par sites pouvant être acceptés, sachant qu'un employé travaille entre 140 et 150 heures par mois. Des corrections ont été apportées et l'importance de la différence entre les résultats de cette année, comparés à ceux de l'exercice précédent, peut être constatée sur les deux tableaux suivants :

25

Tableau 8 : Comparatif des données HT sur sites, corrigées avec celle de l'année précédente éventuellement fausses

Tableau 9 : Comparatif des données HT sur unités, corrigées avec celle de l'année précédente éventuellement fausses

En appliquant cette démarche, on a pu repérer les sites qui enregistrent plus d'HT que les chiffres réalisés. Il a ensuite été utile de récupérer la liste du personnel des sites concernés pour distinguer les surplus et les données manquantes suite au filtre mis en place sur la GTA lors de l'extraction des données du système.

Une fois la liste fixée et les vérifications faites sur les données extraites sur plusieurs mois écoulés de l'année fiscale, on a pu corriger les anomalies sur le filtre en place grâce à l'intervention du responsable de l'outil GTA.

Cette deuxième étape de la démarche a permis de corriger les incohérences sur certains sites concernés mais n'as pas permis de résoudre le problème d'imputation des HT par unités. Une autre anomalie a été repérée en examinant la donnée, où on a remarqué la présence de doublon, comme par exemple, sur les données du tableau 10, le cas de l'ouvrier de matricule 9000290 qui doit travailler presque 8 h par jour, détient deux lignes d'HT sur son compte le 3 mars 2021 avec un centre de cout différent (RCLT-AGM puis FCTC-QUALI), ce qui fait un total

26

de 15,4 h travaillées par jour pour cet ouvrier. On déduit donc qu'une erreur de programmation a eu lieu au niveau de la GTA.

En discutant avec le responsable de l'outil, on a pu déterminer qu'un traitement de la donnée mis en place pour les employés rattachés au siège qui ne badgent pas, a été appliqué par erreur à tous les employés sur la GTA, ce qui a engendré des doublons sur la donnée des employés qui badge. Pour le cas d'exemple prix, l'employé a travaillé 4,5 h le 1^er mars et 7,7 h le 3 du mois, et la donnée sur laquelle l'unité et l'activité manquent (lignes 2,3 et 5) a été rajoutée par erreur par le logiciel.

Tableau 10 : Exemple de doublon de données détecté sur la table des heures GTA

Pour corriger cela, le responsable de l'outil a limité le traitement décrit plus haut à la donnée concernant uniquement les employés basés au siège à Clichy ainsi que les cadres rattachés au siège. Cette donnée est repérable sur la base de données de la GTA par les valeurs « LV » ou « Cadre » dans les champs « Site » et « Libelle » respectivement. Le problème de doublon a été éliminé et les données de la GTA peuvent désormais être considéré vraie et cohérente avec la réalité, à un souci d'imputation près.

II.2. Descriptif des solutions

Enoncés des solutions et définitions des outils nécessaires :

SAP BW :

La majorité du reporting à Salins est fait de manière automatique, notamment sur les ventes et achats, la logistique ou encore les livraisons des fournitures. Ce reporting est fait grâce à un outil de modélisation SAP BW (en mode Delta) et ce à travers l'intégration de l'outil BW à SAP. Cette méthode de reporting permet de centraliser les données nécessaires dans un même système SAP.

La modélisation de ces données sur BW est suivie de plusieurs traitements faits sur des cubes d'information grâce à des requêtes Bex Analyzer pour construire les reporting selon les formats et formules souhaitées. Le mode Delta de BW alimente automatiquement l'entrepôt de données dès qu'un changement est détecté sur les sources de données.

27

SAP BW (Business Warehouse) un outil BI de SAP qui permet de faire du reporting et de l'analyse basée sur des données stockées provenant de plusieurs sources SAP ou hors SAP. Il permet d'intégrer la donnée, la nettoyer, la transformer, la stocker dans des InfoProviders et la restituer selon le besoin métier. SAP BW est en mesure d'uniformiser les données en provenance de plusieurs systèmes hétérogènes grâce aux étapes de transformation de données.

Trois phases ordonnées construisent le process de traitement avec SAP BW. Il faut d'abord apprivoiser les données des différentes sources de données, stocker la donnée dans l'entrepôt après préparation puis l'utilisation d'outils de reporting pour accéder à la donnée stockée.

Il existe plusieurs types d'InfoProviders dans SAP BW, dont les InfoObjets et les InfoCubes. Les InfoObjets sont les plus petites entités de stockage dans BW et elles sont de plusieurs types :

· Les caractéristiques ou les axes d'analyse

· Les ratios c'est à dire les indicateurs, ...

Les InfoCubes contiennent les données altérables à un niveau agrégé et contiennent des caractéristiques représentant les différents axes d'analyse et les différents ratios.

Une fois que les InfoProfiders à utiliser sont choisis, le flux de données peut être créé afin de charger l'entrepôt de donnée.

D'abord, les informations sont extraites des sources de données grâce à l'objet

« DataSource » et les données à leur état brut sont inscrites sur une table PSA Persistent Storage Area.

Suite à cela, une transformation des données est nécessaire pour uniformiser les données en provenance de plusieurs sources de données.

Ensuite, les données transformées sont chargées depuis la PSA dans des InfoProviders de types choisis pour un ultérieur reporting. Enfin, les InfoProviders sont traités par des requêtes Bex pour la création du reporting souhaité qui pourrait être distribué par mail aux intéressés.

Jusqu'à aujourd'hui, SAP BW est utilisé par deux parties chez Salins : la partie ECC qui englobe tous les modules vente, achat, logistique, les transports, les livraisons et la gestion des entrepôts ainsi que la partie CRM contenant les modules de gestion de la relation client. Ces modules de SAP, clairement représentés sur l'annexe 1, servent à remonter la donnée à BW à des fins de reporting.

Bex Analyzer est un outil de création de rapports inclus dans SAP BW. Il peut être utilisé pour analyser, grâce à des requêtes Bex, les données dans l'InfoProvider.

Il est recommandé de baser la requête sur un seul InfoCube dans la base de données puisqu'une requête basée sur plusieurs sources peut aboutir durant l'extraction des données à des erreurs SAP BW.

28

Cette méthode de reporting automatique présente une éventuelle solution à notre problématique. En effet, elle est recommandée quand il s'agit de reporting basés sur des données sur SAP. Dans notre cas, les données de la GTA sont reliées au système SAP. On peut donc considérer la possibilité d'utiliser BW pour solutionner la problématique.

1) Importation de la donnée :

L'exploitation des sources de données hors SAP, concrètement dans notre cas, les données qui arrivent sous format Excel et qui concernent l'exercice mensuel des autres sites hors France, est possible en respectant certaines exigences.

Il est primordial que les fichiers à consulter soient publiés sur un serveur ou un SharePoint afin que BW puissent détecter, grâce à des requêteurs à mettre en place, si un fichier est publié à l'adresse indiquée pour aller chercher l'information de manière automatique. L'outil BW, au-delà des données SAP, peut aussi se connecter à d'autres systèmes ou récupérer des données à partir de fichier plat CSV. Une autre exigence doit donc être respectée : il faudrait que tous les collaborateurs publient les mêmes tableaux habituels mais sous formats CSV.

Il est important de préciser que la donnée sur les documents CSV sera recherchée selon certains critères, que l'emplacement de la donnée dans le tableau est libre tant que les requêtes peuvent reconnaitre l'information recherchée. En plus, si nécessaire, une modification des données peut être appliquée si le format de celle-ci ne correspond pas au format souhaité, ce qui peut arriver par erreur lors du remplissage des tableaux par les collaborateurs.

Quant aux données sur les accidents qui seront stockées sur la base Maria DB grâce à l'interface d'Altair, bien que l'outil de GMAO est relié à SAP,une liaison entre BW et la base Maria DB est à envisager pour permettre à BW d'aller chercher les données aux champs qu'on précisera sur les requêtes.

Concernant la connexion à la GTA, il faut mettre en place un lien entre BW et la GTA. Une fois les données importées sur BW, il va falloir appliquer un traitement pour la synthétiser pour un résultat proche de celui qu'on obtient avec la méthode actuelle suite à l'application du tableau croisé dynamique. Il serait préférable de faire ce traitement sur la donnée provenant de la GTA avant de la mettre en cube puisque les données de la GTA sont de masse importante (presque 15860 lignes de données stockées par mois). Il n'est pas pratique de prendre la donnée entière telle qu'elle est sur la GTA.

Comme BW peut, à partir de données, modifier, agrémenter de nouvelles données et faire des calculs, on peut donc simplifier le processus en allégeant la masse de donnée à mettre en cube pour traitement avec Bex Analyzer.

Quant au budget de l'exercice que doit fixer chaque année Mr PLANCQUEEL le responsable sécurité du groupe, il serait possible de lui fournir un rapport Excel construit automatiquement par BW avec les résultats de l'année précédente avec des champs libres pour qu'il puisse y remplir le nouveau budget de l'année qui suit. Une fois rempli, il suffira de le déposer sur un emplacement précis sur le serveur pour que BW le considère sur les rapports du nouvel exercice.

Une fois que l'accès sera donné depuis BW à la base de Altair, que les tableaux de reporting par sites sont sous format CSV sur le serveur de Salins, que le droit d'accès en lecture aux données de la GTA est accordé par le responsable de l'outil de gestion à BW, toutes les informations sont réunies pour construire les indicateurs sécurité.

2) 29

Requêtage :

Pour que le reporting soit fait de manière automatique, des requêtes sont à préparer et mettre en place pour aller chercher l'information dès qu'une modification est détectée dans les data sources (la base d'Altair, l'adresse d'emplacement des fichiers CSV sur le serveur des Salins, la base de données de la GTA) et apparaît dans les InfoProvider fourni à la requête Bex pour traitement. Les requêtes naviguent dans les InfoQubes reçus grâce à des attributs de navigation qui sont par défaut une clé et une description. La description permet de mieux comprendre les objets fournis pour traitement.

Une fois que les requêtes sont prêtes à aller chercher les informations au début de chaque mois, les informations de différentes sources sont rassemblées et compilées sur BW et prêtes à alimenter des rapports. Des cubes de données sont produits à la suite de leurs agrégations avec des vues par axe d'analyse et prêts à être traité par l'outil de requêtage, le BEx Analyzer, qui appliquera, grâce à des requêtes personnalisées, les formules de calculs des TF et TG en se basant sur la donnée reçue dans les cubes. Les axes d'analyse sont cependant à fixer selon le besoin métier.

3) Diffusion automatique des résultats :

Les résultats construits peuvent par la suite envoyés par mail au responsable Sécurité et/ou au service de gestion et exploité par les intéressés.

En suivant cette méthode, on répond au besoin exprimé par le responsable Sécurité du groupe en permettant une construction automatique des indicateurs sans besoin d'intervention humaine. Cependant, il est nécessaire d'assurer une surveillance sur l'application des requêtes sur la donnée pour pouvoir intervenir en cas d'erreur sur le système.

Microsoft Power BI Desktop :

Un autre outil de restitution très utilisé chez Salins est l'outil Microsoft Power BI Desktop. Il admet plus de connecteurs à des sources de données, permet de les transformer, de faire des calculs, et de garantir une meilleure visualisation de ces données grâce aux trois modules qu'il intègre : Power Query, Power Pivot et Power View.

« Power BI Desktop est une application qui permet la connexion à différentes sources de données, ainsi que la transformation de la donnée et sa modélisation afin de créer des visuels attrayants. Elle centralise, simplifie et rationalise le processus de conception et de création de rapports et de référentiels décisionnels. C'est l'outil le plus préconisé par les entreprises pour assurer une compréhension accrue des données avant de prendre des décisions. »

(Source : https://urlz.fr/gkTC)

30

Voici un dessin du process à suivre pour réaliser le rapport :

Figure 13 : Le reporting avec Power BI Desktop

(Source : https://urlz.fr/gl1i)

De la définition, on comprend que l'outil peut répondre aux besoins soulignés précédemment. Il est primordial de commencer par étudier la possibilité des différents types de connexions avec les sources de données.

1) Migration des données nécessaires sur Power BI :

· Import de la donnée depuis les sources Excel :

Tout d'abord, on sait que la connexion et l'import des données de fichiers de types Excel

est possible. Il suffit de sélectionner les fichiers et les tables dont on a besoin.

Avant de procéder à l'importation, il faut réfléchir aux étapes qui vont suivre, c'est-à-dire, à l'étape de transformation des tables pour minimiser le nombre de modifications à apporter puis à l'étape de modélisation, qui est la plus importante pour réussir le rapport.

Pour cela, il est indispensable de changer la manière dont est communiquée la donnée par les collaborateurs. L'idée consiste à fournir un fichier Excel (voir figure suivante) à chacun des collaborateurs des sites et ce sur le SharePoint, en attribuant le droit d'écriture uniquement aux collaborateurs responsables de chaque site, en plus du responsable sécurité du groupe, qui peut en avoir besoin en cas de présence d'anomalie sur les fichiers.

Figure 14 : Exemple de fichier préparé pour les sites italiens

31

A préciser que la même table sera fournie à chaque responsable et que le nom de l'onglet doit rester le même sur tous les fichiers pour pouvoir les rassembler sur une même table sur Power BI. L'ensemble des fichiers est présent dans un même dossier qui se trouvera sur le SharePoint.

Avec cette nouvelle procédure, chaque responsable devrait remplir les heures travaillées au total par le site dont il est responsable, en précisant l'unité concernée sur chaque ligne qu'il rajoute.

En considérant cette méthode ainsi que le fichier type montré sur la figure précédente, on peut par la suite, grâce à une requête sur Power Query (voir la figure suivante), rassembler les fichiers sources des sites sur une même table grâce à la fonction GetHData :

Figure 15 : Définissions de la fonction GetHTData à appliquer sur le dossier source

Voici les étapes qui suivront pour l'application de la fonction GetHTData:

Figure 16 : Appel de la fonction sur les liens sources

32

Lors de l'appel de la fonction, il faut indiquer le lien vers le fichier mais aussi le nom de l'onglet « HT » qu'on a choisi sur les fichiers sources. Ensuite, il faut importer les données :

Figure 17 : Importation de la donnés suite à l'appel de la fonction

Le résultat de la transformation est présenté sur la figure suivante. On peut voir les données de plusieurs sites étrangers qui ont initialement été remplies sur différents tableaux Excel.

Figure 18 : Résultat du rassemblement des données des sites étrangers

Puisque pour certains sites, les versions actuelles de rapport sur Excel servent aussi à d'autres fins, on peut leur fournir la version des rapports mensuels qu'ils ont l'habitude d'envoyer et remplir automatiquement les informations qui nous intéressent dans un autre tableau qu'on récupérera sur Power BI. Ce choix rentre dans ceux à faire avec les collaborateurs lors de la présentation de la solution avant la réalisation du projet. On essaiera tout de même de préconiser la manière qui ne demande pas plus de travail à ces derniers.

33

Enfin, puisqu'on a uniquement besoin des statistiques de l'année fiscale précédente pour réaliser le prochain rapport de l'année en cours, il est suffisant de mettre ces résultats dans les fichiers à fournir.

Quant aux résultats des années précédentes, l'archive actuelle sera gardée sur le serveur de l'entreprise en cas de besoin futur de données d'entrainement pour faire de la prédiction.

Concernant les informations sur le budget, on va fournir un document Excel (voir la figure suivante) au responsable Sécurité du Groupe sur lequel il pourra remplir le nouveau budget en observant le dernier rapport produit sur l'application Power BI. Ce document sera accessible en lecture par le responsable de contrôle de gestion. Les informations remplies seront ensuite disponibles sur l'application et à jour sur les visuels existants sur le rapport une fois que les données seront rafraichies.

Figure 19 : Exemple d'emplacement possible du budget de l'année en cours

En plus de ces tables, on va avoir besoin d'importer 3 tables : une table qui précise la répartition des unités par site et le nom de leurs responsables, une table qui précise la répartition des centres de cout par unités et une table qui rassemble les informations des sites nécessaires à impliquer dans les rapports.

· Import des données depuis la base de données existante sur le serveur SQL `GTA' : Pour assurer cette connexion, il faut se munir des informations d'authentification au server SQL `GTA'. Ensuite, sur l'application, en cliquant sur le bouton « SQL Server > apparent sur la barre du menu d'accueil, il faut inscrire ces informations sur le formulaire de connexion. Avant de valider, un choix se présente :

Soit on décide d'importer la donnée depuis la source, soit on choisit, grâce à Direct Query, d'agir directement sur la base. Dans ce cas, ayant conscience de la fragilité et de l'importance de la donnée RH qui nous intéresse, on va préconiser le choix d'importer la donnée sur l'application. Ce mode va permettre par la suite d'apporter des transformations sur les données importées sans entrainer de modification sur la donnée d'origine sur la base.

Enfin, il est important de cocher « Activer la prise en charge du basculement SQL Server > pour permettre à Power Query de passer au prochain noeud disponible quand il rencontre un noeud indisponible lors du basculement de la base.

Ensuite, nous serons amenés à nous connecter à la base en entrant un mot de passe. Une fois l'accès réussi, nous pouvons enfin sélectionner les tables de la base à importer

34

pour construire le fichier qui habituellement est envoyé de manière automatique par mail et qui comprend les H1 des employés du groupe sous le format présenté dans le tableau 7.

· Connexion à la base de données MariaDB d'Altair :

Pour accéder aux données de la base de type MariaDB, il est nécessaire d'installer un connecteur MariaDB ODBC adapté à l'application Power BI. Pour cela, il est recommandé d'installer tous les paquets MSI de MariaDB sur la machine du responsable Sécurité du Groupe pour que les paramétrages nécessaires à la connexion soient réalisés automatiquement.

Par la suite, il suffirait de relancer l'application Power BI Desktop et rentrer les informations d'authentification à la base Altair-MSI, existante sur le serveur grenat.salins.net en précisant le numéro du port et les informations de l'utilisateur. Une fois connecté, la sélection des tables qui stockent les informations reliées aux événements de sécurités est permise.

2) 1ransformations simples des données importées :

Quand on importe de la donnée d'une base de données (SQL ou MySQL), les tables reçues sont généralement bien arrangées et déjà prêtes à l'exploitation. Cependant, Power BI propose la possibilité de la transformer si besoin grâce à l'outil intégré Power Query. Les transformations restent utiles en cas de besoin pour ce genre de source de données, par exemple pour remplacer des données manquantes sur la base ou supprimer les doublons. Puisque ces bases sont aussi utilisées à d'autres fins, il est recommandé de signaler l'existence de doublons ou de donnée aberrante ou importante mais manquante et ce directement à l'administrateur de la base pour des modifications directes sur celle-ci.

Quant aux tables importées depuis des fichiers Excel, on a fréquemment besoin

d'apporter des modifications dessus avant l'exploitation. Voici les modifications à faire après avoir vérifié et importé les nouveaux fichiers décrits précédemment :

· Supprimer les colonnes vides.

· Vérifier le type de donnée assigné automatiquement aux champs et corriger si nécessaire.

· Utiliser la première ligne pour remplir les noms des champs correspondants aux tables.

· En cas de présence d'erreur sur les tables provenant des fichiers, remplacer ces erreurs par les bonnes valeurs. Cette modification peut être faite directement sur le fichier source dans le cas où l'erreur proviendrait d'une information référenciée non reconnue. Une correction de l'adresse de référence serait à appliquer.

· La création de colonnes sur la table des accidents pour y calculer, grâce à des formules DAX, le nombre de jours perdus dans les cas d'accidents avec arrêt et possiblement les indicateurs sécurité qui nous intéressent : 1F et 1G.

Ces modifications suffisent pour la préparation des tables, puisqu'on les a optimisées lors de la mise en place du format des fichiers sources.

3) 35

Modélisation :

Une fois toutes les tables de données préparées, on peut maintenant réfléchir aux liaisons à faire entre elles pour permettre de créer les visuels sur le rapport.

Un des trois modules intégrés dans Power BI Desktop, il y a Power Pivot qui permet de conceptualiser les données et de créer le model de données.

Pour accélérer l'étude de cette solution, nous avons décidé de la simplifier en s'appuyant sur les fichiers sources décrits plus haut ainsi que sur des fichiers des données ressemblant à celles sur la GTA et la base d'Altair. On a donc créé deux fichiers Excel en plus pour réaliser un modèle de test.

Après réflexion, et en se basant sur des données de test importées, voici le modèle de données qu'on a jugé adéquat au besoin :

Figure 20 : Exemple de modèle permettant le reporting Sécurité

Lors de la mise en place de la solution, les tables Accidents et HT GTA seront substituées par plusieurs tables existantes sur les bases sources. Le modèle ci-dessus sera élargi pour permettre la construction des informations sur les accidents et les HT en France depuis ces tables.

4) Création du rapport Sécurité :

Basé sur le modèle qu'on a créé et grâce à Power View, nous pouvons maintenant

construire et proposer un exemple de rapport pour donner une idée du résultat qu'on peut observer en appliquant cette méthode.

Pour pouvoir comparer les résultats de cette année à ceux de l'année précédentes et pour calculer les moyennes glissantes sur les mois écoulés de l'année, nous allons utiliser les mesures sur les visuels. C'est l'outil à utiliser quand on a besoin de faire des calculs basés sur des données de plusieurs tables disposées sur plusieurs lignes. Nous allons

aussi nous en servir pour calculer le nombre d'ENS par type (AAA et ASA) ainsi que pour le calcul des taux TF et TG.

Concernant les visuels que nous voulons créer, nous allons essayer de reproduire dans un premier temps ceux du rapport mensuel, c'est-à-dire, les tables de résultats du groupe, du CSME, des sites et des unités qui nous intéressent ainsi que les graphiques et courbes que les collaborateurs de gestion ont l'habitude d'analyser. Nous pouvons filtrer ces données sur le mois qui nous intéresse en un simple clic sur le visuel de filtre. Voici un exemple de filtre utilisé pour afficher les données des unités correspondants au site de Aigues-Mortes :

Figure 21 : Filtration des données d'une page

Cette fonctionnalité nous permet de créer un rapport pour tout le groupe sur une première page et de le copier dans une autre page réservée à un site puis de rajouter un filtre sur la page en cochant cette fois-ci le site qu'on veut présenter sur la page. On peut aussi filtrer sur plusieurs données en sélectionnant le visuel sur lequel on veut filtrer la donnée et en cherchant sur le volet « Filtres » les champs souhaités. Il est aussi possible d'appliquer un filtre sur tous les visuels du rapport.

Il serait aussi intéressant de profiter du large choix de visuels que fournit Power Bi pour construire un rapport plus attractif, qui fait mieux parler la donnée et facilite son analyse. Dans cet exemple, et suivant l'ancien modèle, nous avons essayé d'exploiter différents types de visuels pour afficher de différente manière des informations qu'on a l'habitude de communiquer sur le rapport. Les visuels présentés sont interactifs. Voici en exemple l'onglet Groupe avec les résultats de novembre 2021 :

Figure 22 : Exemple de rapport Sécurité du Groupe

36

5) 37

Points sécurité et stockage de données :

Pour assurer la sécurité des données importées depuis les sources de données SQL Server, le fichier sur SharePoint et la base interne du projet Altair, nous sommes obligés d'utiliser une passerelle de données d'entreprise.

Nous définirons d'abord ces sources dans la passerelle, ceci va nous fournir les informations de connexion. Il faut auparavant vérifier si le responsable de la sécurité du groupe dispose déjà d'une passerelle sinon la créer. La création de cette passerelle se fait sur l'application Power Automate.

Le problème de stockage des données ne se pose pas puisque la taille de données générées à la phase de transformation n'est pas importante.

Sur Power Bi Premium, la capacité maximale que peut héberger l'application est de 13 Go, ce qui doit être suffisant pour la réalisation des rapports de sécurité

6) Diffusion automatique des rapports :

L'actualisation des données importée et utilisée sur Power BI se fait par un simple clic sur un bouton « Actualiser » visible sur la barre de menu d'accueil de l'application. Le responsable Sécurité doit effectuer cette rapide intervention avant de vérifier sur le rapport que tout se passe comme prévu et que les visuels sur le rapport représentent bien ce qu'il a besoin de diffuser aux équipes collaboratrices.

Pour partager le rapport, une liste de diffusion est à définir sur l'interface de service en ligne de Power BI, accessible sur ce lien : powerbi.com. Le responsable doit d'abord se connecter à son compte Microsoft et aller dans « Espaces de travail » pour créer un espace et y rajouter toutes les personnes à qui il souhaite communiquer le rapport sous le format souhaité, soit Excel ou PDF ou en direct accès aux Dashboard sur Power BI.

Passer par la passerelle d'entreprise va aussi nous permettre d'automatiser l'actualisation des données utilisées sur nos sources de données, dès qu'une nouvelle donnée est rajoutée ou modifiée ou sur une fréquence bien définie.

Elle va aussi nous permettre, si besoin, de diffuser de manière automatique les rapports.

La diffusion des rapports hebdomadaires ou d'un récapitulatif des résultats Sécurité en temps réels peut être partagé sur la page dédiée à la sécurité dans l'intranet du groupe de manière automatique, puisque l'intranet présente des sources partagées sur le SharePoint. On pourrait donc soit partager un rapport en PDF à lire en ligne, soit connecter directement l'intranet à Power BI pour afficher les résultats à jour.

38

Figure 23 : Aperçu de l'onglet Statistique, Page Sécurité du groupe, Intranet Salins

Comparaison des avantages et des inconvénients des deux méthodes proposées

Pour pouvoir comparer les deux méthodes, on construit un tableau comparatif des points forts et faibles de chacune d'elles :

Solutions				Points forts				Points faibles
1ère méthode :		·		La méthode est recommandée			·	Compliqué à utiliser
SAP BW				quand il s'agit de croiser des données de BW avec des données de SAP.			·	Le process de reporting avec BW est long à mettre en place (Importations, création de flux, production
		·		L'outil dispose d'une large palette de choix concernant les systèmes				d'InfoProviders, préparation de requêtes Bex...)
				sources.			·	SAP BW n'est pas très recommandé
		·		La connexion entre SAP et le server qui héberge la base de données d'Altair est déjà accomplie.				quand la donnée à traiter ne s'agit pas de donnée dans SAP, même quand la liaison de ce dernier avec le serveur
		·		L'importation des données depuis				hors SAP souhaité existe déjà.
				des fichiers plats CSV est possible et simple à réaliser.			·	La donnée n'est pas mise à jour en temps réel. Les modifications et
		·		Beaucoup sollicité pour la construction des reporting de				importations sur la base se font tous les jours à minuit.
				différents services du groupe, il est bien connu par la DSI et un responsable est déjà assigné à			·	Interface non intuitive et nécessite une longue formation à un nouvel utilisateur pour pouvoir exploiter l'outil.
				l'outil pour intervenir en cas de problème ou erreur dans le process.			·	Nécessite un monitoring tous les jours pour s'assurer que les chargements se sont bien passés et que le process se
		·		La détection des changements se				déroule comme convenu.
				fait de manière automatique.			·	La détection de la source d'une éventuelle erreur dans les calculs ou le requêtage mis en place est une tâche compliquée qui peut nécessiter beaucoup de temps et retarder la diffusion des rapports. Ce problème de
2ème méthode : Power BI Desktop
· Permet de renforcer la protection des données si besoin. · S'ouvre à multiples sources de données · Facile à manipuler et à la portée de tous. · Permet d'observer les graphiques du modèle de manière dynamique avec des données mises à jour en temps réel. · Permet d'analyser l'évolution en temps réel des indicateurs grâce à la possibilité de partage des visuels sur Microsoft, notamment sur le SharePoint avec le service de contrôle de gestion, ainsi qu'en réunion sur Microsoft Teams, ce qui peut être utile lors des réunions. · Outil multiplateforme : accessible sur PC, tablette et mobile. · Fonctionnalités dynamiques fournies par l'outil. · L'outil ne nécessite pas une formation pour gérer les rapports. · Moderne et simplifié : un simple clic suffit pour actualiser la donnée. · Propose un large choix de modèles de graphiques attractifs et interactifs, qui mettent en valeur la donnée exploitée. · Peut servir pour faire de la prévision avec du Machine Learning si le besoin s'exprime dans le futur.					temps risque de peser sur le responsable de l'outil en vue de ces nombreux engagements. · Bex Analyzer est le seul outil de restitution compatible avec BW de SAP. Il propose un choix limité des visuels qu'on peut produire sur les rapports. · La liaison de BW au SAP Analytics Cloud pour permettre une meilleure visualisation de la donnée reste désormais impossible. · Avec BW, il faut utiliser Microsoft Excel ou Microsoft PPT pour faire de beaux schémas à présenter à la direction, pour des rapports dignes de ce nom.
· R.A.S

40

Solution préconisée pour la problématique :

Basé sur le tableau listant les points forts et faibles de chacune des deux solutions, et prenant en considération des critères et hypothèses citées dans l'énoncé des deux méthodes, il est maintenant possible de préconiser la deuxième méthode basée sur l'utilisation de Microsoft Power BI Desktop pour solutionner la problématique.

D'abord, l'outil est mondialement considéré et reconnu comme l'outil du futur de la gestion des divers services d'entreprise et plus précisément dans l'aide à la prise de décision. En effet, les modèles de données qu'il permet de construire sont adaptés aux nouvelles méthodes développées dans le monde de l'IT pour la réalisation de différents objectifs et répondre à plusieurs besoins métiers. C'est ce qui fait de lui un outil très développé et qui permet d'appliquer des techniques modernes de machine Learning et d'exploiter les méthodes d'intelligence artificiel pour mieux analyser les données.

Cette fonctionnalité peut aider les membres du CODIR dans leur prise de décision. En ce qui concerne les données provenant de la GTA, et suite à ma participation au projet Altair et au changement de ma mission opéré récemment, j'ai pu analyser le besoin pour la réalisation du projet, et découvrir une liaison entre la GTA et l'outil Power BI Desktop afin de construire et visualiser des indicateurs utiles à l'activité des ressources humaines du Groupe. Il est donc intéressant de choisir un même outil pour visualiser les indicateurs des services liés de Sécurité et de RH.

Power Bi Desktop se distingue aussi dans l'assurance de protection de donnée. Sa version Premium propose un renforcement de la protection des données via la configuration BYOK Bring Your Own Key, pour une exploitation fiable des données.

La possibilité de fournir une clé spéciale aux utilisateurs permet d'appliquer des méthodes d'accès aux serveurs conformément à la RGPD, ce qui permet aussi de rassurer les administrateurs du serveur qui héberge la donnée sécurité des sites afin d'accorder les autorisations requises pour l'accès direct au serveur.

Grâce à ses interfaces intuitives et faciles à manipuler qui rendent l'outil à la portée de tous, on peut élargir la liste d'utilisateurs en donnant accès au modèle de données sécurité à tous les collaborateurs sécurité ainsi qu'au personnel du service de contrôle de gestion pour améliorer la communication inter-sites et encourager l'exploitation des données récoltées. A titre d'exemple, on peut afficher certains chiffres parlants sur des panneaux d'affichage connectés installés dans les espaces de repos dans les usines pour montrer aux ouvriers qu'on tient à leur sécurité et encourager la compétition sur les défis mis en place par les responsables de sécurité en rappelant les résultats en temps réel comparés avec les autres sites.

Pour améliorer les plans de préventions et aider à baisser l'occurrence des accidents sur les sites du groupe, les responsables des sites pourront utiliser l'outil pour construire de nouveaux indicateurs et de nouveaux graphiques basés sur la donnée importée et sa modélisation afin de mieux faire parler la donnée et mettre l'accent sur certains points importants jamais abordés auparavant.

A noter aussi que l'outil permet une interaction entre les gestionnaires sous les graphiques des rapports par la possibilité d'ajouter des commentaires ou notifier un collègue. Pour conclure, cette méthode pourra donc favoriser une culture basée sur les données au sein de l'entreprise ce qui peut être très important dans l'accélération du process de modernisation des services du groupe.

41

Sachant que la date prévue par le groupe pour la mise en place d'une solution informatique au reporting des indicateurs de sécurité est le T3 de l'année 2022, l'étude réalisée jusqu'à présent permet largement de respecter ce délai en comptant sur le professionnalisme, les compétences et le sérieux des équipes même si le choix de la méthode n'a été réalisé que récemment suite à plusieurs échanges et des longs entretiens avec plusieurs intervenants. Un plan de mise en place de cette méthode sera élaboré et présenté aux décideurs dans les prochains jours.