Tableaux de bord et analyses de localisation : des KPI opérationnels issus des données de position, dans l'outil BI que vous utilisez déjàDes données de localisation, mais aucun KPI qui déclenche une action ?
Les systèmes de localisation produisent un flux continu d'événements de position. La valeur réside dans un petit nombre de KPI opérationnels que les équipes consultent et sur lesquels elles agissent. Nous définissons ces KPI avec vous, normalisons les données d'événements de votre plateforme RTLS, RFID ou IoT et les livrons dans l'outil BI que votre entreprise utilise déjà. Conseil indépendant. Aucune vente de matériel, aucune commission des fournisseurs.
Ce qu'un tableau de bord de localisation doit montrer
Les quelques indicateurs qui changent une décision dans l'atelier, dans le service de soins ou dans la cour, et non un point qui bouge sur une carte. Lesquels comptent dépend de l'activité, mais la plupart des programmes puisent dans les six mêmes familles :
| KPI | La question à laquelle il répond | Calculé à partir de |
|---|---|---|
| Taux d'utilisation | Quelle part du temps les actifs, véhicules, salles ou emplacements sont-ils réellement utilisés, et où se cache la capacité inemployée ? | Présence en zone et états de mouvement ou d'utilisation, rapportés aux postes de travail et aux calendriers |
| Temps de séjour | Combien de temps les articles, commandes, patients ou remorques attendent-ils dans chaque zone ou étape du processus, et où l'attente s'accumule-t-elle ? | Événements d'entrée et de sortie de zone, rapprochés des enregistrements de commandes, de tâches ou de visites |
| Flux et goulots d'étranglement | Quels parcours, transitions et passations ralentissent le processus, et à quels moments ? | Transitions de zone à zone, comptage des trajets et longueur des files d'attente dans le temps |
| Temps de recherche | Combien de temps le personnel passe-t-il à chercher des outils, chariots, équipements ou stocks que le système pourrait localiser ? | Dernière position connue et demandes de localisation, comparées à une situation de référence mesurée avant la mise en service |
| Événements de sécurité et de géorepérage | Où et quand des personnes et des véhicules entrent-ils dans des zones réglementées, et que s'est-il passé ensuite ? | Franchissements de géorepérage, événements de proximité et acquittements d'alarmes |
| Chaîne du froid et état | Les marchandises sensibles à la température sont-elles restées dans les limites dans chaque zone et pendant combien de temps ont-elles été exposées ? | Relevés de capteurs associés à la localisation et à la chaîne de possession, avec la durée d'excursion par zone |
Chaque KPI doit avoir un responsable désigné et une décision explicite qu'il éclaire. Si personne ne peut dire ce qu'il ferait différemment quand un chiffre bouge, ce chiffre n'a pas sa place sur le tableau de bord.
Des événements de position à votre outil BI
Les données de localisation brutes sont bruitées, propres à chaque fournisseur et beaucoup trop granulaires pour le reporting. C'est le travail entre le système radio et le rapport qui fait réussir ou échouer la plupart des projets de tableaux de bord.
- Capter : récupérer les événements de la plateforme de localisation via l'API, le flux de messages ou les webhooks du fournisseur, ou via un middleware ou une plateforme IoT qui agrège déjà plusieurs systèmes.
- Normaliser : ramener chaque source à un schéma d'événements unique (quoi, où, quand, avec quel degré de confiance), traduire les noms de zones du fournisseur dans votre propre hiérarchie de site, supprimer les doublons et la gigue, et synchroniser les horloges avec vos systèmes de gestion.
- Dériver : transformer les positions en événements métier, tels que l'entrée et la sortie de zone, le temps de séjour, les transitions et les états d'utilisation, puis les rapprocher des commandes, tâches, ordres de travail ou visites de patients issus de votre WMS, MES, ERP ou DPI.
- Livrer : diffuser les événements en continu pour les alertes et les vues en temps réel, ou les charger selon un calendrier dans votre entrepôt de données ou votre lakehouse pour le reporting. De nombreux sites ont besoin des deux, alimentés par le même modèle.
Pour les systèmes situés de l'autre côté de l'intégration, voir la page des intégrations. Pour la conception et le développement du pipeline de données lui-même, voir développement et intégration.
Pourquoi des tableaux de bord indépendants comptent
La technologie de localisation évolue plus vite que le reporting. Un site peut commencer avec des portiques RFID, ajouter l'UWB pour les véhicules et le BLE pour les personnes, puis remplacer l'un d'eux quelques années plus tard. Si chaque rapport repose sur les structures de données d'un seul fournisseur, chacun de ces changements oblige à reconstruire les rapports et fait perdre un historique comparable.
- Changez la couche radio, gardez les rapports : un nouveau système nécessite un nouveau connecteur vers le modèle de données, pas un nouveau jeu de tableaux de bord.
- Plusieurs technologies, une seule vue : les lectures RFID, les positions RTLS et les relevés de capteurs aboutissent dans le même schéma, de sorte qu'un KPI peut s'appuyer sur toutes ces sources.
- Vos définitions, pas celles du fournisseur : le taux d'utilisation ou le temps de séjour est calculé selon la définition de votre activité, et la logique est documentée.
- Vos données, votre historique : l'historique des événements réside dans votre propre plateforme et reste exploitable après la fin d'un contrat.
Ce que nous livrons
| Livrable | Ce que vous obtenez | Pourquoi c'est important |
|---|---|---|
| 1 · Atelier de définition des KPI | Une liste courte et validée de KPI, chacun avec une définition écrite, un responsable, un public cible, une fréquence d'actualisation et la décision qu'il éclaire | Évite que le projet ne devienne un mur de graphiques sur lesquels personne n'agit |
| 2 · Modèle de données | Un schéma d'événements et une hiérarchie de site indépendants (site, bâtiment, zone, type d'actif), des tables dérivées pour le temps de séjour, les transitions et le taux d'utilisation, et des règles de qualité des données | La couche qui résiste à un changement de fournisseur radio ou d'outil BI |
| 3 · Développement ou spécification des tableaux de bord | Des tableaux de bord développés dans votre outil BI, ou une spécification détaillée avec maquettes et logique de calcul des indicateurs, que votre propre équipe BI réalisera | S'adapte à vos licences, à votre modèle de sécurité et à vos compétences internes |
| 4 · Passation | Documentation des sources, des transformations et de la logique des indicateurs, présentation commentée pour les responsables des rapports, et liste des limites connues de qualité des données | Votre équipe peut exploiter les chiffres, les faire évoluer et s'y fier sans nous |
Nous travaillons avec vos équipes BI, data et OT, pas en les contournant. Lorsque votre équipe préfère développer elle-même, nous nous arrêtons au modèle de données et à la spécification, puis nous revoyons le résultat.
Plateformes BI dans lesquelles nos conseillers ont livré des tableaux de bord de localisation
Nos conseillers ont livré des tableaux de bord de localisation dans chacune des plateformes ci-dessous, y compris dans des fonctions antérieures. Il s'agit d'une expérience personnelle de réalisation. Ce n'est pas une liste de projets clients de TRACIO, et TRACIO n'est ni partenaire ni revendeur de l'un de ces fournisseurs.
- Microsoft Power BI
- Tableau
- Grafana
- Qlik
- Looker / Looker Studio
- Reporting Excel / SharePoint
Si votre organisation utilise un autre outil de reporting, l'approche est la même : le modèle de données et les définitions des KPI sont repris, et le développement suit les conventions de votre plateforme.
Ce que nous ne faisons pas
- Nous ne vendons pas de matériel, notre conseil reste donc indépendant.
- Nous n'enfermons pas les tableaux de bord dans un environnement hébergé par TRACIO. Ils sont développés dans votre tenant, ou spécifiés pour que votre équipe les réalise.
- Nous ne publions aucun chiffre de KPI avant qu'il ait été vérifié par rapport à vos propres données. Lorsque la qualité des données de localisation ne permet pas un reporting fiable, nous le disons et corrigeons d'abord ce point.
Mission et honoraires
Le travail sur les tableaux de bord est cadré et chiffré à l'avance, seul ou dans le cadre d'un programme plus large. Consultez Notre façon de travailler et honoraires pour les modes d'intervention, ou réservez un appel de cadrage gratuit pour passer en revue vos sources de données et votre chaîne de reporting.
Questions fréquentes
Dans quel outil BI nos tableaux de bord de localisation doivent-ils être développés ?
Généralement celui que votre entreprise utilise déjà pour son reporting, afin que les KPI de localisation figurent à côté des chiffres de production, d'entrepôt ou cliniques auxquels les équipes font déjà confiance. Nos conseillers ont personnellement livré des tableaux de bord de localisation dans Microsoft Power BI, Tableau, Grafana, Qlik, Looker / Looker Studio et en reporting Excel / SharePoint, y compris dans des fonctions antérieures. Si vous n'avez pas encore de standard, nous comparons les options au regard de vos utilisateurs, de votre plateforme de données et de vos licences avant tout développement.
Pourquoi ne pas simplement utiliser le tableau de bord du fournisseur RTLS ?
La console du fournisseur est le bon outil pour surveiller le système de localisation lui-même : tags, ancres, batteries et couverture. Elle est moins adaptée aux KPI métier. Elle n'affiche que les données d'un seul fournisseur, définit les indicateurs à sa façon et se rapproche rarement proprement des enregistrements WMS, MES, ERP ou DPI. Nous conservons généralement la console du fournisseur pour la santé du système et développons les KPI métier dans votre outil BI.
Les données de localisation doivent-elles parvenir à notre outil BI en streaming ou par lots ?
Cela dépend de la rapidité avec laquelle quelqu'un doit agir. Les alertes de géorepérage et de sécurité et les vues en temps réel du site nécessitent du streaming. Le taux d'utilisation, les tendances de temps de séjour et les revues opérationnelles hebdomadaires fonctionnent bien avec des chargements planifiés par lots dans votre entrepôt de données. De nombreux sites utilisent les deux : un flux continu pour les alertes et un traitement par lots pour le reporting, alimentés par le même modèle d'événements normalisé.
Qu'arrive-t-il à nos tableaux de bord si nous changeons de fournisseur RTLS ou RFID ?
Si les tableaux de bord reposent sur un modèle de données indépendant, vous remplacez le connecteur qui ramène les événements du nouveau système dans ce modèle, puis vous revalidez les chiffres. Les définitions des KPI, les rapports et l'historique sont conservés. C'est la principale raison pour laquelle nous séparons la couche radio de la couche de reporting.
Vendez-vous des licences BI ou une plateforme d'analyse TRACIO ?
Non. Les tableaux de bord et les modèles de données sont développés dans votre environnement, ou spécifiés pour que votre équipe les réalise, et ils vous appartiennent à la passation.
Dernière mise à jour :