2 Informationssamordning

För varje projekt eller annat samarbete överenskoms hur digital information ska struktureras, kommuniceras och lagras. Dokumentationen är/ska vara en del av den leverans som ingår i arbetet vid en förändring på våra fastigheter. Alla som är delaktiga i ett arbete är ansvariga för att se till att dokumentationen uppdateras och levereras. För att underlätta informationssamordningen är det därför praktiskt att ta fram ett styrande dokument som beskriver vad man kommit överens om ska ingå i leveransen, hur informationen ska struktureras, hur arbetet ska genomföras och överlämnas till förvaltning. Dokumentet tas fram för ett visst projekt och ska underlätta beslut, samordning och samarbete, men är även ett stöd för framtida förvaltning, för att förstå varför modellerna är uppbyggda som de är. Projektets tillämpningsanvisning är ett levande dokument. Förändringar och uppdateringar görs av informationssamordnaren för samarbetet.

2.1 Organisation

I ett projekt är det bra att beskriva vilken person som har vilken roll för att förtydliga för alla inblandade vad man har för rättigheter och skyldigheter. Ibland kan man dela upp en roll mellan flera personer och då måste uppdelningen förtydligas och ibland kan en och samma person inneha flera roller.

I löpande förvaltning behöver man kanske inte alltid beskriva vilka roller olika personer har men det är viktigt att man ändå förstår och klargör vilka rättigheter och skyldigheter olika personer har för slutresultatet.

Beställare

se beskrivning i Tillämpningsanvisning: förvaltning.

Beställare/byggherren kan företrädas av förvaltare, hyresgäst/kund och/eller projektledare beroende på projektform.

Vid en generalentreprenad/utförande entreprenad är det beställaren som handlar upp projekteringen och ansvarar därmed för alla handlingar. Ofta får man då underlag för relation från respektive leverantör. Vid en totalentreprenad ansvarar entreprenören för att ta fram detaljprojektering samt handlingar i enlighet med de krav som projektet har satt upp.

Förvaltare

Den uppdragsgivare som är angiven i beställning eller i kontrakt och som tar över i förvaltningsskedet. Detta kan därför i olika projekt vara olika typer av förvaltare, fastighetsförvaltare, teknisk förvaltare, informationsförvaltare mfl.

Hyresgäst/kund

Person eller juridisk person som ska nyttja hela eller delar av fastighet och/eller byggnadsverk. Ofta benämnd ”kund” i processen.

Projektledare

Person som agerar som företrädare för beställare i ett projekt.

Leverantör

upprättar informationsmängd och ansvarar för innehåll, har full kännedom om tillämpningsanvisningen och kunskap att efterleva den mm se Tillämpningsanvisning: förvaltning.

Leverantör kan vara projektörer och entreprenörer.

Projektör

Person eller organisation som framställer underlag för produktion och arbetar med virtuellt byggande. Ofta indelade i flera discipliner.

Entreprenör

Juridisk person som åtagit sig en entreprenad.

Informationssamordnare för samarbetet

se beskrivning i Tillämpningsanvisning: förvaltning.

Informationssmordnare i en generalentreprenad/utförandeentreprenad är ofta beställaren själv (se Beställare).

I förstudie och tidiga skeden kan informationssamordnaren vara en strategisk affärsutvecklare eller en projektledare från Akademiska Hus. Då handlar det främst om att ta fram en bra grund med förutsättningarna inför projektet.

I större projekt och från Program- eller systemhandlingsskedet är det vanligt att informationssamordnaren är en teknisk handläggare eller en projekteringsledare. Att utse en informationssamordnare är viktigt för att kunna hålla Akademiska Hus tekniska information uppdaterad.

Teknisk handläggare

Person som handlägger olika teknikområden i projektet. Ansvarar för att kontrollera omfattning och innehållet i förvaltningsinformationen från entreprenör och projektör.

Projekteringsledare

Person som ansvarar för samordning av projekteringen vid bland annat totalentreprenad. Projekteringsledaren styr projekteringsarbetet så att ställda krav och mål uppfylls i projektet.

Informationsförvaltare hos beställaren

se beskrivning i Tillämpningsanvisning: förvaltning.

