En upphandlare på ett svenskt lärosäte visade oss nyligen sitt förfrågningsunderlag. Kravet på beläggningsdata löd: "Systemet ska visa antal personer i realtid." En mening. Tre leverantörer svarade "uppfylls" — och menade tre helt olika saker. En uppdaterade var femtonde minut. En räknade wifi-enheter, inte personer. En tredje levererade faktisk realtid men bara i sin egen app, utan API. Alla tre hade formellt rätt att kryssa i rutan.
Det är där de flesta upphandlingar av beläggningsmätning i realtid går fel: inte i utvärderingen, utan i kravformuleringen. Den här artikeln går igenom de krav som faktiskt skiljer leverantörer åt — och hur du skriver dem så att de går att verifiera vid leveransgodkännande, inte bara i anbudet.
"Realtid" är branschens mest töjbara ord. För en energioptimering som styr ventilation räcker ofta data med några minuters fördröjning. För kapacitetsstyrning i en tentamenssal, ett gym eller en offentlig servicelokal behöver siffran vara aktuell inom sekunder. Skriv därför latenskravet som ett mätbart tal: "Beläggningsdata ska vara tillgänglig via API senast X sekunder efter registrerad passage." Ange också uppdateringsfrekvens separat — ett system kan ha låg latens men bara skicka data i femminutersbatcher, vilket ger samma praktiska problem.
Kräv dessutom att latensen gäller i gränssnittet ni faktiskt ska använda. Många plattformar visar realtid i sin egen dashboard men exponerar bara aggregerad timdata via API. Om er facility management-plattform eller ert bokningssystem är den verkliga konsumenten av datat, är det där kravet ska mätas.
Nästan alla leverantörer uppger 98 eller 99 procents noggrannhet. Frågan är vad som händer när de inte når dit. En siffra i en broschyr är inte ett åtagande — en siffra i avtalet är det. Seriösa leverantörer kan skriva in en kontraktuell miniminivå; hos Vemco är den 96 procent, medan den faktiska noggrannheten typiskt ligger på 98–99 procent när förutsättningarna kring ljus, entréutformning och besöksflöden tillåter. Skillnaden är avgörande i en upphandling: miniminivån är det ni kan hålla leverantören ansvarig för, resten är förväntad prestanda.
Här kommer en observation från praktiskt införande som sällan står i anbuden: noggrannhet är inte en systemegenskap, det är en egenskap per mätpunkt. En sensor över en smal entré med bra ljus presterar nästan alltid i toppskiktet. En bred entré med motljus, roterdörr eller kundvagnar drar ned snittet. Skriv därför att noggrannheten ska verifieras per entré vid ett dokumenterat acceptanstest — manuell kontrollräkning mot systemets data under normala driftförhållanden — inte som ett genomsnitt över hela anläggningen. Då upptäcker ni den problematiska entrén i vecka två i stället för i månad åtta.
Hårdvara och mjukvara har olika livscykler. Sensorer i tak sitter ofta kvar i åtta till tio år; analysbehoven förändras betydligt snabbare. Om plattformen bara fungerar med leverantörens egen hårdvara sitter ni fast åt båda hållen — ni kan varken byta sensorer utan att byta mjukvara, eller tvärtom. Kräv därför att plattformen är sensoroberoende: att den kan ta emot data från flera hårdvarufabrikat och sensortyper (3D-kameror, termiska sensorer, lidar) i samma installation.
Det här är särskilt relevant för universitet och offentliga fastighetsägare med blandade bestånd. Ni har sannolikt redan sensorer i vissa byggnader från tidigare projekt. En sensoroberoende plattform kan ofta återanvända befintlig hårdvara, vilket sänker investeringen påtagligt — men bara om ni skrivit kravet så att leverantören måste redovisa vilka fabrikat som stöds, inte bara svara "ja" på en generell fråga.
För offentliga institutioner är det här ofta den punkt som avgör om ett avrop över huvud taget går att genomföra. Tre krav bör stå med ordagrant:
Realtidsdata skapar värde först när den når systemen där beslut fattas: fastighetsautomation, lokalbokning, städplanering, BI-verktyg. Kräv ett dokumenterat, öppet API och fråga specifikt efter färdiga integrationer mot de system ni redan kör. Plattformar med ett dedikerat integrationslager — som Vemcos VemFusion, som kopplar beläggningsdata mot BI-, ERP- och CRM-system — sparar månader av eget integrationsarbete jämfört med ett generiskt API där allt byggs från noll.
Kräv också skalbarhet i praktiska termer: kan samma plattform hantera både en enskild byggnad i pilotfasen och hela beståndet vid utrullning, med samma datamodell och samma användarrättigheter? Många lösningar klarar tio mätpunkter men inte tusen — och det märks först när det är för sent att byta.
Avsluta kravspecifikationen med hur ni tänker verifiera. Tre mekanismer räcker långt:
Begär också in leverantörens certifieringar och supportmodell som en del av anbudet, och väg in hur länge plattformen funnits i skarp drift. Mjukvara som utvecklats och driftats sedan mitten av 00-talet har hunnit möta betydligt fler entrétyper, byggnadsvarianter och integrationsscenarier än en plattform lanserad förra året — och det syns i hur få överraskningar som dyker upp under införandet.
En sista sak: skriv kraven i den ordning ni ska leva med dem. Latens och noggrannhet avgör om datat går att lita på. Sensoroberoende och dataägande avgör om ni är fria om fem år. Integration avgör om någon i organisationen faktiskt använder siffrorna. Vänd på den ordningen, och ni riskerar att upphandla en snygg dashboard som ingen tittar på efter det första kvartalet.
Står ni inför en upphandling av beläggningsmätning i realtid? Kontakta Vemco Group så går vi igenom er kravspecifikation tillsammans — inklusive hur ett kontraktuellt noggrannhetsgolv, sensoroberoende arkitektur och acceptanstest per entré bör formuleras för just er fastighetstyp.