De Digitale Dage 2013 – Summa sumarum

Efter tre dage med fuld gas på BIM, kommunikation og innovation kunne vi med god samvittighed fredag eftermiddag sætte tænderne i en pølse og skylle efter med en fyraftensøl ved afslutningen af De Digitale Dage 2013.

Min rolle ved dette års DDD var, som skrevet i forrige indlæg, projektleder. Jeg har aldrig deltaget i DDD før, men det kan varmt anbefales til alle, som gerne vil være spydspids for udvikling og afprøvning af de nyeste IT-systemer inden for byggeriet og indenfor BIM.
Jeg vil kort beskrive processen omkring nogle få af de  programmer vi anvendte ved DDD:

  • Vi anvendte ibinder som projektweb kombineret med Bips struktur for dokumenthåndtering nemlig A104.
    • Beskrivelse af ibinder – http://www.ibinder.com
      • Ibinder er en webbaseret mappestruktur som mest anvendes indenfor  Byggeprojekt, Digitalt udbud, Ejendomsdrift og Arkiv. Det byder på en overkommelig brugerflade, hvor man nemt kan få overblikket over, hvilke mapper man har og hvilke der er aktive.

Untitled

Billedet er fra projektwebbet DDD.
Mapperne som er i halftone er tomme og de andre er i brug – nemt og overskueligt

      • Vurdering
        • Der var masser af opstartsproblemer, da mange skulle oprettes som brugere inden vi kunne komme i gang på dag 1. På trods af det var det en stor succes. Ibinder er som sådan en virtuel mappestruktur, som man nemmere kan overskue pga. opsætningen omkring aktive og ikke aktive mapper. I al sin enkelthed minder det meget om en traditionel mappestruktur man f.eks. bruger, hvis man anvender dropbox til projektweb. Ibinder styres vha. en administrator, som disponere over brugerens rettigheder. På den måde styres hvem, der kan hhv. downloade og uploade. Dermed bliver enkelt for brugeren at forholde sig til.
          Jeg mener ibinder er et godt værktøj til projektweb og jeg tror det bliver noget vi kommer til at stifte bekendtskab med fremover både på skoler og i erhvervslivet.
    • Beskrivelse af A104 – http://bips.dk/nyhed/video-l%C3%A6r-om-dokumenth%C3%A5ndteringsmanualen
      • A104 dokumenthåndtering er et styresystem til at håndtere sin projektweb. Det hjælper til at navngive filer og lave en gennemsigtighed i den måde branchen skal håndtere deres projektweb. Ligesom mange andre tiltag fra BIPS lægger A104 også op til at fordelen rigtig kommer ved. BIPS’ værktøj til dokumenthåndtering slår rigtigt igennem når flere parter i et konsortium eller et samarbejde mellem faggrupper anvender A104Således bliver dokumenthåndteringen lettet pga. de samarbejdende parter kan overskue hindandens filnavngivninger og placeringer i mapperne i deres projektweb.
    • Vurdering
      • Jeg har anvendt A104 til 2 projekter. Det er uden tvivl et værktøj, som skaber en retningslinje for, hvordan man håndterer sin dokumenthåndtering. Selve vejledningen er udført således der ikke er meget overladt til fantasien ift. en almen mappestruktur som hverenkelt firma sætter op. For at komme i gang med A104 er det dog essentielt, at man har BIM-koordinatorer der kan hjælpe en i gang. På trods af at A104 virker godt, er det svært at komme i gang med pga. det er et meget omstændigt dokument at sætte sig ind i – det er 86 sider.
        I vores gruppe på UCN har vi udvalgt de ting af A104 vi kunne bruge og derefter rettet META-DATA’en til, så det har passet til vores projekt. Det er en succes. Til DDD har det været et andet opsæt, så det skulle indlæres med en smule opstartsproblemer, men det var også en succes. Til DDD anvendte vi ikke en så stor del af mappestrukturen som vi ellers gør på skolen, derfor kom der situationer, hvor vi måtte tolke på mapperne.
        Helt sikkert også et værktøj, som efterhånden vil blive anvendt mere og mere, men jeg tror der kommer til at gå tid inden det når ud til de mindre tegnestuer pga. kompleksiteten i opstartsfasen. Det vil med sikkerhed skræmme mange.