Informationsförvaltare hos beställare är ofta de Digitala informationsförvaltarna, men kan även vara någon på fastighets/campusavdelningen hos hyresgäst/kund.

Digital informationsförvaltare

Hanterar och publicerar modeller och ritningar till förvaltningssystemen inom Akademiska Hus AB. Ansvarar för att den gemensamma Kravmanualen hålls uppdaterad och utbildar organisationen i hur den ska användas.

Informationsansvarig hos leverantör

se beskrivning i Tillämpningsanvisning: förvaltning.

Beroende på entreprenadform och vad man kommit överens om från i början av samarbetet levereras underlag till relation eller uppdaterade handlingar enligt kraven vilka samordnas med informationssamordnaren på informationssamordningsmötet se bilaga 1.

2.12 Projektnätverk

I projekt är det viktigt att man tidigt beslutar hur man ska hantera dokumentationen i projektet, men även den dokumentation som kravställs till förvaltning. Vem ansvarar för vad och vilka rättigheter och skyldigheter har de olika rollerna. Detta ska finnas beskrivet som en del av projektets tillämpningsanvisning. I tidigt stadium ska även en plats för informationsutbytet beslutas och en beskrivning på hur informationen ska vara strukturerad tas fram, så att alla projektmedlemmar vet vad, hur och var de ska spara information och så att man med hjälp av denna beskrivning ska kunna hitta bland dokumenten i framtiden. Ett tips är att använda strukturen i mallen DoU 1 Mappstruktur samordnande DoU-instruktioner ur skriften Instruktioner för drift och underhåll en branschstandard för upphandling och innehåll från svensk byggtjänst AB samt den struktur som förvaltningen använder, för lagring av relationshandlingar, eftersom det underlättar leveransen. I löpande förvaltning kan det vara så att dokumentationen bara hanteras vid startpaket och överlämning och att det sker via e-post. Om projektnätverket hanterar metadata på filerna kan det med fördel användas. Hantering av metadata ska var så smidig som möjlig och minimera det administrativa arbetet.

2.2 Teknisk specifikation

Kontrollera vilka programvaror som används och dokumentera de egenskaper hos mjuk och hårdvara som påverkar projektet. Om man behöver förändra mjukvara och hårdvara ska detta komma överens om i projektet.

2.22 Krav på mjukvara

Areamätning i objektmodellen ska ske enligt gällande svensk standard (nuvarande SS 02 10 54:2020) med verktyg som finns i CAD-programmet. Objektmodellen ska hålla sådan kvalitet att areamätning kan utföras. Utrymmesinformationen ska kunna exporteras i XML-format enligt FI2.

Areor som ska redovisas är NTA, BRA, BTA enligt Värdelista VB002_001_001.

Utrymmesobjekt i modellen ska i första hand ändras eller uppdateras (inte raderas och ritas på nytt) då varje utrymme får ett unikt ID (s.k. FMGUID) i objektmodellen. Detta ID används sedan i beställarens fastighetssystem för att identifiera utrymmet i fastighetsdatabasen.

2.3 Informationsutbyte

I projektets tillämpningsanvisning ska formerna för informationsutbyte beskrivas. Krav på ordning och exakthet är viktigt vid överlämning mellan personer och organisationer. Detta gäller främst vid informationsutbytet mellan projekt och förvaltning (åt båda håll) men kan vara till god nytta även inom projektet.

Man beslutar vilken information som ska utbytas genom att utgå från Tillämpningsanvisningens bilaga 5 och bilaga 4 för de olika disciplinerna och tar fram vilka delar som påverkas i det specifika projektet. Bilaga 4 beskriver vilka objekt (ex. utrymmen, byggdelar och byggdelskomponenter samt installationer) med objektegenskaper (se även värdelistor) som kravställs och Bilaga 5 beskriver informationsmängder (ex. dokumentation/filer) utifrån dokumentklasser i Bilaga 2. I en förteckning sammanställs den information som är med i leveransen.

Man fastställer hur informationen ska levereras och hur det ska dokumenteras, vilket görs enligt en leveransspecifikation som ingår i bilaga 5. Tänk på att filer som ska kunna uppdateras i förvaltningen måste levereras i ett format som bibehåller innehåll och struktur dvs ett neutralt utväxlingsformat eller originalformat.

