Locatiedashboards en analyse: operationele KPI's uit positiedata, in de BI-tool die u al gebruiktWel locatiedata, maar geen KPI's waar iemand op stuurt?
Locatiesystemen produceren een constante stroom positiegebeurtenissen. De waarde zit in een kleine set operationele KPI's die mensen bekijken en waarop ze handelen. Wij definiëren die KPI's samen met u, normaliseren de gebeurtenisdata uit uw RTLS-, RFID- of IoT-platform en leveren die aan in de BI-tool die uw organisatie al gebruikt. Onafhankelijk advies. Geen hardwareverkoop, geen leverancierscommissies.
Wat een locatiedashboard moet laten zien
De paar meetwaarden die een beslissing op de werkvloer, op de afdeling of op het terrein veranderen, en geen bewegende stip op een kaart. Welke ertoe doen, hangt af van de operatie, maar de meeste programma's putten uit dezelfde zes categorieën:
| KPI | De vraag die het beantwoordt | Gebaseerd op |
|---|---|---|
| Benutting | Hoeveel van de tijd zijn assets, voertuigen, ruimtes of laadplaatsen daadwerkelijk in gebruik, en waar zit verborgen restcapaciteit? | Aanwezigheid in zones en beweging of in-gebruikstatussen, afgezet tegen diensten en kalenders |
| Verblijftijd | Hoe lang wachten artikelen, orders, patiënten of trailers in elke zone of processtap, en waar loopt de wachttijd op? | Gebeurtenissen bij het binnenkomen en verlaten van zones, gekoppeld aan order-, opdracht- of bezoekrecords |
| Doorstroming en knelpunten | Welke routes, overgangen en overdrachten vertragen het proces, en wanneer? | Zone-naar-zone-overgangen, padtellingen en wachtrijlengtes in de loop van de tijd |
| Zoektijd | Hoeveel tijd besteden mensen aan het zoeken naar gereedschap, karren, apparatuur of voorraad die het systeem zou kunnen lokaliseren? | Laatst bekende locatie en zoekverzoeken, vergeleken met een nulmeting die u vóór go-live uitvoert |
| Veiligheids- en geofencegebeurtenissen | Waar en wanneer betreden mensen en voertuigen verboden zones, en wat gebeurde er daarna? | Geofence-overtredingen, nabijheidsgebeurtenissen en alarmbevestigingen |
| Koudeketen en conditie | Zijn temperatuurgevoelige goederen in elke zone binnen de grenzen gebleven, en hoe lang stonden ze bloot aan afwijkingen? | Sensormetingen gekoppeld aan locatie en bewaarketen, met de duur van afwijkingen per zone |
Elke KPI moet een benoemde eigenaar hebben en een vastgelegde beslissing die hij ondersteunt. Als niemand kan zeggen wat hij anders zou doen wanneer een getal verandert, hoort het niet op het dashboard.
Van positiegebeurtenissen naar uw BI-tool
Ruwe locatiedata is ruisgevoelig, leveranciersspecifiek en veel te gedetailleerd voor rapportage. Het werk tussen het radiosysteem en het rapport bepaalt of de meeste dashboardprojecten slagen of mislukken.
- Vastleggen: haal gebeurtenissen uit het locatieplatform op via de API, de berichtenstroom of webhooks van de leverancier, of via middleware of een IoT-platform dat al meerdere systemen samenbrengt.
- Normaliseren: breng elke bron onder in één gebeurtenisschema (wat, waar, wanneer, met welke zekerheid), vertaal de zonenamen van de leverancier naar uw eigen locatiehiërarchie, verwijder duplicaten en jitter en synchroniseer klokken met uw bedrijfssystemen.
- Afleiden: zet posities om in business events zoals het betreden en verlaten van zones, verblijftijd, overgangen en in-gebruikstatussen, en koppel ze aan orders, opdrachten, werkorders of patiëntbezoeken uit uw WMS, MES, ERP of EPD.
- Leveren: stream gebeurtenissen voor meldingen en live weergaven, of laad ze volgens planning in uw datawarehouse of lakehouse voor rapportage. Veel locaties hebben beide nodig, gevoed vanuit hetzelfde model.
Voor de systemen aan de andere kant van de integratie, zie het integratieoverzicht. Voor het ontwerp en de bouw van de datapijplijn zelf, zie bouw en integratie.
Waarom onafhankelijke dashboards belangrijk zijn
Locatietechnologie verandert sneller dan rapportage. Een locatie begint misschien met RFID-portalen, voegt UWB toe voor voertuigen en BLE voor mensen, en vervangt na een paar jaar een van die systemen. Als elk rapport is gebouwd op de datastructuren van één leverancier, betekent elke wijziging dat de rapporten opnieuw moeten worden gebouwd en dat vergelijkbare historie verloren gaat.
- Vervang de radiolaag, behoud de rapporten: een nieuw systeem heeft een nieuwe connector naar het datamodel nodig, geen nieuwe set dashboards.
- Meerdere technologieën, één beeld: RFID-uitlezingen, RTLS-posities en sensormetingen komen in hetzelfde schema terecht, zodat een KPI op al die bronnen kan steunen.
- Uw definities, niet die van de leverancier: benutting of verblijftijd wordt berekend zoals uw organisatie die definieert, en de logica wordt gedocumenteerd.
- Uw data, uw historie: de gebeurtenishistorie staat op uw eigen platform en blijft bruikbaar nadat een contract is afgelopen.
Wat wij leveren
| Deliverable | Wat u krijgt | Waarom het belangrijk is |
|---|---|---|
| 1 · Workshop KPI-definities | Een korte, overeengekomen lijst met KPI's, elk met een schriftelijke definitie, eigenaar, doelgroep, verversingsfrequentie en de beslissing die hij ondersteunt | Voorkomt dat het project uitmondt in een muur van grafieken waar niemand iets mee doet |
| 2 · Datamodel | Een onafhankelijk gebeurtenisschema en locatiehiërarchie (locatie, gebouw, zone, assettype), afgeleide tabellen voor verblijftijd, overgangen en benutting, en regels voor datakwaliteit | De laag die een verandering van radioleverancier of BI-tool overleeft |
| 3 · Bouw of specificatie van dashboards | Dashboards gebouwd in uw BI-tool, of een gedetailleerde specificatie met mock-ups en metriekenlogica waarmee uw eigen BI-team ze kan bouwen | Past bij uw licenties, beveiligingsmodel en interne vaardigheden |
| 4 · Overdracht | Documentatie van bronnen, transformaties en metriekenlogica, een toelichting voor rapporteigenaren en een lijst met bekende beperkingen in de datakwaliteit | Uw team kan de cijfers zonder ons beheren, aanpassen en vertrouwen |
Wij werken samen met uw BI-, data- en OT-teams in plaats van langs hen heen. Als uw team liever zelf bouwt, stoppen wij bij het datamodel en de specificatie en beoordelen wij het resultaat.
BI-platforms waarin onze adviseurs locatiedashboards hebben geleverd
Onze adviseurs hebben in elk van de onderstaande platforms locatiedashboards opgeleverd, ook in eerdere functies. Dit is persoonlijke opleveringservaring. Het is geen lijst van TRACIO-klantprojecten, en TRACIO is geen partner of wederverkoper van een van deze leveranciers.
- Microsoft Power BI
- Tableau
- Grafana
- Qlik
- Looker / Looker Studio
- Excel / SharePoint-rapportage
Als uw organisatie in iets anders rapporteert, is de aanpak dezelfde: het datamodel en de KPI-definities blijven bruikbaar en de bouw volgt de conventies van uw platform.
Wat wij niet doen
- Wij verkopen geen hardware, zodat ons advies onafhankelijk blijft.
- Wij sluiten dashboards niet op in een door TRACIO gehoste omgeving. Ze worden gebouwd in uw eigen tenant, of gespecificeerd zodat uw team ze kan bouwen.
- Wij publiceren geen KPI-cijfers voordat ze zijn getoetst aan uw eigen data. Als de kwaliteit van de locatiedata niet goed genoeg is om op te rapporteren, zeggen we dat en lossen we dat eerst op.
Samenwerking en tarieven
Dashboardwerk wordt vooraf afgebakend en geprijsd, los of als onderdeel van een breder programma. Zie Onze werkwijze en tarieven voor de samenwerkingsvormen, of boek een gratis verkenningsgesprek om uw databronnen en rapportageomgeving door te nemen.
Veelgestelde vragen
In welke BI-tool moeten onze locatiedashboards worden gebouwd?
Meestal in de tool waarin uw organisatie al rapporteert, zodat locatie-KPI's naast de productie-, magazijn- of klinische cijfers staan die mensen al vertrouwen. Onze adviseurs hebben persoonlijk locatiedashboards opgeleverd in Microsoft Power BI, Tableau, Grafana, Qlik, Looker / Looker Studio en Excel / SharePoint-rapportage, ook in eerdere functies. Als u nog geen standaard heeft, vergelijken we de opties op basis van uw gebruikers, dataplatform en licenties voordat er iets wordt gebouwd.
Waarom niet gewoon het eigen dashboard van de RTLS-leverancier gebruiken?
De leveranciersconsole is de juiste plek om het locatiesysteem zelf te monitoren: tags, anchors, batterijen en dekking. Voor business-KPI's is hij minder geschikt. Hij toont de data van één leverancier, definieert metrieken op de manier van de leverancier en laat zich zelden netjes koppelen aan records in WMS, MES, ERP of EPD. Meestal houden we de leveranciersconsole voor de systeemgezondheid en bouwen we de business-KPI's in uw BI-tool.
Moet locatiedata via streaming of in batches naar onze BI-tool?
Dat hangt af van hoe snel iemand moet handelen. Geofence- en veiligheidsmeldingen en live overzichten van de werkvloer vereisen streaming. Benutting, trends in verblijftijd en wekelijkse operationele reviews werken goed met geplande batchladingen in uw datawarehouse. Veel locaties gebruiken beide: een streamingroute voor meldingen en een batchroute voor rapportage, gevoed vanuit hetzelfde genormaliseerde gebeurtenismodel.
Wat gebeurt er met onze dashboards als we van RTLS- of RFID-leverancier wisselen?
Als de dashboards op een onafhankelijk datamodel zijn gebouwd, vervangt u de connector die de gebeurtenissen van het nieuwe systeem naar dat model vertaalt en valideert u daarna de cijfers opnieuw. De KPI-definities, rapporten en historie blijven behouden. Dat is de belangrijkste reden waarom we de radiolaag scheiden van de rapportagelaag.
Verkoopt u BI-licenties of een TRACIO-analyseplatform?
Nee. Dashboards en datamodellen worden in uw omgeving gebouwd, of gespecificeerd zodat uw team ze kan bouwen, en bij de overdracht bent u er eigenaar van.
Laatst bijgewerkt: