IFC integrasjon i ERP system RAPPORT MODELLERINGSCASE, JUNI 2015

Transkript

1 IFC integrasjon i ERP system RAPPORT MODELLERINGSCASE, JUNI 2015 Lofthus, Astrid BIM 4. juni 2015

2 SAMMENDRAG Tittel: IFC integrasjon i ERP system Dato: Deltaker: Veileder: Oppdragsgiver: Stikkord / nøkkelord: Astrid Lofthus Bjørn Godager GC Rieber Eiendom BIM, Modellering, IFC, ERP Antall sider / ord: 44 /10342 Antall vedlegg: 2 Publiseringsavtale inngått: Nei Kort beskrivelse av denne avsluttende casen: Oppgaven består av to deler. En del hvor jeg har jeg laget en modell for et allerede eksisterende bygg i GC Rieber Eiendom sin portefølje. En del har jeg fokusert på prosessen rundt overgangen til nytt forretningssystem for avdelingen. Bygget er modellert og beriket med aktuell informasjon på objekter for å se på om denne informasjonen lar seg overføre med IFC-filen til valgte ERP løsning. Spesielt har det blitt fokusert på overføring av areal til bruk i arealberegning og leiekontrakter. Problemstillingen er interessant fordi det er en reel situasjon som vi vet må fungere i valgte ERP løsning for konsernet. Større bedriftene er med å sette standard for programløsninger for økonomisk administrativ forvaltning og vil igjen påvirke bruken av BIM på eksisterende bygg i forbindelse med forvaltning, drift, vedlikehold og utvikling (FDVU)

3 FORORD Denne rapporten er en avsluttende del av emne 4 i studiet BIM2001 modelleringscase H2014, årsstudium i BIM ved Høyskolen i Gjøvik. På bakgrunn av min stilling som teknisk tegner i GC Rieber Eiendom og GC Rieber AS sin beslutning om å innføre ERP i konsernet, var det naturlig å velge IFC integrasjon i ERP som emne i denne casen. Rapporten beskriver modellering og berikelse av BIM objekter til bruk i overførsel av informasjon i IFC-fil. Arbeidet med casen startet i januar 2015 og selve modelleringen er i hovedsak utført på fritiden. Det har vært en lærerik og spennende prosess men også veldig arbeidskrevende. Underveis har jeg deltatt på workshop i jobb sammenheng som en del av prosessen av innføringen til det nye forretningssystemet. Fokus har da vært på informasjons overføring og tegning. I disse møtene har det vært representanter fra prosjekt gruppen hos GC Rieber AS, for Advania og vår BIM konsulent, Ånond Viki. Jeg vil med dette få takke disse for god informasjon og god oppfølging i denne casen. Astrid Lofthus Bergen, 04. Juni 2015 SIDE 1

4 INNHOLDSFORTEGNELSE 1. Innledning... 3 Bakgrunn... 3 Problemstilling... 4 Avgrensning Modelleringsprosess... 6 FDV dokumentasjon og underlag... 6 Modellering i Revit... 8 Revit Family... 8 ID nummer... 9 IFC Tabeller / Schedule Legge til Parameter på objekt Modellering av Objekter Solibri ERP ERP leverandør Advania Løsningsforslag fra Advania Prosessen Kravstillinger Utfordringer Intervju av Advanina AS, ERP leverandør Intervju av Rom Eiendom AS, ERP bruker av dagens løsning Forkortelser og begreper Diskusjon og Refleksjoner Kilde Vedlegg SIDE 2

5 1. Innledning BAKGRUNN Jeg har lest at ERP system kan sammenlignes med dagens media kommunikasjon for private og da tenker jeg på Facebook. Dette er et sikkert media for å finne ut hva venner gjør, hvor de er og hvordan man kan kontakte de. Jeg vil trekke parallellen enda lenger å si at BIM fungerer på samme måte. Det er et godt oppslagsverk for hvordan bygget ser ut, hva er status og hvordan man kan finne kilden for å kunne ivaretar vedlikehold på bygget. Sammenlignet med mekanisk og olje rettet virksomhet kan en undre seg hvorfor dette har tatt så lang tid for bygge bransjen. Jeg har en forståelse av at i mekanisk og olje virksomhet er logistikken for datavarehus langt mere utbredt og lenger kommet en bygge bransjen. En mulighet er at det vært en helt annen kultur til investering og nøyaktighetsgrad til sikkerhet i denne bransjen. Krav til lønnsomhet vil være den samme i begge bransjer men utgangspunktet for innvestering har vært bedre. Selve begrepet ERP ble innført av forsknings- og analysefirmaet Gartner i Mange ERPløsninger var opprinnelig spesialisert på enten produksjon, økonomi eller HR. Nærmere årtusenskiftet ble det vanligere med bredere systemer som dekker flere ting. I Norge var Statoil tidlig ute med å anskaffe en SAP-løsning, mens offentlig sektor med helseforetakene (Sykehuspartner) og Forsvaret (via Los-programmet) har fulgt etter med milliardinvesteringer utover 2000-tallet. Det er fokusert mye på BIM i planlegging, byggeprosessen og som FDVU verktøy og hvordan IFC som åpent filformat skal gjøre denne kommunikasjonen lettere. Fokus på effektiv bruk av IT som kostnadsbesparende tiltak i byggenæringen tenker jeg vil være med å fremme IFC filen som mulig løsning for ERP systemer. Hvordan bygge bransjen blir drevet fram mot dette ser vi tydelig ut ifra hvordan de store offentlige byggherrer setter krav til leveranser i deres prosjekter. Forsvarsbygg, Helse Sør-Øst RHF, Helse Midt-Norge RHF og Statsbygg har sagt klart at fra 1. juli 2016 skal alle aktører i deres prosjekter skal bruke programvare som er basert på åpen standard. Også Stortingsmelding nr. 28 ( ) «Gode bygg for eit betre samfunn» gir oss en god peker på regjeringens bygningspolitikk for bruk av BIM som god satsing innen byggekvalitet, forenkling av byggesaksprosesser og et kunnskapsløft for byggesektoren. Miljøklassifisering av bygg Breeam er for fullt kommet inn i norsk bygge bransje. Som en del av fillevereansen for Breeam sertifisering er IFC fil utveksling nevnt som krav både som tekst format og 3D CAD/BIM fil. Målet for videre utvikling innen informasjons overføring må være å gjøre det mest mulig enkelt og kommunisere på tvers interesse og behov. Dessverre vil jeg si, er IFC filen fortsatt i utvikling og ikke ferdig utviklet til dette formålet. SIDE 3