Dessutom behöver man komma överens om när och var eller på vilket sätt informationen ska levereras till mottagaren. Det behöver var tydligt hur man kommunicerar när en leverans sker och vad som ingår i leveransen. Det åligger alltid den som ska leverera att utföra leveransen i rätt tid och på rätt plats. Leveransen ska verifieras av mottagaren. Det är även mottagarens ansvar att meddela om handlingarna inte stämmer överens med leveransspecifikationen.

I projektet kan det vara praktiskt att bestämma vilken information som ska levereras vid vilket skede (t.ex Systemhandling, Bygghandling, Relationshandling) då tillämpningsanvisning:förvaltning tydligt inriktar sig på relationshandlingsleveransen.

Om inget annat är överenskommet i projektet lämnas den slutgiltiga leveransen (relationshandlingar och förvaltningsdokument) till ansvarig projektledare. Vid slutleverans är det mottagaren av dokumenten som har ansvaret att se till att de blir åtkomliga för förvaltningen.

I de fall projektet berör konfidentiell eller mycket konfidentiell information är det extra viktigt att det är tydligt hur informationen får hanteras.

Backup ska göras varje dag på de filer som har förändrats. Varje vecka görs en totalbackup, som sparas i en månad. Varje månad görs en totalbackup som sparas i ett år. Backupen ska förvaras på annan plats än själva filservern.

2.31 Omfattning av informationsutbyte

I olika projekt och samarbeten krävs olika mycket information. Det är viktigt att den information som levereras är tillräcklig men inte för mycket. Även vid olika skeden under projektets framskridande behövs olika information och det gör att innehållet i leveranserna hela tiden uppdateras. Viktigt att tänka på är också att syfte och mål med olika information kan vara olika i olika skeden.

I relationshandlingen är det viktigt att vissa egenskaper finns dokumenterat på ett visst sätt för att det ska gå att läsa in i förvaltningssystemen. Detta gäller främst IFC-filen men även originalmodellen som vi önskar kunna använda vid nästa förändring. Den relationsmodell som levereras ska inte rensas från sådan information som kan vara viktig i framtida projektering, eller från information som behövs för att ”återskapa” de ritningar eller IFC-modeller som levererats.

2.34 Utbyte av modellfiler

Eftersom modellen är grunden till en digitaltvilling så är det mycket viktigt att de skapas och uppdateras på ett sätt som gör det möjligt att använda informationen i modellen. Av denna anledning är det bra att beskriva vad modellen ska kunna användas till i de fall man tar fram nya modeller. Tips för att uppfylla kravspecifikationen beskrivs i bilaga 6a -Revit, 6b –AutoCAD och 6c -Archicad. Modellen levereras i flera format för inläsning i förvaltningssystemen. Motsvarande information ska även levereras i startpaket.

Det är viktigt att man beslutar om katalogstrukturen för lagringen av filer samt läget på utsnitt eller layouter. Om inget är beslutat, bibehåller man strukturen från befintliga handlingar.

Hur modellen är orienterad i koordinatsystemet och förhållande till andra ritningar behöver fastställas. På befintliga byggnader får denna information inte förändras men det får gärna tas fram en relation till SWEREF99 TM och RH2000 om det inte redan finns.

Vid uppdateringar av befintliga modeller ska projektet besluta hur versionshanteringen ska skötas så att modell och ritningsdefinition samordnas.

Alla referensfiler och styrfiler ska redovisas och de ska även ha en beskrivning av användning, struktur och innehåll så att man kan hantera det rätt i förvaltningen och framtida förändringsarbeten.

2.36 Konvertering

Dokumentera vilka konverteringar som kan förekomma i projektet och vilka konverteringsprogram som ska användas inklusive version på format och programvaror. Kontrollera att konverterade filer inte påverkar de krav som ställts på leveransen genom att göra tester.

