BIM OG UTVIKLING
Modellen skal brukes
lenge etter
søknaden
Vi bygger den for bruken, og lager objektene og verktøyene som ikke finnes. Bygget av fagfolk, for fagfolk.
Modellen er leveransen
Byggesak, byggherre, entreprenør og forvalter skal kunne bruke den direkte, og de andre fagene skal bygge videre på den. Det som er nok for den ene er for lite for den neste.
Problemet
Modellen bygges først, og så kommer spørsmålene om hva den skal inneholde. Da må informasjonen legges inn i noe som allerede er ferdig, og i hver revisjon etterpå. Hva den skal brukes til er som regel kjent lenge før noen spør.
Dette gjør vi
- Finner ut hva byggesak, entreprenør og forvalter skal gjøre med modellen
- Skriver det ned som konkrete krav før modelleringen starter
- Prosjekterer selv der modellen er poenget: veg og adkomst, trafikksikring og parkeringsanlegg
Neste steg
Fortell hva som skal bygges, og hvem som skal bruke modellen etterpå.
Problemet
Det tydeligste tilfellet er en skann-til-BIM-modell av det som står der fra før: den ser helt riktig ut, og er likevel bare flater uten objekter, etasjer eller egenskaper. Den holder til å se på. Skal noen hente mengder eller bygge videre på den, må den gjøres om. Det samme skjer i prosjekterte modeller når ingen har sagt hva de skal brukes til etterpå.
Dette gjør vi
- Bygger opp eller rydder i objektstruktur og klassifisering
- Gjør navngiving og egenskaper like på tvers av fag og filer
- Jobber på modellnivå sammen med fagene, uten å overta prosjekteringen
Problemet
En fil kan validere mot standarden og likevel mangle det mottakeren trenger, enten det er byggesak, byggherre, entreprenør eller forvalter: riktige objektklasser, utfylte egenskaper og romstruktur som stemmer. Hva som mangler står sjelden i avviket.
Dette gjør vi
- Finner ut hva mottakeren faktisk krever, ikke hva standarden sier
- Setter opp eksporten etter det, ikke etter standardoppsettet
- Klassifiserer og koder etter NS 3940 eller kundens egne krav
- Kontrollerer filen mot mottakerens krav før den sendes
- Eksporterer stikningsdata til maskinstyring, i samme referansesystem hele veien
Oppgaven bestemmer verktøyet
Det finnes nesten alltid noe, men det passer sjelden slik dere jobber, eller det er et helt system der dere trenger én del. Vi bygget våre egne av samme grunn.
Problemet
Fagkunnskap som ligger i ett regneark, hos én person, er sårbar. Den som laget det vet hvilke celler man ikke skal røre. Ingen andre gjør det.
Dette gjør vi
- Pakker beregningen i et verktøy som tåler å bli brukt av andre
- Utvider fagverktøyet direkte i grensesnittet dere allerede bruker
- Dere eier løsningen, kode og data
Problemet
Standardbiblioteket tar deg langt, så begynner omveiene: kantsteinen som ikke finnes, familien som mangler riktig parameter, normalprofilen som nesten stemmer. Kompromisset følger så med i hver eneste revisjon etterpå.
Dette gjør vi
- Bygger regelsett og objekter i Civil 3D (veg, landskap og terreng) og Revit
- Legger kravet inn i modellen fra start
- Lar modellen oppdatere seg selv når forutsetningene endres
Neste steg
Send oss regelsettet, objektet eller modellen som lager trøbbel.
Problemet
Navngiving, mappestruktur og eksportoppsett settes av den som starter, og neste prosjekt gjør det litt annerledes. Det som ble løst sist er ikke til hjelp denne gangen. Ingen merker det før noen slutter, eller før en leveranse skal gjentas.
Dette gjør vi
- Setter opp maler, navngiving og eksportoppsett som gjelder på tvers av prosjekter
- Skriver det ned, så nye folk kommer i gang uten å spørre
- Prøver det på et reelt prosjekt før det settes som standard
Hva skal modellen brukes til etterpå?
Beskriv prosjektet og hvem som skal ha den. Vi sier hva det krever.
Vi kommer fra utførelsen
Bygg, veg, landskap, VA og geomatikk. Vi vet hva modellen mangler når noen skal bygge etter den.
Vi er ikke konkurrenten deres
Vi går inn som underleverandør eller direkte, uten å ta over fagene deres.
Kort beslutningsvei
Spørsmålet går rett til den som avgjør.