När BRF:er upphandlar “digital underhållsplan” blandas ofta två helt olika saker ihop: konsultleverans (en rapport i PDF/Excel) och system (SaaS där ni kan uppdatera, analysera och rapportera löpande). Den här kravspecen hjälper er att ställa rätt krav – och undvika att köpa “en fil i molnet” när ni egentligen behöver ett verktyg.
- Börja med att definiera vad ni köper: konsultrapport, system – eller båda.
- För ett system: kräva struktur (byggnad + systemkod/u_system + AFF) så att planen blir analysbar och rapporterbar.
- Kräv behörighet per fastighet/byggnad och ändringslogg (spårbarhet i styrelsearbete).
- Kräv import (Excel/PDF→Excel) och en tydlig mall (minst aktivitet, systemkod, kostnad, startår).
Vill du förstå helheten innan du upphandlar? Läs Digital underhållsplan för BRF. Vill du jämföra verktyg mot Excel, läs Digital underhållsplan vs Excel.
Steg 1: Sätt ramarna – vad är leveransen?
Svara på dessa frågor först. De avgör vilka krav som är relevanta:
- Ska ni primärt ha ett system som styrelsen kan arbeta i löpande?
- Ska ni också ha konsultstöd (t.ex. kvalitetssäkring/registrering) som en tjänst?
- Behöver ni att leverantören tar ansvar för löpande uppdatering – eller vill ni ha egen kontroll?
Vanlig fallgrop: Ni upphandlar “digital underhållsplan” och får en PDF/Excel i en portal – men saknar verktyg för att uppdatera, filtrera, analysera och rapportera på samma data. Var tydliga med att ni vill ha SaaS om det är målet.
Steg 2: Kravlista (kort) – det här ska ni kunna kryssa i
| Område | Krav (SaaS/verktyg) | Varför |
|---|---|---|
| Datamodell | Aktiviteter kopplas till byggnad (stöd för flera fastigheter/byggnader) | Gör urval, ansvar och rapporter tydliga |
| Struktur | Systemkod (u_system) och AFF-kod på aktiviteter | Möjliggör analys “per system” och per AFF-huvudgrupp |
| Tidslogik | Startår + intervall (kan generera förekomster eller enstaka aktivitet) | Planen blir konsekvent utan manuellt dubbelarbete |
| Status | Status som går att använda: Planerad/Akut/Eftersatt/Beslutad/Utförd | Styrelsearbete kräver beslut och uppföljning |
| Analys | Kostnad per år + gruppering per AFF huvudgrupp, filter | Identifiera toppar och prioritering |
| Rapport | PDF-rapport med urval + sektioner, inkl. “per år” och “per system” | Beslutsunderlag till styrelse/stämma |
| Behörighet | Behörighet per fastighet/byggnad | Styrelsebyte och konsultstöd utan att exponera allt |
| Spårbarhet | Central logg över ändringar (vem/när/vad) | Kontroll över beslut och ändringar över tid |
| Import | Excel-import + stöd för PDF→Excel-flöde | Ni kan migrera befintliga planer utan att börja om |
| Dataägarskap | Tydligt: kunden äger data; export/åtkomst policy dokumenterad | Minskar inlåsning och risk vid leverantörsbyte |
Steg 3: Fördjupade krav (för att undvika “halvdigitalt”)
A) Planens struktur och kvalitet
- Det ska gå att filtrera på byggnad, årintervall, systemkod, AFF, status och flaggor.
- Minimiregistrering ska vara tydlig och validerad (aktivitet, startår, kostnad, systemkod, AFF).
- Stöd för intervall (teknisk livslängd) och möjlighet att skapa enstaka aktiviteter vid behov.
B) Arbetsvy utan risk
Om leverantören erbjuder “drag & drop” eller kanban: ställ krav på att den är säker att använda. En bra design är att drag-and-drop styr årtal, medan större ändringar (t.ex. massflytt eller massprisändring) sker via separata verktyg med tydlig bekräftelse.
Bra kontrollfråga till leverantör: “Hur undviker ni att en användare råkar ‘flytta allt’ och förstör logiken i planen?”
C) Analys och “rådgivning”
Om leverantören marknadsför AI/analys: be om tydlighet i vad som är beslutsstöd och vad som är autopilot. Ett trovärdigt upplägg är att analysen ger råd (t.ex. datakvalitet, rimlighet/täckning och besparingsförslag) men att ändringar alltid måste bekräftas av användaren.
D) Rapport och urval
Ni vill kunna skapa PDF-rapporten utifrån urval som ni kan återskapa. Be leverantören visa:
- rapportsektioner (t.ex. fastighets-/byggnadsinfo, underhållsdiagram, aktiviteter per år, aktiviteter per system, avsättningsdiagram),
- hur ni gör urval “nästa 5 år” och “per systemkod”,
- hur ni kan lägga in egen text (t.ex. sammanfattning eller introduktion).
E) Behörighet och styrelsebyte
- Det ska gå att ge en ny styrelse eller extern part tillgång per fastighet/byggnad.
- Det ska finnas central logg över ändringar.
- Leverantören ska kunna beskriva hur ni gör en trygg överlämning (vilka urval/rapporter som tas ut).
Steg 4: Frågor att ställa i upphandlingen (copy/paste)
| Fråga | Vad du vill höra |
|---|---|
| Är detta ett system vi kan uppdatera löpande, eller en rapportleverans? | Tydligt “SaaS” + vad som ingår som tjänst |
| Kan ni visa filtrering per byggnad, systemkod och status? | Ja, med konkreta exempel i UI |
| Hur hanterar ni intervall/teknisk livslängd? | Startår + intervall, kan generera förekomster |
| Hur ser er ändringslogg ut? | Vem/när/vad loggas, åtkomligt i systemet |
| Hur fungerar import från Excel/PDF? | Excel-mall + ev. PDF→Excel-flöde, tydliga minimifält |
| Hur ser rapporteringen ut “per år” och “per system”? | PDF-sektioner och urval som är lätta att återskapa |
| Vem äger data och hur ser export/åtkomst ut? | Tydlig policy, låg inlåsning |
Bilaga: Minimal datamall att kräva vid import
Om ni vill försäkra er om att ni kan migrera och kvalitetssäkra, be leverantören visa en mall som minst innehåller:
- maintenance_activity (aktivitet)
- u_system (systemkod)
- total_cost (kostnad)
- start_year (startår)
Bonusfält som sparar tid: building_code (om byggnaden redan är upplagd) och technical_life (intervall/teknisk livslängd).
Relaterade artiklar
- Digital underhållsplan för BRF
- Digital underhållsplan vs Excel
- Importera befintlig plan
- Underhållsplan i molnet
- Kom igång på 14 dagar
Vill du se hur en digital underhållsplan faktiskt ser ut (vy-för-vy) innan du kravställer? Läs: Exempel: så ser en digital underhållsplan ut.