Leverans till förvaltning ska alltid innehålla originalfil och en publiceringsfil (Bilaga 5). I de fall originalet är en BIM-modell ska även en ifc-fil och en fi2xml av modellen skapas och levereras. Ifc-filen publiceras i en asset databas och används som en 3D:vy i förvaltningssystemet. fi2xml filen används för att läsa in polygonerna över NTA, BRA och BTA i vårt grafiska verksamhetssystem samt egenskaperna kopplade till objekt.

2.4 Gränsdragning och teknisk samordning i projektet

Tidigt i projektet behöver man komma överens om vem som ska ansvara för vilka delar av dokumentationen. Det kan som exempel handla om vem som fyller på information om objekt i en modell som någon annan i projektet har ritat. Det är bra med en gränsdragningslista om vem som har ansvaret för att det blir gjort och vem som har ansvaret för att informationen är rätt.

I projekt där flera discipliner bygger upp en gemensam modell kan man behöva skapa en gränsdragningslista så att man är överens om vem som ska göra vad för att modellen ex. ska kunna användas för areaberäkning.

Vid flera olika uppdrag i samma byggnad eller där flera projekt påverkar samma dokument är det även viktigt med samordning mellan projekten.

Det är även bra att komma överens om hur man ska hantera installationer och utrustning som ägs av hyresgästen som exempelvis installationsbunden inredning i form av dragskåp och anläggningar för specialgaser, passersystem och AV-utrustning som förvaltningen är i behov av att känna till.

2.5 Arkivering

Vid projektets avslut ska alla juridiskt bindande utskrivna original från projektet arkiveras. De filer som finns i projektnätverken rensas enligt ABK 96 och sparas som underlag för framtida projekt. Det digitala projektarkivet ska sparas hos Akademiska Hus AB i ett projektarkiv i ritningsarkivet. För att kunna hitta i projektarkivet är det viktigt att det finns metadata på filerna så att de är sökbara alternativt att det finns en väl beskriven struktur. Den struktur som finns beskriven i Bilaga 6 gäller för relationshandlingar för förvaltning.

Med fördel används en dokumenthanteringsplan eller en arkiveringsplan för att hantera de filer som tas in.

Förvaltningshandlingarna (Bilaga 5) som kravställts har som syfte att användas i förvaltningen och hanteras enligt en dokumenthanteringsplan för tekniskdokumentation.

3.1 Namngivning av filer

I projekt med befintliga ritningsnummer/filnamn ska man i början av projektet besluta hur man ska göra vid eventuell omdöpning. Det är väldigt viktigt att detta redovisas i en ritningsförteckning så att det går att följa vilka dokument som ska utgå och vilka som är omdöpta. Hur filer ska namnges finns beskrivet i Bilaga 6 Tillämpningsanvisning förvaltning.

Det är inte tillåtet att radera eller ändra ett filnamn, ta bort registreringsnummer eller ändra i en namnruta utan att man kommit överens om det i projektet och beskrivit hur det ska hanteras.

Filnamn bör inte innehålla parenteser eller andra tecken då det kan bli problem vid publicering i förvaltningen.

4.1 Kvalitetsaspekter och uppmärkning

Mängden information som ska levereras och vilka objekt som ska finns med vid leverans tas fram med hjälp av Bilaga 4 och 5 genom att skapa en leveransspecifikation för projektet. Kontroll på vad som levereras sker sedan genom att jämföra leveransspecifikationen och leveransmeddelandet.

4.12 Detaljeringsgrad

LOI- Level of information. Ska ha minst nivå 4.12 c klassning på förvaltningsdokumentationen.

Det är viktigt att både konstruktionsmodellen och Prefab-konstruktionerna som kanske skapas i olika programvaror kan läsas ut som IFC-fil med de objektklasser och egenskaper som behövs för att kunna göra en korrekt areamätning i A-modellen.

4.15 Aktualitet

Det är mycket viktigt att man alltid kontrollerar befintliga byggnader och anläggningar så att den dokumentation man utgår ifrån är aktuell. Ibland kan det krävas att dokumentationen först uppdateras till befintlig aktualitet. Det är även viktigt att kontrollerar vilken status den befintliga dokumentationen har så att man få med det vid planering och vet vad som behövs göras för att nå önskad status på handlingarna.

Ibland har exempelvis inte förvaltningens krav på inmätning och exakthet vid löpande underhåll varit den samma som man kravställt från projekt.