Det var de programmer jeg stiftede mest bekendtskab med. Ud over disse programmer blev der anvendt følgende programmer jeg kun har ringe kendskab til.

  • Solibri modelchecker og naviate – NaviateSolibri
    • Beskrivelse
      • Begge programmer er til at lave kollisionskontrol i. På den måde kan vi kontrollerer vores modeller passer sammen og  om der er sammenstødende objekter, for derefter at rette dem
    • Vurdering
      • Programmerne voldte problemer ved DDD. Både pga. det var nyt materiale der skulle læres, men også fordi der var forvirring omkring hvad programmerne formåede. Jeg mener programmerne begge er gode, men vi havde simpelthen ikke tid nok på de 3 dage til at give dem den tid de fortjente.
        I forbindelse med disse programmer og generelt med kollisionskontrollen stiftede vi bredt bekendtskab med IFC filformatet. Det er det format, der kan trækkes ud fra rigtig mange programmer, som deltager i byggeprocessen. De programmer vi kender bedst er Revit, auto-cad, magi-cad mfl. Her bruges IFC formatet til at udveksle informationer med mellem programmerne og dermed kan der udføres kollisionskontrol. Det var en vigtig lektie. Her er et link til en blog, som fortæller mere omkring dette format. IFC

Dette er mit sidste indlæg på bloggen angående DDD 2013. Jeg håber, at det har givet et indblik i, hvad man som studerende kan få af udbytte ved at deltage i DDD. Såfremt du har lyst til at spørge omkring indhold i mine indlæg eller andet er du velkommen til at skrive til mig.

– Peter Haven

peterhaven@gmail.com

Twitter: Klik her
LinkedIn: Klik her
Blog: Klik her

Reklamer

De Digitale Dage – BIM Koordinator dag 1

Som skrevet igår, vil jeg hver dag under DDD skrive om dagens oplevelser.

Da jeg ankom i dag, var jeg meget spændt på hvordan dagen ville forløbe. Jeg havde hørt fra tidligere deltagere at den første dag godt kunne opleves hektisk og en smule kaotisk. Det kan jeg kun give dem ret i.

De IDM-studerende havde givet os alle en dagsorden, hvori jeg som BIM-Koordinator, ansvarlig for projekweb, skulle starte dagen med at checke om alle de deltagene havde modtaget login og oprettet sig på iBinder (DDD’s Projektweb). Allerede her opstod nogle af dagens store problemer. Mange af deltagernes mail var ikke blevet tilføjet til deltagerlisten, og af samme grund var de ikke blevet tilføjet til iBinder. Pludselig gik megen af den tid der skulle bruges på at instruere i filnavngivning, til at få tilføjet de manglende folk. Denne opgave strakte sig stort set over hele dagen, hvor flere kom til for at få invitationen til iBinder.

Resten af vores opgaver var efterfølgende at kontrollere de filer der blev uploaded til projektwebben. Vi havde valgt kun at tildele en enkelt fra hver faggruppe muligheden for at uploade, for at minimere chancen for forkerte navngivninger, og det gav pote. Efter et par svipsere i starten af dagen, lærte de projektweb-ansvarlige i grupperne hurtigt at filnavngive ud fra Bips A104 – Dokumenthåndtering. Inden DDD havde vi udarbejdet en skabelon for dokumenthåndtering. Den skulle foregå på samme måde som en light udgave af en IKT-aftale, der udspecificerede; placering, fil-,tegning- og modelnavngivning. Den skulle være med til at sikre at folk fik en langt hurtigere forståelse, i stedet for at skulle gennemlæse hele BIPS A104.

Som dagen startede hektisk, sluttede dagen fredeligt og roligt. Efter der kom styr på deltagerliste og alle deltagere havde den fornødne adgang til iBinder. Havde vi tid til bedre at kontrollere at strukturen blev overholdt, samt lave konsistenskontrol på filer.

Dagen i dag har helt klart været utrolig lærerig, én ting er at sidde og læse i A104 om dokumenthåndtering, men en anden ting er at sidde med det i hænderne og bruge det som et redskab i et projekt, bestående af over 30 mennesker.

Det har allerede nu givet mig en langt bedre forståelse for filhåndteringen. Men også nogle problemstillinger jeg kan trække over i mit 4. semesters speciale. Gennem dagen, henvendte flere sig omkring placeringen af filer. Det skyldtes at i vores navngivning af filer bruger Vidensområde (K) og Indholdstype (C). Disse to metadata definerer placering og arbejdsområde. Det i sig selv gør, at man meget præcis kan definere fagområde og hvor filen præcis skal ligge. Problemet opstår dog, når filen i sin helhed kunne ligge flere steder, eller/også tilhører forskellige fagområder. Et eksempel vi stødte på tidligt, var bygherrens kravspecifikationer. Placering blev C08 (Specifikationer), men da den omhandler flere videnområder, var det pludselig svært at navngive og bygherrerådgiveren besluttede at give den, K01 (Arkitektur)

Jeg håber at dagens hektiske start og forvirringer har gjort, at vi i morgen er klar til at tage fat i nye områder, og ikke er nødsaget at bruge størstedelen på fejl invitationer. Men samtidig også byder på nye udfordringer, der skal løses i gruppen.

Mvh. Anders Norup

4. sem.
Mail: 1010937@ucn.dk
LinkedIn: Klik her

%d bloggers like this: