När en BRF går från Excel/PDF till en digital underhållsplan händer ofta samma sak: man får in “något” i systemet – men upplever inte att det blir enklare. Nästan alltid beror det på ett fåtal återkommande misstag i struktur och arbetssätt. Här är de vanligaste felen och hur ni fixar dem, utan att göra projekt av det.
- En digital underhållsplan fungerar när aktiviteter är byggnadskopplade och har minimidata (startår, kostnad, systemkod/u_system, AFF).
- De största riskerna är spretig struktur, passerade år och massändringar utan rutiner.
- Byggnadsattribut/ytor/mängder är hjälpmedel för registrering och transparent prissättning vid skapande av aktivitet – inte ett krav.
- Gör små förbättringar: först “analysbar plan”, sedan “styrelsebar plan”, sedan “finplan”.
Om du vill förstå helheten först, läs Digital underhållsplan för BRF. Behöver du praktiskt upplägg, se Kom igång på 14 dagar.
Fel 1: Aktiviteter kopplas inte till rätt byggnad
Det här är den vanligaste orsaken till att filtrering, analys och rapporter blir otydliga. Om aktiviteter ligger “lösa” eller kopplas fel tappar ni möjligheten att förstå planen per hus – vilket nästan alltid behövs i praktiken.
Åtgärd: Skapa byggnader först och säkerställ att varje aktivitet alltid kopplas till en byggnad.
Fel 2: Minimifälten saknas – planen blir inte analysbar
Många importerar in “text och årtal” men missar strukturen som gör planen användbar. För att planen ska gå att analysera och rapportera behöver ni en konsekvent miniminivå:
- maintenance_activity (aktivitet)
- start_year (startår)
- total_cost (kostnad)
- u_system (systemkod)
- AFF-kod (för gruppering/analys per AFF huvudgrupp)
Bonusfält som ofta sparar tid: building_code (koppling till byggnad) och technical_life (intervall/teknisk livslängd).
Fel 3: Systemkod (u_system) blir spretig
I Excel blir det lätt “VVS”, “VS”, “Rör”, “Vatten” – och sen går det inte att rapportera “per system” utan att först städa.
Åtgärd: Normalisera systemkoderna till en liten uppsättning (t.ex. 8–15 systemkodvärden) innan eller direkt efter import.
Fel 4: Dubletter efter import (intervall + manuella upprepningar)
Många äldre planer har aktiviteter upprepade manuellt i flera år. I ett system kan intervall skapa förekomster inom planperioden. Om ni importerar både manuella upprepningar och sätter intervall får ni dubletter.
Åtgärd: Välj strategi: antingen importerar ni enstaka aktiviteter, eller så importerar ni med intervall och låter systemet skapa förekomster. Rensa dubletter manuellt.
Fel 5: Aktiviteter ligger kvar i passerade år
En aktivitet som ligger i ett år som redan passerat blir snabbt ett brus i analys och rapport. Det kan också skapa missförstånd i styrelsen: “skulle vi inte gjort detta redan?”.
Att sätta en aktivitet på år 2020 när det är 2026 är nästan aldrig korrekt. Spegla behovet genom att flytta till ett relevant år – eller använd status Eftersatt om syftet är att visa underhållsskuld.
Fel 6: Status används inte – planen blir en lista, inte ett beslutsstöd
Utan status kan ni inte skilja på “plan” och “verklighet”. I praktiken behöver styrelsen veta vad som är akut, vad som är beslutat och vad som är utfört.
Åtgärd: Använd status konsekvent: Planerad, Akut, Eftersatt, Beslutad, Utförd.
Fel 7: För många försöker ändra samtidigt
Om många gör ändringar utan gemensamma rutiner blir planen “rörlig” men inte bättre. Det skapar också osäkerhet kring beslut och ansvar.
Åtgärd: Utse 1–2 planansvariga som gör ändringar, övriga använder urval/rapport.
Fel 8: Massändringar i stället för rutiner
Om ni ofta känner behov av att “flytta allt”, “ändra alla priser” eller “städa hela planen” är det ett tecken på att rutinerna saknas. Det är lätt att skapa en plan som ser snygg ut men där logiken spricker (”mattkant”).
Åtgärd: Jobba med små, återkommande uppdateringar via årshjul i stället för stora engångsoperationer.
Fel 9: Man försöker göra byggnadsattribut/ytor/mängder till ett måste
Byggnadsattribut, ytor och mängder är bra – men om ni gör dem till ett krav i starten så fastnar ni. De är främst ett hjälpmedel för:
- att modellen kan föreslå artiklar från prislistan,
- att skapa en transparent utgångspunkt för prissättning vid skapande av aktivitet (om artikeln har default value).
De påverkar alltså registrering och spårbar prissättning – inte om ni “kan” ha en fungerande plan.
Snabbfix: 60-minuters kvalitetssäkring efter import
- Filtrera per byggnad: sitter aktiviteterna rätt?
- Filtrera fram saknade u_system/AFF: komplettera.
- Öppna analys: kostnad per år (per AFF huvudgrupp) – finns extrema toppar?
- Hitta passerade år: flytta eller sätt Eftersatt (medvetet).
- Skapa en PDF-rapport: “per år” + “per system” + “diagram avsättningar”.
Översiktstabell: fel → symptom → åtgärd
| Fel | Symptom | Åtgärd |
|---|---|---|
| Fel byggnadskoppling | Rapporter blir otydliga | Skapa byggnader först, använd building_code |
| Saknar minimifält | Analys/urval fungerar dåligt | Komplettera startår, kostnad, u_system, AFF |
| Spretig u_system | “Per system” blir skräp | Normalisera till få systemkoder |
| Dubletter | För många poster i samma period | Välj intervall-strategi, rensa manuellt |
| Passerade år | Planen känns “gammal” | Flytta år eller markera Eftersatt |
| Ingen statusdisciplin | Svårt att besluta/budgetera | Använd Planerad/Akut/Eftersatt/Beslutad/Utförd |
| Massändringar | Planen tappar logik | Inför årshjul, små uppdateringar |
Relaterade artiklar
- Importera befintlig plan
- Kom igång på 14 dagar
- Årshjul för uppdatering
- Underhållsplan och budget
- Digital underhållsplan vs Excel
Vill du få ordning snabbt? Börja med importguiden: Importera befintlig plan och följ sedan rutinen i: Årshjul för uppdatering.