6 PROBLEMSTILLING Bakgrunnen for oppgaven er å se på IFC som informasjons overføring fra tegning til det nye forretningssystemet som konsernet GC Rieber AS har bestem skal innføres fra For å gjennomføre dette skal alle byggene tegnes om fra Autocad ADT til Revit Denne beslutning er tatt uavhengig av ERP men ble ytterligere forsterket da dette ble aktuelt. Allerede i 2013 ble det bestemt at vi går for å tegne om eksisterende bygg til tegneprogrammet Revit. Beslutningen ble tatt på grunnlag av trenden i markedet for bygg og anlegg. Rådgivere og arkitekter er i en omstillingsfase hvor de går over til å bruke tegne program Revit eller Archicad som er et bygnings informasjons modellering verktøy (BIM). De ble innhentet pris for dette og BIM manual for GC Rieber Eiendom (heretter kalt GCRE) ble påbegynt. På grunn av den høye kostnaden de ble for å tegne opp igjen byggene, ble det bestemt å bare tegne opp de mest aktuelle byggen i første omgang. Etter beslutningen om å gå over til ERP er dette nå gjort om til alle bygg i GCRE sin portefølje. Beslutningen om å gå fra mange små systemer til et samlet ERP system ble startet allerede september Firmaet som skal levere ERP løsningen til GC Rieber AS heter Advania AS. Det har vært en lang prosess hvor mye skal på plass. Alle avdelinger har deltatt med egen representant og alle ansatte har deltatt i workshop underveis. I disse prosessene har det vært vanskelig og tenke i helt nye baner uten å sammenligne med de program-løsningene vi har i dag. Det faller veldig naturlig å sammenligne i stedet for å tenke nytt. Det er i dag 2 personer som jobber med dette på full tid. Det har vært nødvendig og ansette egen løsnings arkitekter for å få optimal løsninger på tvers av sektorene. For GCRE vil dette si at vi går fra mange små program og over til Pmax som er et komplett økonomisk og administrativt forvaltningssystem for eiendomsbransjen I Pmax har de lang erfaring med akkurat dette å kunne vise tegning som en viktig del av kontrakts arealet. Pr i dag har de basert det på et DWF fil format fra Autodesk og vist tegninger i viewer programmet Autodesk Design Review. Programmet er 12 år gammelt og har hatt sin misjon i disse årene. Spørsmålet er om filformatet er godt nok utviklet med de dynamiske funksjonene som et BIM verktøy krever. Advania har ingen erfaring med BIM verktøy og dets funksjoner og er innforstått med at bruk av IFC fil vil bety en endring i deres leveranser av viewer. SIDE 4

7 AVGRENSNING Rapporten inneholder en ferdig opptegnet modell med den objekts informasjon som er ihht til GCRE sin BIM og DAK Manual v0.2. Objektene vises i tabeller som er tatt ut fra Revit modellen. Det er lagt vekt på objekts ID Rapporten viser prosessen fra beslutningen om å tegne eksisterende bygg om i tegneprogrammet Revit, til overføring av informasjon fra modell til ERP. Objekts informasjon på leieareal er spesielt lagt vekt på for å se om IFC filen får med seg den informasjon som er nødvendig til bruk i ERP. Dette vil bli en videre reel fasit for hele bygnings porteføljen til GC Rieber Eiendom AS Det er også tatt med et intervju av leverandør for ERP løsningen og en et intervju av en bruker av systemet som er tilsvarende firma som GCRE. I Forprosjektet er det beskrevet at jeg vil prøve på eksport av Revit- modell til programmet Lumion for visualisering av leie areal. Dette er ikke tatt med. SIDE 5

8 2. Modelleringsprosess FDV DOKUMENTASJON OG UNDERLAG Bygget er tegnet av Arkitekt Røstøen AS og oppført i Samlet BTA for bygget er 1479 m2 over 2 etasjer med tak parkering. Taket består av trapperom og uteparkering: - 1 etg 718m2-2 etg 742m2-3 etg 748 inklusiv 724 m2 tak parkering. - Bygget er frittstående med gang bro over til nærliggende bygg, Bontelabo 2 som knytter en leietaker sammen med sine arealer i dette bygget. Bygget har ikke heis da det blir dekket av gangbroen over til Bontelabo 2. I dette bygget finnes heis som kan benyttes fra tak parkering om nødvendig. Tak parkering har kjørebro over til Bontelabo 2 sin tak parkering med nedkjøring derifra. Største delen av rapporten har dreid seg om å tegne en modell av Bontelabo 4 i modellerings programmet REVIT2015 med hovedvekt på og gi egenskapsintelligens til objektene. Det foreligger en 3D modell av bygget tegnet i Autocad ADT og min første tanke var å prøve utnytte dette ved å lage en IFC fil og importere denne inn i Revit. Det viste seg at dette var ingen lettvint løsning da Revit har alle sine objekter basert grunnleggende typer Family maler. Ved import av IFC filen i Revit følger ikke all nødvendig objekt informasjon med, naturlig nok siden den ikke allerede finnes i Autocad. Det er da fort å tenke seg hvor lang tid det vil ta og sette hvert av objektene inn i sin rette familie. Jeg valgte da å tegne modellen fra grunnen av med dwg fil som underlag for hver etasje linket inn som x-ref. Denne løsning ble valgt også dels for å ha mest mulig kontroll på at geometrien ble riktig gjengitt. SIDE 6

9 Figur 2.1. Viser eksport av IFC fil fra Autocad ADT importert i Revit med informasjon av objekt. Ved hjelp av tegningslister fant jeg underlag i FDV dokumentasjonen for bygget. Dels ble den funnet på IT-base Prosjektweb som er GCRE s dokumentasjons base for FDV, og noe ble funnet som papir dokumentasjon på fjern arkivet. Siden Autocad 3D tegningene ikke inneholdt riktig oppbygging av vegger, vindu osv. hadde jeg stor nytte av se på skjema, plan, fasade og detalj tegninger som ble levert ved overtagelse av bygget. Dessverre kan jeg vel si så fantes det dokumentasjon der som ikke var riktig slik bygget ble levert oss og det fantes dokumentasjon som ikke var oppdatert ihht. dagens situasjon. Ved videre opptegning av andre bygg er dette en god erfaring å ta med. Det er nå laget en mal for hvilken standard dokumentasjon som skal legges til grunn for videre opptegning av våre bygg. - Som bygget skjema tegning for dør og vindu - Som bygget detalj tegninger for innvendig vegger, utvendig vegger og glass felt. - Plan tegninger med vegg koding, papir eller digitalt - Fasade tegninger - Snitt - Dwg tegning med eksisterende polygon linjer for hvor hver av dagens leietakere leier - Bilder av bygget. SIDE 7

10 MODELLERING I REVIT Revit Family Gjennom å modellere i Revit har jeg fått grunnleggende kjennskap til oppbyggingen og logikken i Revit. Jeg er blitt kjent med mange av de viktigeste verktøyene, lære å lage gulv, vegger, vinduer, dører, trapper. Jeg lærte å skrive ut tegning, ta ut mengde lister og lagre til IFC. Det er bestemt at vi ikke skal lage byggene våre i fullverdig BIM da vi pr. i dag ikke har FDV system som kan gjøre seg nytten av dette. Jeg har lært å lage egne objekter i Revit gjennom Revit Family. Revit Family er objektene i Revit og er med og danne grunnlag for alle objekter. Disse kan være alt fra interiør, dører vindu, tagger, vindski, mm. og vil være med å gi objektene en unik ID som er avgjørende primærnøkkel til dette ene objektet. Hvert av objektene blir automatisk generert med nytt nr. innfor sin familie. Helt grunnleggende i Revit er familie type maler: - Vegg-baserte - Tak-baserte - Gulv-baserte - Himlings-baserte - Frittstående - Linje-basert - Flate-baserte (Face based) Hvert objekt i modellen er adressert til en av disse familiene, som igjen har en unik ID som IFCSpace, IFCBuilding osv, og egenskaper som IFCMaterialer, IFCPropertyset, osv. Alt som har med åpen BIM og gjøre er navngitt etter typisk informasjonsteknologiske normer og tradisjoner. Men objektets ID har ingen info som tilsier HVOR i bygget objektet befinner seg. SIDE 8