6.2 Struktur

Den struktur som beskrivs i Bilaga 5 och 6 gäller för relationshandlingar till förvaltning.

Mapp-/pärmstrukturen för Drift och Underhållsdokumentation kan med fördel följa mallen DoU 1-Mappstruktur samordnade DoU-instruktioner som finns beskriven i Instruktioner för drift och underhåll, branschstandard upphandling och innehåll, en publikation från Svensk Byggtjänst. Alternativt får beställaren ge förslag på den struktur man önskar ha i förvaltningen, dvs ofta den struktur man har använt historiskt i förvaltningen.

Strukturen för innehållet i en eventuell Projektportal och Projektarkiv tas fram i projektet och dokumenteras i syfte för användare att hitta och göra rätt.

6.21 Identifiering

Befintliga objekt som finns i förvaltningssystemen har en identifiering som skapats i förvaltningssystemet, en FMGUID. Denna GUID används för att identifiera objektet mellan de olika förvaltningssystemen och ska inte förväxlas med andra systemGUIDar. Vid förändringar i modeller är det viktigt att FMGUIDen på objektet lämnas ut i startpaketet och följer objektet.

Alla objekt i modellen behöver kunna identifieras enligt BIP TypeID. De objekt som inte är relevanta i förvaltning och saknar TypeID ska rensas från relationshandlingens modell.

För objektet utrymme motsvaras TypeID av rumsfunktionen Typrum. Utrymme identifieras även av egenskapen Rumsnummer/RumID.

Installationer ska ha egenskapen BIP SpaceName och SpaceNumber för identifiering av placering.

Alla system ska identifieras enligt BIP SystemID. Kombinationen TypeID, SpaceNumber/SpaceName och SystemID kan användas för att ta fram betjäningsområde för ett system. Identifiering med SystemID gör också att man kan koppla D&U-information på systemnivå något som är önskvärt i förvaltning.

6.22 Klassificering

Vid export av modell till IFC är det viktigt att dokumentera vilka TypeID som klassas som vad enligt IFCs klassning av objekten.

6.3 Modeller

Modeller kan skapas utifrån en punktmolnsscanning eller utifrån en arkitektritad projektering modell. Modeller med informationsobjekt ska vara strukturerade så att objekten modelleras med rätt plantillhörighet och inte spänner över flera våningar. Rätt verktyg ska användas till respektive objekt och fasader skall moduleras sammanhängande och inte delas upp i mindre väggbitar. Grundnivån på A-modellen är att följande objekt finns med:

• Väggar /Wall – modelleras och typindelas med avseende på väggtjocklek samt utvändig/invändig/schakt. TypeID enligt BIP och egenskaperna tjocklek och brandklassning.

• Glasparti/Curtain Walls - används vid entrépartier, invändiga glaspartier eller i fasad. TypeID enligt BIP och egenskapen brandklassning.

• Fönster/Window – ritas som ej öppningsbara. TypeID enligt BIP och egenskaperna bredd och höjd.

• Dörr/Door - ritas med fokus på öppningsmåttet och rätt slagning. TypeID enligt BIP och egenskaperna bredd, höjd och dörrbladstyp.

• Öppningar/Opening - TypeID enligt BIP.

• Bjälklag/Slab - moduleras plant på den höjd som det ansluter mot vägg. TypeID enligt BIP och egenskapen tjocklek.

• Pelare/Column - TypeID enligt BIP med egenskaperna bredd, längd eller radie.

• Undertak/Suspended Ceiling - TypeID enligt BIP.

• Yttertak/Roof - TypeID enligt BIP egenskap tjocklek och lutning.

• Trappa/Stair - TypeID enligt BIP med egenskaper om antal trappsteg

• Inredning/Furniture - innefattar WC-stol, handfat, diskbänk, bänkskivor, köksinredning, micro, spis, fläkt, ugn, diskmaskin, tvättmaskin, torktumlare, torkskåp, dusch, blandare, utslagsback, skåp, garderober, kapphyllor, kyl, frys. TypeID enligt BIP.

