CoClass i praktiken: så använder du klassificeringen utan att det blir teoretiskt
Första gången jag öppnade CoClass-tabellen tänkte jag att det här är ju bara en lista. Sedan satt jag i ett projekteringsmöte där en konstruktör frågade om en spännkabel skulle klassas som komponent eller som funktionellt system. Då förstod jag att verktyget är enkelt. Tillämpningen är inte det.
Vad CoClass egentligen löser
CoClass bygger på ISO 81346 och ger ett gemensamt språk för objekt, egenskaper och funktioner. I praktiken betyder det att en pelare i Stockholm och en pelare i Göteborg får samma kod, oavsett vem som ritar och vilket verktyg som används. Det är där värdet ligger. Inte i kodlistan i sig.
Det som brukar gå snett
Tre saker ser jag återkomma i nästan varje projekt jag varit med i.
- Disciplinerna börjar klassa innan någon bestämt vilka koder som ska användas. Då sitter elsamordnaren med ett system och installationssamordnaren med ett annat.
- Klassificeringen behandlas som en exportknapp i slutet. Den ska byggas in i mallar och familjer från start, annars blir det manuellt arbete på tusentals objekt.
- Förvaltningen är inte med i diskussionen. De som ska ta över modellen vill ha klasser som matchar deras underhållssystem, inte den projekterande sidans logik.
Hur jag brukar börja
Jag plockar fram tio till femton objektstyper som täcker huvuddelen av projektet. Pelare, balkar, brunnar, stolpar, kanalisation, skåp. För varje typ skriver vi ner CoClass-koden, vilka egenskaper som ska vara ifyllda och vem som ansvarar. Det dokumentet är inte långt, men det förhindrar nio av tio diskussioner senare.
Egenskaper är viktigare än koder
Koden i sig säger ingenting för en förvaltare. Det är egenskaperna kopplade till klassen som ger nytta. Material, dimension, fabrikat, installationsdatum. En klassad pelare utan egenskaper är fortfarande en pelare, men nu med en kod på.
Koppling till förvaltningens system
Trafikverket använder TDOK som ramverk och har en egen mappning mot CoClass i sina krav. Privata förvaltare har ofta egna fastighetssystem som Landlord eller Pythagoras. Innan klassningen startar bör ni veta vilket system informationen ska landa i. Annars gör ni jobbet två gånger.
Verktygssidan
Revit, Civil 3D och Tekla har olika sätt att hantera klassificering. Det går att lösa med delade parametrar eller egna properties, men det kräver att någon faktiskt äger uppsättningen. I små projekt blir det BIM-samordnaren. I stora projekt behövs en dedikerad datasamordnare som äger informationsstrukturen, läs mer i vårt inlägg om skillnaden mellan rollerna.
En enkel testmetod
När klassningen är på plats: be någon utanför projektet exportera en lista över alla brunnar med material och dimension. Tar det mer än fem minuter har ni mer jobb kvar. Det är hela poängen med klassificering, att information ska gå att plocka ut snabbt.
Sammanfattning
CoClass är ett bra verktyg. Det blir användbart först när någon tar ansvar för vilka koder som gäller, vilka egenskaper som ska följa med och hur informationen ska användas efter projektet. Börja smalt, dokumentera enkelt och testa exporten tidigt.
Källor: Svensk Byggtjänst, CoClass introduktion (2023). ISO 81346 1:2009, Industrial systems, installations and equipment and industrial products. Trafikverket, TDOK 2015:0181 Krav på BIM-leveranser.
Relaterade tjänster
Läs även
Informationsleveranser enligt TDOK: vad Trafikverket kräver
Trafikverkets TDOK-krav styr informationsleveranserna i svenska infrastrukturprojekt. Men kraven kan vara svåra att tolka. Här reder vi ut det viktigaste.
Datadriven förvaltning: hur projektdata lever vidare efter bygget
Byggprojektet är klart, men datan lever vidare. Rätt hanterad projektdata kan spara miljoner i förvaltningsskedet.