11 ID nummer Hva er Revit ID og hva er IFCGuid og hvordan henger de sammen. Ved bruk av verktøyet Filter and search i Revit Productivity Kit kan en henter ut informasjon om Objektene. Det meste av denne informasjonen finnes også i Schedule eller lister i Revit. I Revit finnes det tre typer ID av objekt; To Revit ID er og en IFGCGuid ID. IFCGuid blir automatisk generert ut ifra Revit sin ID og har ganske lang bokstav rekke i forhold til den interne ID i Revit. IFCGUID finnes IKKE i modellen. Den blir regnet ut som en del av prosessen når brukeren lager en IFC-fil. Når dette så er gjort en gang så kan man velge å lagre denne informasjonen i Revit modellen dersom en spesielt haker av for dette ved eksport til IFC. På denne måten eksisterer samme GUID nummer i Revit som det et ERP eller FDVU system leser. Man åpner dialogboks for IFC eksport, går på modify setup og krysser av for «Store GuidID after IFC Eksport. Da blir informasjonen skrevet til Revit filen. Figur 2.2. Viser eksport av IFC fil fra Revit som viser hvor man haker av for at informasjon IFCGuid skal bli lagret tilbake i Revit. SIDE 9

12 Hvordan man bruker ID nummer. Revit ID er kun unik i denne ene modellen. Så hvis en åpner en annen modell kan en finne igjen samme ID nummer på et helt annet objekt. Dette kan være et problem dersom du kryss sjekker to modeller. I et FDV system så går de gjerne inn på ett bygge, og da vet de at det er kun i denne filen de skal søke etter objektet med dette nummeret. Men hvis du skal kjøre et søk på tvers av alle eiendommene dine i IFC systemer som Solibri og du vil vite hvor mange håndslokkere har vi og hvilke etasje og rom står de i for eksempel. Da holder det ikke med ID. Da må en gå på den andre hardkodet ID hos Revit. Denne har et lengre ID nummer som er unik på tvers av alle modeller. I likhet med de andre to Revit ID ene blir også denne automatisk generert. Mark er en parameter som brukeren må fylle ut. Derfor er ikke dette riktig id for et ERP-system. De bruker enten den lang eller den korte Revit ID nummeret ved import i ERP systemet. Ved import av IFC-filen vil det bli IFCGuid som blir informasjons bæreren av objektet. Men for eksempel detektornummer som vil ha et original nummer for hver røykdetektor, det er et ID-nummer en legger på i en parameter i Revit og som vises i Mark som er et Instans Parameter. Vi kan si at de er menneskeskapt ID. Alt som ikke har et nummer som er manuelt laget som detektor nummer, så er det best å bare la programmet generere det automatisk i IFCGuid. Det går på automatikken, det går raskere, man slipper å tenke på det, det likt hver gang. Disse er programskapte ID er. Figur 2. 3 Enkel database modellert og utformet i Microsoft Access 2007 SIDE 10

13 Objekt ID er er viktig i eksport av IFC filen, en annen ting er plasseringen eller nullpunkt av selve modellen i forhold til x,y og z koordinater. For å få en best mulig forståelse av hva BIM er så er det viktig å forstå oppbyggingen av intelligente objekter. En enkel forklaring på dette er å sammen ligne BIM objektet med leie av film. Informasjonen om deg ble matet inn på datamaskinen slik at kundenummeret entydig henviste til deg som person. Tidligere er den samme prosessen gjort med alle filmene i deres arkiv. Figur 2. 4 Enkel database modellert og utformet i Microsoft Access IFC IFCGuid er grunnleggende informasjon ved eksport av IFC fil som er hard kodet og genereres automatisk. Hardkoding vil si at den ikke lar seg endre og vil følge objektet til det ikke lenger eksisterer. Dette er først og fremst en filtype, men også et grensesnitt, eller rammeverk for lagring av bygningsinformasjon. Har man først nevnt IFC så må man forklare i sin helhet hva dette er og da er det naturlig å nevne IFD og IDM som er tett knytt opp til bakteppet av IFC. IFC er et åpent filformat for utveksling av bygningsinformasjonsmodellering som er tilgjengelig som ISO standard filformat standard både som tekst og xml basert. IFD er en standard for sortering og koding av objekttyper innen åpen BIM, sertifisert ISO Det er IDM som sier hvilken informasjon som skal til hvem til hvilken tid og kvalitet. BIM = IFC + IFD + IDM SIDE 11

14 Tabeller / Schedule I Schedule har kan man liste opp alle objektene som modellen består av. Som vist nedenfor er dette til stor nytte for å danne seg et raskt overblikk i modellen. Det er også her mulighet for å lage materialparameter og fylle ut disse, plassere de i et bestemt rom og etasje. Her kan man velge disiplin og ulike typer parameter i forhold til faggrupper. Vi kan altså legge til andre parameter enn det som styrer størrelse på objektet her. Disse parameterne kan man redigere videre i materialparametere, og knytte til tekstur om man ønsker. Dette er begge to en metode for å legge til parametere. Forskjellen er om man senere kan få Revit til å automatisk legger verdien (f.eks. slokkemiddel) på tegningen som tekst. 1. Forekommer ikke i lister og koder 2. Delte parameter. Kan deles av flere prosjekter og familier, og vises i lister og koder. Figur 2.5. Viser hvordan man oppretter Parameter Properties. SIDE 12

15 Legge til Parameter på objekt. Håndslokkeren er lastet inn i Revit ved hjelp av BIM Object browser, den inneholder informasjon som lar seg redigere. Gevinsten er at en slipper å modellere geometrien på nytt. Og tilpasse FDV informasjon etter type som er brukt på bygget. 1. I Property kan en legge til parameter i den aktuelle Family Types 2. Viser hvor man går inn for å legger til Parameteret 3. Her velger en hvilke type parameter samt setter tekst på hva parametere gjelder 4. Dette er tekst Parameter som nå vil vise i Properties og som kan fylles ut med gjeldende tekst. 5. Viser hvor man finner Family Category for valgte objekt. Dette er viktig for at objektet skal listes opp i riktig liste eller Schedule/Quantities. Figur 2.6. Viser Properties for Objekt. Håndslokker SIDE 13

16 Modellering av Objekter Modellering av vegger Vegger er modellert med Basic Wall og Curtain Wall. Veggene har Type IfcGUID og utover det er det lagt inn IFC-egenskaper for Structural Function; bærende eller ikke bærende. Function; innervegger eller yttervegger. Brann og lydklassifisering der det fantes. Figur 2.7. Viser Hvor Properties Parameter for vegger SIDE 14

17 Modellering av dører Av FDV-data for dører og porter er det lagt inn generell beskrivelse som ble funnet på FDV dokumentasjon. Eventuelt lyd-krav, brannkrav, karm materielle og låssystem dersom jeg fant dette beskrevet. I tabellene for dører har jeg tatt med hvilke rom nr. døren tilhører. Dører tilhører det rommet de slår inn i, dvs. ToRoom. Der vises også hvilke type rom det er og hvem som er leietager. Figur 2.8. Viser Properties Parameter for dørene i bygget. SIDE 15

18 Modellering av vindu Innvendig vindu er modellert med Family Window. Ett vindu ble laget for hver type / utseende og ved hjelp av parameter har en mulighet til å endre dimensjoner og tilpasse lengde og bredde etter behov. Vinduene kan kopieres og navngis etter type, bredde og høyde. Figur 2.9. Viser Properties Parameter for vindu som kan endre høyde, bredde osv. Figur Viser Properties Parameter vindustabell med utdrag av type vindu. SIDE 16

19 Utvendig fasade glassfelt ble modellert på annen måte da flere av felten går over flere etasjer. Med litt prøving og feiling for å finne den beste måten å tegne opp bygget bestemte jeg meg for å bruke «Curton Wall» Family. Dette er i utgangspunktet en vegg, CurtonWall vegg som en setter inn hjelpelinjer for å dele opp i riktig inndeling og deretter setter «sprosser, vindu osv inn. Det er fort å lage og enkelt og kopiere videre. Det er greit å ha mulighet til å skape objekter man ikke har i standard biblioteket. Gjør du en endring i parameteren i Properties til glassfeltet vil alle objekter med samme Family type bli oppdatert, dette gjelder for Type Properties ikke Instance Properties. Ulempen er at den er ikke dynamisk når du gjør en endring som ikke er lagt inn som parameter i Properties. Da må du ta runden og oppdatere alle i bygget. Dette til tross så vil jeg si at det forenklet arbeidet siden her er mange glassfelt i bygget. I etter tid har jeg lært at jeg kunne laget et glassfelt og gruppert denne, deretter kopiert den rundt. Man kan da endre en gruppe, lagre den og alle vil bli oppdatert. Innvendige glassfelt ble laget som vanlig Window Family og vil bli listet opp som dette i skjema. Figur Viser Properties for valgte «Curton Wall» glassfelt. SIDE 17

20 Modellering av dekker Dekker ble laget med System Family: Floor og lagret som Type etter hva som stod beskrevet i detaljtegninger for bygget. Jeg har ikke bygget opp sjiktene med lag og skrevet inn forklarende teks med hvilken type dekke det er. Figur Viser Properties for valgte dekker Figur Viser snitt av Bontelabo 4 for å vise dekke. På taket er det inntegnet dobbelt som beskrevet i FDV dokumentasjonen. Det er ikke lagt inn ytterligere informasjon utover at jeg har tegnet inn riktig sjikt inndeling. Type viser hvilket dekke det er. SIDE 18

21 Figur Viser snitt av dekke. Modellering av trapper Figur Viser Properties for valgte trapper Modellering av areal Areal er det eneste objektet som er bestemt skal overføres til bruk i annet system. Denne informasjonen skal nyttiggjøres i ERP system som GC Rieber AS skal innføre i konsernet fra år Denne informasjonen er grunnleggende for kontrakter knytt opp mot den enkelte leietager i bygget. Vi skiller på areal for ett rom og areal for leietaker. Romarealet følger innvendig gulv-list for hvert enkelt rom og kan være nyttig som informasjon ved praktisk bruk av størrelse på rommet, vaske areal, total areal på vegger, energi osv. Arealet for leietaker følger Norsk Standard NS3940:2012 punkt Bruttoarealet for et rom. - «Bruttoarealet for et rom beregnes fra utside yttervegg eller til midt i delevegg og inkluderer utside utvendig avsluttende overflate». SIDE 19

22 Arealene har forskjellig kategorier som igjen utgjør grunnlag for arealberegning av bygget. Areal som knyttes mot kontrakts kunden vil være et eksklusivt leie areal mens areal som er felles for alle kontrakts kunder vil være et felles areal for bygget. Typisk felles areal er; gang, heis, ventilasjon, bossrom, sykkelstall, felles dusj anlegg osv. Disse arealene genereres det automatisk et IFCGuid nummer. I tillegg har disse en ID som fortløpende genereres og som følger med areal objektet over i ERP systemet. Det er den sistnevnte ID en som benyttes i knytningen mot tegning. Sletter en et areal i Revit og oppretter to nye genereres det automatisk to nye areal som blir eksportert til Pmax. I Pmax vil arealene bli oppdatert med påslaget for felles arealene. Figur Viser Properties for valgte rom skjema. SIDE 20

23 Kategori Rooms vist ved hjelp av Revit productivity Kit Her vises blant annet ID som automatisk blir tillagt et areal og IfcGuid som begge er hardkodet og som automatisk generes og ikke kan endres på. Figur Viser Properties for rom skjema. På Type vises rom nr. som er manuelt skrevet inn. SIDE 21

24 Modellering av branndokumentasjon Røykdetektorer og Manuelle meldere er en av de objektene som er bestemt skal modelleres. De er lagt inn med nummer og vil bli oppdatert fortløpende. På sikt skal de bli veldig interessant å se om disse objektene vil komme FDV til nytte. Det er enda tidelig å si noe om hvordan en kan gjøre seg nytten av dette i ERP systemet. Objekter for håndslokker, markeringslys og røykdetektorer har jeg importert inn i Revit. Nedenfor vil jeg vise hvordan en med hjelp av parameter lager en ID. Dette gjelder egentlig for alle objekter i modellen. Rømningsveier er foreløpig bestemt at vi har liggende i dwg format. Det er bestemt at vi fortløpende lager dwg av plan tegning som vi ved hjelp av x-ref legger som «geometri» underlag branndokumentasjon tegningene. ID-merkingen ble hentet ut fra branndokumentasjonen. Figur Viser Properties for valgte Branndokumentasjon SIDE 22

25 Modellering av innredning Innredning for fast inventar som wc, vask og dusj er lagt inn i bygget, det samme gjelder for kjøkken. Dette er i tråd med hva vi har utarbeidet som standard for bygg modellene våre. Objektene er beriket med den informasjon som er tilgjengelig. Med IFCGuid og romnummer overføres dette til et FDV system dersom det blir aktuelt i fremtiden. Løst inventar er tatt med i noen rom. Som standard skal ikke dette modelleres men ved prospekter og tilrettelegging for kunde vil det fylles på. Rent praktisk er dette for å vise Rådgivende Ingeniører for Elektro bl.a. hvor stikk for data og lys armatur for kontorpult skal monteres. Figur Viser Properties for fast inventar. SIDE 23

26 3. Solibri Modellen er blitt sjekket i Solibri Model Checker. I dag har GCRE ikke lisens på denne programvaren men det har vært diskutert på Prosjekt avdelingen og det ble gjort en test for å se om den lot seg gjøre å laste ned programmet på Serveren for konsernet slik at de som ønsker kan benytte dette. Vi fant ut at det ikke gikk. Det ble da bestemt at hver og en skal ha installert programmet på sin egen bærbare pc. Solibri Model Checker 9 blir benyttet av konsulenter og entreprenører i bygge møter og ingeniører ved vår avdeling ser nytten av denne. I oppgaven bruker jeg Solibri for å sjekke de bygningsmessige konstruksjonene. Jeg har brukt regelsett som finnes i programmet. En IFC-fil ble eksportert ut fra modellen, versjon IFC 2x3 Coordination view 2.0. Jeg avdekket en del konstruksjons feil som doble vegger, doble gulv osv. så den var til stor hjelp ved ferdigstillelse av modellen. Figur 3.1. Viser sjekk av IFC fil med valgte regelsett i Solibri. SIDE 24

27 4. ERP ERP er forkortelse for Enterprise Resource planning. Dette er en internasjonal betegnelse for programvare som støtter opp om flere av en bedrifts virksomhetsområder, som produksjon, lager, salg, innkjøp og økonomi. Dette vil si å samle data et sted, som er oppdatert til enhver tid i en felles database og enhetlig brukergrensesnitt på tvers av modulene. Gevinsten av dette er at man unngår unødvendig dobbel lagring av informasjon som igjen skal føre til at en kan ta bedre beslutninger. ERP leverandør Advania AS Konsernet Advania AS er det 9. største IT-selskapet i Norden med 1100 medarbeidere og 20 kontorer fordelt på 3 land. Advania har kunder fra hele verden og omsetter for over 1 milliard norske kroner. Pmax er en komplette løsning for økonomisk administrativ eiendomsforvaltning levert av Advania som GCRE skal ta i bruk. En bedrift som vurderer å kjøpe en ERP løsning bør tenke gjennom noen spørsmål på forhånd som for eksempel : - hvor mye dobbelt arbeid gjøres i bedriften til daglig?, - hvor mange forskjellige systemer / programmer bruker bedriften til daglig? - Hvor enkelt kan du følge med på hva som skjer i din bedrift? - hvordan utveksles informasjon mellom ansatte, - Hvordan holder du styr på ordrer og fakturaer? - Hvordan har bedriften sporing på lageret? - Har ledelsen den informasjonen de trenger for å ta gode avgjørelser for å legge gode planer for bedriften? Det å koble tegning til Pmax er veldig tids besparende. De som jobber i administrasjonen og økonomi i sektor for GCRE kan opprette leiekontrakter uten å spørre den som sitter på tegning hvor i bygget kontrakten skal knyttes mot. De kan se etasjer, og knytte leietakere tilhørende kontrakt og selv legge på informasjon om moms eller ikke momspliktige leietagere. For GCRE medfører dette omlegging i forhold til dagens situasjon hvor de forskjellige funksjoner er fordelt utover flere programmer. For GCRE vil det være tidsbesparende og lett ha tilgang til «hvem leier hvor i bygget». SIDE 25

28 Løsningsforslag fra Advania AS Vi er blitt vist fra Advania AS hvordan strukturen i Pmax er satt opp og beskrevet overordnet hvordan løsningen er tenkt å bli. De workshop'ene som vi har hatt i etterkant kan ha ført til at noen deler av løsningen er blitt annerledes enn beskrevet i dette dokumentet, men mye vil være relevant fortsatt. Advania bruker i dag DWFx-formatet som tegnings visning. Pmax oppbygning, ble som vist i skisse nedenfor, gjennomgått. Først ble alt gjennomgått, så ble fokus satt på «eiendom, områder og leiearealet inkludert tegning». Kontrakt og leieareal strukturen ble gjennomgått Figur 4.1. Viser Pmax struktur for oppretting av kontrakt. En viktig faktor rundt håndteringen av tegninger er kontroll med versjoner. En enkel og trygg metode er å la alle filer eksportert fra Revit til IFC ha en gyldig «fra dato» som siste del av filnavnet. Når denne filen blir erstattet i PMAX kan man der sette en «gyldig til» dato. En slik løsning blir en mere fremtidsrettet og mindre komplisert SIDE 26

29 Prosessen Prosessen frem mot endelig resultater for integrasjoner og tilpasninger har vært krevende og er enda ikke ferdig. Det har vært workshop på tvers av sektorene og spesifikt for GCRE. Som er nevnt i Forprosjektet var det satt opp en ERP workshop for Pmax i uke 8.: Agenda for ERP Review : PMAX, Project og Service ,: - Oversikt Pmax struktur - Eiendom, areal, leieobjekter inkludert tegning - Kontrakt og leieobjekt - Fakturering - Regulering - Avregning - Mva håndtering Det ble vurdert tre måter og overføre tegnings informasjon fra Revit til Pmax. 1. Ved fortsatt bruk av dwf filer fra Revit. Dette vet vi ville vert en kortsiktig løsning. 2. Ved direkte integrasjon av Revit modell i Pmax. Denne løsningen ønsket ikke GCRE IT og gå inn på fordi den krever mere tilpasning og vedlikehold ved for eksempel oppgradering av programvare. En annen viktig faktor er at det er egentlig sporadisk at selve arealene blir endret i en kontrakt. 3. IFC-filer fra Revit som pr. i dag ikke kan vise geometri i Pmax Som et endelig resultat er det bestemt IFC-filen skal brukes som informasjon overførings fil til Pmax. Utgangspunktet for visning av tegning har vært å benytte view er/tegningsviser som brukes i Pmax i dag. Dette har vist seg er problematisk da Advania benytter en viewer i dag som ikke vil være supportet i fremtiden og som ikke har funksjoner GCRE har satt som krav. Det ble konkludert etter råd fra vår BIM konsulent hvor han sier at fra 2013 supporterer ikke Autodesk DWFx-formatet. Det å basere seg på dwf formatet er kortsiktig løsning. Det er en løsning som fungerer nå, men den vil før eller siden krasje når det kommer nye Windows oppdateringer. Det vil ut inneværende år, muligens også ut neste år, være mulig å eksporter DWFx-filer fra Revit og AutoCAD slik sett vil PMAX sin løsning fungere i sin nåværende form. Det en gjør av tilpasninger i Revit-modellen for integrasjon mot PMAX sin nåværende løsning vil kunne videreføres når ny viewer kommer på plass. SIDE 27

30 Vianova TIPS FM har landets fremste kompetanse på dette feltet og er selv i en prosess med å bytte ut vieweren i sitt eget produkt, BYGGEWEB. Ut ifra dette rådet har Advania valgt å benytte Vianova TIPS FM sin kompetanse og vil derfor gå for samme tegningsviseren/vieweren. En oppsummering fra siste møtet sier at Vianova TIPS FM enda ikke har landet på hvilken tegningsvisning/viewer de vil benytte i sin Byggeweb løsning Det er bestemt en «test kjøring» til høsten. Bekymringen til Advania går ikke på det tekniske men at de får det de skal ha, i tide, i vårt prosjekt. GC Rieber sin konklusjon fra møtet: Det er ikke kritisk at denne funksjonaliteten ikke er på plass til avtalt tid. Vi avventer derfor til høsten i påvente av Vianova Tips FM sin beslutning på hvilken viewer de vil benytte fremover. Bakgrunnen er at denne funksjonen er veldig isolert til selve tegningsvisningen, og en ser ikke at dette vil påvirke testingen av den øvrige funksjonaliteten i PMax løsningen. Noen punkter er satt opp fra GC Rieber sin side: - Funksjonaliteten som mangler i dagens tegningsvisning i PMax, er i hovedsak (ref. GAP som er listet i vår kontrakt med Advania): - Vise leietakernavn på farget areal i tegningen - Risikovurdering - noen momenter: Det er nesten et helt år før Eiendom starter å benytte AX/PMax løsningen, og i den første perioden vil en uansett være opptatt med andre og mer kritiske funksjoner. Ikke stor risiko om en ikke får tegningsvisningen på plass til akseptansetestinen i høst, og heller ikke dersom dette i verste fall skulle mangle ved oppstart. En vil kun mangle funksjonalitet for visning av leietakernavn på arealer i teningen, mens resten av løsningen vil virke. SIDE 28

