AIR, PIR och EIR i upphandling: så skriver du krav som faktiskt går att leverera mot

AIR, PIR och EIR. Tre förkortningar som låter byråkratiska men som faktiskt avgör om informationen i ett projekt blir användbar eller bara levererad. Jag har sett upphandlingar där hela informationskravet är en mening: "Modeller ska levereras i IFC-format." Det räcker inte.

Vad förkortningarna betyder

AIR står för Asset Information Requirements. Vad förvaltaren behöver veta om sin tillgång under hela dess livslängd. PIR är Project Information Requirements. Vad beställaren behöver av projektet för att fatta beslut. EIR är Exchange Information Requirements. Vad varje leverantör konkret ska leverera och när. Hierarkin är att AIR styr PIR som styr EIR.

Var de flesta börjar fel

De flesta börjar med EIR. De skriver en lång lista med leveranskrav på filformat, namngivning och struktur. Men eftersom AIR aldrig definierats vet ingen vad informationen ska användas till. Resultatet blir leveranser som uppfyller bokstaven i kravet men inte syftet.

AIR börjar hos förvaltaren

Ett konkret exempel: en kommun ska bygga en ny gång- och cykelbro. Förvaltaren behöver veta vilka komponenter som ingår, när de senast inspekterades, vilket material de är gjorda av och vem leverantören var. Det är AIR. Allt annat i informationskravet ska syfta till att tillhandahålla just det, plus det som behövs under projektet.

PIR ska kunna besvara beställarens frågor

PIR handlar om projektets behov. Vilka beslut ska fattas och vilket underlag krävs? Behöver beställaren energiberäkningar i tidigt skede? Behöver de mängdförteckning för att jämföra anbud? Skriv ner frågorna först. Härled sedan informationen som behövs för att svara på dem.

EIR är där det blir konkret

EIR är leverantörens kravspec. Filformat, leveranspunkter, modellnoggrannhet, klassificering, ansvarsmatris. Det är här ni hänvisar till specifika standarder, läs gärna vår genomgång av ISO 19650 och TDOK-leveranser.

Det här brukar fattas i EIR

• Vilken IFC-version och vilka Pset som gäller
• Tydlig mappning mot klassificering, ofta CoClass i svenska projekt
• Exakta leveranstidpunkter kopplade till projektets faser, inte bara "vid leverans"
• Krav på granskningsrapporter, inte bara på själva modellfilen

En tabellsida slår ofta tio sidor löptext

Det bästa EIR-dokument jag sett var en tabell på sex sidor. För varje informationsmängd stod det vem som levererar, när, i vilket format, mot vilken standard och vem som granskar. Inget mer. Det var begripligt för anbudsgivarna och möjligt att följa upp för beställaren.

Sammanfattning

Börja med vad förvaltaren behöver. Härled vad projektet behöver. Översätt till konkreta leveranskrav. Skriv som om någon faktiskt ska följa dokumentet, inte bara läsa det. Då fungerar AIR, PIR och EIR som de var tänkta.

Källor: ISO 19650 2:2018, Delivery phase of the assets. buildingSMART International, Information Requirements Guide (2023). BIM Alliance Sweden, Vägledning för informationskrav (2022).