• Utrymme/Space - moduleras enligt funktionen, TypeID enligt Akademiska Hus typrumslista, egenskaper se värdelista för utrymme.

Utrymme som ej är scannat och därmed inte kan moduleras upp markeras som ett 3D-objekt.

6.4 Dokument

I startpaketet ingår en mallfil för nya ritningsunderlag. I mallfilen ingår en ritningsram och en namnruta. Beroende på vilken programvara man använder fungerar det lite olika men informationsfälten är de samma och ska fyllas i med följande information.

Figur 6.4a Ritningsstämpel.

1. Ritningens innehåll samt typ av handling. Här ska bl.a. planbenämningen anges
2. Ritningens originalformat (ex A1)
3. Skala i originalformat (ex 1:100)
4. Ritningsnummer enligt Bilaga 6 (ex A-40-1-1007)
5. Ändringsbeteckning kopplat till ändringstabell 15 (gäller inte Relationshandlingsritningar)
6. Projektörens uppdragsnummer
7. Ritad/konstruerad av
8. Handläggare
9. Datum för upprättande av original relationshandling ÅÅÅÅ-MM-DD (Akademiska Hus AB relationsdatum)
10. Ansvarig
11. Ändringsdatum ÅÅÅÅ-MM-DD uppdaterad relationshandling
12. Konsult, företagets namn samt orten där företaget finns.
13. Lokaliseringsfigur
14. Ritningens status (RELATIONSHANDLING)
15. Ändringstabell. Projekterande företag ska vara infört i anslutning till ändringstext. (OBS! Samma datum som under punkt nr 11)
16. Registerfastigheten (Fastighetsbeteckningen ex NORRA DJURGÅRDEN 1:45)
17. Byggnadsverksnummer (1 bokstav och 7 siffror ex M0017722)
18. Husdel (används i de fall detta finns)
19. Plan ID enligt bilaga 6. (Gäller endast planer med undantag för disciplin K)
20. Ansvarig part, enligt SS 32202 Allmänna beteckningar projektörer + eventuell numrering för att skilja flera projektörer av samma disciplin.
21. Innehåll, enligt SS 32271:2016 Tabell 1 Koder för ritningens innehåll.
22. Redovisning, enligt SS 32271:2016 Tabell 2 Redovisningssätt
23. Uppdragsbeteckning, AH projektbeteckning eller uppdragsnummer
24. Koordinatsystem (ex SWEREF 99 TM)
25. Höjdsystem (ex RH2000)

7.22 Redovisning av innehåll

Vid uppstart ska mottagaren specificera sina behov av egenskaper för objekt, detta görs med fördel genom att gå igenom värdelistorna per objekttyp. Värdelistorna visar vilka objekt med dess egenskaper som används i AH förvaltningssystems fastighetsdatabas och installationsdatabas. Vissa egenskaper styrs av förutbestämda värden som redovisas i klasslistor.

Vid avslut redovisas vilka objekt och egenskaper som ingår i projektleveransen. De fall där objekten inte är skapade i en modell för inläsning med fi2xml eller IFC publicering kan egenskaperna på objekten levereras enligt en excellmall.

I leveranser medföljer en handlingsförteckning. Kontrollera att alla utlämnade originalhandlingar finns med i detta dokument, även om de inte är uppdaterade eller ändrade. I de fall informationen är oförändrad finns detta som en anmärkning i leveransmeddelandet, detta för att mottagaren ska veta att dokumentet är återlämnat utan ändringar. Handlingsförteckningen ska även innehålla information om att den ersätter eller är ersatt av en eller flera andra ritningar.

Information om Cad-version samt applikationer inklusive version som använts då filen senast sparades ska finnas dokumenterad för modell.

Underlagen för disciplin Brand tas fram med stöd och hjälp av MetisWeb, i denna applikation hittar man allt från regler och anpassningar utifrån Akademiska Hus förutsättningar till beskrivningar kring det organisatoriska brandskyddet.

I löpande förvaltning händer det att leverans med handlingsförteckning utgår då det inte alltid behövs. Även vid denna typ av förändringar är det viktigt att ett underlag på förändringarna redovisas i ett underlag för relation. Informationen ska vara samlad och överlämnas till överenskommen person.