31 Kravstillinger Det er lagt frem krav fra GCRE om at vi vil bruke IFC filformat for overføring av data fra Revit til ERP systemet. Det er et krav fra GCRE at tegning må vises i Pmax Advania ble spurt om de kunne utvikle en ny viewer som viser tegning i Pmax, siden den de bruker i dag vil gå ut om ikke lenge. Dette har de sagt ja til. De har kontaktet Vianova TIPS FM som skal utvikle viewer som Advania kan videre utvikle tilnærmelsesvis slik viewer de har i dag. Vi ser for oss tre måter og visualisere areal på: - Leietager. Med det menes navn på leietaker - Kategori. Med det menes leieareal, felles areal bygg, ikke målbart areal osv. - Type. Med det menes kontor, lager, wc, ventilasjon osv. Figur 4.2. Viser hvordan arealene i Bontelabo 4 er vist i Fenistra AS. Et forvaltningssystem for eiendom som GCRE bruker i dag. SIDE 29

32 UTFORDRINGER De største utfordringene har vert problemstillingen rundt dette at vi ikke får sett tegning i Pmax med overføring av IFC-filen siden vieweren ikke er ferdig utviklet. Vi har oversendt IFC-filer og fått positiv tilbakemeldinger på at Pmax kan lese denne type fil. En annen utfordring har vært og definere hva som skal gjøres i Revit og hva som skal gjøres i Pmax. Det er nå endelig bestemt at i Revit opprettes arealene som viser kategori og type. I Pmax blir disse arealene kategorisert. Det er også naturlig at de som oppretter kontrakt i Pmax markerer kontrakten som moms pliktig eller ikke moms pliktig. SIDE 30

33 Intervju med leverandør av ERP og bruker av ERP. Jeg har intervjuet en representant fra Advania AS og en representant fra Rom Eiendom AS og på denne måten prøvd å få en bedre forståelse av prosessen rundt forretningssystemer. Jeg har spesielt stilt spørsmål om problemstillinger rundt filoverføring, tegning / BIM og IFC filformatet. Spesielt for Rom Eiendom AS har jeg stilt spørsmål om hvordan de forvalter FDV dokumentasjon og hvordan de bruker tegning til arealberegning og leiekontrakter. SIDE 31

34 INTERVJU AV ADVANINA AS, ERP LEVERANDØR Intervju med Bjørn Sand, løsnings arkitekt hos Advania Blå tekst er spørsmål stilt til Bjørn Sand av Astrid Lofthus Vi ønsker å benytte IFC-filformat som informasjons overføring fra Revit. Hvordan gjør dere dette i forhold til andre kunder for å slippe gå inn på for mye skreddersydd søm til GC Rieber AS? Dette åpne filformatet IFC, enten det er tekst basert eller xml basert, det kunne vi utmerket godt ha lest inn i vår løsning og opprettet bygg, etasje og rom ut ifra det. Men problemet med Axapta er at det er laget for å være en ERP løsning. Et system hvor du har kunder og bilag og kontoplan osv. Det klarer ikke vise grafiske elementer type vektor grafikk som du har i en tegning. Det klarer ikke den løsningen å vise i det hele tatt. Derfor så valgte vi å gå veien om en Viewer, et visnings program som pr. nå er Autodesk Design Review. Da er det slik at starte visnings programmet med informasjon om hvilken tegnings fil som skal vises. Tegnings fil for en etasje til eksempel. Og da, siden vi uansett må ha et program i mellom, så har ikke vi laget noen rutiner for å lese selve bygningsinformasjonen direkte fra ISO standarden. Vi kan godt lese IFC og få inn samme informasjon som vi får i dag men vi klarer ikke å vise det grafisk. Med den nye vieweren så lar det seg gjøre forhåpentligvis. Vi har over flere måneder prøvd å få kontakt med VIANOVA Tips FM men de har ikke bestemt seg enda. Den siste informasjonen fra 8. mai er at de har tre alternative viewere og de vet ikke hvem av de de vil gå videre med. Lars Jørgen har kontakten mot VIANOVA Tips.FM. Men viss det Ånond Viki sier er riktig, han sier noe om at en kan ta vare på en GUIDE referanse, Vi kan begynne å tegne i Revit uavhengig av det her. Dette er jo et viktig valg for Tips så Tips må være sikker på å gjøre det riktige. Ingen ny dato for valg av viewer er satt. Hva tenker dere er effektiv bruk av IT systemer?: Når du snakker AX så er det en stor løsning som inneholder mange delmoduler. Så er det frittstående Apper som du kan koble til AX for eksempel. Time registrering. At du kan gjøre det via en telefon. Så selve ERP løsningen er en stor løsning. Består ERP seg av mange APPER? Det er riktig å si at ERP er en stor løsning hvor Apper kan hente ut data fra løsningen. En er lite program som gjør en bestemt funksjon. Da kan forskjellige brukere ha de Appene de har brukt for og de skal bruke, så slipper de å se alt. En kan godt si at dette er å optimalisere IT. Når en tenker effektiv bruk av IT når det gjelder tegning så er en effektivitets gevinst er jo at en slipper å registrere mange ganger. Dersom jeg tegner og tildeler det nummeret for rom SIDE 32

35 eller soner, da slipper du å registrere det samme på nytt inne i ERP løsningen. Informasjonen skal kunne gå begge veier. I Pmax kan en eksportere ut informasjon vi Excel og importere dette inn i Revit. I tegninger kan en da se hvem som er leietager på hver etasje, det er også effektivt at jeg slipper spørre andre. I Revit oppretter du selve leiearealet, men selve knytningen av areal på hvem som leier hvor, blir gjort i Pmax av praktiske grunner. Det er de som oppretter kontraktene som gjør dette samtidig som de vil ha kontrollen på hvem som er moms pliktig. Det er et revisjonskrav at vi skal kunne dokumentere. Det å koble tegning til ERP er veldig besparende, en slipper nitidig dobbel registrering. Og at de som jobber i AX kan se data uten å spørre de som sitter på tegning. De kan se etasjene, at de kan vise det til Skatt Vest når de kommer på besøk. Har dere brukere av Axapta som benytter tegning til andre formål en leieareal, for eksempel til vaskearel? Nei, det har vi ikke. Rom Eiendom benytter Lydia som sitt drift og vedlikehold system. Lydia leser dwg filer og så kan de legge på selve tegningsinformasjonen i Lydia som har tegnefunksjonalitet i seg. Men da bryter du linken mot originalen, informasjonen er ikke toveis. En vil alltid ajourholde tegningen i BIM-verktøyet i motsetning til å ta en kopi av dwg fila og lagrer denne i et eget format. Da har man to versjoner av samme tegning. En annen problemstilling er at vi mottar forskjellig fil-format fra forskjellige tegneverktøy. En IFC vil da være en god løsning siden den er en åpen standard. Den kan både gi og motta informasjon. Vi er da prisgitt et viewer program imellom, men vi kunne godt ha lest IFC filene og opprettet det som ikke er grafisk. Byggene med etasjer, rom og størrelsen. Men så lenge en ikke ser tegningen så er det ikke så praktisk. Har Advania mange underleverandører?: I Advanina har vi ikke underleverandører i den forstand, vi har samarbeidspartnere i de tilfeller hvor vi har felles kunder. Rom Eiendom og Lydia er et godt eksempel på det. Vi har jobbet sammen siden Lydia er et fullt drift og vedlikehold system. Og inne i Pmax så ser du ikke tegning i Lydia. Pr. nå så er det en database integrasjon. Det virker på den måten at en tegner etasjer i Lydia, dvs. dwg tegning kommer fra Autocad. Vi har et bygg i Lydia med mange etasjer og en sam tegning pr. etasje. Når her blir gjort en endring så kan man i Pmax hente arealer inn fra tegningen. Så vil Pmax fortelle til Lydia hvem som er leietakere på de forskjellige arealene. Slik at i Lydia vil en se tegning med leietakerinformasjon og i Pmax vil en bare se arealene hvor store de er. Det er som regel de samme personene som sitter i begge systemer og har to skjermbilder åpne samtidig. IFC har ikke vert snakk om i denne sammenheng av den enkle grunn at Lydia gir Pmax det de skal ha. Det har ikke vert snakk om et spesielt grensesnitt med bakgrunn i hvilke behov Rom Eiendom har. Hvordan er Pmax bygget opp?; SIDE 33

36 I Revit blir det lagt på informasjon Pmax kan nyttiggjøre seg av. Dvs. informasjon om klassifisering og hvilke type areal som er i hver etasje. Inne i Eiendom, Pmax, opprettes det et bygg med nummer og navn. Det er noe mere informasjon også men det er det som er nødvendig for regnskaps avdelingen sin del og vite og vite hvor kostnadene hører hjemme. Videre så forteller det hvilke etasje det er i bygget, 1, 2 og osv. Og så per etasje så trykker de en knapp og får opp en Windows utforsker og peker på hvilken tegning som hører til etasjen. Da har vi fått en kobling mellom etasje og plantegning for etasjen, videre så trykker brukeren på en knapp for å opprette soner og arealer inne i etasjen. Da leser Pmax dwf filen og trekker ut informasjon. Når det er gjort så kan en opprette leiekontrakter og knytte de til soner i etasjen. Dette er hoved essensen i hva som skjer. Videre kan man på et gitt tidspunkt kan en ta opp tegning for en etasje og se hvilke soner som er utleid og hvem som ledige. Slik virker det i dag. Så sant arealet ikke er forandret ved ny leietager kan en videreføre et leieareal til en annen leieareal. Revit lager kun nye areal dersom størrelsen på selve arealet endrer seg. Det vil si at dersom tegningen endrer seg, en vegg går ned eller kommer opp så skjer det i Revit i ERP løsningen. All fysisk informasjon kommer fra Revit i form av IFC eller som i dag, dwf. Momspliktige leietakere håndteres i Pmax i utleiemodulen. Det har ingenting med tegning og gjøre. Denne informasjonene kan la seg gjøre å tilbakeføre til Revit. Det er dette vi må samarbeide med Vianova om på et senere tidspunkt. Vil DWF-filen fortsatt leve videre?: DWF filen vil bestå men Autodesk vil ikke bli videre utvikle/komme i ny versjon design Review. De snakket om å kunne vise veldig store dwf filer og at de da vil gjøre det ut i en sky løsning i Autodesk 360. Selve formatet har de ikke tenkt og legge dødt. Er det mulig for Advania og hente inn informasjon fra skyen? Det kan godt hende at det er veien å gå på litt sikt. Det spørs om kundene våre ønsker å lagre informasjon ute i skyen. SIDE 34

37 INTERVJU AV ROM EIENDOM AS, ERP BRUKER AV DAGENS LØSNING. Intervju med Tore Håsæther, IT rådgiver hos ROM Eiendom AS Blå tekst er spørsmål stilt til Tore Håsæter av Astrid Lofthus Hvordan bruker dere Pmax og Axapta? Vi bruker ganske mye i Axapta og Pmax, vi bruker det meste av det som er mulig å bruke. Vi bruker ikke tegning pr i dag da den er relativt ny. Vi har Lydia FDV system til tegning. Tegning hos oss foregår i Autocad, så importeres tegning inn i Lydia som dwg tegninger. Så knyttes det databaseinformasjon til de tegningene. Knytte intelligens til de tegningene. Det samme løsninger som Plania har. I dag er det de to løsningene som er mulig å knytte til Database på markedet i Norge slik vi kjenner det. Autocad tegninger ligger i bonn i Lydia og så knyttes det database informasjon til tegningene både til bygg, etasje, fløy og rom. Du kan gå inn i Lydia og se tegning der, og du kan du kan gå inn i tegning og se der hvem som er leietager, hvilket romnr. er det, hvilke areal type er det på rommet man skal inn i. I Ax bruker vi Eiendoms modulen hvor vi har alle eiendommene våre både med grunn og bygg og alle leiekontraktene på utleie eller Pmax. Og dette er master for eiendommene våre. Så har areal regnskapet i Ax sånn at vi måler ledighet, økonomisk ledighet osv. Vi bruker fullt regnskap i Axapta og kun der. Vi bruker Anleggsmodulen i Ax slik at vi kjører avskrivning i anleggsmodulen eller i anleggsregisteret som vi har lagt inn. Anlegg vil si at du legger inn verdien av et bygg når det er bygget så aktiverer du det, skriver det ned over x-antall år avhengig av hvilke regler det er so gjelder for nedskriving. Så dannes det anleggsregister og anleggsposter og du kan rapportere på det. Samtidig dannes det regnskapsposter inni i regnskapet. I stedet for, veldig mange så kjører rett i regnskapet i Plania, vi kjører det via anleggsmodulen og så bruker vi den. Har dere vært lenge kunde hos Advania?: Vi startet med forløperen til Ax, det var jo EKO live eller Concord xal. Og vi startet med det juni 1999, så 16 år ganske snart. I 2004 så gikk vi over til Ax og da kom AX med Eiendomsløsning. Det har vært samme leverandør hele veien her, så vi har ikke hatt behov for å bytte leverandør. Det er opprinnelig Advania. Er Advania en god leverandør for dere? Ja det er en god leverandør og det viktigeste med leverandøren er ikke systemene men kompetansen til leverandøren. De er gode på faget når de leverer et fagsystem. Det er det vi la vekt ved. Bjørn Sand er den som har utviklet forløperen og det vi har i dag. Han har vært med hele veien. Dette med tegning er ganske nytt i Ax som pr. i dag bruker DWF fil i viweren. Dette er en lettere utgave av dwg filen. Bjørn Sand har fortalt oss om litt om det, men i og med at vi har Lydia så er ikke det noe vei og gå for oss egentlig for vi har jo dekka det behovet vi har SIDE 35

38 gjennom Lydia. Og Lydia har vi hatt så pass lenge at det hadde vi faktisk før vi kjøpte Ax Concord, så det er et eldre system fra tidlig på 90 tallet. Ønsker dere dwg filer i 2Dog 3D?: Vi ønsker bare å motta 2 D tegninger fra Arkitektene eller entreprenørene. Når vi tar over tegningene også nybygg, så legger vi de inn i Lydia, og kommer det en oppdatert versjon fra en entreprenør eller hva det skulle være, så kan vi bare legge de inn som en revisjon oppå den andre. Tegningene har samme navn så de finner hverandre og det fungerer som sømløst. Så dersom vi får tegnet på EL, VVS eller RIB så kan vi bare ta en kopi, sende til den som skal gjøre det og få det tilbake og legge det inn i Lydia. I Lydia er det noe som heter temaet og så gjør at du kan vise temaer også kan du velge hva du ønsker vise på hvert tema. Dvs. vil du vise EL så lager du et tema som heter EL også viser du alt som har med elektro. Lydia er et FDV system egentlig men vi bruker ikke forvaltningsdelen, vi bruker det ikke til utleie, vi bruker det bare til tegning. Vi har tidligere brukt Lydia til drifting. Drifting av byggene våre har vi satt bort til eksterne, ISS drifter disse for oss. Tidligere hadde vi det inhouse og da brukte vi Lydia til drifting og hadde tiltak i Lydia, så ting som skulle gjøres på byggene, både planlagte og uforutsette ting lages som tiltak og det ble gjort og det ble fulgt opp i Lydia. Tegning ble knyttet til tiltak enten på et rom eller til en bygnings del som, et brannslukkings apparat eller servant ol. Nå bruker vi bare Lydia til å beregne arealer, knytte kontrakter til rom og få riktige arealer på kontrakter og bygg inn igjen i ax hvor vi har areal regnskapet. Vil det si at dere ikke bruker Pmax som et arealberegningssystem? Når det gjelder arealberegning i AX så bruker vi kun felles arealer, på kontrakt det beregnes i Ax. Når det gjelder bygg så kommer arealene i sin helhet fra Lydia. Når det gjelder kontrakt så kommer areal som det eksklusive leiearealet som i Axapta kalles H1(hoved areal) også blir det påslag av felles arealene det skjer i Ax. Axapta beregner påslag av felles arealene på kontrakter i dag. Hva er da forskjellen på Lydia sin areal beregning og Axapta sin areal beregning? De beregner jo likt men i Lydia så har vi knyttet intelligens til tegning, det betyr at hvert rom i alle bygg i Lydia har et rom skjema som sier noe om hvilke areal type, med x antall kvm, det kan være et kontor areal, et felles areal bygg, felles etasje de sitter på. De er ut ifra de begrepene er det den beregninga finner ut hvor mye felles areal etasje det er i forhold til hoved areal, det skjer i Lydia. Og det overføres til Ax så de er like. Det er en link mellom Lydia og Ax. Vi overfører kontrakter og bygg fra Ax til Lydia og fellesareal på kontrakter. Fordi AX vet allerede hvor mye felles areal det er i etasjene i bygget. Til forskjell skal GCRE ta hele denne regne biten i AX og det er ikke blitt gjort før. Har du noen kjennskap til om noen har gjort tilsvarende? SIDE 36

39 Nei, dette er ganske nytt men det blir helt sikkert bra. Den forbindelsen mellom Lydia og AX kommer vi til å revurdere nå i forbindelse med oppgradering av Lydia til ny versjon. Samtidig så i dag så har ikke vi arealene med på rom eller sone vi har det på etasje på seksjonen, som er etasje. Nå ønsker vi å gå over til rom eller sone som er et krav fra leverandøren fra og med Og da når vi skal bytte Lydia så passer vi på re-utvikle grensesnittet. Så nå kommer vi til å få alle rom ifra Lydia inn i AX, AX kommer til å bli en speiling av Lydia. Vil det si at all arealberegning blir gjort i AX og kun der? Ja, når vi får det nye grensesnittet så kommer alle arealene til å ligge i AX på bygg. Når det gjelder kontrakt så kommer vi fortsatt til å bruke Lydia fordi når vi oppretter en kontrakt så eksporteres den til Lydia. Der er det en veldig enkel brukervennlig funksjonalitet for å knytte rom til kontrakt. Når det er gjort så kommer det tilbake igjen med beskjed om de og de rommen er knytt til den kontrakten og så beregne AX selv og knytter til de rommene og beregner arealet. Og da kommer vi til å bruke AX til arealberegning på en annen måte. Samtidig så bruker vi også Lydia til å skrive ut grafisk rapporter fra tegningene så at vi viser en rapport med arealet hvor det er vist hvor den enkelte leier, fargelagte tegning hvor rommet som leies er fargelagt så man ser hvilke rom de leier i bygget. Det er noe vi bruker Lydia til som ikke vi kunne hatt i AX så vidt jeg skjønner. Vi har hatt Lydia som har funger godt for oss så vi har ikke engasjert oss så mye, annet at vi vet at det ligger noe der. Advania snakker varmt om det så jeg er helt sikker på at det blir bra. Hvordan forholder dere dere til fil formatet IFC? Nei, vi har ikke engasjert oss i det siden vi er et aksje selskap og underlagt offentligheten, så det berører ikke oss. Vi har så vidt sett på BIM for et par år tilbake men vi er ikke pålagt å bruke BIM og har funnet ut at det er veldig omfattende. Det har jo med vedlikehold av dataene å gjøre. En ting er å bruke BIM i prosjektering og bygge fasen en annen ting er å bruke BIM i en driftsfase. Det krever at du vedlikeholder dataen på en ordentlig måte. Det å så vurdere hva du er villig til å legge i inn av ressurser for å holde data i orden i forhold til hva du får tilbake. Det er et slikt spørsmål en må stille, egentlig uavhengig av BIM. Det gjelder jo også for vanlig FDV systemer. Alt avhenger av hva du putter inn og får ut. Hvis du bytter lysarmatur, servanter og toaletter uten å oppdatere dataene dine er ikke dataene dine noe vert. Vi prøver å begrense hva vi legger inn i sånne systemer. Vi startet på 90 tallet med veldig ambisjoner om det men har tonet det veldig mye ned i løpet av de siste åra. Kan dere motta IFC fil i Lydia? Det vet jeg dessverre ingenting om. Dere vil fortsette med Lydia som FDV program fremover eller tilsvarende program, hvordan forholder dere til dwf fil som er på vei og bli faset ut? Pmax kan også lese dwg fil den er bar litt tung å åpne i vieweren. Plan Tracer er en gratis dwg Viewer. Men det som fint med AX er at hvis du legger inn en fil, Excel, Word el så er det programmene til filene som åpnes og ikke AX sånn sett. Så hvis du har en dwg fil så har du en gratis dwg Viewer som du kan åpne denne i. Mens i Lyda så er det litt annerledes fordi SIDE 37