aalto-yliopisto suunnitelmien yhteensovittaminen ja

Transcription

AALTO-YLIOPISTO
Insinööritieteiden korkeakoulu
Rakenne- ja rakennustuotantotekniikan koulutusohjelma
Rakennusmateriaalit ja tuotantotekniikka
Jaakko Kinnari
SUUNNITELMIEN YHTEENSOVITTAMINEN JA TIEDONVAIHDON
TARPEET TIETOMALLINNETUSSA RAKENNUSHANKKEESSA
Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi
diplomi-insinöörin tutkintoa varten
Espoossa 26. maaliskuuta 2013
Valvoja: Professori (ma.) Arto Saari Aalto-yliopisto
Ohjaaja: Diplomi-insinööri Annikki Karppinen Lemminkäinen Talo Oy
Aalto-yliopisto, PL 12100, 00076 AALTO
www.aalto.fi
Diplomityön tiivistelmä
Tekijä Jaakko Kinnari
Työn nimi Suunnitelmien yhteensovittaminen ja tiedonvaihdon tarpeet tietomallinnetussa rakennushankkeessa
Laitos Rakennustekniikan laitos
Professuuri Rakentamistalous
Professuurikoodi Rak-63
Työn valvoja Professori (ma.) Arto Saari
Työn ohjaaja(t)/Työn tarkastaja(t) DI Annikki Karppinen, Lemminkäinen Talo Oy
Päivämäärä 26.03.2014
Sivumäärä 134 + 15
Kieli suomi
Tiivistelmä
Tämän diplomityön tarkoituksena oli selvittää, miten osapuolten välistä tiedonvaihtoa ja suunnitelmien yhteensovittamismenettelyitä voitaisiin kehittää nykyisestä toiminnasta tietomallinnetuissa rakennushankkeissa. Tutkimuksessa keskityttiin tapaukseen, jossa rakennushankkeen pääurakoitsija vastaa suunnittelun tilaamisesta ja ohjauksesta.
Tutkimuksen teoriaosuudessa selvitettiin kirjallisuudesta periaatteet tietomallinnetun rakennushankkeen suunnittelun lähtökohdille, tiedonvaihtoon liittyvälle teknologialle, IFC- ja yhdistelmämallien käytölle, sekä rakennushankkeen vaiheisiin liittyville tiedonvaihtotarpeille, joita havainnollistettiin SADT-kaavioina.
Tutkimuksen empiirinen osio suoritettiin hankkeiden osapuolten haastatteluina perustajaurakointikohteessa sekä kahdessa elinkaarihankkeessa, joista jälkimmäisten tuloksia tarkasteltiin toimitilakohteina. Lisäksi tutkija osallistui kolmeen suunnitteluun liittyvään kokoukseen hankkeissa.
Tutkimuksen havainnoissa korostuivat osapuolten erilaiset tarpeet tietomalleille ja niihin liittyville
prosesseille, mitkä tulee huomioida myös suunnittelun ohjauksessa. Lisäksi suunnitelmien tarkkuustason kasvamisen ja tiedonvaihdon prosessien monimutkaistumisen myötä suunnitteluvaiheisiin liittyvä tiedonvaihto tulee olla aiempaa hallitumpaa ja oikein rytmitettyä.
Case-kohteiden havaintoihin pohjautuen, tutkimuksen tuloksina esitettiin kehitysehdotuksia ja
näkökulmia liittyen suunnittelun ajalliseen hallintaan, tietomallisuunnittelun koordinoimiseen,
tietomallien laadunvarmistus- ja julkaisumenettelyihin sekä suunnittelun yhteistoimintamenettelyihin.
Avainsanat Tietomallintaminen, BIM, IFC, yhdistelmämalli, tietomallikoordinaattori, suunnittelun ohjaus
Aalto University, P.O. Box 12100, FI-00076 AALTO
www.aalto.fi
Abstract of master's thesis
Author Jaakko Kinnari
Title of thesis Design Coordination and the Needs for Information Exchange in BIM Projects
Department Department of Civil and Structural Engineering
Professorship Construction Economics and Management
Code of professorship Rak-63
Thesis supervisor Professor (acting) Arto Saari
Thesis advisor(s) / Thesis examiner(s) M.Sc. (tech.) Annikki Karppinen, Lemminkäinen Talo
Oy
Date 26.03.2014
Number of pages 134 + 15
Language Finnish
Abstract
The aim of this master’s thesis was to determine ways to develop information exchange and methods of design coordination between project stakeholders in current BIM projects. This study was
focused on a case where general contractor is responsible for purchasing design services and design control.
In the theoretical part of the study a literature review was used to define the key principles for
starting points of designing construction project using BIM methods, technology related to information exchange, the usage of IFC and merged models and the needs for information exchange
related to different phases of construction project, which were presented using SADT-charts.
The empirical part of the study was conducted as interviews of project stakeholders in a founder
contractor project and two PPP-projects. Results of the latter ones were examined as business
premises. In addition, the researcher participated in three meetings related to design of the projects.
Findings of the study emphasised the different needs for building information models and processes related to them, which has to be taken into account in design control. Furthermore, due to
growing level of detail in design and complexity of information exchange, the information exchange related to different design phases has to be well-paced and more controlled.
Based on the findings in case-projects, the study presented perspectives and propositions for development related to following topics: design scheduling, coordinating BIM design, quality assurance and publication methods of building information models and collaboration methods in design.
Keywords Building information modeling, BIM, IFC, merged model, BIM Coordinator, design
control
Alkusanat
Tämä työ on tehty opinnäytteeksi diplomi-insinöörin tutkintoon Aalto-yliopiston insinööritieteiden korkeakoulun rakennustekniikan laitokselle. Työn toimeksiantajana oli
Lemminkäinen Talo Oy.
Haluan kiittää lämpimästi työni ohjaajaa, Lemminkäinen Talo Oy:n kehityspäällikkö
Annikki Karppista mahdollisuudesta diplomityön tekemiseen, työn ohjauksesta, lukuisista ideoista ja kehitysehdotuksista sekä jatkuvasta kannustuksesta työn suorittamisen
aikana. Haluan erityisesti kiittää myös Lemminkäinen Talo Oy:n tietomalliasiantuntija
Artur Viritiä, jonka asiantuntemusta ilman työn suorittaminen ei olisi ollut mahdollista.
Suuret kiitokset myös kaikesta panoksestanne tutkimukseen osallistuneille henkilöille,
joiden kanssa olin tekemisissä Helsingissä, Hämeenlinnassa, Hyvinkäällä, Järvenpäässä,
Kuopiossa, Oulussa sekä sähköpostin ja puhelimen välityksellä. Työn tarkastamisesta ja
ohjaamisesta kohti tieteellistä tutkimusta kiitän työn valvojaa, professori Arto Saarta.
Lopuksi haluan kiittää perhettäni ja ystäväpiiriäni tuestanne opintojeni aikana. Erityisesti haluan kiittää Liinaa tukemisestasi, kannustuksestasi ja kärsivällisyydestäsi.
Espoossa 26.03.2014
Jaakko Kinnari
5
Sisällys
1 Johdanto .................................................................................................................... 8
1.1 Tutkimuksen tausta ............................................................................................. 8
1.2 Tutkimusongelma ja tavoitteet ............................................................................. 9
1.3 Tutkimuksen rajaus ........................................................................................... 10
2 Kirjallisuusselvitys ................................................................................................... 11
2.1 Tietomallipohjaisen suunnittelun lähtökohdat .................................................... 11
2.1.1 Tietomallipohjaisen suunnittelun erot perinteiseen rakennushankkeeseen ... 11
2.1.2 Mallintamisen tavoitteiden määrittely ......................................................... 13
2.1.3 Tietomallihankkeen koordinointi ja osapuolten vastuut ............................... 14
2.2 Yhdistelmämallien käyttö tietomallinnetussa rakennushankkeessa..................... 18
2.2.1 IFC-tiedonsiirtostandardi ............................................................................ 18
2.2.2 Natiivimallit ............................................................................................... 21
2.2.3 Tiedonsiirto projektissa ja mallien yhdistäminen......................................... 22
2.2.4 IFC- ja yhdistelmämallien käyttökohteet ..................................................... 27
2.3 Tietomallinnetun hankkeen vaiheet ja tietomallien tietosisällöt.......................... 40
2.3.1 Tarveselvitys ja hankesuunnittelu ............................................................... 42
2.3.2 Ehdotussuunnittelu ..................................................................................... 44
2.3.3 Yleissuunnittelu .......................................................................................... 48
2.3.4 Toteutussuunnittelu .................................................................................... 52
2.3.5 Rakentaminen ............................................................................................. 55
3 Haastattelututkimus kohdeyrityksessä ...................................................................... 56
3.1 Tutkimusmenetelmät ja tutkimusaineisto ........................................................... 56
3.2 Case-kohteiden tarkastelu .................................................................................. 59
3.2.1 Kastellin monitoimitalo .............................................................................. 59
3.2.2 Järvenpään Vilja ......................................................................................... 60
6
3.2.3 Pohjantien koulu ......................................................................................... 61
3.3 Haastattelut case-kohteissa ................................................................................ 62
3.3.1 Suunnitteluun varattu aika .......................................................................... 62
3.3.2 Suunnittelun kokouskäytännöt .................................................................... 65
3.3.3
Suunnitteluaikataulut
ja
tiedonvaihtotarpeiden
tarkentaminen
suunnitteluaikataulusta ........................................................................................ 69
3.3.4
Mallinnusaineisto
ja
mallien
hyödyntämisen
määrittely
projektin
alkuvaiheessa ...................................................................................................... 73
3.3.5 Projektipankki ja muut tiedonsiirto- ja kommunikointivälineet ................... 74
3.3.6 Mallien päivitystiheys ................................................................................. 75
3.3.7 Tietomalliselostus ....................................................................................... 76
3.3.8 Suunnitelmien valmiusaste ja suunnitelmamuutokset .................................. 76
3.3.9 Tietomalleista tuotetut suunnitelmat ........................................................... 79
3.3.10 Suunnittelijoiden omat laadunvarmistusmenettelyt ................................... 79
3.3.11 Tietomallikoordinaattorin rooli ................................................................. 80
3.3.12 Reikä- ja varaussuunnittelu ....................................................................... 82
3.3.13 Alakattosuunnittelu ................................................................................... 85
3.3.14 Muut tiivistä tiedonvaihtoa vaativat suunnittelutehtävät ............................ 86
3.3.15 IFC-tiedonsiirtoformaatin ongelmat .......................................................... 88
3.3.16 Muiden suunnittelualojen mallien hyödyntäminen .................................... 89
3.3.17 As-built mallien tuottaminen..................................................................... 90
3.3.18 Mallien luovuttaminen natiivimuodossa .................................................... 91
3.4 Keskeiset tulokset ja toiminnan kehitysehdotukset ............................................ 91
3.4.1 Ajallisen hallinnan ja suunnittelutiedonvaihdon erityiskysymykset ............. 91
3.4.2 Tietomallien koordinoimisen tehtävien jakaminen osapuolten tarpeiden
mukaan ............................................................................................................... 96
3.4.3 Mallien julkaisuprosessin kehittäminen ...................................................... 99
7
3.4.4 Muutosten tiedottaminen ja visualisointi ................................................... 105
3.4.5 Yhteistoimintaa vaativien suunnittelutehtävien ohjeistukset ...................... 107
3.4.6 Mallien hyödyntämisen näkökulma laadunvarmistuksessa ........................ 110
3.4.7 Solibrin tarkastussäännöstöt...................................................................... 114
3.4.8 Solmutyöskentelyn mahdollisuudet yhteistoimintaa ja ongelmanratkaisua
vaativissa suunnitteluvaiheissa .......................................................................... 116
4 Tutkimustulosten arviointi ..................................................................................... 122
4.1 Keskeisten tulosten suhde aiempaan tietoon .................................................... 122
4.2 Tulosten luotettavuus ...................................................................................... 122
4.3 Tulosten yleistettävyys .................................................................................... 124
5 Johtopäätökset ....................................................................................................... 125
5.1 Jatkotutkimusmahdollisuudet .......................................................................... 126
Lähteet ...................................................................................................................... 128
Liitteet
Liite 1 – Tietomallisuunnittelun koordinoimisen tehtävätaulukko. 2 s.
Liite 2 – Yhdistelmämallin tarkastus- ja julkaisuohjeet. 9 s.
Liite 3 – Solibri Model Chckerillä luotu yhdistelmämallin tarkastustaportti. 1 s.
Liite 4 – Revisiovertailun tuottaminen arkkitehtimallista, ohjeet. 3 s.
8
1 Johdanto
1.1 Tutkimuksen tausta
Tietomallipohjainen suunnittelu on vakiinnuttanut asemansa toimintatapana etenkin
kompleksisissa hankkeissa, joissa tietomallintamisesta koetaan saavutettavan hyötyä
tavalla johon perinteisellä suunnitteluprosessilla ei pystytä. Tietomallipohjaisesta suunnittelusta saatava hyöty riippuu siitä, mitä useampi suunnittelualan edustaja ja projektin
toimija käyttää tietomalleja. Eräs tärkeimmistä tietomallien tuomista hyödyistä on
hankkeen osapuolien välisen tiedonsiirron ja yhteistyön tehostuminen, sekä suunnitelmien yhteensopivuuden paraneminen.
Tietomallintamisella on myös pystytty vastaamaan lisääntyneeseen suunnittelun tarkkuustason tarpeeseen, mikä on korostunut etenkin taloteknisten järjestelmien monimutkaistuessa hankkeissa. Kasvanut suunnitelmien tarkkuustaso on kuitenkin luonut uusia
vaatimuksia myös suunnittelun tiedonhallinnalle:
-
Suunnitelmien ollessa entistä tarkempia, kasvaa myös vaatimus tiedon oikeellisuudelle. Tällöin suunnittelun laadunvarmistuksen merkitys korostuu ja ristiriitojen välttämiseksi suunnittelualakohtaisia suunnitelmia täytyy vertailla aikaisempaa enemmän keskenään.
-
Mahdollisuuksien ollessa käytännössä rajattomat suunnitelmien tietosisällölle,
tietosisällöt pitää rajata ja rajauksissa tulee huomioida osapuolten erilaiset tarpeet tietosisällöille.
-
Tiedonvaihdon kompleksisuuden lisääntyessä, aiheutuu myös muutostarpeita perinteisille suunnittelun prosesseille sekä vaatimuksia tiedonvaihdon ja yhteistoiminnan koordinoinnille.
Tietomallinnetun hankkeen läpiviemiseksi on viime vuosina laadittu toimintaohjeita
diplomitöissä, osana yritysten toimintajärjestelmiä sekä COBIM-hankkeessa yleisten
tietomallivaatimusten 2012 muodossa, mikä on antanut viitekehyksen osapuolten väliselle toiminnalle. Ongelmana osapuolten välisessä toiminnassa on se, että tietomallintamista toteutetaan vielä osittain perinteisen suunnitteluprosessin mukaisesti. Muuttamalla suunnitteluprosessia pystyttäisiin tehostamaan suunnittelijoiden välistä tiedon-
9
vaihtoa, rytmittämään suunnittelu oikein ja vähentämään puutteellisista lähtötiedoista
johtuvia virheitä.1 Muuttuneen suunnitteluprosessin tarpeisiin onkin viimeaikoina tutkittu uusia toimintatapoja suunnittelun ohjaukseen erityisesti Lean Construction periaatteita soveltaen.
Projektimenettelyiden kehittäminen on luonut tarpeen yksityiskohtaisemmalle lisätutkimukselle tietomallien hyödyntämisestä. Vaikka perusperiaatteet osapuolten väliselle
toiminnalle ja hankkeen vaiheille on luotu, ongelmia esiintyy silti, mikä ilmenee suunnittelun aikaisina häiriöinä, ongelmina tietomallien hyödyntämisessä sekä ristiriitoina
toteutusvaiheen suunnitelmissa. Toisaalta koska tietomallinnetuissa hankkeissa projektin toimijat pysyvät monesti samoina, ovat monet osapuolten välisistä toimintakäytännöistä jalostuneet paremmiksi hankkeesta toiseen.
Tutkimus laadittu osana RYM Oy:n PRE-ohjelman Model Nova -työpakettia, jossa
Lemminkäinen Talo Oy on mukana. Tutkimus on jatkoa Lemminkäinen Talo Oy:lle
aiemmin tuotettuihin diplomitöihin, joista viimeisimpinä on laadittu Antti Halosen diplomityö tuotannon aikataulutuksesta rakennemallista (2013), Ville Niskakankaan diplomityö tietomallinnetun rakennushankkeen suunnittelunohjauksesta (2013) sekä Heikki
Uusitalon diplomityö tietomallien hyödyntämisestä määrälaskennassa (2013). Model
Nova -työpakettia koordinoi Senaatti-kiinteistöt ja sen rahoitukseen on osallistunut hankeosapuolten lisäksi teknologian ja innovaatioiden kehittämiskeskus Tekes.
1.2 Tutkimusongelma ja tavoitteet
Tutkimusongelmana tässä diplomityössä on selvittää, miten osapuolten välistä tiedonvaihtoa ja suunnitelmien yhteensovittamismenettelyitä voitaisiin kehittää nykyisestä
toiminnasta tietomallinnetuissa rakennushankkeissa. Tutkimuskysymykset voidaan tiivistää seuraavasti:
1) Mitkä suunnitteluvaiheet ovat nykyisissä projekteissa kriittisiä suunnittelijoille yhteistoiminnan osalta?
2) Mitä ongelmia osapuolten välisessä toiminnassa ja tiedonvaihdossa on nykyisissä
projekteissa? Miten tiedonvaihtoa tulisi edistää?
1
SKOL Ry: Talotekniikan tietomallinnuksen prosessimuutos, projektisuunnitelma. Viitattu 29.7.2013.
10
3) Miten suunnitelmien yhteensovittamisen ja laadunvarmistuksen koordinointia voitaisiin kehittää suunnittelun tilaajan näkökulmasta?
Tutkimus koostuu teoriaosuudesta ja empiirisestä osuudesta. Teoriaosuudessa on tavoitteena selvittää kirjallisuudesta yleiset periaatteet tietomallinnetun suunnittelun lähtökohdista, tiedonsiirrosta ja siihen liittyvästä teknologiasta, yhdistelmämallien käytöstä
sekä tietomallinnetun hankkeen vaiheista ja vaiheisiin liittyvistä tiedonvaihtotarpeista.
Teoriaosuuden pohjalta on tarkoitus muodostaa yleinen näkemys suunnitteluprosessista
tutkimuksen empiiristä osuutta varten.
Tutkimuksen empiirisessä osuudessa haastatellaan kolmen case-hankkeen suunnittelijoita, tietomalliasiantuntijoita, tuotanto- sekä projektihenkilöstöä. Tutkimusmenetelmänä empiirisessä osiossa on teemahaastattelu, jossa teoriaosuuden pohjalta muodostetun
haastattelurungon avulla on tavoitteena tuoda esiin eri osapuolten näkökulmat tiedonvaihdosta ja suunnitelmien yhteensovittamisesta case-kohteissa.
Tutkimuksen tavoitteena on esittää tutkimustuloksiin perustuen kehitysehdotuksia ja
uusia näkökulmia nykyisiin prosesseihin. Tutkimuksen tavoitteen saavuttamisen tueksi,
alatavoitteena on tunnistaa ongelmat ja hyväksi havaitut menettelyt nykyisissä projekteissa, case-havaintoihin ja saatavilla olevaan kirjallisuuteen perustuen.
1.3 Tutkimuksen rajaus
Tutkimus rajataan käsittelemään tietomallinnetun rakennushankkeen suunnitteluvaiheita, joita ovat tarveselvitys ja hankesuunnittelu, ehdotussuunnittelu, yleissuunnittelu,
toteutussuunnittelu sekä rakentamisvaihe tarkentavan suunnittelun osalta. Käyttö- ja
ylläpitovaihetta ei käsitellä tässä tutkimuksessa erikseen, lukuun ottamatta toteumamalleja suunnittelun päättyessä. Vaihe on rajattu molempien tutkimusosioiden ulkopuolelle.
Tiedonvaihtoa käsitellään tässä tutkimuksessa kahdesta näkökulmasta: Suunnittelutietoon liittyvinä kommunikointi- ja yhteistoimintamenettelyinä, sekä tietomallipohjaisena
tiedonsiirtona, keskittyen pääasiallisesti IFC-tiedonsiirtoformaattiin.
11
2 Kirjallisuusselvitys
2.1 Tietomallipohjaisen suunnittelun lähtökohdat
2.1.1 Tietomallipohjaisen suunnittelun erot perinteiseen rakennushankkeeseen
Perinteisissä rakennushankkeissa suunnitelmien tuottaminen on perustunut piirustuksiin
siten, että tiettyä hankkeen vaihetta tai päätöksentekopistettä varten on tuotettu suunnitelmadokumentit, ja suunnitelmia tarkennetaan ja täydennetään seuraavassa vaiheessa.
Perinteisen vaiheistetun rakennushankkeen edelliset vaiheet saatetaan aina päätökseen
ennen seuraavan aloittamista.1 Eastmanin mukaan siirryttäessä hankevaiheesta toiseen
katoaa aina tietovarantoa, koska hankevastuun siirtyessä suunnitelmista manuaalisesti
tuotettu tieto ei ole enää hyödynnettävissä seuraavassa vaiheessa.2 Tietomallien avulla
suunnitelmatieto siirretään eri osapuolille elektronisessa muodossa siten, että tieto on
hyödynnettävissä ilman manuaalisia välivaiheita. Tietomallit sisältävät kaiken rakennuksen elinkaaren aikana tarvittavan tiedon yhdessä paikassa, eikä tarpeetonta tietoa
siirretä osapuolten välillä, vaan tietoa käsitellään kulloisenkin tiedontarpeen mukaan.
Tietomallien käyttö mahdollistaa myös uuden lisäarvon tuomisen suunnitelmiin, mikä ei
ole aikaisemmin ollut mahdollista: Esimerkiksi elementtitehdas voi päivittää työmaalle
valmistustiedot tietomalleihin.3
Keskeiseksi ongelmaksi 2D-dokumentteihin perustuvassa suunnittelussa on koettu olevan vaihtoehtoisten suunnitelmaratkaisujen ja niitä tukevan analyyttisen vertailutiedon
(value engineering), kuten kustannusarvioiden, energia-analyysien tai rakenteellisten
järjestelmien vertailutiedon tuottaminen. Usein suunnitelmien tarkempi analysointi on
tehty suunnitelmien valmistuessa tiettyyn pisteeseen, kun merkittävien suunnitteluperiaatteiden muutosten toteuttaminen on jo liian myöhäistä. Koska analysointia ei tehdä
suunnittelun aikana ja mahdolliset suunnitelmien optimoinnit tehdään valmiisiin suunnitelmiin, ne ilmenevät lähinnä kompromisseina alkuperäisiin suunnitteluratkaisuihin.4
1
Rakennustieto Oy. 2010. RT 10-10992.
Eastman, C. et al. 2011. s. 153
3
Penttilä, H. et al. 2006. s. 11
4
2
12
Kuva 1. Tietomallinnetun ja perinteisen hankkeen väliset erot tietovarannon kertymisen
ja suunnittelupanoksen aikaistumisen näkökulmista. Lähteet: Rakennustieto Oy. 2010.
RT 10-10992, Eastman, C. et al. 2011. s. 198
Myös tietomallinnetussa hankkeessa hankevaiheet ovat peräkkäisiä, mutta ne limittyvät
ja ovat osittain päällekkäisiä. Lisäksi tietomallinnetussa hankkeessa käytetään edelleen
vähintään yhtä paljon 2D-suunnitelmia kuin aikaisemminkin, mutta ne tuotetaan suoraan tietomalleista.1 Suunnittelun painopiste sen sijaan siirtyy aiempaan verrattuna aikaisemmaksi. Hanke- ja ehdotussuunnitteluvaiheessa on mahdollista tuottaa vaihtoehtoisia suunnitelmia, jotka voivat olla tietosisällöltään kevyitä, mutta mahdollistavat silti
suunnitelmien analysoinnin päätöksenteon tueksi ja siten aiempaa suuremman vaikutusmahdollisuuden rakennuksen toteutus- ja elinkaarikustannuksiin. Myös yleissuunnitteluun ja toteutussuunnitteluvaiheen alkuun joudutaan varaamaan enemmän aikaa johtuen kaiken toteutuksen vaatiman tiedon syöttämisestä malliin.2 Vastaavasti toteutuspiirustusten tuottamiseen vaadittu aika olennaisesti lyhenee, sillä mallit sisältävät jo pääosin niiden vaatiman tiedon ja piirustusten tuottamiseen liittyvä rutiinityö vähenee.3, 4
1
Rakennustieto Oy. 2010. RT 10-10992.
Penttilä, H. et al. 2006b. s. 9
3
4
Penttilä, H. 2009. s. 347
2
13
2.1.2 Mallintamisen tavoitteiden määrittely
Hankkeen alussa arvioidaan, saadaanko tietomallintamisella tuotettua hankkeelle lisäarvoa ja miten sillä edesautetaan kokonaistavoitteiden saavuttamista. Erityisesti haastavissa ja monimuotoisissa rakennushankkeissa korostuvat tietomallintamisen käytöllä saavutetut hyödyt. Tietomallinnus ei ole kuitenkaan itseisarvo, vaan keino varmistaa projektille asetettujen tavoitteiden toteutuminen. Hankkeen alussa tulisikin tehdä päätös –
varsinaisen investointipäätöksen ohella – tietomallintamisen tavoitteista, käytöstä ja sen
laajuudesta hankkeessa.1 Tietomallinnetussa hankkeessa edellisen vaiheen tulos toimii
lähtötietona seuraavalle vaiheelle ja malleista tarvitaan erilaista tietoa hankkeen eri vaiheissa. Siksi tietomallien tietosisällöt pitää pystyä määrittämään myös ajallisessa yhteydessä.
Mallien tietosisällön kannalta on olennaista, että tietomallintamisen tavoitteet olisivat
pääosin määritelty jo vähintään suunnittelusopimusneuvotteluissa. Muussa tapauksessa
suunnitteluryhmän kokoonpanolla sekä yritysten tiedonhallinnan ja mallintamisen
osaamistasolla voi olla liian suuri rooli siinä, miten ja minkä tasoisia malleja rakennusprosessin aikana on mahdollista luoda ja miten tehokkaasti niitä voidaan hyödyntää.2
Suunnittelun käynnistämisen yhteydessä on tärkeää huolehtia, että kaikilla osapuolilla
on myös yhteinen näkemys mallinnukselle asetetuista päämääristä ja tavoitteista. Dokumentit mallien tavoitteista tulee liittää myös suunnittelusopimuksiin, jolloin mallien
käytöstä ja asetetuista tietosisältövaatimuksista tulee osapuolia sitovia. 3
Keskeisimmät mallintamisen tavoitteita määrittävät dokumentit projektin alkuvaiheessa
ovat:

Suunnitteluaikataulu
o Sisältää mallien tarkastusmenettelyiden aikataulutuksen sekä mallien tietosisällön kehittymisen ajallisesti

Tietomalliohje
o Suunnittelulle asetettavat tavoitteet ja vaatimukset tietomallien ja yhteistoiminnan osalta, päivitetään projektin edetessä
1
YTV2012, Osa 11.
YTV 2012, Osa 1.
3
YTV2012, Osa 11.
2
14

Tietomallin käyttötarkoitukset projektissa (voi sisältyä edelliseen)
o Kuvaus tietomallien hyödyntämisestä malleittain/toiminnoittain

Suunnittelualakohtaiset mallien tietosisältötaulukot
o Tietomallien sisällön määrittely suunnittelun eri vaiheissa, muokataan
projektikohtaisesti

Mahdolliset suunnittelualakohtaiset mallinnusohjeet ja aloituspohjat
Tietomalliselostus on kunkin suunnittelualan ylläpitämä kuvaus osamallin julkaisuhetken sisällöstä, käytetyistä mallinnustavoista ja poikkeamista edellä mainittuihin mallintamisen tavoitteita määrittäviin dokumentteihin nähden. Selosteen avulla muut osapuolet voivat tulkita mallin valmiusastetta, järjestelmien ja rakennusosien nimeämiskäytäntöjä ja mallin yleistä rakennetta. Tietomalliselostus tulee aina päivittää kun malli julkaistaan muiden osapuolten käyttöön, olipa sitten kyseessä työmalli tai tietomalli urakkalaskentaa varten. 1 Tietomalliselostuksen toimittaminen mallijulkaisun yhteydessä on
ehdoton edellytys osapuolten väliselle tiedonvaihdolle ja mallien hyödyntämiselle esimerkiksi kustannuslaskentaa varten. Julkaistun mallin puutteellisesta dokumentoinnista
johtuvista seurauksista vastaa virheen tekijä suunnittelusopimusten ja yleisten sopimusehtojen määrittelemässä laajuudessa.2
2.1.3 Tietomallihankkeen koordinointi ja osapuolten vastuut
2.1.3.1 Tilaajan tehtävät
Tilaajan ensisijaisena tehtävänä on tehdä päätökset tietomallintamisen tavoitteista, käytöstä ja laajuudesta hankkeessa, sekä vastata hankkeen suunnittelun johtamisesta ja lähtötietojen toimittamisesta. Tilaajan intressinä on myös varmistaa, että toteutusta varten
saadaan hyvälaatuiset suunnitelmat. Huonosta suunnitelmien laadusta aiheutuvat kustannukset koituvat lopulta pääsääntöisesti tilaajan hoidettaviksi, pois lukien selkeät
suunnitteluvirheet, jotka suunnittelija sopimuksensa mukaisesti joutuu korvaamaan.
Ongelmat suunnitelmissa voivat aiheuttaa viivästystä aikatauluihin, tai pahimmillaan
kasvattavat rakennuksen käytöstä aiheutuvia kustannuksia vuosiksi eteenpäin.3 Siksi
myös tilaajan on usein järkevää varmistaa tietomallien oikeellisuus laadunvarmistusme-
1
YTV2012, Osa 1.
YTV2012, Osa 1.
3
YTV2012, Osa 6.
2
15
nettelyin. Laadunvarmistuksen lisäksi tilaajan tulee valvoa että mallien tietosisällöt ja
vaatimukset vastaavat sopimuksia ja aikatauluja kussakin hankkeen vaiheessa.
2.1.3.2 Pääsuunnittelijan tehtävät
Myös tietomallinnettavassa hankkeessa pääsuunnittelija on henkilö, joka vastaa suunnittelun kokonaisuudesta ja sen laadusta. Keskeiset tietomallintamiseen liittyvät tehtävät
Maankäyttö- ja rakennuslain sekä Suomen rakentamismääräyskokoelman osan A2 mukaan ovat:1
• Pääsuunnittelija vastaa suunnittelun kokonaisuudesta, suunnitelmien riittävästä laadusta ja laajuudesta.
• Pääsuunnittelija varmistaa että lähtötiedot ovat käytettävissä, ristiriidattomat ja ajan
tasalla sekä saattaa ne suunnittelijoiden tietoon.
• Pääsuunnittelija huolehtii eri alojen suunnittelijoiden yhteistyön järjestämisestä.
• Pääsuunnittelija huolehtii, että tarvittavat suunnitelmat tehdään ja että suunnitelmat on
todettu yhteensopiviksi ja ristiriidattomiksi sekä huolehtii muutossuunnittelun yhteensovittamisesta.
• Pääsuunnittelija huolehtii että rakennuslupa-asiakirjat, erityissuunnitelmat ja selvitykset on laadittu ja toimitettu rakennusvalvontaviranomaiselle kunnan ohjeiden mukaisesti.
• Pääsuunnittelija huolehtii, että laaditussa aikataulussa on suunnittelulle varattu riittävästi aikaa.
• Lisäksi pääsuunnittelija antaa energiatodistuksen (Laki rakennuksen energiatodistuksesta).
Etenkin laajemmissa hankkeissa mallien yhdistämis- ja tarkastusmenettelyt ovat paljon
aikaa vieviä ja vaativat riittävästi IT-osaamista, joten erinäisten tietomallintamiseen
liittyvien tehtävien hoitoon on hankkeissa muodostettu tietomallikoordinaattorin rooli.
Yleisesti tietomallikoordinaattorin tehtävät ovat osin pääsuunnittelijan tehtävien kanssa
1
Kallio, T. 2013. s. 78
16
päällekkäisiä, mutta luonteeltaan usein teknisiä. Hankkeen laajuudesta riippuen, myös
pääsuunnittelija voi hoitaa tietomallikoordinaattorin tehtäviä. Tietomallikoordinaattori
huolehtii yhdistelmämallien kokoamisesta ja raportoi havaitsemansa virheet pääsuunnittelijalle ja muille suunnittelijoille. Eri suunnittelualojen mallien päivittämisestä ja suunnitelmien yhteensovittamisesta huolehtiminen ja muutostilanteiden valvonta on kuitenkin tehtäväluettelon mukaisesti pääsuunnittelijan vastuulla1, joten käytännössä pääsuunnittelijan tulee käydä läpi laaditut tarkastusraportit suunnitteluryhmän kanssa suunnittelukokouksissa, tai erikseen järjestetyissä tietomallikokouksissa. Jako pääsuunnittelijan
ja tietomallikoordinaattorin tehtävien välillä tulisi tehdä mahdollisimman aikaisessa
vaiheessa. Valitusta tehtäväjaosta huolimatta pääsuunnittelijan ja tietomallikoordinaattorin välisen yhteistyön tulisi olla tiivistä hankkeen alusta lähtien. Esimerkiksi pääsuunnittelijalle asetettu vaatimus suunnitteluun varatun ajan riittävyydestä on hyvä selvittää
yhteistyössä, huomioiden tietomallinnetun hankkeen erityispiirteet, kuten tilaajan päätöksentekopisteet, tietomallien tietosisällön riittävyys ja tietomallitoimitusten oikeaaikaisuus päätöksentekopisteitä varten.2
2.1.3.3 Suunnittelijan tehtävät
Huolimatta tilaajan tai pääsuunnittelijan tietomallien laadunvarmistuksesta, suunnittelija
on kaikissa tilanteissa vastuussa toimittamiensa tietomallien laadusta ja myös tietosisällöstä. Vastuu on siis virheen tekijällä eikä sillä, joka ei virhettä huomannut.3 Käytännössä suunnittelijan tuleekin järjestelmällisesti tehdä laadunvarmistusta suunnitelmiensa
osalta suunnittelutyön aikana. Lemminkäinen Talo Oy:n hankkeissa suunnittelutoimistoilta on edellytetty hyväksytty laatujärjestelmä jonka mukaisesti suunnittelun laatua
valvotaan, tai erillinen selvitys toimiston laadunvarmistusmenettelyistä. Myös tietomallikoordinaattorin tekemissä tarkastuksissa havaittujen puutteiden korjaaminen on suunnittelijan vastuulla. Laadunvarmistuksen lisäksi suunnittelijan tulee myös omalta osaltaan huolehtia, että hänellä on käytössään suunnittelussa tarvittavat lähtötiedot.4
Suunnittelun käynnistyessä kunkin suunnittelualan on nimettävä suunnittelualakohtaiset
vastuuhenkilöt tietomallintamistehtäviä koskien. Vastuuhenkilöinä voivat toimia kysei-
1
YTV2012, Osa 1.
YTV2012, Osa 11.
3
YTV2012, Osa 6.
4
RakMK A2. 2002.
2
17
sen suunnittelualan vastuulliset suunnittelijat tai suunnittelutoimistossa tietomallinnuksesta vastaava henkilö. YTV2012:n osassa 11 on lueteltu esimerkkinä suunnittelualakohtaisen vastuuhenkilön tehtäviä:

toimii yhteyshenkilönä tietomallintamiseen liittyvissä asioissa

koordinoi oman suunnittelualan tietomallinnustehtäviä sovitusti

ohjeistaa omaa ryhmäänsä sovituista projektin pelisäännöistä

osallistuu projektin tietomalliohjeen päivittämiseen

kommunikoi tehokkaasti muiden suunnittelualojen kanssa rajapintoihin, tiedonsiirtoon, pelisääntöihin ja yhteistyöhön liittyen

osallistuu tietomallinnuspalavereihin (yhdessä suunnittelualan vastuullisen
suunnittelijan kanssa)

huolehtii suunnittelualakohtaisesta laadunvarmistuksesta, tietomalliselostusten
laadinnasta ja tiedonhallinnasta

varmistaa ja tarkistaa omalta osaltaan yhdistelmämallien toimivuuden ja suunnittelumallien yhteensopivuuden.
Erikoisalan kokonaisuudesta vastaavan suunnittelijan (vastaava erityissuunnittelija) on
oman suunnittelutehtävänsä lisäksi huolehdittava siitä, että erillistehtävinä laaditut rakenteiden, rakennusosien tai järjestelmien suunnitelmat muodostavat keskenään toimivan kokonaisuuden.1 Käytännössä tietomallinnetussa hankkeessa vastaava erityissuunnittelija siis vastaa esimerkiksi tuoteosakauppana hankittujen rakennusosien suunnittelun yhteensovittamisesta omiin suunnitelmiinsa.
2.1.3.4 Tietomallikoordinaattori
Tietomallihankkeen teknisestä hallinnoinnista ja koordinoinnista on muodostunut merkittävä työtehtävä hankkeisiin. Tietomallikoordinaattorin tehtävät ovat sekoitus hankkeen johtamisen, teknisen asiantuntijan ja pääsuunnittelijan tehtäviä, joten käytännössä
ne täytyy määrittää hankekohtaisesti riippuen siitä, kenen vastuualueeseen ne nimellisesti liitetään. Esimerkiksi tilaajan täytyy hankkeen alussa määrittää tietomallin käyttötarkoitukset ja sitä kautta vaatimukset tietomalleille. Etenkin jos suunnittelun tilaajana
1
RakMK A2. 2002.
18
toimii urakoitsija, vaatimukset mallien hyödyntämistä varten voivat olla esimerkiksi
pääsuunnittelijalle mahdotonta määritellä.
Yleisten tietomallivaatimusten 2012 osan 11 mukaan tietomallikoordinaattori on riittävän pätevä ja osaava henkilö, joka huolehtii, ohjeistaa, koordinoi ja ohjaa tietomallinnustehtäviä koko hankkeen ajan yhteistyössä pääsuunnittelijan kanssa, sekä raportoi
hankkeen suunnittelujohdolle sovitusti. Tehtäviin voi YTV2012:n mukaan sisältyä yhdistelmämallien tuottaminen ja tietoteknisen yhteensovittamisen varmistaminen. Kuitenkin useasti1 tietomallikoordinaattori käsitetään nimenomaan henkilöksi, joka vastaa
mallien yhdistämisestä ja tarkastamisesta. Sami Tuuhea toteaakin pääsuunnittelijakoulutuksen tutkielmassaan tietomallikoordinaattorin tehtävien olemassaolon ja määrittelyn
olevan vielä veteen piirretty viiva.2
2.2 Yhdistelmämallien käyttö tietomallinnetussa rakennushankkeessa
2.2.1 IFC-tiedonsiirtostandardi
IFC (Industry Foundation Classes) on kansainvälinen avoin tiedonsiirtostandardi, jota
kehittää International Alliance for Interoperability (IAI). IAI tunnetaan nykyisin nimellä
buildingSMART International. Standardi on kehitetty edistämään rakennusalan ja kiinteistönpidon toimijoiden välistä yhteistyötä tarjoamalla tavan siirtää tietoa eri tietojärjestelmien välillä ohjelmistoriippumattomasti.3
1
Mäki, T. et al. 2012.
Tuuhea, S. 2010. s. 36
3
buildingSMART International, http://www.ifcwiki.org. Viitattu: 11.3.2013.
2
19
Kuva 2. IFC-tiedonsiirto. Lähde: RAKLI ry. 2003. s. 4
IFC-tiedonsiirron toimintaperiaate on, että tiedon tuottamiseen käytetty ohjelmisto esikäsittelee tiedot ohjelman omasta tiedontallennusmuodosta IFC-tiedostomuotoon, ja
tietoa vastaanottava ohjelmisto käsittelee tiedot IFC-muodosta omaan sisäiseen muotoonsa, ellei se ole IFC. Tiedonsiirron pohjalla ovat ohjelmiin toteutetut IFC-standardin
mukaiset rajapinnat, joiden avulla IFC-muotoista rakennuksen tuotemallitietoa luetaan
ja kirjoitetaan.1 Nämä rajapinnat määrittelevät siis siirretyn tuotemallitiedon tietosisällön ohjelmasta toiseen. Geometriatiedon lisäksi IFC-malli sisältää tiedot objektien sijainnista, suhteesta toisiin objekteihin, ominaisuudet, joita voivat olla esimerkiksi objektin materiaalitiedot, sekä taustatiedot. Jokainen objekti yksilöidään niille luodulla
GUID-tunnuskoodilla.2
IFC-standardin tavoitteena on kattaa rakennushankkeiden ja rakennusten koko elinkaaren aikainen tiedonsiirto ja tiedon yhteiskäyttö. Tällä hetkellä IFC on onnistunut tavoitteessaan avoimista tiedonsiirtoformaateista parhaiten, ja onkin laajasti käytössä tietomallinnetuissa projekteissa Suomessa ja maailmalla. IFC-standardia kehitetään jatkuvasti buildingSMART:in johdolla, ja sen kattavuus laajenee aina uuden version julkaisemisen myötä. Tällä hetkellä on yleisesti käytössä standardin versio 2x3 ja IFC4 (aik.
2x4) julkaistiin 12.3.2013.3 Versiot eivät ole keskenään täysin yhteensopivia, joten pro-
1
Penttilä, H. et al. 2006b.
3
buildingSMART International, http://www.buildingsmart-tech.org. Viitattu: 13.3.2013.
2
20
jektin aloituksessa tuleekin sopia käytettävä versio tiedonsiirron ongelmien välttämiseksi. Version 2x3 tärkeimmät ominaisuudet käytön kannalta ovat:1

Arkkitehdin tilamalli ja sen sisältämät tilaobjektit,

rakennuspaikan kuvaus ja lähtötilanne,

tuotemalli rakennuksesta ja rakennukseen liittyvät rakennusosat ominaisuuksineen, sekä niiden relaatiot toisiin rakennusosiin (esim. kerrokset, lohkot, muodot
ja materiaalit),

rakenteelliset osat (esim. anturat, laatat ja pilarit) ja rakennuksen rakenteellinen
analyysi,

taloon asennettavien järjestelmäosien tiedot ja ominaisuudet (esim. IVpäätelaitteet, sähkökeskukset),

sähkö- ja automaatiokaapelointi sekä LVI-putkitukset,

sekä kiinteistönpidon tiedot.
IFC-muotoa käytetään toistaiseksi ainoastaan tietomallimuotoisen tiedon siirtämiseen
eri ohjelmien välillä, joten kaikkia hankkeen tiedonsiirtotarpeita ei formaatilla pystytä
täyttämään. Esimerkiksi piirustusmuotoista tietoa ei IFC-muodossa pystytä siirtämään,
joten tällä hetkellä rakennushankkeissa tarvitaan myös muita tiedonsiirtotapoja.2
Aikaisemmissa tutkimuksissa IFC:n käytöstä on todettu, että jo nykyisin käytössä oleva
IFC-standardi 2x3 on tarpeeksi kattava osapuolten väliseen tiedonsiirtoon projekteissa.
Informaatiota katoaa tai siirtyy väärin aina IFC-muunnon aikana, mutta useimmissa
tapauksissa IFC-mallin käyttäjä ei edes tarvitse kaikkea osamallien sisältämää informaatiota. Tiedonsiirto-ongelmat johtuvat pääasiassa suunnitteluohjelmistojen ongelmista
IFC-käännön implementoinnissa, tai käyttäjän valitsemista IFC-käännön asetuksista.3,4,5
Käytännössä on huomattu, että eri ohjelmistot tuottavat ja lukevat IFC-tiedostoja eritasoisesti. Tiedon katoamisesta aiheutuva haitta riippuu IFC-tiedoston käyttötarkoituksesta: Esimerkiksi mallien välisissä törmäystarkasteluissa geometria ja rakennusosien
identiteettitieto on riittävää, kun taas mallien käyttö simulointeihin asettaa vaatimuksia
myös tilatietojen oikeelliselle siirtymiselle.
1
Shen, W. et al. 2010. s. 202
Penttilä, H. et al. 2006b.
3
Niemi, H. 2011. s. 56
4
van Berlo, L. A. H. M. 2012. s. 5
5
2
21
Kuva 3. Tiedon häviäminen siirrettäessä tietoa IFC-muodossa ohjelmasta toiseen. Lähde: Penttilä, H. et al. 2006b. s. 38
IFC-tiedostoja on mahdollista tuottaa erilaisilla kääntömoduuleilla. IFC-käännön asetukset on valittava käyttötarkoituksen mukaan, kokemukseen tai ohjelmistotoimittajien
ohjeisiin perustuen. Yhdistelmämalleja tuottaessa IFC-tiedostojen tietosisältöjen tulee
olla tarkoituksenmukaisia, ettei niiden käytöstä tule liian raskasta tietokoneilla ja etteivät tiedostokoot kasva liian suuriksi. Esimerkiksi rakennemallin raudoitteita tai teräsrakenteiden liitososia harvemmin tarvitsee yhdistelmämalleissa.
2.2.2 Natiivimallit
Kuten edellisessä luvussa todettiin, IFC-tiedonsiirtoformaattia ei pystytä toistaiseksi
käyttämään rakennushankkeiden kokonaisvaltaisessa tiedon tuottamisessa ja -siirrossa.
Natiivimalleilla tarkoitetaan suunnittelijoiden käyttämien ohjelmistojen alkuperäisten
tiedostomuotojen mukaisia malleja.
Tietoa harvemmin pystytään siirtämään toisiin
suunnitteluohjelmistoihin natiivimuodossa, elleivät ohjelmistot kuulu samaan tuoteperheeseen.
Natiivimalleista tuotetaan suunnitteludokumentit ja saadaan esimerkiksi tarkempaa
määrätietoa kuin IFC-malleista. Toisin kuin IFC-tiedostoja, natiivimalleja voidaan
muokata erilaisiin tarpeisiin, kuten esimerkiksi työmaasuunnitelmaa tai tuotannon aikataulutusta varten. Ainoastaan natiivimalleihin on mahdollista päivittää myös rakennuksen ylläpidonaikaiset käyttäjämuutokset, mikäli malleja hyödynnetään ylläpidon aikana.
Suunnittelijoiden huoleen natiivimallien luovuttamisesta tilaajalle on usein liittynyt
22
mallien sisältämien yrityskohtaisten objektikirjastojen ja työkalujen päätyminen kolmansille osapuolille.1
Aikaisemmin on mielletty, että suunnittelija on vapaa valitsemaan käyttämänsä työkalut
suunnittelutehtävänsä suorittamiseen. Yleensä julkisissa hankkeissa ainoana vaatimuksena suunnitteluohjelmistoille on vähintään IFC 2x3 sertifiointi, mutta usein rakennusliikkeet kehittävät omia tietomalliprosessejaan tiettyjen ohjelmistojen ympärille, jolloin
niiden käyttöä voidaan edellyttää myös suunnittelijoilta.2 Lemminkäinen Talo Oy:ssä
suunnittelijoille on määritelty seuraavat suunnitteluohjelmat, joista poikkeaminen käsitellään tapauskohtaisesti:

Arkkitehtisuunnittelu: ArchiCAD (Graphisoft / Nemetschek Group), toissijaisesti Revit Architecture (Autodesk)

Rakennesuunnittelu: Tekla Structures (Tekla), toissijaisesti Revit Structure (Autodesk)

LVISA-suunnittelu: MagiCAD (Progman), poikkeustapauksissa CADS Planner
(Kymdata)

Mallien yhdistäminen: Solibri Model Checker (Solibri)
Suunnitteluohjelmistoista julkaistaan vuosittain uusia versioita, mutta niiden käyttöönotto kesken projektin on sovittava erikseen ja testattava huolellisesti, etteivät yhteensopivuusongelmat haittaa tiedonsiirtoa.
2.2.3 Tiedonsiirto projektissa ja mallien yhdistäminen
Tiedonsiirto projekteissa toteutetaan kuvassa 4 esitetyn prosessin mukaisesti. Kuten
aikaisemmin todettiin, tietoa katoaa aina IFC-käännön aikana. Toisaalta natiivimalleja
sekä IFC-malleja ja niistä tuotettua yhdistelmämallia käytetään eri tarkoituksiin. Kun
suunnittelijat tallentavat osamallinsa keskitetysti sekä IFC- että natiivimuodossa, tietoa
ei häviä missään vaiheessa prosessia. Keskitettynä tallennuspaikkana voi toimia projektipankki tai tietomallipalvelin.
1
2
YTV2012, Osa 11.
YTV2012, Osa 1.
23
Kuva 4. Mallien tiedonsiirto. Kuvassa nuolet kuvaat tiedon kulun suuntaa. Lähde: van
Berlo, L. A. H. M. 2012. s. 5
IFC-tiedonsiirron avulla voidaan välittää merkittävästi enemmän ja laadukkaampaa tietoa osapuolten välillä kuin perinteisillä dokumenteilla. Toistensa tietoja hyödyntämällä
suunnittelualojen välinen suunnitteluprosessi tehostuu ja väärien tulkintojen mahdollisuudet pienenevät. Suunnitelmien tarkastelu IFC-muodossa myös antaa mahdollisuuden
nähdä suunnittelun eteneminen konkreettisemmin ja samalla saadaan useampia henkilöitä havainnoimaan mahdollisia ongelmia.1 Samalla kasvaa myös vaatimus tiedon oikeellisuudelle, minkä vuoksi hallitun julkaisuprosessin ja osapuolten laadunvarmistusmenettelyiden merkitys korostuu.
IFC-tiedosta saatavan palautteen (kaareva nuoli kuvassa 4.) pohjalta tehdyt korjaukset ja
muutokset tehdään aina suunnittelualojen alkuperäisiin malleihin. Tilannetta jossa muu1
YTV2012, Osa 6.
24
tokset päivitetään IFC-tiedostoista takaisin natiivimuotoon käännettyihin malleihin kutsutaan round tripiksi,1 joka entisestään lisää mallien tietosisällön hävikkiä. Malleja tai
yhdistelmämallia hyödynnettäessä osapuolten tulisi aina saattaa tieto mahdollisista virheistä ja puutteista alkuperäisen suunnittelijaosapuolen tietoon, eikä itse pyrkiä korjaamaan hyödyntämiään malleja.
2.2.3.1 Mallien julkaisu ja yhdistäminen
Viralliset julkaisut
Tietomallien päivitykset ja julkaisut tapahtuvat hankkeissa suunnitteluaikataulun mukaisesti. Päivitysrytmi sovitaan aina hankekohtaisesti suunnittelun käynnistyessä ja kuvataan projektin tietomalliohjeessa. Tietomallipohjaisessa suunnitteluprosessissa ei voida erottaa suunnitelmia ja tietomalleja, joten tiedon siirtymisen varmistamiseksi ja turhan suunnitteluiteroinnin vähentämiseksi mallien päivitysrytmi tulee asettaa sopivaksi
hankkeen laajuus ja vaativuus huomioiden. Päivitysrytmiä muokataan tarvittaessa hankkeen edetessä suunnittelutilanteen vaatiman tiedonvaihtotarpeen mukaisesti.
Tietomallinnuksen päivitystaajuudeksi hankkeen eri vaiheissa on aikaisemmissa opinnäytetöissä ehdotettu seuraavaa:2,3

Ehdotus- ja yleissuunnitteluvaiheen tietomallien päivitys suunnitteluratkaisujen
tarkastelua ja päätöksentekoa varten sekä energia- ja olosuhdesimuloinnin ja
kustannuslaskennan pohjaksi noin 2-4 viikon välein

Toteutussuunnitteluvaiheen tietomallien päivitys tapahtuu 1-2 viikon välein.
Tarvittaessa rakennemalli päivitetään elementtituotantoa varten 1 viikon välein.

Tuotantovaiheessa tietomallit päivitetään aina olennaisten muutosten jälkeen.

Mallien yhdistäminen yhdistelmämalliksi tehdään eri suunnittelualojen osamallien päivityksen jälkeen.
1
Jørgensen, K. A. et al. 2008.
Niemi, H. 2011.
3
Niskakangas V. 2013.
2
25
Kuva 5. Mallien julkaisu Lemminkäinen Talo Oy:ssä. Lähde: Niemi, H. 2011. s. 84
Lemminkäinen Talo Oy:n elinkaarihankkeissa on käytetty seuraavanlaista julkaisuprosessia:1
1. Suunnittelijat tarkastavat omat osamallinsa visuaalisesti ja ohjelmistojen tarkastustyökaluja käyttäen, korjaavat suunnitteluvirheensä sekä tallentavat mallin
projektipankkiin sekä natiivi- että IFC-muodossa. Samalla suunnittelija täyttää
omasta tarkastuksestaan tarkastusraportin ja tietomalliselostuksen, josta käy ilmi
mm. mallin statustieto ja tietomalliohjeesta poikkeavat mallinnustavat.
2. Tietomallikoordinaattori tarkastaa, että suunnittelualojen osamallit noudattavat
sovittua mallinnustapaa ja ne voidaan yhdistää.
3. Tietomallikoordinaattori lisää yhdistelmämallin projektipankkiin.
4. Tietomallikoordinaattori tekee visuaalisen tai ohjelmallisen tarkastuksen säännöstöjä käyttäen ja kokoaa raportin olennaisimmista törmäyksistä, ristiriidoista
ja ongelmista.
1
Niskakangas V. 2013.
26
5. Suunnittelijat käyvät yhdistelmämallin raportin läpi ja korjaavat omat suunnittelualansa virheet. Suunnittelualojen väliset ristiriidat ratkaistaan pääsuunnittelijan
johtamassa yhdistelmämalli- tai suunnittelijakokouksessa.
6. Suunnittelijat korjaavat oman suunnittelualansa virheet.
7. Yhdistelmämallikokouksia järjestetään riittävin väliajoin. Yhdistelmämalli käydään läpi ja keskitytään virheraportissa ilmenneisiin ongelmiin.
Työmallit
Viralliset mallijulkaisut toimitetaan aina projektiaikataulun mukaisesti ja tietomallipohjaisessa suunnitteluprosessissa piirustuksien tulee vastata aina mallijulkaisuja. Etenkin
hankkeissa joissa mallien julkaisusykli on asetettu pidemmäksi (esim. asuntorakentaminen), on usein tarkoituksenmukaista jakaa suunnittelutietoa tietomallipohjaisesti useammin. Virallisten mallijulkaisujen ulkopuolisia, projektipankkiin tallennettuja malleja
kutsutaan työmalleiksi. Työmallit ovat osa tietomallintamisen mahdollistavaa joustavaa
ja nopeaa tiedonvaihtoa ja ne voivat kuvata esimerkiksi aiottua suunnitteluratkaisua,
tilavarauksia tai tiettyjen yksityiskohtien havainnollistamista.1 Työmallien ei tarvitse
välttämättä käydä läpi virallisissa julkaisuissa käytettyä laadunvarmistusprosessia, kunhan toimintatapa ja siitä mahdollisesti aiheutuvat rajoitukset ovat tietoa hyödyntävien
osapuolten tiedossa.2 Kuitenkin aina julkaistaessa työmalleja, suunnittelijan on täytettävä mallin statustiedosta ja rajoituksista kertova tietomalliselostus. Mallien lähettäjän
tulee myös selkeästi viestiä projektipankissa muille osapuolille, että kyseessä on työmalli. Työmalleja voidaan tallentaa projektipankkiin aina tilanteen mukaan niin sovittaessa, mutta myös niille olisi hyvä sopia tietty julkaisusykli virallisten mallijulkaisujen
väliin.
Mallien tarkastus käytännössä
Mallien julkaisuprosessissa on luotettu siihen, että suunnittelijat tekevät omille malleilleen tarvittavat laadunvarmistus- ja korjaustoimenpiteet aina ennen mallien julkaisua ja
yhdistämistä. Esimerkiksi suunnittelualakohtaisten mallien sisäisiin törmäyksiin tai oikeaoppiseen mallinnustapaan ei tietomallikoordinaattorin ole oletettu ottavan kantaa,
1
2
YTV2012, Osa 3.
YTV2012, Osa 3.
27
vaan tarkastus suoritetaan suunnitteluryhmän keskinäisen laadunvarmistuksen näkökulmasta. Yleisten tietomallivaatimusten osassa 6 on esitetty vähimmäisvaatimuksena
tehtäväksi seuraavat tarkastukset yhdistetylle mallille:

Sovitut tietomallit ovat käytettävissä

Malleista on toisiaan vastaavat versiot

Mallit on kohdistettu oikein keskenään

TATE mahtuu pystykuiluihin ilman törmäyksiä

TATE mahtuu vaakareiteille ilman törmäyksiä

TATE-järjestelmillä ei ole keskinäisiä leikkauksia

Alaslasketut katot suhteessa TATE:an ovat kunnossa

TATE ei törmää pilareiden kanssa

TATE ei törmää palkkien kanssa

TATE ei törmää muiden rakenteiden kanssa

Laatoissa on aukot pystykuilujen kohdalla

Rakenne- ja arkkitehtimallin rakenteet vastaavat toisiaan

Rakenne- ja arkkitehtimallin aukot ovat vastaavilla kohdilla
2.2.4 IFC- ja yhdistelmämallien käyttökohteet
2.2.4.1 Havainnollistaminen
IFC-malleja ja niistä tuotettuja yhdistelmämalleja käytetään projekteissa suunnitelmien
havainnollistamiseen eri osapuolille. Tehtäessä havainnollistamisia tiettyihin tarkoituksiin, kuten markkinointiin tai suunnitelmien havainnollistamiseen tilojen käyttäjälle,
tulee vaadittu havainnollistamisten määrä ja laatu olla määriteltynä tarjouspyynnöissä ja
suunnittelusopimuksissa projektikohtaisesti. Vaikka tietomallit sisältävät suuren osan
havainnollistamisessa tarvittavista lähtötiedoista, eivät ne aina mahdollista halutun lopputuloksen saavuttamista ilman lisätyötä.1 Havainnollistamisten tarve ja tietomallien
tietosisältö eivät aina myöskään kohtaa ajallisesti, sillä mallien sisältämä tieto määrää
havainnollistamisten tarkkuustason. Esimerkiksi hankkeen alkuvaiheessa tietomallien
tietosisältö voi olla riittämätön, kun taas toteutussuunnitteluvaiheessa havainnollistamista voidaan käyttää aiempia vaiheita paremmin, koska mallin tiedot riittävät usein varsin
1
YTV2012, Osa 1.
28
korkeatasoiseenkin havainnollistamiseen.1 Havainnollistaminen voidaan jakaa kahteen
päämuotoon, visuaaliseen ja tekniseen havainnollistamiseen.
Visuaalinen havainnollistaminen
Visualisointi kuvaa suunnittelijan näkemystä hankkeesta ja sen suunnitteluratkaisuista. 2
Rakennusta tai sen tiloja voidaan visualisoida hankkeen sidosryhmille fotorealistisen
tarkasti. Mallipohjaiset visualisoinnit tukevat tietomallinnetun suunnittelun dynaamista
luonnetta, mahdollistaen eri ratkaisuvaihtoehtojen vertailun. Ohjelmistoissa on mahdollista lukita esimerkiksi valaistus-, materiaali- ja sävytys- eli renderöintivalintoja, jolloin
visualisointikuvien tuottaminen on tehokasta, vaikka mallin geometria muuttuisi suunnitteluprosessin aikana.3 Perinteisesti visualisoinneissa on käytetty arkkitehdin tai rakennesuunnittelijan malleja.
Visualisointeja käytetään hankkeissa päätöksenteon tukena, mikä lisää niiden merkitystä. Suunnittelua koskevaan arviointiin osallistuu aina myös henkilöitä, joilla ei ole rakennusalan koulutusta. Pohjapiirrosten, leikkausten ja julkisivukaavioiden lukeminen
vaatii kokemusta, jotta tarkastelija voi ymmärtää suunnitelmien sisällön. Tällöin havainnekuvat ja visualisoinnit saavat suuren painoarvon suunnitelmiin liittyviä arviointeja tehtäessä. Samasta syystä suunnitelmien valmiusasteesta riippuen tulee harkita, onko
varhaisessa vaiheessa syytä valita visualisointeihin luonnosmainen ”käsin piirretyn”
näköinen ulkoasu, jotta keskeneräisiä suunnitelmia ei pidetä valmiina.4
Tietomallien hyödyntäminen visualisoinneissa tulee arvioida aina projektikohtaisesti.
Koska mallin tietosisältö määrittää myös visualisointien tason, ei suunnittelumallin
tarkkuustaso ole aina välttämättä riittävä kaikkiin visualisoinnin tarpeisiin. Esimerkiksi
monimuotoiset kipsikoristeet eivät ole tarpeellisia muussa mallin hyötykäytössä, vaan
kuormittavat mallia turhaan. Myöskään tietomallien päivittäminen visualisointeja ajatellen ei aina ole järkevää, sillä usein niitä käytetään vain hankkeen tietyissä vaiheissa.5
Projektikohtaisesti voidaan harkita erillisen visualisointimallin tuottamista, mikä olisi
1
YTV2012, Osa 1.
YTV2012, Osa 8.
3
YTV2012, Osa 8.
4
Aaltonen, M. 2012. s. 5-6
5
YTV2012, Osa 8.
2
29
kevyempi päivittää tarpeen mukaan. Pelkästään visualisointia varten luodulle mallille ei
ole pinta- ja muototietojen lisäksi muita tietosisältövaatimuksia.
IFC-pohjaiseen tiedonsiirtoon liittyy jonkin verran rajoituksia, mutta myös mahdollisuuksia suunnitelmien visualisointeihin liittyen. Sen avulla eri suunnittelijoiden malleista voidaan tuottaa visualisointeja, joilla pystytään havainnollistamaan tuleville käyttäjille esimerkiksi tekniikan sijoittumista sairaalaympäristössä.
Kuva 6. Järvenpään Viljan arkkitehtimallista tuotettu visualisointi markkinointiaineistoa varten. Lähde: Arkkitehtitoimisto Kaipainen Oy, www-sivut. Viitattu: 23.5.2013.
Tekninen havainnollistaminen
Toinen havainnollistamisen muoto on tekninen havainnollistaminen, jossa yhdistelmämallia käytetään kommunikaatiovälineenä suunnitteluryhmälle, tilaajalle, hankkeen
johdolle ja työmaalle. Teknisen havainnollistamisen käytön etuja ovat suunnitelmien
laadun optimointi, ratkaisuvaihtoehtojen vertailun helpottaminen ja eri osapuolten vuorovaikutuksen lisääminen. Teknisessä havainnollistamisessa esitysmateriaalissa keskitytään fotorealistisuuden sijaan havainnolliseen esitystapaan. Esimerkiksi värit kuvaavat
erilaisia järjestelmiä materiaalien sijasta, jolloin on helpompi tunnistaa eri suunnittelualojen objektit ja ovatko ne mallinnettu oikeilla työkaluilla. Katselu- ja laadunvarmistusohjelmissa arkkitehdin mallinnusosat voidaan pääosin visuaalisesti tunnistaa muo-
30
tonsa perusteella, ja ne ovat väriltään harmaan tai muun haalean värin eri sävyjä. Talotekniikan ja rakennesuunnittelijan malleissa käytetään havainnollisuuden vuoksi voimakkaita ja tunnistettavia värejä. Kaikki värit ovat symbolisia ja määräytyvät johdonmukaisesti mallinnusosaryhmien mukaan.1 Lisäksi ohjelmistot tunnistavat mallien
tyyppitiedon, geometrian ja sijainnin. Suunnitelmien tekninen havainnollistaminen toteutetaan lähes poikkeuksetta erilaisilla katselu- ja laadunvarmistustyökaluilla, mitkä
mahdollistavat myös liikkumisen mallien sisällä.
Tekninen havainnollistaminen toimii niin pääsuunnittelijan kuin suunnittelunohjauksen
tehtävien suorittamisen tukena. Yhdistelmämallien avulla suunnitelmia ja niiden ratkaisuvaihtoehtoja voidaan havainnollistaa hankkeen eri vaiheissa niin tila- kuin rakennusosa- ja järjestelmämallien osalta. Yhdistelmämalleja käytetään suunnittelija- ja suunnittelukokouksissa kollektiivisesti suunnittelun yhteensovittamiseen ja ongelmakohtien
ratkaisemiseen, sekä myös teknisenä materiaalina päätöksenteon tueksi. Myös työmaakokouksissa yhdistelmämallit toimivat kommunikointivälineenä ja niitä hyödynnetään
ongelmakohtien käsittelyyn ja tuotantotilanteen vertaamiseen suunnitelmiin.
Lähtökohtaisesti mallinnus vähentää ongelmia työmaalla. 3D-pohjainen suunnittelu
tarkentaa mm. korkojen mitoitusta ja luo paremmat lähtökohdat detaljien, risteilyjen ja
liittymien suunnittelulle jo ennen rakentamisvaiheen alkua. Perinteisissä 2Dpiirustuksissa järjestelmäosien korkotason muutokset esitetään muutoksen suunnan ilmaisevilla merkeillä ja korkoluvulla, mikä joissain tapauksissa voi vaikeuttaa suunnitelmien hahmottamista ja huonontaa luettavuutta. Yhdistelmämalleista voidaan työmaalla ottaa asentajille erilaisia leikkauksia ja kuvankaappauksia tiloista joissa tekniikkaa on paljon, kuten IV-konehuoneista. Kun piirustukset on laadittu malleista, suunnitelmaratkaisuja ja niiden sijoittumista muihin rakenteisiin voidaan tarkastella työmaalla
käytännössä reaaliaikaisesti. Koska tietomallinnetuissa suunnitelmissa esimerkiksi järjestelmäreitit on kuvattu aikaisempaa tarkemmin, kasvaa myös vaatimus tiedon oikeellisuudelle. Kun asennukset tehdään tietomallien mukaisesti, on mallien absoluuttinen
tarkkuus tärkeää.
1
YTV2012, Osa 8.
31
Kuva 7. Mallinkatseluohjelmilla voidaan esimerkiksi tarkastella huoltoreittien mitoitusta ylläpitojaksoa varten. Kastellin monitoimitalo, Oulu. Suunnittelutilanne 13.5.2013.
2.2.4.2 Tilavaraukset ja vaatimusten hallinta
Tilaajan on saatava tietoa investointiprosessinsa tueksi hankkeen kaikissa eri vaiheissa.
Hanke- ja ehdotussuunnitteluvaiheessa suunnitelmien välinen vertailu tai suunnitelmien
vaatimuksenmukaisuuden selvittäminen toteutetaan tilapohjaisesti. Perinteisessä suunnitteluprosessissa hankkeen alkuvaiheessa rakennukselle asetetut vaatimukset usein
muuttuvat, ja vaikka ne olisivatkin alusta asti selvät, tilaajan voi olla vaikeaa varmistaa
että kaikki vaatimukset täyttyvät.1
Tietomallipohjaisessa suunnitteluprosessissa ratkaisuvaihtoehtojen pohjalta voidaan
suorittaa niin kvalitatiivista kuin kvantitatiivista suunnitelmien arviointia.2 Hankkeen
alussa arkkitehti luo suunnittelun lähtötietojen ja vaatimusten perusteella usein tilaryhmämallin, joka tarkentuneiden tavoitemäärittelyiden jälkeen jalostuu tilamalliksi.3 Tilamallien hyödyntämisen edellytyksenä on, että tilat ovat mallinnettu geometrialtaan
1
YTV2012, Osa 8.
3
Palos, S. 2010. s. 25
2
32
oikein. Vaikka mallin tietosisältö on tässä vaiheessa hyvin kevyt, pystytään sen pohjalta
laskemaan erilaisia tunnuslukuja vaatimustenhallintaa varten. Mallien avulla voidaan
tuottaa tilamallista pinta-ala-, tilavuus sekä tehokkuusraportteja, joita voidaan peilata
tilaohjelmaan vaatimustenmukaisuuden toteamiseksi. Lisäksi suunnitelmien kehittyessä
laajuustiedot päivittyvät automaattisesti, mikä mahdollistaa niiden nopeamman hyödyntämisen suunnitelmien arviointiin. 1 Suunnitteluosapuolien vaatimusmalleja tulisi pitää
jatkuvasti yllä suunnitteluprosessin aikana, jotta niitä voidaan myös myöhemmissä
suunnitteluvaiheissa verrata suunnitelmiin.
Tilamallista laskettujen tunnuslukujen avulla voidaan laskea hankkeen alustavia investointi-, käyttö- ja elinkaarikustannuksia aikaisemmin kerätyn kustannustiedon pohjalta.2
Lisäksi tilamallista tuotettujen tunnuslukujen avulla voidaan suorittaa kohteen alustavia
energialaskelmia, mitkä varsinkin tavanomaisissa kohteissa usein tuotetaan pelkästään
pinta-ala- ja tilavuustietoja hyödyntäen.
Tunnuslukujen laskennan lisäksi tilojen geometriatietoa voidaan hyödyntää projektin
alkuvaiheessa IFC-pohjaisesti mm. seuraavien vaatimusten varmentamiseen erilaisilla
ohjelmistokohtaisilla tarkastuksilla:3

Tilojen käyttö ja keskinäiset yhteydet,

esteettömyys,

määräystenmukaisuus,

rakennettavuus,

turvallisuus (paloturvallisuus, poistumisreitit, valvontakameroiden kattavuus),

tilojen toiminnallisuuden hallinta ja arviointi,

laajuus ja määrätietojen hallinta ja arviointi (Luku 2.2.4.7), sekä

talotekniset olosuhde- ja energia-analyysit
Tilapohjainen suunnittelu mahdollistaa myös muiden suunnittelijoiden (mm. rakenneja
TATE-suunnittelijoiden) vaatimusten liittämisen arkkitehdin tilamalliin, mikä edesauttaa vaatimustenhallintaa myös erityissuunnittelun osalta. Projektin myöhemmissä vaiheissa myös erityissuunnittelijat voivat tuottaa tilavarauksensa tietomallipohjaisesti.
1
Rantala, M. 2009. s. 16
Lemminkäinen Talo Oy. BIM-SLU1 – Tietomallien käyttö suunnittelussa. Sisäinen dokumentti.
3
YTV2012, Osa 8.
2
33
Kuva 8. Arkkitehdin tilaryhmämalli. Kastellin monitoimitalo, Oulu. Suunnittelutilanne
13.5.2013.
34
Kuva 9. Tarkastusohjelmien säännöstöillä pystytään myös tarkastamaan esimerkiksi
esteettömyyksiä. Kuvassa punaisella pyörätuolin vaatima 1,5 m kääntösäde WC-tilassa.
2.2.4.3 Suunnitelmien yhteensovittaminen
Yhdistelmämallien ja IFC-tiedonsiirron käyttö projektissa mahdollistaa sen, että suunnittelijat laativat projekteissa suunnitelmansa yhteensopiviksi toistensa malleja hyödyntäen, eikä pelkästään niin että laaditut suunnitelmat sovitetaan yhteen jälkikäteen.1 Lisäksi tietomallipohjainen työskentely parantaa koko suunnitteluprosessin tehokkuutta ja
läpinäkyvyyttä: Suunnittelijaosapuolilla on käytössään samat ajan tasalla olevat ja yhdenmukaiset suunnitelmatiedot, jolloin riski uudelleensuunnittelulle ja turhalle iteroinnille pienenee.
Lähes kaikki suunnitteluohjelmistot tukevat IFC-tiedostojen tuontia suunnittelualan
oman mallin rinnalle, jolloin suunnittelijat voivat käyttää toistensa malleja referensseinä
ja mallintaa omat suunnitelmansa muiden suunnittelualojen geometrian pohjalta. Äärimmäisissä tapauksissa tietyillä suunnitteluohjelmistoilla on mahdollista jopa kääntää
esimerkiksi arkkitehtimallin rakenteita rakennesuunnittelijan malliobjekteiksi. Vakiin1
Lemminkäinen Talo Oy. BIM-SLU8 – Yhdistelmämallin käyttö suunnittelun ohjauksessa. Sisäinen
dokumentti.
35
tunut menetelmä tietomallinnetussa suunnittelussa on visualisoida suunnitelmien yhteensopivuutta yhdistelmämallien katseluohjelmilla, mikä parhaassa tapauksessa on
mahdollista tehdä lähes reaaliajassa.1 Suunnittelutyön ohessa yhteensopivuutta muiden
suunnittelualojen malleihin on myös mahdollista tarkastaa sääntöpohjaisesti tarkastusohjelmistoilla, kuten Solibri Model Checkerillä.
Suunnittelun työkalujen kehittyessä syntyy muutospaineita totuttuihin toimintatapoihin
ja käytäntöihin.2 Tietomallipohjainen työskentely on luonut mahdollisuuksia tehokkaampaan ja virheettömämpään työskentelyyn: esimerkiksi reikäsuunnittelu LVI- ja
rakennesuunnittelijan välillä on mahdollista toteuttaa IFC-pohjaisesti siirtämällä talotekniikan reikävarausobjekteja rakennemalliin, jolloin reikien tarkat sijainnit ovat kaikkien osapuolten varmennettavissa. Uudet toimintamallit voivat kuitenkin hämärtää 2Dpohjaisessa suunnittelussa muodostuneita toimintamalleja ja aiempia vastuurajoja, joissain tapauksissa virheettömämpien suunnitelmien hintana voi olla myös suunnitteluvaiheen aikaisempaa pidempi kesto. Tietomallipohjainen työskentely vaatii usein myös
suunnitteluryhmältä aiempaa tiiviimpää kommunikointia ja menettelytavoista sopimista.
Esimerkiksi perinteisessä alakattosuunnittelussa tuotettu alakattoruudukkojako on hankalasti toteutettavissa tietomallipohjaisesti, ja vaatii edelleen 2D-piirroksia suunnittelun
tueksi.3
1
Niemi, H. 2010. s. 57
Betoniteollisuus Ry, http://www.elementtisuunnittelu.fi. Viitattu: 20.8.2013
3
Järvinen, T. Blogi: http://tietomalli.blogspot.fi. Viitattu: 20.8.2013.
2
36
Kuva 10. Kastellin monitoimitalon katon monimuotoisen geometrian mallintaminen ei
olisi onnistunut ilman referenssimallien käyttöä suunnittelussa. Kuvassa yhdistettynä
arkkitehti- ja rakennemallit lohkolla 1. Kastellin monitoimitalo, Oulu. Suunnittelutilanne 13.5.2013.
2.2.4.4 Visuaalinen tarkastus
Tarkastamisen yksi muoto on visuaalinen tarkastus, jossa yhdistelmämalli tarkastetaan
”kävelemällä” malli läpi IFC-tiedostojen yhdistämisen mahdollistavalla ohjelmalla, kuten Solibri Model Viewer tai Tekla Bimsight. Visuaalinen tarkastus suoritetaan vertaamalla mallissa näkyviä objekteja katsojan käsitykseen ”oikeasta”.1 Menetelmän etuna
on matala kynnys sen käyttöönottamiseen: IFC-tiedostojen visualisoimiseen on saatavilla nykyisin myös useita ilmaisohjelmia, myös älypuhelimille ja tableteille. Visuaalista
tarkastusta helpottavat ohjelmiin sisäänrakennetut objektien leikkaus-, piilotus- ja läpinäkyvyyden säätötyökalut, ja malli tulisikin tarkastaa myös alakatot piilotettuna talotekniikan keskinäisen sijoittumisen havaitsemiseksi.2 Visuaalisen tarkastuksen ongelmakohtia voidaan havainnollistaa ohjelmien esitys-, sekä teksti- ja mittatyökaluilla.
Menetelmän heikkoutena on se, että huolellisesti tehtynä visuaalinen tarkastelu vie tarkastuksen suorittajalta erittäin paljon aikaa, etenkin laajoissa hankkeissa. Visuaalinen
1
2
YTV2012, Osa 6.
Niemi, H. 2011. s. 88
37
tarkastus on myös altis tarkastajan tekemille inhimillisille virheille, ja piiloon jäävien
rakennusosien tarkastaminen on menetelmällä järjestelmällisesti hankalaa.
Aikaisemmin on todettu, että mikäli projektin ainoana laadunvarmistusmenetelmänä
käytetään visuaalista tarkastusta, malleihin on jäänyt merkittävä määrä virheitä tarkastuksen jälkeen, joten visuaalisen tarkastuksen lisäksi projekteissa suositellaan käytettäväksi myös ohjelmallisia tarkastustyökaluja (Luku 2.2.4.5).1
Kuva 11. Kastellin monitoimitalon 1. lohkon visuaalinen tarkastelu, alakatot piilotettuna. Kastellin monitoimitalo, Oulu. Suunnittelutilanne 13.5.2013.
2.2.4.5 Törmäystarkastelu
Perinteisesti 2D-pohjaisessa suunnittelussa suunnitelmien ristiriidat on etsitty valopöydällä, tai CAD-järjestelmillä tuotetuissa suunnitelmissa laittamalla piirustuksia päällekkäin eri kuvatasoille. Nämä manuaaliset tarkastuskeinot ovat usein olleet hitaita, tehottomia ja virheille alttiita, ja usein vaativat ajan tasaiset suunnitelmajulkaisut.2 Tietomallipohjainen törmäystarkastelu (clash detection) yhdistää rakennuksen geometriatietoon
1
2
Niemi, H. 2011. s. 61
38
sen rakennusosien sisältämän parametrisen tiedon, mikä mahdollistaa törmäysten tehokkaamman luokittelun sääntöpohjaisilla tarkastusmenettelyillä: Tietomalleista haettuja törmäyksiä voidaan esimerkiksi rajata eri suunnittelualojen tai rakennusosatyyppien
välisiksi. Yleisesti ottaen törmäystarkastelut suoritetaan toimintoa varten kehitetyillä
ohjelmistoilla, jotka mahdollistavat eri suunnittelualojen mallien yhdistämisen IFCmuodossa, kuten Solibri Model Checker, Autodesk Navisworks tai Tekla BIMSight.
Myös useimpiin suunnitteluohjelmistoihin on toteutettu toimintoja, jotka mahdollistavat
suunnittelualan sisäisten törmäysten havaitsemisen.
Geometriatörmäysten lisäksi (hard clash) ohjelmistot mahdollistavat myös liian lähekkäin sijaitsevien komponenttien (soft clash) tunnistamisen,1 mikä usein on välttämätöntä
suunnitelmien toiminnallisuuden ja asennettavuuden kannalta. Tämän tyyppisiä suunnitelmaristiriitoja voivat olla esimerkiksi objektien sijainti ovien aukenemissuunnalla, tai
lämpöeristettävien putkien liian läheinen sijainti suhteessa toisiinsa. Etenkin määrälaskennan ja energiasimulointien kannalta on myös tärkeää pystyä tunnistamaan päällekkäiset sekä ns. tuplaobjektit, joita on käytännössä mahdotonta havaita ilman tarkastusohjelmistoja.
Ongelmana nykyisissä tarkastusohjelmistoissa on raportoitavien virheiden suuri määrä
erilaisia tarkastussäännöstöjä käyttäen.2 Tarkastusohjelmat luokittelevat virheitä eri vakavuusluokkiin mm. leikkausten tilavuuden perusteella, mutta käytännössä kahdesta
samantyyppisestä virheestä toinen voi olla merkityksetön ja toinen aiheuttaa merkittävän kustannusvaikutuksen tai haitan työmaalla jäädessään suunnitelmiin. Esimerkkejä
merkityksettömistä törmäyksistä voivat olla esimerkiksi:3
-
Ilmanvaihtokanavan kohtisuora törmäys kipsilevyseinään, sillä varaus pystytään
toteuttamaan usein työmaalla.
-
Valuun sijoitettavien viemäriputkien törmäys mallissa esitettyyn paikallavalurakenteeseen.
1
esim. Gijezen, S. et al. 2010. s. 4
3
YTV2012, Osa 6.
2
39
Törmäystarkastelun raportointi vaatii usein kokemusta ja harkintaa tarkastuksen suorittajalta, sillä merkityksettömien virheiden käsittely kokouksissa vie yhteistä aikaa todellista suunnittelualojen yhteensovittamista vaativien tapausten käsittelyltä.
Teoriassa kaikki tarkastusohjelmistojen sisältämät tarkastussäännöstöt sisältävät parametreja ja toleransseja joita muokkaamalla voidaan säädellä, minkä tyyppisiä virheitä
raportoidaan ja millä vakavuusasteella. Käytännössä kuitenkin yleispätevien säännöstöjen luomiselle ongelmia aiheuttavat hankesidonnaiset muuttujat, kuten esimerkiksi
suunnittelijoiden erilaiset objektien nimeämiskäytännöt hankkeissa tai taloteknisten
järjestelmien monimuotoisuus rakennuksessa.
Kuva 12. IV-kanavan mutkan ja alakaton törmäys pesutilassa. Kastellin monitoimitalo,
Oulu. Suunnittelutilanne 13.5.2013.
2.2.4.6 Yhdistelmämallien käyttö määrälaskennassa
IFC- ja yhdistelmämalleja hyödynnetään erityisesti työmaalla sijaintikohtaisten määrien, aikataulujen, töiden sekä hankintojen suunnitteluun.1 Vaikka natiivimalleista saatava
määrätieto on usein tarkempaa, IFC-muotoisen tiedon hyödyntäminen mahdollistaa
määrätiedon ottamisen eri suunnittelualojen malleista ilman useita ohjelmistolisenssejä.
Kuitenkin Tocoman on julkaissut aiemman natiivimalleja hyödyntävän iLink-ohjelman
1
Uusitalo, H. 2013. s. 42
40
korvaavan EasyBim-laskentaohjelmiston, joka hyödyntää määrälaskennassa ensisijaisesti IFC-tietoa.
IFC-tiedostomuotoa käytettäessä on varmistuttava siitä, mitkä rakennusosat on luettu
mukaan IFC-tiedostoon natiivitiedostosta ja että ohjelmistossa käytettävä IFC-tiedosto
antaa oikeaa määrätietoa. 1,2 Lisäksi yleisesti määrälaskenta asettaa suunnittelijoiden
mallinnustavalle mm. seuraavia vaatimuksia, joita voidaan tarkastaa laadunvarmistusohjelmistoilla niin visuaalisesti kuin sääntöpohjaisestikin:3

Rakennusosien tyypit on määritelty oikein

Tietomallissa kaikille osille on annettu identiteetti ja sijainti

Rakennuskohde on mallinnettu kerroksittain

Rakennusosat on mallinnettu oikeilla työkaluilla

Rakennusosia ei ole mallinnettu päällekkäin

Rakennusosat eivät leikkaa toisiaan.
2.3 Tietomallinnetun hankkeen vaiheet ja tietomallien tietosisällöt
Yleisissä tietomallivaatimuksissa tietomallinnetun rakennushankkeen kulku ja osapuolten tehtävät hankkeen eri vaiheissa on pilkottu julkaisusarjan eri osiin, joita on julkaistu
tällä hetkellä 13. Tietomallinnetun rakennushankkeen kulun selvittämiseksi tässä luvussa on kuvattu osapuolten tehtävät ja tietomallien tietosisällöt hankkeen eri vaiheissa
YTV2012 mukaisesti. Suunnittelijat käyttävät suunnitteluprosessissa usein suunnittelutehtävänsä lähtötietoina muiden suunnittelijoiden toimittamia tietoja tai suunnitelmia, ja
tietyssä suunnitteluvaiheessa jalostetut suunnitelmat siirtyvät lähtötiedoiksi seuraavaan
suunnitteluvaiheeseen. Suunnitteluprosessi esitetään SADT-kaavioiden avulla (Structured Analysis Design Technique). Toimintomalli on riippumaton hankkeen ajallisesta
etenemisestä ja vaiheistuksesta.
Toimintakaavioiden jokainen osatoiminto (Kuva 13.) saa syötteenä tietoa. Osatoiminnon tulokset esitetään oikealle lähtevässä nuolessa. Osatoiminnon tekijä (supporting
1
YTV2012, Osa 7.
3
2
41
mechanism) ilmaistaan alhaalta tulevalla nuolella. Osatoiminnoilla voi olla myös useampia tekijöitä. Osatoimintoja ohjaavat toiminnot (control flows), esimerkiksi tietomallikoordinaattorin tehtävät tai projektin ohjeistus kuvataan ylhäältä tulevalla nuolella.
Kuitenkaan tässä tutkimuksessa ohjaavia toimintoja ei ole kuvattu kaavioissa.
Toimintomalleja kuvaavissa kaavioissa oletetaan, että toimintolaatikkoon tulevat syötetiedot (input) tulevat myös ulos (output) lisättynä osatoiminnossa tuotetuilla tiedoilla.
Mikäli osatoiminnoista lähtevä nuoli haarautuu syötteeksi useisiin laatikoihin, voidaan
näitä osatoimintoja suorittaa samanaikaisesti.1 Periaatteessa hankevaiheiden osatoiminnot voitaisiin edelleen jakaa suunnittelijoiden tiedonvaihtoa kuvaaviin alatoimintoihin,
mutta siihen kirjallisuusselvitys ei antanut valmiuksia.
Kuva 13. SADT-tekniikan periaate. Lähde: Structured Analysis Wiki, www-sivusto. Viitattu 20.6.2013.
1
Karhu, V. et al. 1994. S. 14-16
42
Kuva 14. Tietomallit hankkeessa vaiheittain. Lähde: YTV2012, Osa 3.
2.3.1 Tarveselvitys ja hankesuunnittelu
Kuva 15. Tiedonvaihto tarveselvitys- ja hankesuunnitteluvaiheessa.
Tarveselvityksessä kartoitetaan kiinteistön omistajan sekä tulevien käyttäjien tarpeet ja
tavoitteet, tai olemassa olevan tilan muutostarve. Tilaaja hankkii tarveselvitysvaiheessa
suunnitteluun vaadittavat lähtötiedot, joita voivat olla esimerkiksi rakennuspaikan tai
olemassa olevan rakennuksen tiedot tai inventointimalli, hankkeen budjetti- ja aikataulutavoitteet sekä laajuuden kokonaistavoitteet. Mallinnuksen tarkkuustasosta riippuen
tarpeellisten lähtötietojen selvittäminen voi edellyttää myös erityisalojen suunnittelijoi-
43
den konsultointia.1 Tarveselvityksen tavoitteena on hankepäätöksen valmistelu, mutta
usein tarveselvitysvaiheen tehtävät voivat olla osa hankesuunnitteluvaiheen toimeksiantoa.
Hankesuunnitteluvaiheessa käynnistetään arkkitehtisuunnittelu, ja vaiheen tietomallintamisen tuloksena on arkkitehdin vaatimusmalli. 2 Hankesuunnitteluvaiheessa ei yleensä
ole vielä valittu erityissuunnittelijoita. Erityissuunnittelijoiden vaatimusmallit laaditaan
suunnittelijoiden valintojen jälkeen, tai viimeistään ehdotussuunnitteluvaiheessa.
Pääsuunnittelija/Arkkitehti
Arkkitehdin vaatimusmallilla ei välttämättä ole hankesuunnitteluvaiheessa geometrista
muotoa. Vaatimusmallin minimivaatimus on taulukkomuodossa oleva tilaohjelma, jota
voidaan käyttää tiloille asetettujen vaatimusten ja suunnitelmaratkaisujen vertailussa.
Tilaohjelmassa esitettäviä vaatimuksia ovat esimerkiksi:

tilan nettoalatarve ja tarvittaessa mittoihin ja muotoihin liittyviä vaatimuksia

tilan käyttö ja käyttäjät, keskeiset yhteydet ja vaikutukset muihin tiloihin

sisäilmasto, ääneneristys, valaistus, kuormitus, kestävyys, turvallisuus ja laatutaso

LVI-järjestelmät, sähköjärjestelmät, kalusteet, varusteet, laitteet, tilan jako-osat,
sisäpuoliset pintarakenteet.3,4
Vaatimusmalli voidaan toteuttaa myös tietomallipohjaisesti, mikäli käytössä on tätä
tukevia työkaluja.5
Vaatimusmallia päivitetään hankkeen keston ajan tavoitteiden ja vaatimusten muuttuessa, ja jatkossa suunnitelmia verrataan tilaohjelmassa asetettuihin vaatimuksiin. Vaatimusmalli toimii lähtötietona seuraaville suunnitteluvaiheille.
Lähtötiedot: Tilaajan lähtötiedot
Vaiheen tuotokset: Vaatimusmalli
1
YTV2012, Osa 11.
YTV2012, Osa 11.
3
YTV2012, Osa 3.
4
Penttilä, H. et al. 2006a.
5
YTV2012, Osa 11.
2
44
2.3.2 Ehdotussuunnittelu
Kuva 16. Tiedonvaihto ehdotussuunnitteluvaiheessa.
Ehdotussuunnitteluvaiheessa haetaan asetetut tavoitteet täyttävää perusratkaisua karkealla tasolla olevilla vaihtoehtoisilla suunnitelmilla. Ehdotussuunnittelussa sopivinta perusratkaisua haetaan vaihtoehtoisilla arkkitehdin tilamalleilla (tai tilaryhmämalleilla).1
Mallien avulla vertaillaan tilaajan ja käyttäjän kanssa laajuus- ja kustannustavoitteita.
Rakennuksen elinkaari- ja käyttökustannukset pyritään varmistamaan energiasimulointien ja elinkaarilaskelmien avulla. Näiden tuottama analyyttinen vertailutieto on eräs
keskeisimpiä integroidun suunnittelun hyötyjä.
Ehdotussuunnitteluvaiheessa erityissuunnittelijat tutkivat sovittavassa laajuudessa rakenneja taloteknisiä ratkaisuvaihtoehtoja. Kunkin suunnittelualan ajantasaiset mallit
tulisi olla aina muiden saatavilla, mikä varmistetaan sopimalla riittävän tiheä tietomallien tallennus esimerkiksi projektipankkiin. Sopiva tallennusväli ehdotussuunnitteluvaiheessa on esimerkiksi suunnittelukokousten väli ja tarpeen vaatiessa energiasimuloinnin
ja kustannuslaskennan pohjaksi. 2, 3 Edellisessä hankkeen vaiheessa tuotettua vaatimusmallia päivitetään ehdotussuunnitteluvaiheessa tehtyjen päätösten mukaan.
1
YTV2012, Osa 11.
YTV2012, Osa 1.
3
Niskakangas, V. 2013.
2
45
Arkkitehti mallintaa vaihtoehtoisia tilamalleja sopivina tilaryhminä käyttäen valitun
suunnitteluohjelmiston tila- tai vyöhyketyökalua. Työn tarkoituksena on tutkia vaihtoehtoja tilojen ryhmittelystä sekä rakennuksen massoittelusta ja sijoittamisesta tontille.1
Projektin laajuudesta ja tarpeista riippuen voidaan tämä vaihe ohittaa ja siirtyä suoraan
tilakohtaisen tilamallin käyttöön. Tilaryhmien lisäksi tilamallissa mallinnetaan tavallisesti tilat ja niitä rajaavat seinät. Jotta tilamallia voidaan hyödyntää erilaisissa analyyseissä, pitää seinät jakaa minimissään ulko- ja väliseiniin. Energiasimulointia varten
tarvitaan myös yksinkertaisesti mallinnetut ikkuna-alueet.2
Lähtötiedot: Vaatimusmalli
Vaiheen tuotokset: Tilaryhmämallit ja tilamalli
Rakennesuunnittelija
Rakennesuunnittelulle laaditaan vaatimusmalli, jossa esitetään rakennesuunnittelulle
asetetut tavoitteet ja vaatimukset. Vaatimusmalli voi olla esitysmuodoltaan taulukkomuotoinen esitys, piirustus, tekstiasiakirja, tietomalli tai näiden yhdistelmä.3
Ehdotussuunnitteluvaiheessa rakennesuunnittelija arvioi arkkitehdin esittämien vaihtoehtojen toteutettavuutta. Ehdotussuunnitteluvaiheessa rakennesuunnittelijalla ei ole varsinaisia mallinnusvaatimuksia. Projektikohtaisesti voidaan mallintaa arkkitehdin tilamallivaihtoehtojen pohjalta esim. erilaisia runkovaihtoehtoja kustannusten selvittämiseksi päätöksenteon vaatimassa laajuudessa.4
Lähtötiedot: Arkkitehdin (vaihtoehtoiset) tilamallit
Vaiheen tuotokset: RAK-vaatimusmalli, vaihtoehtovertailu
1
YTV2012, Osa 3.
YTV2012, Osa 3.
3
YTV2012, Osa 5.
4
YTV2012, Osa 5.
2
46
TATE-suunnittelijat
Ehdotussuunnitteluvaiheessa TATE-suunnittelu on muita suunnitteluosapuolia tukevaa
suunnittelua, jossa tavoitteena on tuottaa riittävät tiedot ARK- ja RAK-mallin tekemiseksi.1 TATE-suunnittelu keskittyy järjestelmävalintoihin, palvelualuekaavioihin, sekä
tilavarauksiin, jotka pyritään suunnittelemaan arkkitehtoniset vaatimukset säilyttäen.2,3
Suunnittelutarjouspyynnön mukaisessa laajuudessa TATE-suunnittelijalta edellytetään
vaatimusten määrittelyä ja ylläpitoa. TATE-suunnittelijat laativat vaatimusmallit, joita
ylläpidetään läpi suunnitteluprosessin ja jatkossa verrataan suunnitteluratkaisuihin. Vaatimukset liittyvät esimerkiksi tilojen sisäilmaolosuhteisiin, sähkötekniikan järjestelmävaatimuksiin sekä valaistusolosuhteisiin. Sopivilla työkaluilla vaatimukset voidaan liittää osaksi arkkitehdin tuottamaa tilamallia, mutta minimivaatimuksena on taulukkomuotoinen esitys. 4
Ehdotussuunnitteluvaiheessa TATE-suunnittelijat tutkivat sovittavassa laajuudessa
myös taloteknisiä ratkaisuvaihtoehtoja arkkitehdin tilamallien avulla. Tietomallinnuksen
laajuus sovitaan projektissa tarkoituksenmukaiseksi. Suunnittelun edetessä yleissuunnitteluvaiheeseen arkkitehdin tilamallista tulee usein osa rakennusosamallia. Mallin monimutkaistuessa tiedonsiirto analysointiohjelmiin voi olennaisesti hankaloitua ja voidaan joutua mallintamaan erillinen malli energiasimulointeja varten esimerkiksi tarkoitukseen sopivalla MagiCad Room -ohjelmalla.
Ehdotussuunnitteluvaiheessa muiden suunnittelijoiden tekemät ratkaisut konkretisoituvat elinkaarivaikutuksiksi, joista tulee saada tietoa mm. suunnitteluratkaisuiden energiatehokkuuden ja elinkaarikustannusten osalta. Talotekniikan analyysien avulla voidaan
luotettavammin ohjata suunnittelua ja toteutusta elinkaariedullisiin ratkaisuihin. 5 Analyysejä voidaan tehdä arkkitehdin tilaryhmä- ja tilamallien pohjalta niin tila- kuin rakenneratkaisupohjaisesti. Talotekniset analyysit toteuttavat joko TATE-suunnittelijat,
1
YTV2012, Osa 4.
YTV2012, Osa 11.
3
YTV2012, Osa 4.
4
YTV2012, Osa 4.
5
YTV2012, Osa 9.
2
47
tai erikseen hankkeeseen organisoidut energia/elinkaarikonsultit. Ehdotussuunnitteluaiheessa tuotettavia analyysejä ovat mm.1

Energia- ja olosuhdesimuloinnit,

sisäilmaston virtaussimuloinnit (CDF),

elinkaarikustannusten analyysit (LCC),

valaistusvisualisoinnit,

sekä ympäristövaikutusanalyysit (LCA).
Lähtötiedot: Arkkitehdin (vaihtoehtoiset) tilamallit
Vaiheen tuotokset: TATE-vaatimusmallit, vaihtoehtovertailu, elinkaari- ja energiaanalyysit
1
YTV2012, Osa 9.
48
2.3.3 Yleissuunnittelu
Kuva 17. Tiedonvaihto yleissuunnitteluvaiheessa.
49
Yleissuunnitteluvaiheessa lähdetään kehittämään ehdotussuunnitteluvaiheessa valittua
perusratkaisua arkkitehdin tilamallin pohjalta. Tietomallien mahdollistamat suunnitelmien visualisoinnit ja tiedonvaihto, sekä suunnitelmaratkaisujen tarkemmat analyysit
tukevat päätöksentekoa.
Eri suunnittelijoiden työn tulee edistyä loogisesti rinnakkain ja yhteistyössä. Yleissuunnitteluvaiheessa kiinnitetään yksittäisten suunnittelualakohtaisten osamallien lisäksi
erityistä huomiota mallien yhteistarkasteluun. Yleissuunnitteluvaiheen jälkeen mallit
sisältävät jo valtaosan toteutussuunnitteluvaiheessa tarvittavasta tiedosta.1 Vaiheessa
tietomallit tallennetaan projektipankkiin muiden saataville esimerkiksi suunnittelijapalavereiden välein ja tietoa vaihdetaan myös työmalleilla suunnittelijaosapuolten välisesti.
Hankkeesta riippuen yleissuunnitteluvaiheessa malleja kehitetään tietyiltä osin hankintojen tarjouspyyntöjen edellyttämälle tasolle, mikäli tarvitaan tarkennettua tietoa kiirehankintoja varten. (ns. hankintoja palveleva suunnittelu) Hankintoja palveleva suunnittelukokonaisuus tehdään siinä laajuudessa ja sillä tarkkuudella, että kohteen ja rakennusosien laajuus, määrät, työtavat ja laatutaso voidaan määrittää toteutuskustannusten
edellyttämällä tarkkuudella.2
Yleissuunnittelussa valittua suunnitelmavaihtoehtoa kehitetään alustavaksi rakennusosamalliksi, joka rakennusosiltaan vastaa hyvin pitkälti toteutussuunnitteluvaiheen
suunnitelmia, mutta on usein tietosisällöltään suppeampi esimerkiksi pintamateriaalitietojen ja liittymien osalta.3 Arkkitehtimallia vertaillaan taloteknisten järjestelmien tilantarpeisiin, jotka vaikuttavat esimerkiksi alakattokorkeuksiin.4
Yleissuunnitteluvaiheessa tietomalleista tuotetaan rakennusluvan hakemiseen vaadittavat piirustukset (mm. pääpiirustukset), joihin mallin tarkkuustaso tulee olla riittävä.
Suunnitelmien yhteensovittamisella on yleissuunnitteluvaiheessa suuri rooli ja arkkitehti
täydentää vaiheessa malliaan kantavien rakenteiden ja TATE-tilanvarausten osalta.
1
YTV2012, Osa 11.
RAKLI ry. TELU2012, TATE 12.
3
YTV2012, Osa 3.
4
2
50
Lähtötiedot: Ehdotussuunnittelun valittu tilamalli, alustava rakennemalli, tilavarausmalli
Vaiheen tuotokset: Alustava rakennusosamalli
Rakennesuunnittelijan tulee tässä vaiheessa varmistaa tietomallin avulla rakennejärjestelmän mitoitus, vaatimukset ja vaikutukset muiden suunnittelijoiden työhön.1 Rakennesuunnittelijan malli tarkentuu yleissuunnitteluvaiheessa alustavaksi rakennusosamalliksi, jota verrataan arkkitehdin rakennusosamalliin. Rakennemallissa tuote- ja rakennusosat tulee määrittää vaiheessa riittävällä tarkkuudella tuoteosa- ja tuotantosuunnittelua
varten.2
Mallia käytetään yleissuunnitteluvaiheessa suunnitelmien yhteensovittamiseen TATEsuunnittelijoiden kanssa yhdistelmä- ja referenssimallien avulla. Rakennesuunnittelijan
tehtäviin kuuluu TATE-asennusten tilanvarausten ja reititysten tarkastaminen rakenteiden kannalta. 3 Myös alustava reikä- ja varaussuunnittelu aloitetaan yhteistyössä TATEsuunnittelijoiden kanssa yleissuunnitteluvaiheessa. Reikäsuunnittelun menettelyt ja vastuut tulee sopia projektikohtaisesti.
Lähtötiedot: Arkkitehdin alustava rakennusosamalli, tilavarausmalli/pääreitit
Vaiheen tuotokset: Alustava rakennusosamalli
TATE-suunnittelijat
Arkkitehdin tilamallin ja tarvittavilta osilta rakennusosamallin avulla LVI- ja sähkösuunnittelijat varmistavat yleissuunnitteluvaiheessa tiloihin vaikuttavien järjestelmäkomponenttien ja -osien tilantarpeet. TATE-suunnittelijat ilmoittavat muille suunnittelijoille arvionsa järjestelmien tilantarpeesta ja tilojen sijoitusalueesta, jotka päivittävät
nämä omiin malleihinsa tilavarausobjekteina.4
1
YTV2012, Osa 1.
Finnmap Consulting Oy & Rakennusteollisuus RT ry. 2004.
3
RAKLI ry. TELU2012, RAK 12.
4
YTV2012, Osa 4.
2
51
TATE-suunnitelmat tarkentuvat yleissuunnitteluvaiheen loppua kohti tilavarausmalleista alustaviksi järjestelmämalleiksi, joissa kuvataan konehuoneiden tilantarpeet, (vaakasuuntaiset) järjestelmien pääreitit, tilaa vievät kanavat ja johtoreitit. Muita vaiheen
tietomallitehtäviä ovat mm. palvelualuekaaviot, 3D-mallihuoneet sekä 2D-leikkaukset,
joita käytetään apuna järjestelmien sijoittelussa.1 Kukin pääjärjestelmä mallinnetaan
omaksi mallikseen. Taloteknisten pääreittien ja tyyppitilojen määrittämisellä ja yhteensovittamisella varmistetaan, että kaikilla suunnittelualoilla on tekniset edellytykset toteuttaa ehdotussuunnitteluvaiheessa päätetyt ratkaisut.2
Yleissuunnitteluvaiheessa tehdään tarkempia olosuhdesimulointeja arkkitehdin tila- tai
rakennusosamallin pohjalta. Tarkemmilla laskelmilla halutaan varmistua siitä, että
mahdollisten yleissuunnitteluvaiheessa tehtyjen muutosten vaikutukset tulevat selville.3
Rakennuslupatehtäviä varten määritetään rakennuksen kokonaisenergiankulutus, Eluku, energiatodistus sekä kesäaikainen huonelämpötilojen pysyvyys.4 Talotekniset analyysit tukevat myös yleissuunnitteluvaiheessa kommunikointia ja päätöksentekoa.
Lähtötiedot: Arkkitehdin tilamalli, alustavat RAK- ja ARK-rakennusosamallit
Vaiheen tuotokset: Tilavarausmalli/alustavat järjestelmämallit, mallihuoneet, 2Dleikkaukset, palvelualuekaaviot, tarkentavat TATE-analyysit
1
YTV2012, Osa 1.
3
4
YTV2012, Osa 10.
2
52
2.3.4 Toteutussuunnittelu
Kuva 18. Tiedonvaihto toteutussuunnitteluvaiheessa.
Toteutussuunnitteluvaiheen menettely on sama kuin yleissuunnitteluvaiheenkin, mutta
tuotettavan tiedon tarkkuustaso kasvaa oleellisesti.1 Malleja kehitetään rakentamisen
edellyttämään tarkkuustasoon, jotta niiden pohjalta voidaan laatia urakkatarjouspyynnöt
ja myöhemmin toteutusta varten tuotetut paperidokumentit.2 Kaikki projektista tehtävät
mallit tarkentuvat yksityiskohtaisilla tyyppitiedoilla. Toteutussuunnittelua täydennetään
suunnittelutarjouspyynnöissä esitettyjen suunnittelualakohtaisten tietomallinnusohjeiden
ja tietosisältötaulukoiden tarkkuustason mukaisesti.
Tietomallien mahdollistama visualisointi ja analyysit tukevat toteutussuunnitteluvaiheen
tarkentavaa suunnittelua ja suunnitelmien yhteensovittamista. Perinteisen suunnittelukäytännön mukaisesti tarkentavaa suunnittelua jatketaan vielä toteutusvaiheessa. Vaiheen lopussa hyväksytään toteutussuunnitelmat siinä laajuudessa, että niiden avulla voidaan siirtyä hankkeen valmisteluvaiheeseen ja urakkatarjouskyselyihin.3
1
YTV2012, Osa 1.
YTV2012, Osa 11.
3
YTV2012, Osa 1.
2
53
Kaikkien suunnittelijoiden ajantasaisten mallien tulee olla aina muiden saatavilla. Sopiva tallennusväli toteutusvaiheessa on noin yksi viikko, lisäksi malleja päivitetään hankintojen tarpeiden mukaan.
Nimensä mukaisesti toteutussuunnitteluvaiheessa arkkitehdin malli kehitetään rakennusosamalliksi, jolloin malli tarkennetaan todellisilla rakennusosilla ja rakentamisen
edellyttämiksi mitoitetuiksi suunnitelmiksi. Mallin sijainti ja geometria on mallinnettu
vaatimusten mukaisesti, rakennetyypit määritelty ja tuoteosat mallinnettu niin, että kappalemäärät ja muu oleellinen määrätieto saadaan tuotetyypeittäin mallista.1 Liittymät
mallinnetaan rakennusosamalliin mahdollisimman oikein, mutta tarkat detaljit tehdään
yleensä detaljipiirroksina.2
Mallia käytetään myös toteutussuunnitteluvaiheessa eri suunnittelualojen yhteensovittamiseen. Arkkitehdin tulee toteutussuunnitteluvaiheessa käyttää yhdistelmämallia tai
talotekniikan järjestelmämalleja referensseinä, jotta arkkitehtisuunnitelmiin saadaan
toteutettua esimerkiksi alakatot tai valaisimien väliin asennettavat akustiikkalevyt oikein.3
Mallissa esitetään rakennusosat todellisin tyyppitiedoin, kuitenkin toimittajien tuoteosat
pystytään päivittämään malliin vasta urakoitsijavalintojen jälkeen.4 Tilamallin sisältävät
tilat tulee olla alkuperäisine GUID:ineen myös rakennusosamallissa. Tiloja hyödynnetään tilakorttien laatimissa, joten tiloihin liittyvät materiaali- ja pintatiedot tulee olla
linkitettynä niihin.
Lähtötiedot: ARK ja RAK Alustava rakennusosamalli, (alustava) TATE-järjestelmämalli
Vaiheen tuotokset: Rakennusosamalli (toteutus)
Toteutussuunnitteluvaiheessa rakennesuunnittelijan tietomallin tulee vastata arkkitehtimallia ja malli kehitetään rakentamisvaiheen tarkennuksia lukuun ottamatta toteutustar1
YTV2012, Osa 3.
3
4
2
54
kaksi. Kuten arkkitehtimallissa, rakennesuunnittelijan malli täydennetään todellisuutta
vastaavilla tuoteosilla. Mikäli hankkeeseen otetaan mukaan tuoteosasuunnittelijoita,
mallintamisen vastuut tulee olla määriteltynä. Toteutussuunnitteluvaiheessa myös TATE-suunnittelijat kehittävät mallinsa lopulliseksi järjestelmämalliksi, joten vaiheessa
tehdään lopullinen varaussuunnittelu sovittujen vastuiden mukaisesti.
Lähtötiedot: ARK ja RAK Alustava rakennusosamalli, (alustava) TATE-järjestelmämalli
Vaiheen tuotokset: Rakennusosamalli (toteutus), varaustiedot
TATE-suunnittelijat
Toteutussuunnitteluvaiheessa mallit tarkennetaan koko rakennuksen kattaviksi järjestelmämalleiksi. Talotekniset järjestelmät voidaan mallintaa vaaditulla tarkkuustasolla,
kun TATE-suunnittelijoilla on käytössä päägeometrialtaan todenmukainen rakennemalli.1 Kukin pääjärjestelmä mallinnetaan omaksi mallikseen ja malleja käytetään havainnollistamiseen sekä suunnitelmien yhteensovittamiseen. Esimerkkikohteita ovat tilavarausten verifiointi ja järjestelmämallissa tarkentuvien päätelaitteiden tarkastelu osana
rakennuksen arkkitehtuuria, sekä eri järjestelmämallien yhteensopivuustarkastelut.
Geometrian tarkkuustason on oltava sellainen, että kohteen TATE-asennukset on asennettavissa tietomallin perusteella.2 Tavoitteena on, että toteutussuunnitteluvaiheessa
tietomallissa esiintyvät komponentit ja päätelaitteet vastaavat asennettavia. Varaukset
suunnitellaan yhteistyössä rakennesuunnittelijan kanssa.
Suunnitelmaratkaisut ovat toteutussuunnitteluvaiheessa pääosin selvät, joten energiaanalyysejä päivitetään lähinnä suunnitelmamuutosten yhteydessä.3
Lähtötiedot :ARK ja RAK rakennusosamallit
Vaiheen tuotokset: Järjestelmämallit, varaustiedot
1
YTV2012, Osa 4.
YTV2012, Osa 3.
3
YTV2012, Osa 10.
2
55
2.3.5 Rakentaminen
Kuva 19. Tiedonvaihto rakentamisvaiheessa.
Rakentamisvaiheessa malleja täydennetään ja päivitetään urakoitsijoilta saatavilla tuotetiedoilla, sekä aina suunnitelmamuutosten yhteydessä. Tarkentavaa suunnittelua rakentamisvaiheessa tehdään työmaan tarpeiden mukaisesti. Mallien sekä niistä tuotettavien
ajantasaisten piirustusten tulee olla yhdenmukaisia. Tietomalleja hyödynnetään työmaan
tarpeisiin määrälaskennassa, aikataulusuunnittelussa sekä asennusten suunnittelussa ja
havainnollistamisessa. Malleihin voidaan lisätä esimerkiksi tuenta- ja työturvallisuuskomponentteja. Urakoitsija välittää suunnittelijoille ja tietomallikoordinaattorille tiedot
havaitsemistaan virheistä tietomalleista ja vastuusuunnittelijat korjaavat virheensä muita
osapuolia tiedottaen.1 Energiankulutusta analysoidaan rakentamisen aikana tapahtuneiden muutosten pohjalta.
1
YTV2012, Osa 13.
56
3 Haastattelututkimus kohdeyrityksessä
3.1 Tutkimusmenetelmät ja tutkimusaineisto
Suunnitelmien laadunvarmistuksen, yhteensovittamisen ja tiedonvaihdon nykytilanteen
selvittämiseksi projekteissa, tutkimusmenetelmäksi valittiin case- eli tapaustutkimus.
Tutkimuksen kohdeyrityksenä toimi Lemminkäinen Talo Oy. Tapaustutkimuksen tavoitteena on pyrkiä seikkaperäisesti ymmärtämään nykyisiä tapahtumia ympäristössä,
jossa tapahtumien kulkuun ei ole merkittävää vaikutusmahdollisuutta.1 Luonteeltaan
suoritettu tapaustutkimus on monitapauksinen, mutta holistinen, eli tutkittava ilmiö on
enemmän kuin tutkittavien osakokonaisuuksiensa summa.2 Perimmäisenä tarkoituksena
kaikissa tapaustutkimuksen tyypeissä on kuvata ilmiön taustalla olevat päätökset, sekä
niiden vaikutukset tapahtumien kulkuun.3
Tutkimuksen luonteesta johtuen case-kohteiden valinnassa tärkein kriteeri oli se, että
suunnittelun tilaaminen ja suunnittelun ohjaus tulevat kohdeyritykseltä, eikä esimerkiksi
kohteen tilaajalta. Tällöin niihin sovelletaan pääosin samoja suunnittelunohjauksen menettelyitä, jotka ovat kohdeyrityksen käytössä osana toimintajärjestelmää ja tietomallintamiseen liittyvää ohjeistusta. Tällä pyritään varmistamaan, että valitut case-kohteet
kuvaavat samaa ilmiötä.4 Kriteerin täytyttyä kohteet pyrittiin valitsemaan mahdollisimman monipuolisesti mallintamalla suunniteltujen kohteiden joukosta, mikä parantaa
tutkimustulosten yleistettävyyttä.
Case-kohteina olivat seuraavat hankkeet:

Lemminkäinen PPP Oy, Kuopion elinkaarihanke, Pohjantien koulu

Lemminkäinen PPP Oy, Kastellin monitoimitalon elinkaarihanke

Lemminkäinen Talo Oy, Järvenpään Vilja
Pääasiallisena tiedonkeruumenetelmänä tutkimuksessa oli puolistrukturoitu haastattelu,
tässä tapauksessa teemahaastattelu. Puolistrukturoiduissa haastatteluissa kysymykset
1
Yin, R. K. 2009. s. 11
Yin, R. K. 2009. s. 59-60
3
Yin, R. K. 2009. s. 17
4
Yin, R. K. 2009. s. 91-92
2
57
ovat kaikille samat, mutta vastauksia ei ole sidottu vastausvaihtoehtoihin, vaan haastateltavat voivat vastata omin sanoin.1 Teemahaastattelu on puolistrukturoitu menetelmä
siksi, että haastattelun aihepiirit, teema-alueet ovat kaikille samat. Menetelmä ottaa
huomioon sen, että ihmisten tulkinnat asioista ja heidän asioille antamansa subjektiiviset
merkitykset ovat keskeisiä.2 Tapaustutkimuksessa usein haastattelukysymykset keskittyvät kysymyksiin ”miksi” tai ”miten”,3 mutta tutkimusmenetelmä mahdollistaa myös
syvällisemmät haastattelut, joissa haastateltavat kertovat laajemmin omista mielipiteistään ja ehdottavat jopa omia ideoitaan toiminnan parantamiseksi.4 Hyvien käytäntöjen
selvittämiseksi projekteissa tämä lähestymistapa oli tarkoituksenmukainen.
Haastattelukysymykset oli jaettu seuraaviin teemoihin:

Tehtäväkuvaus ja taustat

Projektimenettelyt ja tiedonsiirto

Tarveselvitys ja hankesuunnittelu

Ehdotussuunnittelu

Yleissuunnittelu

Toteutussuunnittelu

Rakentaminen

Käyttö ja ylläpito

Yhdistelmämallit ja suunnitelmien yhteensovittaminen
Haastattelukysymykset muodostettiin perehtymällä aiheen kirjallisuuteen, keskusteluilla
työn ohjaajan ja muiden asiantuntijoiden kanssa, sekä perehtymällä etukäteen saatavilla
oleviin case-kohteiden dokumentteihin, kuten esimerkiksi Pohjantien koulun LastPlanner-kokousten taulukoihin. Lisäksi tutkija osallistui kolmeen suunnitteluun liittyvään
kokoukseen hankkeissa. Haastatteluiden runko on muodostettu edellisessä luvussa kuvattuun, YTV2012:ssa esitettyyn tietomallinnetun hankkeen kulkuun pohjautuen. Vaikka case-kohteiden suunnitteluvaiheet eivät edenneetkään kokonaan kuvatun mallin mukaisesti, tuli eri vaiheisiin liittyvät erityispiirteet ja ongelmat käytyä läpi. Haastattelurungon viimeisessä teema-alueessa keskityttiin projektin yhteensovitusmenettelyihin ja
1
Hirsijärvi, S. et al. 2000. s. 47
Hirsijärvi, S. et al. 2000. s. 48
3
Yin, R. K. 2009. s. 10
4
Yin, R. K. 2009. s. 107
2
58
yhdistelmämallien käyttöön kokonaisuudessaan, kun projektin kulku oli aikaisemmin
keskusteltu läpi ja yksittäiset, suunnitteluvaiheisiin liittyvät kysymykset käsitelty. Tämä
toimi osaltaan myös kertaavana osiona, jossa haastateltavat kertasivat pahimmat ongelmat, ja toisaalta myös jakoivat mielipiteensä toiminnan kehittämiseksi.
Monipuolisen näkemyksen saamiseksi kohteista haastateltiin tuotantoinsinöörejä, projektipäälliköitä, tietomallikoordinaattoreita ja -asiantuntijoita sekä pää/arkkitehti-, rakenneja talotekniikkasuunnittelijoita. Haastattelut suoritettiin sovittuina tapaamisina
tai puhelimessa, sekä kahden haastateltavan osalta sähköpostin välityksellä. Kaikki
haastateltavat antoivat luvan haastatteluiden äänittämiselle, jonka jälkeen haastattelut
kirjattiin haastattelukysymysrunkoihin sanatarkasti jatkotarkastelua varten. Lista tutkimukseen haastatelluista henkilöistä löytyy lähdeluettelosta.
Taulukko 1. Case-kohteet ja haastatellut henkilöt.
Pohjantien koulu, Kuopio
Kastellin monitoimitalo,
Järvenpään Vilja
Oulu

Projektipäällikkö

Tuotantoinsinööri

Tuotantoinsinööri

Pää/arkkitehtisuun

Projektijohtaja

Projektipäällikkö
nittelija

Tietomallikoor-



dinaattori
nittelija (toimi
Kustannusinsinööri
myös hankkeen tie-

LV-suunnittelija
(puhelinkeskuste-
tomallikoordinaat-

IV-suunnittelija
lu)
torina)

Sähkösuunnittelija

TATE-urakoitsijat


luryhmä
nittelija

Rakennesuunnittelijan tietomalliasiantuntija

LVI-suunnittelija

Sähkösuunnittelija
Rakennesuunnitte-

LVI-suunnittelija
59
3.2 Case-kohteiden tarkastelu
3.2.1 Kastellin monitoimitalo
Oulun kaupungin tilaamaan Kastellin monitoimitalon hankkeeseen sisältyvät Oulun
Kontinkankaan kaupunginosaan rakennettavan monitoimitalo Kastellin suunnittelu,
paikalla olevien rakennusten purkaminen sekä monitoimitalon rakentaminen. Rakennuksen hoito, ylläpito, käyttäjäpalvelut sekä palvelusopimuksen aikaiset perusparannusinvestoinnit ovat palveluntuottajan vastuulla 25 vuoden palvelujakson ajan.1 Kastellin monitoimitaloon sijoittuvat tilat päiväkodille, ala-asteelle, ylä-asteelle, lukiolle, kirjastolle, nuorisotoiminnalle, palloiluhalleille, sekä muille liikuntatiloille.2 Kohteen tilavuus on 124 010 rm3.
Kohteen palveluntuotannosta tilaajalle vastaa projektiyhtiö Lemminkäinen PPP Oy,
jonka omistavat Lemminkäinen-konsernin yhtiöt Lemminkäinen Talo Oy ja Lemminkäinen Talotekniikka Oy.
Hankeosapuolet:
1
-
Tilaaja: Oulun kaupunki, liikelaitos Oulun tilakeskus
-
Rakennuttaja/päätoteuttaja: Lemminkäinen PPP Oy
-
Arkkitehtisuunnittelu: Arkkitehtitoimisto Lahdelma & Mahlamäki Oy
-
Rakennesuunnittelu: WSP Finland Oy
-
Sähkösuunnittelu: Insinööritoimisto Sähkötele Oy
-
LVI-suunnittelu: LVI-insinööritoimisto Plan-Air Oy
http://www.lemminkainen.fi/PPP/
http://www.puuinfo.fi/ajankohtaista/ouluun-mittava-monitoimihalli-puun-ja-betoninyhdistelmarakenteena
2
60
-
LEED-konsultointi
ja
energiatehokkuus:
Green
Building
Partners
Oy
Kuva 19. Kastellin monitoimitalon yhdistelmämalli kokonaisuudessaan. Hankkeen
suunnittelu ja tuotanto oli jaettu neljään lohkoon, joista oli laadittu tietomallit erikseen
lohkoittain. Kastellin monitoimitalo, Oulu. Suunnittelutilanne 13.5.2013.
3.2.2 Järvenpään Vilja
Järvenpään Vilja on omaperusteinen Järvenpään Lepolaan toteutettava asuinkerrostalokohde. Kohde sisältää 3- ja 4-kerroksiset, yksi- ja kolmeportaiset asuinrakennukset.
Lisäksi kohde sisältää asunto-osakeyhtiötä palvelevan varasto/VSS-rakennuksen ja kaksi autokatosta. Kohteen tilavuus on 15 750 rm3.
Hankeosapuolet:
-
Tilaaja: Lemminkäinen Talo Oy / As. Oy Järvenpään Vilja
61
-
Rakennuttaja/päätoteuttaja: Lemminkäinen Talo Oy
-
Arkkitehtisuunnittelu: Arkkitehtitoimisto Kaipainen Oy
-
Rakennesuunnittelu: Ins. tsto Gabrielsson & Pietiläinen Oy
-
LVISA-suunnittelu: Optiplan Oy
Kuva 20. Järvenpään Viljan yhdistelmämalli. Suunnittelutilanne 3.4.2012.
3.2.3 Pohjantien koulu
Pohjantien koulu on Kuopion elinkaarihankkeen viidestä kohteesta viimeinen, Kuopion
Männistön kaupunginosassa sijaitseva n. 400 oppilaan peruskoulu. Pohjantien koulussa
suoritettiin kattava peruskorjaus ja samalla sen rakennusten tilaratkaisuja kehitettiin
opetustoiminnan kannalta paremmiksi. Lisäksi rakennuksen hoito, ylläpito, käyttäjäpalvelut sekä palvelusopimuksen aikaiset perusparannusinvestoinnit ovat palveluntuottajan
vastuulla 25 vuoden palvelujakson ajan. 1 Kohde otettiin käyttöön syksyllä 2013 ja sen
laajuus on 35 211 m3.
Kohteen palveluntuotannosta tilaajalle vastaa projektiyhtiö Lemminkäinen PPP Oy,
jonka omistavat Lemminkäinen-konsernin yhtiöt Lemminkäinen Talo Oy ja Lemminkäinen Talotekniikka Oy.
Hankeosapuolet:
1
Tilaaja: Kuopion kaupunki, Kuopion kaupungin tilakeskus
http://www.lemminkainen.fi/PPP/
62
-
Rakennuttaja/päätoteuttaja: Lemminkäinen PPP Oy
-
Arkkitehtisuunnittelu: Arkkitehtitoimisto Perko Oy
-
Rakennesuunnittelu: Rakennussuunnittelutoimisto Nylund Oy
-
LVISA-suunnittelu: Insinööritoimisto Granlund Kuopio Oy
-
Energiakonsultti: Pöyry Building Services Oy
Kuva 21. Pohjantien koulun yhdistelmämalli. Suunnittelutilanne 12.11.2012.
3.3 Haastattelut case-kohteissa
3.3.1 Suunnitteluun varattu aika
3.3.1.1 Kastellin monitoimitalo
Kaikkien haastateltujen mukaan Kastellin monitoimitalon suunnitteluaikataulu oli erittäin tiukka, mikä heijastui varsinkin rakennesuunnitteluun suunnittelun käynnistyessä.
Lähtökohtana suunnittelussa oli aiemmassa suunnittelukilpailuvaiheessa luodut L1tason luonnokset arkkitehtisuunnitelmista. Tieto tarjouskilpailun voittamisesta tuli loppuvuodesta 2011 ja sopimus Oulun kaupungin kanssa piti päästä tekemään alkuvuodesta 2012. Kuitenkin sopimus päästiin tekemään vasta puoli vuotta oletettua myöhemmin,
mikä heijastui kohteen suunnitteluaikatauluun.1 Suunnitteluratkaisuja hahmoteltiin esimerkiksi runkorakenteiden osalta, tavoitteena rakennuslupa-aineiston valmistelu, mutta
ilman varsinaista sopimusta ja mahdollisuutta rakennusluvan hakemiseen, suunnittelua
ei päästy viemään täysmääräisesti eteenpäin. Kun sopimus päästiin tekemään ja rakennuslupa saatiin porrastettua kolmeen vaiheeseen, alkoivat samana syksynä myös raken1
Anttonen. Haastattelu, Helsinki 28.6.2013
63
nustyöt. Projektinjohtaja luonnehti aikaa erittäin kiireiseksi etenkin suunnitteluryhmälle
johtuen siitä, että suunnittelua jouduttiin tekemään sekä tuotantopiirustusten, että rakennuksen yleissuunnittelun ehdoilla. 1
Kohde oli poikkeuksellisen laaja ja suunnittelu oli jaettu neljään eri lohkoon. Lohkojaosta huolimatta tietyt suunnittelutehtävät, kuten maanrakennus- ja perustussuunnittelu
jouduttiin suunnittelemaan kokonaisuutena, sillä yhdellä lohkolla valitut ratkaisut vaikuttavat myös toisiin lohkoihin. Kohteen projektinjohtaja koki, että myös elinkaarihankkeille tyypilliseen ratkaisuvaihtojen tarkasteluun olisi kohteen alkuvaiheessa tarvittu lisää aikaa.2 Osaltaan suunnitteluaikaan tuotti paineita myös tilojen hyväksyttäminen
käyttäjillä, sekä tilaajalta saatavien lähtötietojen hankkiminen.
3.3.1.2 Järvenpään Vilja
Järvenpään Viljassa osapuolet yleisesti kokivat että suunnitteluun oli varattu riittävästi
aikaa ja perinteisesti omaperusteisessä asuntotuotannossa suunnitelmat on viety melko
pitkälle ennen rakentamisen aloittamista. Kaikilla suunnittelijoilla oli jonkinasteista
kokemusta mallintavasta suunnittelusta, mutta pääosin he luonnehtivat Järvenpään Viljaa pilottiprojektiksi. Osapuolille järjestettiin projektin alussa koulutus Solibri Model
Checkerin käytöstä, mitä he pitivät hyödyllisenä asiana. Yleisesti suunnittelijat olivat
tyytyväisiä, että projektin alkuvaiheeseen oli varattu aikaa uuden opetteluun ja myös eri
suunnittelualojen mallien yhteensovittamiseen ja tarkastamiseen.
Suunnitteluun käytettävissä olevan ajan sijaan haastateltavilla oli erilaisia näkemyksiä
työjärjestyksistä. Rakennesuunnitteluryhmä koki, että nimenomaan suunnitelmien mallintaminen aloitettiin liian aikaisessa vaiheessa. Arkkitehtisuunnitelmiin tuli muutoksia
jotka he kokivat osaksi suunnittelutyötä, mutta vaikuttivat rakennemallin luomiseen
työllistävästi. Heidän mukaansa mallintamisen aloittamista olisi voinut lykätä jopa 2-3
kuukaudella. 3
Kohteen pääsuunnittelija koki että muut suunnittelualat olisi ollut hyvä saada suunnittelutyöhön aikaisemmassa vaiheessa. Suunnittelutyö eteni sikäli perinteisen kaavan mukaan, että suunnittelu käynnistyi arkkitehtisuunnitteluvetoisesti ja erityissuunnittelu
1
3
Pietiläinen, Westerlund, Sund. Haastattelu, Järvenpää 31.5.2013
2
64
aloitettiin vasta hyvin pitkälle viedyillä luonnossuunnitelmilla. Myös ensimmäiset tietomallit muilta suunnittelijoilta yhteensovittamista varteen saatiin melko myöhään. Pääsuunnittelija koki tärkeäksi, että myös muu suunnittelu saataisiin jatkossa aikaisemmassa vaiheessa mukaan tukemaan arkkitehtisuunnittelua ja hakemaan ratkaisuvaihtoehtoja
yhdessä, mutta myös mallintamisen aloittamista muilla suunnitteluosapuolilta olisi syytä
aikaistaa. Tämä aiheuttaa erityissuunnitelmiin enemmän muutostarpeita projektin alkuvaiheessa, mutta pääsuunnittelijan mukaan edesauttaa kaikkien osapuolten suunnittelutyötä.1
Kohteen projektipäällikkö kertoi aikaistaneensa kokemusten pohjalta erityissuunnittelijoiden tuloa Järvenpään Viljan jälkeisissä asuntokohteissa. Hän koki silti että ainakin
rakennesuunnitelmien mallintaminen aloitettiin Järvenpään Viljassa liian aikaisin, ja oli
sitä mieltä että erityissuunnittelijoiden on hyvä olla mukana tukemassa arkkitehdin
suunnittelua tilavarausten, detaljien ja rakenneratkaisujen osalta, mitkä usein toteutetaan
perinteisesti 2D-suunnitteluna. Erityissuunnittelijoiden tietoa on tärkeää saada arkkitehtimalliin jo luonnossuunnitteluvaiheessa, mutta heidän malliensa luomisen kanssa ei
välttämättä kannata hätiköidä alkuvaiheessa.2
3.3.1.3 Pohjantien Koulu
Pohjantien koulu on Kuopion elinkaarihankkeiden kokonaisuuden viides kohde. Hankkeita on pääsääntöisesti suunniteltu niin, että kun aiempia kohteita ollaan oltu rakentamassa, seuraava kohde on ollut suunnittelussa. Hektisimmillään samanaikaisesti on ollut
kaksi kohdetta rakenteilla ja kaksi suunnittelussa.3 Tahti on jonkin verran kuormittanut
projektiorganisaatiota, sillä pääsääntöisesti samat henkilöt ovat olleet sidottuina sekä
kohteiden toteutukseen, että seuraavien kohteiden suunnittelunohjaukseen.
Suunnitteluun on ollut käytössä noin vuosi ennen rakentamisen aloittamista. Kohteen
projektipäällikkö piti aikataulua tiukkana, mutta käytännössä riittävänä. Hänen mukaansa suurimman paineen suunnittelun ajankäyttöön aiheutti suunnittelunohjauksessa elinkaarihankkeille tyypillinen ratkaisuvaihtoehtojen luominen elinkaariedullisuuden, ja
toisaalta riskien minimoimisen näkökulmasta.4 Omalta osaltaan jonkin verran häiriöitä
1
Konola. Haastattelu, Hämeenlinna 5.6.2013
Mäenpää. Haastattelu, Hyvinkää 25.6.2013
3
Varstala. Haastattelu, Helsinki 27.8.2013
4
2
65
suunnitteluun on aiheuttanut myös korjauskohteiden yllätyksellisyys, ja aikaa on vienyt
myös suunnitelmien hyväksyttäminen tilaajalla sekä osana rakennuslupaprosessia.
3.3.2 Suunnittelun kokouskäytännöt
Taulukko 2. Kokouskäytännöt projekteissa kuukauden syklillä.
vko
vko 2
1
Kastellin
moni-
toimitalo
vko
vko 4
3
Suunnittelijoiden
Suunnittelijoiden palaveri +
palaveri
Suunnittelukokous
Järvenpään Vilja
Suunnittelukokous + yhdistelmämallin läpikäynti
Pohjantien koulu
LastPlanner-kokous
Suunnittelukokous + yhdistelmämallin läpikäynti
Projektin alkuvaiheessa Kastellissa pidettiin tietomallikokouksia, joihin osallistui Lemminkäisen projektihenkilöstö sekä suunnittelijat. Kokouksissa käsiteltiin mallintamisen
teknisiä vaatimuksia, kohdeyrityksen vaatimuksia tietomalleille, osapuolien valmiuksia
tietomallintamiseen, sekä myöhemmin mallien alustavaa yhteensovittamista.1
Alkuvaiheen suunnitteluperiaatteiden sopimisen jälkeen tietomallikokouksia ei enää
pidetty, vaan kokoukset olivat normaaleja suunnittelukokouksia, joissa suunnittelijat
tekivät suunnitteluvaiheilmoitukset ja kokousten kulku oli sidottu valmiiseen asialistaan. Jossakin vaiheessa siirryttiin käytäntöön, jossa aina kahden viikon välein järjestettiin suunnittelijoiden palaveri, ja joka toisella kerralla palaverin jälkeen edellä mainittu
suunnittelukokous. Suunnittelijoiden palaveri oli luonteeltaan suunnittelukokousta vapaamuotoisempi2 ja ne toimivat ensisijaisesti suunnittelijoiden yhteensovittamis- ja keskustelukanavana. Palavereissa käytiin tavanomaisesti läpi myös tietomallikoordinaatto1
2
Häkkinen. Haastattelu sähköpostin välityksellä.
Mäläskä. Haastattelu 16.5.2013
66
rin tarkastama yhdistelmämalli pääsuunnittelijan johtamana videotykillä. Lisäksi palavereissa on käsitelty suunnittelualoittain läpi suunnitelmien ristiriitoja, tarvittavia suunnittelun lähtötietoja sekä sovittu jatkotoimenpiteitä.1 Käytännössä palaverit ovat kestäneet aamusta pitkälle iltapäivään, riippuen siitä järjestettiinkö suunnittelukokous suunnittelijoiden palaverin jälkeen.2 Tämän lisäksi tietyin väliajoin pidettiin myös yhteisiä
kokouksia kohteen tilaajan kanssa.
Kastellissa oli tarkoituksena ottaa käyttöön LastPlanner kokoukset suunnittelijoiden
tiedonvaihtoa varten. LastPlannerista järjestettiin koulutus, ja kokouksia pidettiinkin
ainakin kaksi kertaa.3 LastPlanner ei kuitenkaan vakiintunut käyttöön tämän pidemmälle, jota eräs haastateltavista oli ihmetellyt. Lemminkäisen projektihenkilöstön mukaan
syynä oli se, että menetelmä yritettiin ottaa käyttöön erittäin kiireisessä suunnitteluaikataulussa kesken kaiken. He pitivät LastPlannerin ajatusta hyvänä, mutta toimiakseen se
vaatisi täysin erilaisen lähestymistavan. Suunnan kääntämistä ”keskellä vauhtia” pidettiin mahdottomana.
Kohteen pääsuunnittelija kertoi kirjanneensa suunnittelijoiden palavereissa osapuolten
välisiä tiedonvaihtotarpeita, ja käyttäneensä tähän myös LastPlannerin taulukkopohjaa.4
Hänen mukaansa kokouksissa oli niin paljon asiaa, että tiedonvaihtoon on yksinkertaisesti hankalaa vaikuttaa enempää. Pääsuunnittelijan mukaan käsiteltävien asioiden paljoudesta huolimatta kokouksissa pystyttiin keskittymään olennaiseen ja osapuolet pääsivät suunnittelussa aina tehokkaasti eteenpäin. Kokouksessa ei ollut koskaan ”tyhjäkäyntiä”.
Kohteen LVI-suunnittelija piti kahden viikon kokousväliä hyvänä, hän koki että aikavälillä pystyi etenemään suunnittelussa riittävästi.5 Sen sijaan kohteen projektijohtaja ei
ollut varma, oliko valittu kahden viikon kokousväli paras mahdollinen. Pidemmän kokousvälin etuna olisi se, että suunnittelijat ehtisivät viedä suunnitelmiaan kokousvälillä
pidemmälle ja korjata enemmän suunnitelmien ristiriitoja, sillä suunnittelutyö yleisesti
on aikaa vievää. Yhteisten palaverien päätarkoitus kuitenkin on havaita ristiriidat, ja
sopia niiden vaatimat korjaustoimenpiteet. Kuitenkin pidempi kokousväli vaatii myös
1
Anttonen. Haastattelu 28.6.2013
Anttonen. Haastattelu 28.6.2013
3
4
Saarelainen. Haastattelu 3.6.2013
5
Kaakinen. Puhelinhaastattelu 29.5.2013
2
67
tiivistä suunnittelijoiden välistä tiedonvaihtoa kokousten ulkopuolella. Projektijohtaja
piti eräänä ongelmana tiedonvaihdossa suunnittelijoiden fyysistä etäisyyttä. Jos suunnittelijat olisivat samalla paikkakunnalla, tiedonvaihto voisi olla osapuolille luontevampaa.
Mikäli kokousten ulkopuolella ei ole tarpeeksi tiedonvaihtoa, niissä helposti käytetään
yhteistä aikaa asioihin, jotka olisivat suunnittelijoiden keskinäisesti ratkaistavissa pienemmillä porukoilla. Videoneuvottelut mahdollistaisivat kanssakäymisen lisäämistä,
mutta käytännössä usein vastaan tulevat tekniset ongelmat, varsinkin jos videoneuvotteluissa pyöritellään tietomalleja, eivätkä ne siten ole aina rinnastettavissa suunnittelijoiden normaaleihin tapaamisiin.
Järvenpään Viljan kokouskäytännöt eivät juurikaan poikenneet perinteisin suunnittelumenetelmin suunnitelluista omaperusteisista asuntokohteista. Suunnittelukokouksia järjestettiin noin kerran kuukaudessa kohdeyrityksen toimintajärjestelmän asialistan mukaisesti ja niissä mm. verrattiin suunnittelutilannetta suunnitteluaikatauluun, käytiin läpi
suunnittelijoiden asiat ja sovittiin vaadittavat toimenpiteet.1,2 Suunnittelukokouksissa
sovittiin myös suunnittelijoiden keskinäiset yhteensovittamispalaverit tarpeen mukaan,
kuten hormi/tilavarauspalaveri, joista laadittiin myös pöytäkirjat.3, 4
Pääsuunnittelijan tekemä yhdistelmämallin tarkastus käytiin läpi aina suunnittelukokouksen päätteeksi, jolloin suunnittelukokousasioiden käsittelyyn meni noin 1,5 tuntia ja
yhdistelmämallin läpikäyntiin 1,5 tuntia. Osapuolet kokivat käytännön toimivaksi. Joissakin projekteissa pidetään erillisiä tietomallikokouksia yhdistelmämallin tarkastusta
varten, mutta kohteen projektipäällikkö ja suunnittelijat kokivat että kaikki kokousasiat
on parempi käydä samana päivänä. 5 Suunnittelukokousten järjestäminen kuukauden
välein ei ollut aina automaatio, vaan niiden tarvetta peilattiin aina suunnittelutilanteeseen.6 Toisinaan kokouksia järjestettiin tiheämmin, joskus taas harvemmin.
1
Mäenpää. Haastattelu 25.6.2013
Laine Haastattelu 28.5.2013
3
Mustalammi. Puhelinhaastattelu 13.6.2013
4
Laine Haastattelu 28.5.2013
5
6
Konola. Haastattelu 5.6.2013
2
68
3.3.2.3 Pohjantien koulu
Pohjantien koulussa suunnittelijat ja projektiorganisaatio kokoontuivat aina kahden viikon välein siten, että joka toinen kokous oli perinteinen asialistaan sidottu suunnittelukokous jossa käytiin myös tietomalliasiat läpi, ja joka toinen kokous LastPlannerkokous.
LastPlanner-, eli rullaavien suunnitteluaikataulukokousten tarkoituksena oli tarkentaa
lähiviikkojen aikataulutusta suunnitteluaikataulusta. Tavanomainen tarkastelujakso oli
2-4 viikkoa kokouksen järjestämisestä eteenpäin. Kokoukset olivat luonteeltaan vapaamuotoisia ja niissä puheenvuoro oli pääsääntöisesti suunnittelijoilla. Niissä käytiin läpi
lähiviikkojen suunnittelutehtävät suunnittelualoittain, joiden yhteyteen myös kirjattiin
deadlinet ja suunnittelijoiden toisiltaan tarvitsemat lähtötiedot, sekä mahdolliset suunnittelijoiden keskinäisesti järjestämät palaverit.1 Kokousasioiden kirjaamiseen käytettiin
erillistä LastPlanner aikataulupohjaa. Kokousten pohjana käytettiin aina edellisessä kokouksessa täytettyä pohjaa, jolloin sovitut tehtävät ja niiden toteutuminen käytiin yhdessä läpi. Aikataulupohja sisälsi myös tehtävien suorittamisen valvontaan käytetyn sarakkeen, mutta sitä ei case-kohteessa käytetty.
Suunnittelijoiden ja projektiorganisaation mielipiteitä suunnittelukokouskäytännöistä
käytiin läpi suunnittelun palautekeskustelutilaisuudessa Kuopiossa 5.9.2013.2 LastPlanner-kokousten idea koettiin yleisesti toimivaksi. Johtuen niistä tai suunnitteluryhmän
ryhmädynamiikan kehittymisestä kohteiden välillä, koettiin että esimerkiksi alakattokorot saatiin sovittua tarpeeksi ajoissa, mikä ei ole itsestäänselvyys etenkään peruskorjauskohteissa. LastPlanner kokousten pahimmaksi ongelmaksi suunnittelijat kokivat fyysisen läsnäolon, sillä kokoustaminen yleisesti häiritsee suunnittelutyötä. Palautekeskustelussa pohdittiinkin mahdollisuutta järjestää LastPlanner-kokoukset tulevaisuudessa
videoneuvotteluina.
Osa suunnittelijoista ja talotekniset urakoitsijat kokivat, että perinteiset suunnittelukokoukset venyivät aika ajoin liikaa detaljisuunnittelun puolelle. 3 He kokivat että asioiden
”hieromista” suunnittelukokouksissa tulisi välttää, sillä suunnittelukokoukseen osallis-
1
Pohjantien koulun suunnittelun palautekeskustelu, Kuopio. 5.9.2013
3
2
69
tuu myös osapuolia joita ongelmat eivät suoranaisesti koske. Yleisesti tähän syynä pidettiin sitä, että ongelmien käsittely tuo usein esille myös muita ongelmia, mikä saattaa
venyttää niiden käsittelyä. Toinen näkökulma oli, että jos ongelmia ei käsitellä suunnittelukokouksissa vaan jätetään osapuolten keskinäisesti ratkaistavaksi, riskinä on että
vaadittavat toimenpiteet eivät tule tehdyksi vaan ongelmat toistuvat kokouksesta toiseen. Pohjantien koulussa kuitenkin koettiin, että deadlinejen sopiminen suunnittelutehtäville LastPlanner-kokouksissa varmisti, etteivät ne jääneet roikkumaan.
Kuva 22. Ote Pohjantien koulun LastPlanner-aikataulusta. Lähde: Niskakangas, V.
2013. s. 27
3.3.3 Suunnitteluaikataulut ja tiedonvaihtotarpeiden tarkentaminen suunnitteluaikataulusta
Kastellin monitoimitalossa oli käytössä projektiaikataulu, johon on asetettu yhteisiä
välitavoitteita suunnittelun edetessä tuotannon tarpeiden mukaisesti, sillä myös rakentaminen on edennyt kohteen lohkojaon mukaisesti.1 Suunnittelijat ovat asettaneet toisillensa suunnittelu- ja lähtötietotavoitteita pääsääntöisesti suunnittelijoiden palavereissa,
joiden mukaisesti sovitut toimenpiteet on pyritty toteuttamaan suunnittelukokousvälillä.
1
70
Kohteen projektijohtaja piti suunnitteluaikataulun laatimista Kastellissa erittäin haastavana, johtuen juuri koko rakennusmassan suunnittelun ja tuotantopiirrustusten suunnittelun päällekkäisyydestä.1 Pääasiassa erityissuunnittelun aikatauluttaminen on helpompaa sillä suunnitteluratkaisut kulminoituvat yhdellä lohkolla, toisin kuin arkkitehtisuunnittelu, jota viedään eteenpäin enemmän myös kokonaisuuden ehdoilla.
Haastateltavien mukaan tietomallintaminen tuo omat ongelmansa tiukassa, jatkuvasti
muutoksen alla olevassa suunnitteluaikataulussa. Tuotantoon sekä kohteen tilaajan
suunnitelmien hyväksyttämiseen käytetään pääasiassa 2d-suunnitelmia, jotka tuotetaan
tietomalleista. Tällöin myös tietomallien tietosisällöt ja mallintamisen tarkkuustaso pitäisi pystyä määrittelemään myös osana suunnitteluaikataulua tarvittavien suunnitelmadokumenttien kautta, mikä suoraviivaisemmissa kohteissa on helpompaa. Suunnittelijat
antoivat haastatteluissa esimerkkejä etenkin poikkeavista rakenneratkaisuista, joissa
suunnittelua jouduttiin tekemään tästä johtuen 2D:nä. Projektin alkuvaiheessa tulisi olla
aikaa miettiä, millä tarkkuustasolla mitäkin suunnitelmakokonaisuuksia kannattaa toteuttaa, ja samalla huomioida että suunnitelmien tuottaminen tietomalleista kaikilta osin
ei ole kovinkaan automaattista.
Järvenpään Viljassa oli käytössä normaali jana-aikataulu suunnitteluaikatauluna. Suunnittelu oli jaettu aikataulussa suunnittelualoittain luonnossuunnittelu-, rakennuslupa- ja
toteutussuunnitteluvaiheisiin, jotka vastaavat tyypillisen talonrakennushankkeen kulkua.
Lisäksi suunnittelua ohjaavat asuntotuotannolle tyypilliset virstanpylväät, joita ovat
mm.:
1
-
Määrä- ja kustannuslaskenta
-
Maanrakennustöiden tarjouspyyntöaineisto
-
Elementtitoimituksen tarjouspyyntöaineisto
-
LVIS-urakkalaskenta-aineisto
-
Ennakkomarkkinointi
-
Markkinointi
71
Kohteen projektipäällikön mukaan merkittävimmät erot aikataulussa tavanomaisen
hankkeen suunnitteluun olivat arkkitehdin luonnossuunnitteluun ja tietomallin rakentamiseen varattu pidennetty aikaväli, sekä suunnitteluaikatauluun merkityt tietomallikoordinaattorin tarkastukset ja arkkitehdin tietomallin kehitysvaiheet. Projektipäällikkö
koki että jatkossa osapuolten saadessa kokemusta myös tietomallintamisesta, suunnittelun alkuvaiheeseen varattua aika pystytään lyhentämään. 1 Alustavaa järjestelmä- ja osasuunnittelua, kuten tilavarauksia ja alakattosuunnittelua projektipäällikkö kertoi pilkkoneensa seuraavaan projektiin hieman tarkemmiksi suunnitteluaikataulun janoista. Tavoitteena olisi, että arkkitehdin alustavaan tietomalliin saataisiin tarkennettua tietoa järjestelmien tilanvarauksista mahdollisimman aikaisessa vaiheessa.
Suunnitteluaikataulu pystytään suunnittelemaan asuntokohteessa jo alustavasti melko
tarkaksi, ja asuntokohteet pyritään aloittamaan lähes valmiilla suunnitelmilla. Suunnittelun etenemistä ohjaavat projektille asetetut tahdistavat virstanpylväät, joita vasten suunnittelua peilataan suunnittelukokouksissa. Suunnittelijat kokivat, että tiedonvaihtotarpeet ja osapuolten tarvitsemat lähtötiedot tulivat hyvin esille suunnittelukotuksissa, sekä
kokousten ulkopuolisessa, normaalissa suunnittelijoiden välisessä kanssakäymisessä.
Ajoittain aikataulussa pysyminen aiheutti tietyissä suunnitteluvaiheissa ongelmia, mutta
kukaan haastatelluista osapuolista ei kokenut sen vaikuttaneen suunnitteluvaiheiden
lähtötietoihin.
3.3.3.3 Pohjantien Koulu
Suunnitteluaikataulu ei kohteen projektipäällikön mukaan ole ollut kaikissa elinkaarihankkeen kohteissa samanlainen, vaan se on kehittynyt nykyiseen muotoonsa vasta
Pohjantien koulun hankkeen aikana. Suunnittelulle on laadittu aluksi yleisaikataulu,
jonka osatehtäviä on tarkennettu ja päivitetty aikatauluun yhdessä suunnittelijoiden
kanssa ”Tiedonvaihto suunnittelijoiden kesken” -otsikon alle LastPlanner-kokouksissa.
Kokouksissa tiedonvaihtoa on purettu aikataulun osatehtävien tuotoksista taaksepäin
seuraavien asioiden osalta:
-
Mitä suunnittelualakohtaisia alatehtäviä osatehtävän suorittaminen edellyttää,
-
mitkä ovat suunnittelualakohtaiset lähtötietovaatimukset alatehtäville muilta
osapuolilta,
1
72
-
mitä asioita tulee yhdessä päättää/lukita,
-
mitä suunnittelijoiden välisiä palavereja alatehtävien suorittaminen edellyttää,
-
sekä millä viikolla alatehtävä tulee olla tehtynä, tai lähtötiedot toimitettuina. 1
Kuva 23. Suunnitteluaikataulun tehtävien tarkentaminen LastPlanner-kokouksissa.
Kohteen projektipäällikön mukaan ensimmäisissä Kuopion elinkaarihankekokonaisuuden kohteissa suunnittelulle oli varattu vähemmän aikaa ja se tapahtui enemmän päällekkäisesti rakentamisen kanssa. Kaksi viimeistä kohdetta on puolestaan ollut korjauskohteita ja LastPlanner-aikataulutus otettiin käyttöön Pohjantien koulussa. Hänen mukaansa kokemuksen myötä projektin osapuolten välinen toiminta on kehittynyt kohde
kohteelta myös aikataulutuksen osalta. Merkittävimmät erot perinteisen uudiskohteen
aikataulusuunnitteluun olivat Pohjantien koulussa korjauskohteelle tyypillinen yllätyksellisyys, sekä toisaalta elinkaarihankkeelle tyypillinen ratkaisuvaihtoehtojen tutkiminen, joita yhteistyössä määritelty suunnitteluaikataulu menettelynä tuki.2
1
2
73
3.3.4 Mallinnusaineisto ja mallien hyödyntämisen määrittely projektin alkuvaiheessa
Yleisesti kohdeyrityksen mallinnuksen tavoitteita määrittelevään hankesuunnitteluaineistoon oltiin tyytyväisiä, eräs haastateltavista jopa luonnehti sitä ”parhaaksi vastaan
tulleista”. Suunnittelijat pitivät alkuvaiheen mallien sisällön tarkkaa määrittämistä erittäin tärkeänä, jotta myös suunnittelun resursointi voidaan ottaa huomioon.
Kohdeyrityksen aineisto perustuu YTV 2012 ohjeistuksiin, sekä yrityksen sisäisiin dokumentteihin. Suunnittelun alkuvaiheessa joko hankkeen projektipäällikkö tai muu projektihenkilöstön edustaja on muokannut sisältöä projektin tavoitteita ja mallien hyödyntämistä vastaavaksi. Tavoitteet mallintamiselle on pystytty määrittelemään myöhemmissä projekteissa paremmin aineiston kehittyessä. Lisäksi haastatellut suunnittelijat
kokivat, että tavoitteita täsmennettiin tietomallinnuksen aloituspalavereissa tai ensimmäisissä suunnittelukokouksissa, joita järjestettiin tarpeen mukaan useampiakin. Kokouksissa oli paikalla myös Lemminkäisen tuotanto- ja laskentahenkilöstöä osaltaan tuomassa vaatimuksia esille.
Pohjantien koulussa suunnittelun lähtötiedot määriteltiin jo vuonna 2008–2009, jolloin
käytettävä aineisto ei ollut kovin laaja, vaan perustui sen aikaiseen ”parhaaseen tietoon”. Kuitenkin hankkeen projektipäällikön mukaan kohteesta toiseen pystyttiin yhä
paremmin määrittelemään mallintamisen tavoitteita yhdessä suunnittelijoiden ja urakoitsijoiden kanssa.1
Kastellin monitoimitalossa arkkitehdin natiivimallin hyödyntämistä haittasi se, että arkkitehtitoimistolla oli käytössä Autocad Architecture -ohjelmisto, minkä hyödyntämisestä esimerkiksi määrien tuottamiseen ei tuotanto-organisaatiossa ollut kokemusta, eikä
kohdeyrityksen tietomallinnusohjeistus varsinaisesti tue sitä. Suunnitteluohjelmisto olisi
ollut mahdollista vaihtaa, mutta kohteen kiireisessä aikataulussa siihen ei olisi ollut
valmiuksia.2 Lemminkäisen tietomalliasiantuntijoiden mukaan hankkeissa joudutaan
joskus käyttämään suunnittelutoimistoja, jotka käyttävät ohjelmistoja, joiden käyttö
rajoittaa mallien hyödyntämistä kohdeyrityksen tarpeisiin.3 Kuitenkin uudemmissa pro-
1
3
Virit, Partanen. Haastattelu, Helsinki 26.8.2013
2
74
jekteissa suunnittelijoilta on enenevässä määrin ruvettu vaatimaan tavoitteita tukevien
ohjelmistojen käyttöä. Tämä kuitenkin vaatii enemmän aikaa uuden opettelulle projektin alkuvaiheessa, mikäli uusi suunnitteluohjelmisto otetaan suunnittelutoimistossa käyttöön projektia varten.
Eniten
palautetta
suunnittelun
ohjeistuksesta
antoivat
haastatteluissa
TATE-
suunnittelijat, jotka olisivat kaivanneet tarkempaa tavoitteiden määrittämistä suunnittelunohjaukselta. Heidän mukaansa mallien tarkkuustason ja sisällön määrittely on perustunut enimmäkseen YTV2012-ohjeistukseen, johon on myös suunnittelusopimuksissa
viitattu. Suunnittelijat olisivat kaivanneet tarkempaa projektien tavoitteet huomioivaa
vaatimusten määrittelyä, kuten arkkitehti- ja rakennemalleissa, joiden tietomallien tietosisältö määritellään rakennusosittain kolmeen eri tasoon tavoitteiden mukaisesti. Toisaalta TATE-mallien hyödyntäminen muutoin kun suunnitelmien yhteensovittamiseen
ja visuaaliseen suunnitelmien havainnointiin oli Järvenpään Viljassa ja Kastellin monitoimitalossa
melko
vähäistä,
esimerkiksi
Kastellissa
määräluettelot
TATE-
1
suunnitelmista urakoitsijalle toimitti LVI-suunnittelija. Erityisesti Pohjantien koulussa
elinkaarihankkeen sopimuskumppanina olleen Lemminkäinen Talotekniikka Oy:n projektipäälliköt osallistuivat aktiivisesti TATE-suunnitelmien suunnittelunohjaukseen.
Kuopiossa pidetyssä suunnittelun palautekeskustelussa TATE-urakoitsijat antoivatkin
palautetta, mihin suuntaan suunnittelun tarkkuustasoa ja asennettavuuden vaatimia toleransseja kannattaa jatkossa viedä, jotta tietomalleista olisi eniten hyötyä tuotannon näkökulmasta.2 Yleisesti taloteknisten suunnitteluohjelmistojen osaaminen on Lemminkäinen Talo Oy:n organisaatiossa vähäistä, mistä johtuen suunnitteludokumentointia on
myös kehitetty vähemmän.
3.3.5 Projektipankki ja muut tiedonsiirto- ja kommunikointivälineet
Kaikissa case-projekteissa oli projektipankki käytössä tiedonsiirron alustana. Projektipankin eduiksi mainittiin, että se on kaikille osapuolille tuttu menetelmä jo aikaisemmista projekteista ja tiedonsiirto sen kautta on hallittua ja valvottavissa, toisin kuin esimerkiksi suunnittelijoiden välisessä mallitiedonvaihdossa. Negatiivisiksi asioiksi koettiin projektipankkijulkaisuiden raskaus ja monimutkaiset kansiorakenteet, jotka ovat
standardeja kohdeyrityksen projekteissa.
1
2
Kaakinen. Puhelinhaastattelu 29.5.2013
75
Osa haastatelluista olisi kaivannut nopeampaa, joustavampaa tiedonvaihtoa varten esimerkiksi yhteisen verkkolevyn tai mallipalvelimen. Erityisesti tästä odotettiin olevan
hyötyä tietomallien aiempaa reaaliaikaisempaa yhdistämistä varten. Kuitenkin suunnittelijat on monesti sidottuina oman suunnittelutoimistonsa tietoturvakäytäntöihin, joten
käytännössä sellaisen ottaminen käyttöön nykyisellä tekniikalla voisi olla vaikeaa.
Pääosin suunnittelukokousten välillä suunnittelijat ovat käyttäneet kommunikointiin
sähköpostia ja malleista otettuja kuvankaappauksia tai pdf:iä. Muutamat haastatelluista
kertoivat kaivanneensa kommenttien siirtoa yhdistelmämallia hyödyntäen, etenkin tulevia projekteja silmälläpitäen. Erityisesti he kokivat että yhdistelmämallien tarkastusten
kommentoimiseen olisi jatkossa hyvä käyttää Tekla Bimsightin tai Solibrin käyttämää
bcfzip-muotoa. Nykyisellään tarkastusraportit on pääosin siirretty osapuolille excel- tai
pdf-muodossa ja kommentit on päivitetty yhdessä aina kokouspäivinä.
3.3.6 Mallien päivitystiheys
Pääsääntöisesti suunnittelijat julkaisivat tietomallinsa aina ennen yhdistelmämallien
tarkastusta, siten että tietomallikoordinaattorilla on aikaa yhdistää mallit ja tarkastaa ne.
Järvenpään Viljassa palaveriväli oli kuukausi, Kastellissa ja Pohjantiessä kaksi viikkoa.
Järvenpään Viljassa pääsuunnittelija julkaisi lisäksi työmalleja muun suunnittelun tueksi
1-2 viikon välein etenkin kun malliin oli tullut merkittäviä muutoksia. Muutokset edelliseen julkaisuun verrattuna dokumentoitiin tietomalliselostukseen.1,2 Myös Pohjantien
koulussa arkkitehti tarvittaessa julkaisi työmalleja muun suunnittelun tueksi.3 Viljan
rakennesuunnittelija ja LVI-suunnittelija kertoivat ottaneensa myöhemmissä projekteissa käyttöön tietomallipohjaisten reikävaraustietojen siirtämisen, joka heidän mukaansa
vaatii tiheämpää mallien vaihtoa.4 Myös Kastellissa kohteen tuotantoinsinööri kertoi,
että kiivaimmassa vaiheessa rakennemalli lähetettiin hänelle viikon välein tuotannon
tueksi.5
Kastellin monitoimitalossa haastatellut suunnittelijat kertoivat, että kahden viikon julkaisusykli on ollut heidän tarpeisiinsa riittävä, erityisesti mallien tarkastuksessa ilmen1
3
4
5
Mäläskä. Haastattelu, Oulu 16.5.2013
2
76
neet ongelmat ehditään tällä aikavälillä korjata. Eräs suunnittelijoista kertoi, että erityisesti mallien julkaisemisen edellytyksenä oleva tietomallin siistiminen ja pintapuolinen
tarkastus, tietomalliselostuksen täyttäminen sekä tietomallin lataaminen projektipankkiin on kokonaisuutena melko raskas prosessi, mikä hankaloittaisi tiheämmän julkaisusyklin käyttöönottoa.
3.3.7 Tietomalliselostus
Tietomalliselostus on kunkin suunnittelualan ylläpitämä kuvaus mallin sisällöstä, käytetyistä mallinnustavoista ja mahdollisista poikkeamista yleisiin vaatimuksiin tai mallinnustapoihin nähden. Sen avulla muut osapuolet voivat tulkita mallin valmiusastetta,
tietomalliin tehtyjä muutoksia, objektien nimeämiskäytäntöjä ja mallin yleistä rakennetta. Tietomalliselostus tulee päivittää aina mallijulkaisuiden yhteydessä huolimatta siitä,
onko kyseessä työmalli vai virallinen julkaisu.1
Suunnittelijat kertoivat aina pääosin täyttäneensä tietomalliselostuksen julkaisuiden
yhteydessä. Sen sijaan muutama haastateltu suunnittelija kertoi, ettei oikeastaan ole
käyttänyt muiden suunnittelijoiden tietomalliselostuksia, vaan on pitänyt sen merkitystä
tärkeämpänä tietomallikoordinaattorille. Yleisesti haastatteluista ei tullut esille, että
suunnittelijat olisivat hyödyntäneet toistensa tietomalliselostuksia aina erityisen aktiivisesti.
Lemminkäisen henkilöstö koki että tietomalliselostuksia ei aina julkaistu ja niiden taso
oli vaihteleva, osa julkaistuista tietomalliselostuksista oli esimerkillisiäkin. Lemminkäisen tietomalliasiantuntijoiden mukaan tilanne on parantunut aiemmasta, yleisesti tietomalliselostuksia on alettu projekteissa vaatia tiukemmin.2
3.3.8 Suunnitelmien valmiusaste ja suunnitelmamuutokset
Suurimmat suunnitelmien ja suunnitteluperiaatteiden muutokset pystyttiin suunnittelijaosapuolten mukaan viestimään hyvin osapuolille sähköpostin välityksellä, tai työmaakokousten yhteydessä. Myös työmaiden tarpeisiin tehdyt suunnitelmien muutokset ja
korjaukset saatiin sovittua työnjohdon kautta, eivätkä ne aina kerrotuissa esimerkeissä
vaikuttaneet muihin suunnittelijoihin. Eniten osapuolia muutoksissa tuntuivat häiritse1
2
YTV2012: Osa 1
77
vän suunnitelmien yhteensovittamiseen ja tilankäytön suunnitteluun liittyvät muutokset,
kuten aukkojen ja alakattojen sijainti- ja korkomuutokset.
Muutosten syistä korostui useammassa suunnittelijahaastattelussa kaksi yksittäistä asiaa:
-
Suunnittelijat kokivat, että suunnittelua tukevia 2D-leikkauksia ja -detaljeja olisi
pitänyt tehdä enemmän. He kokivat niitä tehdessä paljastuvan usein asioita, jotka myöhemmin ovat johtaneet muutoksiin.
-
Suunnittelijat kokivat, että vaikka muutokset ovat osa suunnittelutyötä, suunnittelukokonaisuuksia (esim. alakattoalueet) ei lukittu tarpeeksi selkeästi tai tarpeeksi varhaisessa vaiheessa. Tämä johti siihen, että muutoksia ilmeni liian
usein, tai niiden päivittäminen valmiisiin suunnitelmiin oli erittäin työlästä.
Useat haastateltavista suunnittelijoista projekteissa kokivatkin, että lähtötietotarpeiden
ja suunnittelukokonaisuuksien lukitseminen ja aikatauluttaminen on yksittäinen asia,
mitä myös kohdeyrityksen suunnittelunohjauksessa olisi syytä parantaa. Eräs haastateltavista koki, että osapuolten lähtötietotarpeita ja suunnittelukokonaisuuksien lukitsemispäivämääriä oltaisiin voitu kirjata tarkemmin esimerkiksi jonkinlaiseen tiedonvaihtoaikataulupohjaan. Muutokset lukitsemispäivämäärien jälkeen tulisi tiedottaa osapuolille selkeästi ja käsitellä poikkeamina sovitusta. Toinen haastatelluista koki, että suunnittelualakohtaisten mallien luovuttaminen muiden suunnittelualojen lähtötiedoksi tulisi
olla hallittua, eikä suunnittelijoiden luonnostelua ole tarkoituksenmukaista häiritä liian
aikaisilla lähtötietovaatimuksilla.
Muutosten päivittämisen työläyttä korostivat eniten TATE-suunnittelijat. Heidän mukaansa LVI- ja sähkösuunnittelijoilla yleisesti käytössä olevassa Progman Oy:n MagiCAD-ohjelmistossa esimerkiksi järjestelmien korkomuutosten tekeminen on erittäin
työlästä ja kankeaa. Monesti muutokset olisi jopa helpompi toteuttaa poistamalla objektit tietomallista ja mallintamalla ne uudestaan, mikä kuitenkin johtaa objektien GUIDtietojen menettämiseen.
Sekä haastatteluissa, että Pohjantien koulun suunnittelun palautekeskustelussa nostettiin
esille suunnitelmamuutosten viestimisen vaikeus. Suunnittelijat kokivat, että projektiluontoisessa suunnittelutyössä projektipankkien ilmoituksia muutetuista suunnitelmista
78
tulee samanaikaisesti useasta projektista. Tietomallien yhteensovittamisesta aiheutuvia
muutostarpeita tulee yleisesti valtavasti, joten omiin suunnitelmiin vaikuttavien muutosten läpikäynti muiden suunnittelualojen malleista on erittäin aikaa vievää. Osapuolet
kokivat, että suunnitelmamuutosten tietomallipohjaiseen tiedottamiseen suunnittelu/tarkastusohjelmistot eivät sisällä työkaluja.
Kattavien muutoslistojen tuottaminen koettiin työlääksi ja niihin sisältyy inhimillinen
riski, että jotain olennaista voi jäädä kirjaamatta. Lisäksi muutosten ilmaantuessa tietomalleihin, myös muut suunnitelmadokumentit ja selostukset tulisi huomioida aina päivittää niiden osalta, mikä lisää muutosten viestimisen vaikeutta. Eräs haastateltavista
kertoi, että vaikka muutoslistaukset tehtäisiin huolella, ne julkaistaan aina tietyissä tarkastuspisteissä virallisten suunnitelmajulkaisuiden, eikä työpohjien yhteydessä. Tällöin
tieto muutoksista saattaa ajallisesti tulla liian myöhään ja suunnitelmia täytyy niiden
osalta korjata. Lisäksi haastatteluissa kävi ilmi, että osapuolet kokivat ajoittain vaikeaksi kohdentaa pitkien muutoslistausten kirjaukset tietomalleihin.
Muutosten lisäksi osapuolet kokivat suunnitelmien valmiusasteen viestimisen asiaksi,
mihin tällä hetkellä ei ole ratkaisua, eikä valmiusasteista siten voida aina olla varmoja.
Suunnittelijat kokivat tiedon valmiusasteesta edellytykseksi, että muiden suunnittelualojen suunnitelmia voidaan käyttää suunnittelun lähtötietoina. Muutosten toteuttamisen ja
paikallistamisen ollessa raskasta, he pyrkivät lykkäämään lopullista suunnittelua pisteeseen, jossa muutoksia lähtötietoihin ei enää tule. Tuotannon aikana tietomalleja sen sijaan hyödynnetään yhä enemmän asennuksessa, jotta tekniikka saadaan sovitettua ongelmitta sille varattuihin tiloihin. Koska tekniikkaa toimitilakohteissa on yleisesti valtavasti ja tietomalleja käytetään käytännössä asennuspiirustuksina, myös vaatimus tiedon
oikeellisuudelle on kasvanut. Eräs haastatelluista projektipäälliköistä piti ongelmallisena, miten suunnitelmien valmiusaste saataisiin viestittyä tällöin myös urakoitsijoille.
Case-projekteista löytyi esimerkki, jossa jo asennettuihin järjestelmiin tulikin suunnittelijalähtöisiä muutoksia ja asennuksia jouduttiin niiden osalta purkamaan.
Lemminkäisen tietomalliasiantuntijat kertoivat haastattelussa, että arkkitehdin tietomalliselosteen liitteeksi on kehitetty tuleviin projekteihin taulukko, johon suunnittelija merkitsisi käytettyjen mallinnustyökalujen, kuvatasojen ja nimeämiskäytäntöjen lisäksi
79
myös rakennusosittain suunnittelun valmiusasteet. He eivät kuitenkaan osanneet sanoa,
tullaanko taulukko ottamaan tulevaisuudessa käyttöön.1
3.3.9 Tietomalleista tuotetut suunnitelmat
2D-suunnitelmat vastasivat haastateltavien mukaan tietomalleja lähes poikkeuksetta,
eikä päällekkäistä työtä tehty mallintamalla ja cad-piirtämällä, kuten joissakin projekteissa on kiireen vuoksi saatettu tehdä.2 Suunnitelmat tuotettiin Cad-viivapiirroksina
vain seuraavissa tapauksissa:
-
Suunnittelua tukevat ja osapiirustukset detaljit, leikkaukset ja kaaviot,
-
alussa määritelty mallintamisen tarkkuustaso ei riittänyt piirustusten tuottamiseen,
-
mallien valmiusaste ei tietyiltä osin ollut riittävä 2d-piirrustusten tuottamiseen
(ei kohdannut piirustusten tarpeen kanssa ajallisesti),
-
tai tieto siirtyi piirustuksiin työmaan/hankinnan tarpeisiin nopeammin.
Poikkeamat piirustusten ja tietomallien välillä pyrittiin kuitenkin aina korjaamaan myöhempiin mallijulkaisuihin.
Yleisesti ottaen koettiin, että tietomalleista tuotetut suunnitelmat olivat vaikealukuisempia kuin perinteisesti tuotetut suunnitelmat, pääosin niiden lisääntyneen tietomäärän
vuoksi. Joissain tapauksissa myös tekniset ongelmat haittasivat piirustusten tuottamista.
Piirustuksista saatiin kuitenkin luettavia, joskin se vaatii suunnittelijoilta ajoittain melko
paljon siistimistä.
3.3.10 Suunnittelijoiden omat laadunvarmistusmenettelyt
Haastatteluissa ilmeni, että suunnittelijoiden omissa tietomallien sisäisten virheiden
poistamiseen tähtäävissä laadunvarmistusmenettelyissä oli eroja. Ensimmäinen ryhmä
haasteltavista kertoi luottavansa pääasiassa tietomallikoordinaattorin tarkastukseen, ja
tarkastavansa oman mallinsa lähinnä visuaalisilla työkaluilla pintapuolisesti. Toinen
ryhmä kertoi käyttävänsä suunnitteluohjelmistojen sisäisiä törmäystarkastelutyökaluja,
jollaiset on esimerkiksi MagiCadissa ja Tekla Structuresissa. Ainoastaan yksi haastatel-
1
2
80
luista suunnittelijoista kertoi tarkastavansa tietomallinsa YTV2012-tarkastuslistan mukaisesti Solibri Model Checkerillä.
Haastatelluista projektihenkilöstön edustajista useampi koki, että suunnittelijoiden
omissa laadunvarmistusmenettelyissä olisi parannettavaa. Suunnittelualojen tietomallien
sisäisiä virheitä on ollut joiltain osin melko paljon, ja niiden käsittely suunnittelukokouksissa on vienyt yhteistä aikaa.
Eräs haastatelluista suunnittelijoista totesi että tarkastuksen tulee aina perustua suunnittelutoimiston sisäiseen laatujärjestelmään, mihin on myös yleisesti projekteissa luotettu.
Muutama haastatelluista näkivät, että he tulevissa projekteissa voisivat tarkastaa omat
tietomallinsa paremmin ennen julkaisua. Yksittäisiksi syiksi tarkastuksen puutteellisuudelle he näkivät aiemman osaamisensa (uuden opettelu), sekä tarkastusohjelmistojen
lisenssien puutteen suunnittelutoimistoissa. Yleisten tietomallivaatimusten osan 6. liitteissä esitettyjä suunnittelualakohtaisia laadunvarmistuksen tarkastusraportteja ei casekohteissa käytetty, mutta vaatimuksia suunnittelijoiden laadunvarmistusmenettelyille on
kirjattu projektien tietomalliohjeisiin.
3.3.11 Tietomallikoordinaattorin rooli
Kaikissa case-kohteissa tietomallikoordinaattoriksi nimetyn henkilön rooli oli melko
samantyyppinen, tehtäväkenttään kuului yhdistelmämallin luominen ja tarkastus ennen
yhdistelmämallin läpikäyntiä. Case-kohteissa seuraavat henkilöt toimivat tietomallikoordinaattoreina:
-
Kastellin monitoimitalo: Juho Vuolteenaho, Gravicon Oy
o kohteen pääsuunnittelijan alikonsultti
-
Järvenpään Vilja: Antti Konola, Arkkitehtitoimisto Kaipainen Oy
o kohteen pääsuunnittelija
-
Pohjantien koulu: Artur Virit, Lemminkäinen Talo Oy
o Lemminkäinen Talo Oy:n tietomalliasiantuntija
Lisäksi Lemminkäisen tietomalliasiantuntijat Artur Virit ja Matti Partanen toimivat asiantuntijoina projektihenkilöstön tueksi muiden tietomallintamistehtävien osalta. Kastellin monitoimitalon alun tietomallinnuksen tavoitteiden määrittelyä hoiti Annikki Karppinen, ja siihen osallistui myös tuotantoinsinööri Mikko Mäläskä, sekä kustannusinsi-
81
nööri Riikka Hannuksela. Kaikissa kohteissa varsinaista tietomallikoordinaattorin tarkastuslistan läpikäyntiä johti pääsuunnittelija.
Suunnittelijat olivat yleisesti tyytyväisiä hankkeiden tietomallikoordinaattorien toimintaan. He kokivat tietomallikoordinaattorin tehtävien kuuluvan käytännössä pääsuunnittelijalle, osana velvoitetta ”huolehtia siitä, että rakennussuunnitelma ja erityissuunnitelmat muodostavat kokonaisuuden, joka täyttää sille asetetut vaatimukset.” Vaikka
hankkeeseen olisi palkattu ulkopuolinen konsultti hoitamaan tietomallikoordinaattorin
tehtäviä, tehtäviä ei saisi heidän mukaansa ulkoistaa kovin kauas päänsuunnittelijasta.
He pitivät tietomallikoordinaattorin tärkeimpänä tehtävänä nimenomaan tuoda esille
suunnittelualojen välisiä ristiriitoja suunnitelmissa. Heidän mukaansa tietomallikoordinaattorilla on tärkeää olla asiantuntemusta, jotta ristiriidoista pystytään tuomaan esille
olennaisimmat virheet. Lisäksi he pitivät tärkeänä, että tietomallikoordinaattori on tiiviissä keskusteluyhteydessä suunnittelijoiden kanssa ja myös omalta osaltaan valvoo,
että esille tuodut ongelmat tulevat korjatuiksi. Kastellin monitoimitalon tietomallikoordinaattori Juho Vuolteenaho totesi että tietomallikoordinaattori pystyy toiminnassaan
seuraamaan myös eri suunnitelmien valmiusasteita suhteessa aikatauluun, ja miten
suunnitelmat vastaavat osapuolten välisiä tietotarpeita.1
Lemminkäisen projektihenkilöstön näkökulmat tietomallikoordinaattorin rooliin olivat
vaihtelevia. Haastateltavista useampi nosti esille, että tietomallikoordinaattorin tulisi
olla taho, joka tuo puolueettomasti suunnitteluryhmälle esiin suunnitelmien väliset ristiriidat. He myönsivät että vastuu suunnitelmien ristiriidattomuudesta kuuluu pääsuunnittelijalle, mutta pohtivat, tekeekö pääsuunnittelija tietomallikoordinaattorin roolissa tarkastusta puolueettomasti, vai ”arkkitehdin näkökulmasta”.
Nykyinen tarkastusprosessi on haastateltujen mukaan melko suunnittelijakeskeinen,
malleista on tarkistettu enimmäkseen suunnittelualojen välisiä törmäyksiä. Eräät haastateltavista toivat esille, että nykyisellään tietomallikoordinaattorit eivät ota kantaa tarpeeksi esimerkiksi objektien nimeämiskäytäntöihin tai mallien yleiseen rakenteeseen,
mikä olisi tärkeää laskennan ja tietomallien tuotannonaikaisen hyödyntämisen kannalta.
Lemminkäisen tietomalliasiantuntijoiden mukaan joissain projekteissa tietomallien si-
1
Vuolteenaho. Haastattelu sähköpostin välityksellä
82
sällön valvonta on ollut vähäistä, mikä on vaikeuttanut niiden hyödyntämistä.1 Lisäksi
haastatteluissa sekä Pohjantien koulun suunnittelun palautekeskustelussa tuotiin esille,
että yhdistelmämallien tarkastuksissa tulisi entistä enemmän ottaa huomioon, ovatko
tarkastuksissa ilmenneet ristiriidat taloteknisten järjestelmien osalta asennettavissa. Tämä vaatii sekä tietomallikoordinaattorin asiantuntemusta suunnittelutoleransseista, että
taloteknisten urakoitsijoiden osallistumista raportoitujen virheiden kommentointiin.
Projektihenkilöstö piti erittäin tärkeänä sitä, että tietomallikoordinaattorin roolista huolimatta projekteissa on käytössä osaamista, joka pystyy spesifioimaan Lemminkäisen
vaatimukset tietomalleille, ja toimimaan asiantuntijana tietomallien sisällön ohjauksessa. Näitä tehtäviä hoitava henkilö olisi ikään kuin rakennuttajan oikea käsi, joka hallitsee tehtäväkenttänsä aina hankesuunnittelusta ylläpitoon asti. Projektihenkilöstö koki
tärkeäksi, että tietomallikoordinaattorin tehtäväkenttä pystyttäisiin määrittämään alussa
hankkeen erityispiirteitä tukevaksi, eikä se olisi sidottu pelkästään yhdistelmämallien
tarkastamiseen tai ohjelmistotekniseen osaamiseen.
Antti Konola, joka toimi Järvenpään Viljan tietomallikoordinaattorina, koki että pääsuunnittelijan roolissa tehtävä oli Viljan kokoisessa hankkeessa työmäärältään vielä
sopiva, mutta isommissa hankkeissa tehtävänkuva voisi olla melko laaja hoidettavaksi
suunnittelutyön ohella.2 Myös Kastellin monitoimitalon projektijohtaja oli sitä mieltä,
että Kastellin kokoisessa hankkeessa tietomallikoordinaattorin tehtävät pääsuunnittelijalla olisivat olleet jo resurssikysymys.3
3.3.12 Reikä- ja varaussuunnittelu
Kastellin monitoimitalossa reikäpiirustukset laadittiin perinteisenä 2D-tasokuvana
CAD-työkaluja käyttäen, joskin rakennesuunnittelija hyödynsi LVIS-suunnittelijoiden
tietomalleja tilavarausten varmentamiseen ja törmäilyjen paikallistamiseen mahdollisuuksien mukaan.4 Rakennesuunnittelijan 2d-kerrostasot kierrätettiin menettelyssä
suunnittelijoilla vuorotellen, ja täydennetyt varaustiedot vietiin myöhemmin myös rakennemalliin. TATE-suunnittelijoiden mukaan reikäpiirustuksia ei pystytty tuottamaan
tietomallipohjaisesti johtuen LVIS-järjestelmämallien varhaisesta valmiusasteesta. Koh1
3
4
2
83
teen ontelolaatoilla ja elementeillä oli pitkät toimitusajat, mistä johtuen reikätiedot jouduttiin tuottamaan ennen järjestelmämallien rakentumista. Perinteisistä menettelyistä ja
varhaisesta suunnitelmavaiheesta huolimatta haastateltujen mukaan suunnitellut varaustiedot ovat pitäneet hyvin paikkaansa, eivätkä ne ole aiheuttaneet merkittäviä ongelmia
tuotantoon.
Myös Järvenpään Viljassa reikäpiirustukset laadittiin perinteisesti 2D-reikäkiertona,
jossa
rakennesuunnittelija
toimitti
tasopiirustukset
dwg-muodossa
LVIS-
suunnittelijoille, jotka merkitsivät järjestelmiensä varaustiedot ja palauttivat täydennetyn suunnitelman rakennesuunnittelijalle. Tämän jälkeen rakennesuunnittelija varmensi
varaustiedot ja vei ne elementtikuviin.1, 2 Rakennesuunnittelija kuitenkin mallinsi reikävaraukset myöhemmin laadittujen reikäpiirustusten pohjalta tietomalliinsa. Tällöin reikäpiirustusten ongelmattomuus voitiin varmentaa yhdistelmämallin avulla.3 Haastateltujen mukaan reikä- ja varaustietoihin ei ole liittynyt pahempia ongelmia tuotannossa.
Järvenpään Viljan LVI- ja rakennesuunnittelijat ovat sittemmin työskennelleet yhdessä
uusissa tietomallinnetuissa hankkeissa, ja ovat ottaneet käyttöön tietomallipohjaisen
reikätietojen siirron. Uudessa menettelyssä LVI-suunnittelija tuottaa reikävarausobjektit
IFC-muodossa rakennesuunnittelijan 3D-dwg-mallin pohjalta ja lähettää ne rakennesuunnittelijalle. Rakennesuunnittelija kommentoi LVI-suunnittelijan reikävarauksia
Tekla Structures -ohjelmistossa ja lähettää komentit xsr-muodossa takaisin LVIsuunnittelijalle, joka tuo xsr-tiedoston MagiCadiin. LVI-suunnittelija korjaa varauksia
rakennesuunnittelijan kommenttien mukaisesti, tuottaa uuden IFC-tiedoston ja lähettää
sen takaisin rakennesuunnittelijalle. Kiertoa jatketaan, kunnes varaukset saadaan hyväksytettyä ja rakennesuunnittelija tuottaa tietojen pohjalta 2D-reikäpiirroksen työmaan
tarpeen mukaisesti.4 Rakennesuunnitteluryhmän mukaan uusi menettely useine kommentointikierroksineen aiheuttaa jonkin verran lisätöitä perinteisiin menetelmiin verrattuna, mutta parantaa reikätietojen luotettavuutta. Kun reikien periaatteista sovitaan
suunnittelijoiden välisesti etukäteen, vältytään usealta turhalta reikien kommenttikierroksilta.5
1
3
4
5
2
84
Pohjantien koulussa reikäsuunnitteluun käytettiin osapuolten mukaan poikkeuksellisen
paljon aikaa. Suunnittelun lähtökohtana oli että tietomallit tehdään myös reikäsuunnittelun osalta suunnittelupöydällä mahdollisimman asennettaviksi. Toisin kuin aiemmassa
Rajalan koulussa, Pohjantien koulun vanhat rakenteet mallinnettiin tarkasti suunnittelun
lähtötiedoiksi. Vanhojen rakenteiden mallintamista helpottivat käytössä olleet vanhat
elementtisuunnitelmat, sekä olemassa olevien reikien sijaintien tarkka mittaaminen.
Olemassa olevat reiät mallinnettiin suoraan rakennemalliin ja TATE-suunnittelijat tuottivat uuden tekniikan vaatimat reikätiedot omina IFC-tiedostoina, jotka rakennesuunnittelija puolestaan toi omaan malliinsa varmennettuaan ne.1
Kuitenkaan kaikkia rakenteita ei pystytty lopullisesti varmentamaan ennen purkutöiden
valmistumista esimerkiksi terästysten osalta, vaan rakennesuunnittelija joutui tarkistamaan reikien paikkoja vielä työmaalla. Tämän johdosta suunnitelmia jouduttiin korjaamaan myöhemmin vielä useaan otteeseen, mikä kävi osapuolten mukaan työlääksi erityisesti TATE-suunnitelmien osalta. Suunnittelun palautekeskustelussa pohdittiinkin
kuinka pitkälle suunnitelmat on järkevää viedä reikien osalta, mikäli niitä joudutaan
kuitenkin myöhemmin muuttamaan reikien merkkaamisen yhteydessä. Ongelmakohdat
olisivat toisinaan myös TATE-urakoitsijoiden ratkaistavissa työmaalla, kunhan pääperiaatteet olisi katsottu. Pitkälle yhteensovitetut suunnitelmat vaativat myös kurinalaisuutta
urakoitsijoilta, sillä pahimmassa tapauksessa niistä poikkeaminen voi johtaa asennusten
purkamiseen, kun tekniikkaa ei saada enää sovitettua sille varattuihin tiloihin.1, 2
Lisäksi palautekeskustelussa keskusteltiin reikä- ja varaussuunnittelun uusista vastuukysymyksistä, liittyen mitoilla varustettujen reikäpiirustusten tuottamiseen ja niiden mahdolliseen päivittämiseen rakenteiden purkamisen ja reikien merkkaamisen yhteydessä.
Normaalisti reikäpiirustukset tuottaa rakennesuunnittelija, mutta korjauskohteissa se ei
ole aina yksiselitteistä ja reikäpiirustusten tuottamiseen liittyvät vastuut ja tehtävät tulisi
määritellä jo suunnittelusopimuksissa.3
1
3
2
85
3.3.13 Alakattosuunnittelu
Kastellin monitoimitalossa haastateltavien mukaan alakattoihin tuli suunnittelun aikana
melko paljon muutoksia ja lopullisten alakattokuvien tuottaminen vei huomattavan paljon aikaa. Muutosten suuri määrä johtui haastattelujen mukaan projektin pääosin tiukasta aikataulusta jossa suunnittelua jouduttiin viemään eteenpäin usealla eri lohkolla,
eikä kaikkia alakattoihin vaikuttavia asioita välttämättä osattu ottaa huomioon suunnittelun kiivaimmassa vaiheessa. Alakatoille asetettiin projektissa lukitsemispäivämääriä,
mutta ne eivät aina pitäneet syystä tai toisesta. Muutokset vaikuttivat eniten TATEsuunnitelmiin, sillä kun päätelaitteita siirretään alakatossa, eri TATE-järjestelmien keskinäinen sijoittelu täytyy usein varmentaa uudestaan. Tietomallit sisältävät vain alakaton korkotiedon ja päätelaitteiden sijoittaminen XY-tasossa tehdään edelleen 2Dpiirrustuksina. Osapuolten mukaan uudelleensuunnittelun tarpeet johtuivatkin pääosin
muutoksista alakattoruudukkoon, jotka jouduttiin viemään myös tietomalleihin. Heidän
mukaansa erillisiä 2D-pystyleikkauksia ei alakatoista erityisemmin tehty paitsi mallihuoneen osalta, vaan järjestelmien keskinäistä sijoittumista tarkasteltiin enemmän tietomalleista. Vaikka alakattosuunnittelun pitkittyminen ei vaikuttanut varsinaisesti tuotantoon, osapuolet kokivat että alakattoalueet tulisi saada lukittua aikaisemmassa vaiheessa.
Järvenpään Viljassa alakattosuunnittelussa ei haastateltavien mukaan ollut erityisemmin ongelmia. Yleisesti asuntokohteissa alakaton sisään jäävän tekniikan määrä on pieni, ja toisaalta asuntotuotannossa suunnittelijoille määritellään alakattokorkeudet tilakohtaisesti jo suunnittelun lähtötiedoiksi. Mikäli tekniikka ei syystä tai toisesta mahdu
annettuihin lähtökorkoihin, mietitään talotekniikan reititykset tapauskohtaisesti tarkemmin.1 Tietomallien tarkastuksessa alakattojen ja tekniikan risteämistä tuli paljon
turhia virheilmoituksia. Kipsilevyalakatto mallinnetaan 79 mm paksuna laattana, jonka
rakennepaksuus sisältää alakattorangat sekä kipsilevyn. Alakattorangat koolataan tietyllä jaolla, jolloin esimerkiksi IV-putket pystyvät kulkemaan koolausten välissä ongelmitta. Kuitenkin tarkastusohjelmistot ilmoittavat alakattolaatan ja IV-putkien leikkauksen
1
86
virheenä, eikä sallittuja leikkauksia pystytty Solibrin käytössä olleessa versiossa rajaamaan kipsilevypintaan, vaan virheet täytyy tutkia manuaalisesti.1
Pohjantien koulun osapuolet kokivat, että alakattosuunnitteluvaihe meni projektissa
hyvin. TATE-suunnittelijat saivat arkkitehdiltä alakattosuunnitelmat riittävän ajoissa,
minkä johdosta LVI-järjestelmät pystyttiin suunnittelemaan ensin ja sähkö vasta tämän
jälkeen. Tämä mahdollisti myös järjestelmien keskinäisen yhteensopivuuden. Kohteen
projektipäällikön mukaan alakattosuunnittelun sujuminen ei ollut lähtökohtaisesti itsestäänselvyys, vaan sen merkitys ja suunnitelmamuutosten aiheuttama työmäärä on konkretisoitunut suunnitteluryhmälle yhteistyön kehittyessä hankkeesta toiseen.2 Hänen mukaansa enemmän ongelmia aiheuttivat rakenteelliset yllätykset korjauskohteessa: Toisinaan ongelmat olisivat TATE-asentajien ratkaistavissa työmaalla, mutta mikäli ne halutaan saattaa kuntoon myös suunnitelmissa, valmiiden suunnitelmien muuttaminen aiheuttaa osapuolille melko paljon työtä. Erityisesti LVIS-suunnitteluohjelmistoissa muutosten toteuttaminen on erittäin kankeaa.
Pohjantien koulussa huomattiin, että suunnitteluohjelmistoissa olevien pääte-elimien ja
muiden järjestelmäosien koko ei aina vastannut todellisuutta, mikä johti ongelmiin tekniikan mahduttamisessa niille varattuun tilaan. Lemminkäisen tietomalliasiantuntijan
Artur Viritin mukaan Solibrin versiossa 8.1 pystyisi linkittämään objekteihin PDFlaitekortteja, joista objektien todellisen koon pystyisi varmentamaan. Tämä kuitenkin
lisäisi tietomallikoordinaattorin työmäärää.3
3.3.14 Muut tiivistä tiedonvaihtoa vaativat suunnittelutehtävät
Useat haastateltavista kertoivat, että arkkitehtimallin ja rakennemallin ovi- ja ikkunaaukkojen yhteensovittamisessa oli ongelmia, vaikka tietomallikoordinaattorin tarkastus
sisälsi myös tietomallien aukkojen vertailun. Aukkoja saattoi olla eri linjoissa, niiden
mitoitus oli väärä tai niitä puuttui rakenteista kokonaan muutamassa tapauksessa. Haastateltujen mukaan ongelmat johtuivat pääosin:

arkkitehtien suunnitelmamuutoksista, jotka tuntuivat häiritsevän rakennesuunnittelua aukkomuutosten paikallistamisen osalta,
1
Laine. Haastattelu, Järvenpää 28.5.2013
3
2
87

detaljisuunnittelun puutteesta aukkojen liittymien osalta (jotka myöhemmässä
vaiheessa johtivat aukkojen muutoksiin)

sekä aukkojen sijaintiin tai kokoon liittyvistä ongelmista, joita ei oltu huomattu
visuaalisen tietomallien tarkastuksen yhteydessä.
Haastatteluista ei käynyt ilmi, kuinka aktiivisesti suunnittelijat vertailivat omia mallejansa muiden suunnittelualojen malleihin aukkojen osalta, ja johtuivatko ongelmat
mahdollisesti vertailun puutteesta. Koska case-kohteissa ei tietomallikoordinaattorin
tarkastusta kommentoitu suunnittelukokousten ulkopuolella tietomallipohjaisesti, yksittäisten ongelmakohtien paikantaminen on ollut riippuvaista suunnittelijoiden omasta
aktiivisuudesta.
Eräässä case-kohteista tietomallien kohdistuksessa törmättiin seuraavaan ongelmaan:
Yksi suunnittelualojen tietomalleista oli muista tietomalleista 400 mm poikkeavassa
korossa. Tietomallikoordinaattori oli yhdistänyt tietomallit Solibri Model Checkerillä
IFC-muodossa ensimmäistä tietomallien tarkastusta varten, ja manuaalisesti kohdistanut
poikkeavan tietomallin oikeaan korkoon yhdistelmämallissa. Yhdistelmämallia päivitettiin jatkossa aina uusilla IFC-malleilla tietomallikoordinaattorin tarkastuksen helpottamiseksi (kuten liitteessä 2), jolloin Solibri automaattisesti säilytti pakotetun korkoeron
myös tulevissa tarkastuksissa. Tietomallien korkoero huomattiin vasta myöhemmin
muiden projektin osapuolten yhdistäessä IFC-malleja. Haastateltujen mukaan vaikka
koordinaatiston varmentamisen tärkeys on tiedossa, projekteissa esiintyy edelleen jonkin verran käytännön ongelmia siihen liittyen. Heidän mukaansa on erittäin tärkeää, että
yhtenevä koordinaatisto varmistetaan yhdessä riittävän aikaisessa vaiheessa, vaikka
suunnittelualat etenisivätkin eri tahdissa tietomallien rakentamisen suhteen. Tietomallien kohdistuksessa on heidän mukaansa hyvä käyttää ns. kohdistusobjektia, mutta myös
mallintaa pieni määrä tekniikkaa yhteneväisyyden varmistamiseksi. Erityisen tärkeää on
että arkkitehtimalli on luotuna ennen muiden suunnittelualojen malleja, sillä arkkitehtimalli määrittää muiden tietomallien koordinaatiston. Jos muut suunnittelualat lähtevät
liikkeelle ennen arkkitehtia poikkeavassa koordinaatistossa, tietomallien siirtäminen
koordinaatistossa voi olla mahdotonta jälkikäteen. Kokemusten perusteella eräs haastateltavista suositteli, että suunnitteluun valitaan suorakulmainen koordinaatisto, sillä
kiertokulmat aiheuttavat osapuolille usein ongelmia.
88
Hormien ja pystysuuntaisen LVIS- tekniikan tilavarausten suunnittelu toteutettiin casekohteissa perinteisellä 2D-piirrustuskierroilla. Mitoituksissa ei hyödynnetty juurikaan
tietomalleja, johtuen TATE-suunnittelun varhaisesta valmiusasteesta suhteessa arkkitehti- ja rakennesuunnitteluun alkuvaiheessa. Tilavarausten suunnittelu sujui haastateltujen
mielestä yleisesti hyvin, ja sen edellytyksenä oli tiivis suunnittelijoiden välinen tiedonvaihto. Eräs haastatelluista arkkitehdeistä koki, että TATE-suunnittelijat on hyvä saada
tietomallinnetuissa hankkeissa entistä aikaisemmin mukaan, sillä perinteisesti suunnittelua on viety melko pitkälle arkkitehdin luonnospohjavetoisesti. Mahdolliset muutokset
esimerkiksi hormien koossa aiheuttavat aikaisempaa enemmän häiriöitä myös arkkitehtisuunnitteluun, niiden toteuttamisen ollessa työlästä.
Pohjantien koulussa, joka oli korjauskohde, vanhojen rakenteiden varmentaminen aiheutti oman haasteensa LVIS-suunnitteluun. Tietomallinnetut suunnitelmat tahdottiin tehdä mahdollisimman asennettaviksi, jolloin hormeihin täytyi jättää asennusvaroja, jotka
tietyissä tapauksissa johtivat rakenteiden kasvamiseen. Asennusvaroista huolimatta
asennusten yhteydessä tuli vastaan tiettyjä rakenteellisia yllätyksiä, joista johtuen tekniikkaa ei pystytty asentamaan aina suunnitelmien mukaisesti. Pohjantien suunnittelun
palautekeskustelussa todettiin, että näissä tapauksissa muutokset ovat aina vaikeammin
toteutettavissa suunnittelijoiden kesken mitä pidemmälle suunnittelu etenee, ja toisaalta
ongelmat ovat toisinaan helpommin asennusryhmän ratkaistavissa työmaalla. TATEurakoitsijoiden edustajat näkivät, että suunnitelmien vieminen mahdollisimman asennettavaan tarkkuustasoon tulisi keskittää paljon tekniikkaa sisältäviin paikkoihin, kuten
konehuoneisin ja tekniikan risteämäkohtiin.1
3.3.15 IFC-tiedonsiirtoformaatin ongelmat
Tietomallikoordinaattorin tarkastuksia varten tietomallien geometria siirtyi IFCmuodossa pääasiassa oikein, pahimmat ongelmat formaatin käytössä liittyivät tietomallien muuhun hyödyntämiseen.
Kastellin monitoimitalossa energia- ja elinkaarikonsulttina toimi Green Building Partners Oy. Arkkitehdin IFC-mallia oli tarkoitus hyödyntää kohteen energia-analyysien
tuottamiseen RIUSKA-ohjelmalla, mutta esimerkiksi tiloja ja seiniä ei saatu siirtymään
oikein, eikä mallia siten voitu hyödyntää suoraan. Kohteen tietomallikoordinaattori jou1
89
tui muokkaamaan arkkitehdin mallista pelkistetyn version, eikä tiedonsiirto silloinkaan
sujunut ongelmitta.1,2, Muita IFC-formaattiin liittyneitä ongelmia case-kohteissa olivat:
-
Määrätiedon
tuottaminen
arkkitehtien
ja
rakennesuunnittelijoiden
IFC-
tiedostoista (ongelmat saattavat liittyä IFC-käännön asetuksiin)
-
IFC-tiedostojen tiedostokoko ja hyödyntämisen raskaus ohjelmistoilla
-
Objektien atribuuttitietojen siirtyminen, esimerkiksi IV-kanavien koko LVImääräluetteloita tehtäessä
-
Tiettyjen rakennusosien geometrian siirtymisen ongelmat
-
Arkkitehtimallien boolean-operaatioiden siirtyminen (yleinen ohjeistus toistaiseksi on, ettei boolean-operaatioita käytetä)
-
Objektien muuttamisesta aiheutuneet käännösvirheet
3.3.16 Muiden suunnittelualojen mallien hyödyntäminen
Pääosin haastatellut suunnittelijat hyödynsivät muiden suunnittelijaosapuolten malleja
visuaalisesti omien suunnitelmiensa yhteensovittamiseen. Heidän mukaansa visuaalinen
tarkastelu on tällä hetkellä toimivin menettely epäkohtien havainnoimisessa, sillä ohjelmalliset tarkastuskeinot eivät heidän mukaansa tuo mallien ongelmakohtia yhtä hyvin
esille. Pääosin tietomalleja hyödynnettiin IFC-muodossa laadunvarmistusohjelmistoissa,
mutta myös tuomalla niitä referenssimalleiksi oman mallin rinnalle suunnitteluohjelmistoon, mikä oli välttämätöntä ainakin Kastellin monitoimitalon monimuotoisen kattorakenteen osalta.3 Myös Pohjantien koulun arkkitehti ja rakennesuunnittelija käyttivät
toistensa malleja aktiivisesti tiedonvaihdossa, sillä olemassa oleva rakennus mallinnettiin osaksi rakennemallia.
Muutama haastatelluista suunnittelijoista kuitenkin kertoi, ettei juurikaan hyödyntänyt muiden suunnittelijoiden malleja suunnittelutyön ohessa. Tämä johtui heidän mukaansa poikkeuksetta siitä, että tietoa vaihdettiin suunnittelijoiden välisesti edelleen
pääosin 2D-piirrustusten muodossa, johtuen vakiintuneista käytännöistä tai aikataulullisista syistä.
1
Saarelainen. Haastattelu 3.6.2013
3
2
90
Haastatteluiden mukaan eniten muiden suunnittelualojen malleja tietomallikoordinaattorin tarkastusten ulkopuolella hyödynsivät talotekniikkasuunnittelijat. Sekä sähkö- että
LVI-suunnittelijoilla on yleisesti käytössä MagiCad-suunnitteluohjelmisto, mikä mahdollistaa muiden taloteknisten järjestelmien ristiin vertailun ohjelmiston natiivimuodossa, ilman erillistä IFC-kääntöä. Mahdolliset tekniikan törmäilyt saatiin tällöin sovittua
LVIS-suunnittelijoiden välisesti. Kaikki haastatellut talotekniikkasuunnittelijat hyödynsivät myös aktiivisesti yhdistelmämalleja suunnittelutyön ohessa Solibrilla tai Tekla
BimSightilla usein niin, että he visualisoivat järjestelmien sijoittumista tilavarauksiin
yhdistelmämallissa rinnakkaisella näytöllä samanaikaisesti. Heidän mukaansa tämä oli
välttämätöntä, sillä yleisesti tekniikkaa on paljon, ja tekniikan reikä- ja tilavaraukset
ovat tiukasti mitoitettuja.
Osa haastatelluista arkkitehdeistä ja rakennesuunnittelijoista olivat myös kokeilleet objektien kääntämistä IFC-tiedostoista tai toisen suunnittelijaosapuolen natiivimallista
oman tietomallinsa objekteiksi. Käännetyt objektit eivät kuitenkaan olleet kaikilta osin
tietosisällöltään käyttökelpoisia ja muutosten ilmaantuessa oman mallin päivittäminen
olisi järkevää vasta kun toinen suunnittelijaosapuoli olisi päivittänyt tietomallinsa ensin.
3.3.17 As-built mallien tuottaminen
Case-kohteita ei oltu haastattelututkimuksen aikana vielä luovutettu, eikä as-builtmallien tuottamisen periaatteita sovittu. Osa tuotannonaikaisista muutoksista oli kuitenkin case-kohteissa viety tietomalleihin jo tuotannon aikana. Keskeisimmät luovutuksen
yhteydessä selvitettävät asiat kohteiden projektipäälliköiden mukaan ovat:1,2,3
-
Kuinka tarkasti tuotannon aikaiset muutokset on saatu dokumentoitua urakoitsijoiden toimesta,
1
-
minkä tyyppiset muutokset on järkevää viedä toteumamalleihin,
-
millä tarkkuudella tuotannon aikaiset muutokset tullaan toteuttamaan,
-
kenen vastuulla toteumamallien tuottaminen on,
-
sekä miten toteumamalleja tullaan hyödyntämään ylläpidon aikana.
3
2
91
3.3.18 Mallien luovuttaminen natiivimuodossa
Suurin osa suunnittelijoista ei nähnyt ongelmaa natiivimuotoisten tietomallien luovuttamiselle kohdeyritykselle kohteiden valmistumisen jälkeen. Huoli natiivimuotoisten
mallien luovuttamisessa liittyi juurikin suunnittelutoimistoissa kehitettyjen lisäosien,
objektien tai rakennekirjastojen päätymiseen kolmansille osapuolille. Toisaalta myös
suunnittelusopimuksiin on usein kirjattu, ettei tietomalleja saa luovuttaa kolmansille
osapuolille ilman suunnittelutoimiston lupaa.1
3.4 Keskeiset tulokset ja toiminnan kehitysehdotukset
3.4.1 Ajallisen hallinnan ja suunnittelutiedonvaihdon erityiskysymykset
3.4.1.1 Asuntotuotanto
Järvenpään Viljan haastatteluiden mukaan omaperusteisessa asuntotuotannossa suunnittelulle on perinteisesti varattu riittävästi aikaa. Lisäksi suunnittelun reunaehdot pystytään määrittelemään hyvin tarkasti jo alussa suunnitteluohjeen avulla ja erityissuunnittelu aloitetaan pitkälle vietyjen arkkitehdin luonnossuunnitelmien pohjalta.
Havaintojen perusteella tietomallipohjainen suunnittelu ei aiheuta muutoksia suunnittelun kokouskäytäntöihin, kun yhdistelmämallin ongelmakohdat käsitellään suunnittelukokousten päätteeksi erillisessä yhdistelmäpalaverissa. Osapuolet kokivat, että yhdistettynä suunnittelijoiden normaaliin kanssakäymiseen, osapuolten tiedonvaihtotarpeet tulivat täytettyä. Case-kohteessa käytössä ollut kuukauden kokousväli oli jopa tavanomaista harvempi: kahdenkaan viikon kokousväli asuntokohteissa ei ole poikkeuksellinen.
Tehtävien valmistumista valvottiin ensisijaisesti työmaakokouksissa niistä tuotettujen
piirustusten kautta, suhteessa asuntorakennuksen suunnittelun virstanpylväisiin liittyviin
suunnitelmiin. Osapuolet luonnehtivat kohdetta pilottihankkeeksi ja esimerkiksi reikäja elementtisuunnittelu toteutettiin perinteisin 2D-menetelmin, ja tietomalleja hyödynnettiin ensisijaisesti suunnitelmien yhteensovittamiseen yhdistelmämallien avulla.
1
92
Yleisesti ottaen suunnittelu pysyi Järvenpään Viljassa hyvin aikataulussa ja suunnitelmat saatiin ajallaan, mutta haastatteluissa törmättiin seuraaviin erityiskysymyksiin, jotka mahdollisesti tulisi huomioida tulevissa hankkeissa.
Tietomallien tarkastusten asettaminen tarkoituksenmukaiselle tasolle
Hankkeissa joissa pääsuunnittelija toimii tietomallikoordinaattorina, yhdistelmämallien
tarkastusten määrä määritellään usein jo suunnittelusopimusneuvotteluissa, minkä lisäksi ne määritellään jo osaksi hankkeen suunnitteluaikataulua. Alussa Järvenpään Viljassa
oli tarkoitus tehdä neljä tarkastusta, mutta määrä nostettiin kuuteen, mikä osapuolten
mukaan vaikutti sopivalta määrältä asuntotuotantoon. Osapuolet kokivat että tarkastusten ajankohdat olisi tarkoituksenmukaista sopia pisteisiin, joissa yhteensovittamista tarvitaan eniten. Viimeinen yhteensovitus Järvenpään Viljassa olisi ollut osapuolten mukaan järkevämpää olla lähempänä tuotannon aloittamista.
Mallien julkaisusyklin sopiminen tiedonvaihtotarpeita palvelevalle tasolle
Haastateltujen suunnittelijoiden mukaan Järvenpään Viljassa tietomallien julkaisusykli
aina suunnittelukokousten yhteydessä oli osapuolille sopiva. Kuitenkin haastatteluiden
mukaan myöhemmissä kohteissa käyttöönotetut tietomallipohjaiset reikä- ja elementtisuunnittelun menettelyt asettavat vaatimuksia tiheämmälle tietomallien julkaisulle, mikä
tulee yhdessä sopia tarkoituksenmukaiseksi.
Tietomallien tietosisällön valvonta suhteessa suunnitteluaikatauluun
Osapuolten mukaan Järvenpään Viljassa vaihdettiin tietoa vielä pääsääntöisesti 2Dpiirrustusten avulla. Lisäksi suunnittelun etenemistä valvottiin asuntotuotannon suunnitteluun liittyvien piirustusten kautta, mikä oli perusteltua, sillä hanke oli osapuolille ensimmäisiä tietomallinnettuja kohteita.
Haastatteluissa koettiin, että tietomallien valmiusaste tulisi saada jatkossa vahvemmin
osaksi suunnittelun ajallista hallintaa. Seuraavat erityiskysymykset ja kehitysehdotukset
nousivat esille haastatteluissa:
-
Muutosten koettiin hankaloittavan suunnittelua tietomallipohjaisesti ja muiden
suunnittelualojen mallien valmiusasteet jäivät joissain määrin osapuolille epä-
93
selviksi. Osapuolet kokivat, että esimerkiksi aikataulutettu, suunnittelijoilla kiertävä lähtötietotarveluettelo, johon suunnitelmat lukittaisiin osa-alueittain, voisi
olla hyvä käytäntö. Suunnittelun valmiusastetta peilattaisiin yhteisissä palavereissa entistä enemmän suhteessa näihin tietomallipohjaisiin lähtötietotarpeisiin
ja poikkeamista lukitsemispäivämääriin tulisi tiedottaa osapuolille selkeästi.
-
Joissain määrin koettiin, että suunnittelun aikana tietomallien valmiusasteet olivat riittämättömät suhteessa projektin virstanpylväiden piirustustarpeisiin. Koska
suunnitteluaikataulu määritellään melko tarkasti heti alussa, koettiin että myös
tietomallien vaiheittain vaaditut tietosisällöt voitaisiin kirjata vahvemmin osaksi
suunnitteluaikataulua. Tietosisältötaulukot tulisi suunnitella siten, että niissä esitetyt mallien tietosisällöt vaiheittain olisivat riittävät suhteessa projektin virstanpylväisiin ja ne voitaisiin merkitä suunnitteluaikatauluun suunnittelualoittain
esimerkiksi pystyviivoina (esim. RAK YS, TATE TS).
Erityissuunnittelun aloitus suhteessa arkkitehtisuunnitteluun
Osapuolet olivat yhtä mieltä siitä, että tietomallinnetuissa hankkeissa ei ehdotus/luonnossuunnittelua voida viedä yhtä pitkälle arkkitehtivetoisesti kuin perinteisissä
hankkeissa, vaan erityissuunnittelun tuloa on syytä aikaistaa. Osapuolilla oli kuitenkin
erilaisia näkemyksiä siitä, kuinka pitkälle erityissuunnittelun tulisi olla alkuvaiheessa
arkkitehdin suunnittelua tukevaa 2D-suunnittelua, ja milloin erityissuunnittelijat aloittavat suunnittelun mallintamalla.
Uusien menettelyiden vaatimukset suunnitteluajalle
Osapuolet kokivat, että tulevissa hankkeissa käytettävä tietomallipohjainen reikä- ja
elementtisuunnittelu vaatii lisääntyvän ajantarpeen huomioimista suunnitteluaikatauluissa. Elementtisuunnittelu usein limittyy asuntotuotannossa rakentamisen alkuvaiheen
kanssa, joten suunnitteluun varattu kokonaisaika tulisi olla mahdollisesti pidempi.
3.4.1.2 Toimitilakohteet
Tutkimuksen kahdessa case-toimitilakohteessa oli erilaiset lähtökohdat suunnitteluun
varatulle ajalle. Kastellin monitoimitalossa suunnittelun aloitus viivästyi, mikä loi aikataulupaineen projektiin ja suunnittelua jouduttiin viemään eteenpäin eri lohkoilla sekä
94
tuotannon, hankintojen, että rakennuksen yleissuunnittelun ehdoilla. Tämä vaikeutti
myös suunnittelun aikataulusta. Pohjantien koulussa taas suunnittelu päästiin aloittamaan hyvissä ajoin ennen rakennustöiden alkamista, mutta häiriöitä aiheuttivat lähinnä
korjausrakentamisen yllätyksellisyys ja elinkaarihankkeille tyypillinen suunnitteluratkaisujen optimointi.
Case-kohteissa oli myös käytössä toisistaan poikkeavat kokouskäytännöt. Pohjantien
koulussa joka neljäs viikko järjestettiin suunnittelukokous ja samana päivänä tarkastettiin yleensä myös yhdistelmämalli. Joka toinen viikko taas pidettiin suunnittelun aikataulukokous (LastPlanner), jonka päätavoitteena oli suunnittelijoiden tiedonvaihto ja
aikataulutehtävien tarkentava sunnittelu. LastPlanner-kokousten idea aikataulun tarkentamisesta suunnittelijalähtöisesti koettiin hyväksi, mutta fyysinen läsnäolo häiritsi suunnittelijoita. Koska LastPlanner-kokousten ensisijainen tarkoitus on toimia suunnittelijoiden keskustelukanavana ja tietomalleja käytetään vain tiettyjen kohtien havainnollistamiseen, ehdotettiin mahdollisuutta järjestää LastPlanner-kokoukset jatkossa videoneuvotteluina.
Kastellin monitoimitalossa suunnittelukokouksia järjestettiin myös neljän viikon välein.
Suunnittelijoiden tiedonvaihtotarpeita palvelivat kahden viikon välein järjestetyt suunnittelijapalaverit, joista joka toinen pidettiin aina ennen suunnittelukokousta. Myös yhdistelmämallit tarkastettiin suunnittelijapalavereissa, ja kohteen laajuuden vuoksi palavereissa jouduttiin keskittymään aina yksittäisen lohkon tarkastukseen. Osapuolet pitivät kahden viikon kokousväliä tiheänä, mutta hankkeen laajuuden vuoksi perusteltuna.
Kohteen pääsuunnittelijan mukaan kokouksissa ei ollut koskaan tyhjäkäyntiä, mutta
erityisesti yhdistelmämallien tarkastus on aikaa vievää, joten tiedonvaihdon määrään
kokouksissa oli hankala vaikuttaa. Kohteen projektijohtaja pohti, olisiko pidempi kokousväli ollut tarkoituksenmukaisempi, sillä tällöin suunnittelua päästäisiin viemään pidemmälle ja kokouksessa sovitut toimenpiteet ehdittäisiin suorittaa kokousvälillä varmemmin.
Suunnittelijoiden näkemyksiin kokouskäytännöistä vaikutti mitä luultavimmin se, että
molemmissa case-kohteissa suunnittelijat olivat eri puolilta Suomea. Siltikään videokokousten ei kaikilta osin koettu vastaavan fyysistä läsnäoloa.
95
LastPlanner-kokoukset oli tarkoituksena ottaa käyttöön myös Kastellissa, mutta ne eivät
vakiintuneet alkua pidemmälle. Syynä tähän voi olla se, että kohteen laajuuden vuoksi
suunnitteluasioihin jouduttiin enemmän tai vähemmän keskittymään lohko kerrallaan,
jolloin LastPlanner-kokousten sovittaminen kokouskäytäntöihin kahden viikon syklillä
olisi voinut olla haastavaa. Lisäksi kohteen pääsuunnittelija ei päässyt osallistumaan
suunnittelun alkuvaiheessa pidettyyn LastPlanner-koulutukseen, mitä voidaan pitää
myös yhtenä syynä. Sekä haastatteluissa että aiheesta tehdyissä tutkimuksissa1 korostettiin pääsuunnittelijan aktiivisuutta kokouksissa.
Mitä luultavimmin LastPlanner tukisi parhaiten suunnittelunohjausta lohkoittain etenevässä suunnittelussa niin, että suunnittelun aikataulukokouksia pidettäisiin esimerkiksi
4-6 viikon välein ja niissä sovittaisiin tavoitteet kaikille suunnittelulohkoille. Suunnittelijapalavereiden tarve taas voitaisiin sopia joustavammin ja niissä pystyttäisiin keskittymään suunnitteluasioihin tai yhdistelmämallin tarkastuksiin lohkoittain, sillä niiden
painopisteet ovat erilaiset hankkeiden eri vaiheissa. Osana suunnittelijapalaveria kirjattaisiin aikataulupohjaan myös päivitykset LP-tehtäviin ja niiden toteutumisen valvonta
käsittelyssä olevan lohkon osalta. Uudet tavoitteet seuraavalle 4-6 viikolle sovittaisiin
aina tulevassa suunnittelun aikataulukokouksessa, joka voitaisiin videoneuvotteluna
limittää osaksi valittua kokouskäytäntöä ja osaltaan tukisi suunnittelijoiden tiedonvaihtoa.
Pohjantien koulun suunnitteluaikataulun nimikkeet saatiin pilkottua melko tarkoiksi
”Tiedonvaihto suunnittelijoiden kesken” -otsikon alle johtuen siitä, että suunnittelijalähtöisiä tiedonvaihtotarpeita voitiin viedä LastPlanner-kokouksista suunnitteluaikatauluun. Tavallaan suunnittelutehtävien aikataulutusta voitaisiin tarkentaa kahdella tasolla:
Suunnittelijapalavereiden tiedot vietäisiin aina LastPlanner-aikataulupohjaan tarvittaessa lohkoittain ja LastPlanner-aikataulupohjan tiedot suunnitteluaikatauluun.
1
esim. Mäki, T. et al. 2013.
96
Kuva 24. Suunnittelun kokouskäytännöt osana suunnitteluaikataulun tarkentamista.
Mukailtu lähteestä: Patel, A. 2011. s. 9
Siitä, oliko LastPlanner-kokouksilla yhteyttä esimerkiksi alakattosuunnittelun sujumiseen ja lähtötietojen aikaiseen lukitsemiseen Pohjantien koulussa, ei voida tehdä tutkimuksessa johtopäätöksiä. LastPlanner-kokoukset otettiin käyttöön vasta Pohjantien koulussa, mutta kohteen projektipäällikön mukaan myös suunnitteluryhmän yhteistoiminta
on kehittynyt kohde kohteelta opitun kautta, minkä merkitystä korostettiin useammassa
haastattelussa. Lähtökohtaisesti osapuolet pitivät kuitenkin sen ideaa suunnittelijalähtöisestä aikataulun tarkentamisesta hankkeen erityispiirteitä tukevaksi.
3.4.2 Tietomallien koordinoimisen tehtävien jakaminen osapuolten tarpeiden mukaan
Haastatteluissa korostuivat erityisesti hankeosapuolten erilaiset tarpeet tietomallikoordinaattoriksi mielletyn henkilön tehtäville.
Suunnittelijat näkivät tietomallikoordinaattorin pääasialliseksi tehtäväksi suunnitelmien
yhteensovitukseen liittyvien ristiriitojen ja ongelmien esilletuomisen, ja näkivät että
tietomallikoordinaattorin tehtävät liittyvät olennaisesti hankkeen pääsuunnitteluun.
Hankkeen laajuudesta riippuen myös pääsuunnittelija voi hoitaa tietomallikoordinaatto-
97
rin tehtäviä, mutta osapuolesta riippumatta tehtäviä ei heidän mukaansa saisi eriyttää
kovin kauas pääsuunnittelijasta.
Lemminkäisen tuotannon ja projektinjohdon edustajat kokivat lisäksi välttämättömäksi
että Lemminkäisen organisaatiossa on tietomallintamisosaamista alkuvaiheen tavoitteiden määrittämisen ja hankkeen johtamisen tueksi projekteissa. Heidän mukaansa, huolimatta yhteydestä pääsuunnittelijaan, tietomallikoordinaattorin tehtäväkenttä tulisi olla
määriteltävissä ja ohjattavissa myös projektiorganisaation tarpeet huomioiden. Tietomallien tarkastusprosessi koettiin melko suunnittelijakeskeiseksi. Jos tietomallien laatua
ei valvota mallien yleisen rakenteen, kuten käytettyjen työkalujen, mallien lohkotuksen
ja objektien tyyppien osalta, ongelmat ilmenevät usein hyödynnettäessä malleja esimerkiksi tuotannon aikataulutuksessa tai määrälaskennassa.
YTV2012 osan 11 liitteessä 2 on esitetty malli tietomallikoordinaattorin tehtävätaulukosta, jossa tietomallinnusprojektiin sisältyvät tietomallinnukseen liittyvät tehtävät valitaan ”rasti ruutuun” periaatteella. Lista on sekoitus tietomallintamisen tavoitteiden määrittämisen, hankkeen johtamiseen, pääsuunnittelun sekä teknisen tarkastuksen tehtäviä.
Tehtävät eivät kuitenkaan ole toisiaan poissulkevia, vaan edellyttävät niiden erilaisten
osaamisvaatimusten vuoksi usein organisointia eri henkilöille. Etenkin Lemminkäinen
Talo Oy:n toimiessa suunnittelun tilaajana, tavoitteiden määrittelyyn sekä hankkeen
johtamiseen liittyy olennaisena osana intressit tietomallien hyödyntämiselle osana kohdeyrityksen prosesseja. Varsinkin projekteihin palveluna tilattavalle tietomallikoordinaattorille näiden tehtävien hoitaminen voi olla mahdotonta, ellei henkilö ole toiminut
tietomallikoordinaattorina kohdeyrityksen hankkeessa aikaisemmin. Tähän mennessä
tehtävä on hoidettu itse tai palvelu on tilattu hankekohtaisesti.
Lemminkäisen tietomalliasiantuntija Artur Virit on toiminut Kuopion elinkaarihankkeiden tietomallikoordinaattorina, jolloin tietomallikoordinaattorin tehtävänkuva on voinut
olla tavanomaista hanketta laajempi. Lemminkäisen tietomalliasiantuntijat kuitenkin
toimivat useissa projekteissa hankejohdon ja tuotannon tukena. Etenkin tietomallinnettujen hankkeiden määrän lisääntyessä tulevaisuudessa kaikkien tehtävien hoitaminen on
mahdotonta, sillä yhdistelmämallien tarkastus ja raportointi osana hankkeen kokouskäytäntöjä on paljon aikaa vievää. Näiltä osin tietomallikoordinaattorin tehtävät ovat myös
98
helpoiten eriytettävissä ja siten tilattavissa palveluna, tai osana pääsuunnittelijan tehtäviä.
Koska tietomallien koordinointi on enemmän hankkeen organisointiin kuin yksittäisen
henkilön kompetenssiin liittyvä tehtäväkenttä, pyrittiin tässä tutkimuksessa helpottamaan tehtävien jakoa muodostamalla tietomallisuunnittelun koordinoimisen tehtävätaulukko. Taulukon ydinajatuksena on jakaa tehtävät eri osa-alueisiin, joiksi valittiin haastatteluiden ja kirjallisuustutkimuksen perusteella:

Hankkeen johtamisen tehtävät

Tietomalliasiantuntijat (tietomallintamisen tuki)

Pääsuunnittelijan tehtävät, sekä

Mallien yhdistäminen ja koordinointi (tietomallikoordinaattori)
Tehtävien muodostamisessa on hyödynnetty haastatteluiden tuloksia, aihepiirin kirjallisuutta sekä kohdeyrityksen sisäisiä dokumentteja. Tehtävät ovat myös osin yhteneviä
YTV 2012:n kanssa, mutta niitä on muokattu tukemaan paremmin kohdeyrityksen prosesseja.
Taulukosta saadun palautteen perusteella tehtävien organisointiin liitettiin sarakkeet
hyväksyy, vastaa, avustaa, sekä osallistuu, jolloin tehtävien suorittamiseen voidaan liittää myös muita niihin olennaisesti liittyviä osapuolia. Esimerkiksi suunnittelualakohtaisten tietosisältötaulukkojen laadinnassa on hyvä olla mukana kustannusinsinööri ja
elinkaarihankkeissa Lemminkäinen Talotekniikka Oy:n edustajat tuomassa vaatimuksia
esille omalta osaltaan. Taulukko toimii myös osapuolille tehtävien suorittamisen muistilistana.
Kehitetyssä tietomallisuunnittelun koordinoimisen tehtävätaulukossa on huomioitu
myös muut tämän tutkimuksen tulokset, kuten mallien uusi julkaisuprosessi. Taulukko
edellyttää aina projektikohtaista muokkaamista ja osapuolille voidaan sisällyttää myös
muita hankesidonnaisia tehtäviä. Listassa on huomioitu myös uusien tehtäväluetteloiden
(TELU2012) mukaisia tehtäviä eri osapuolille. Vaikka suunnittelun tilaamisessa käytetään nykyisin vielä pääosin vanhoja tehtäväluetteloita, ovat TELU2012 tehtävät olennaisilta osiltaan yhteneviä vanhojen tehtäväluetteloiden kanssa, kuitenkin huomioiden
tietomallinnetun suunnitteluprosessin erityispiirteet.
99
Kehitetty tietomallien koordinoimisen tehtäväluettelo on esitetty liitteessä 1.
3.4.3 Mallien julkaisuprosessin kehittäminen
3.4.3.1 Havaitut ongelmat nykyisessä julkaisuprosessissa
Kuvassa 25. on esitetty haastatteluissa ilmenneet ongelmat liittyen luvussa 2.2.3.1 kuvattuun, case-kohteissa käytössä olleeseen tietomallien julkaisuprosessiin. Alkuperäinen
julkaisuprosessi on esitetty Harri Niemen ja Ville Niskakankaan diplomitöissä ja se perustuu Senaatti Kiinteistöjen ohjeistukseen, mutta sitä on kevennetty tilaajan suunnitelmien hyväksyttämisen osalta.1
Kuva 25. Ongelmat nykyisessä tietomallien julkaisuprosessissa. Mukailtu lähteestä:
Niemi, H. 2011. s. 84
Kirjallisuusselvityksessä todettiin, että suunnittelijat ovat aina vastuussa myös tietomallitoimitustensa laadusta. Suunnittelijoiden laadunvarmistusmenettelyt ovat perustuneet
suunnittelutoimistojen laatujärjestelmiin tai suunnittelutarjouksessa esitettyyn selvitykseen, ja niille on esitetty vaatimuksia myös projektin tietomalliohjeessa. Käytännössä
suunnittelijoiden omat tietomallien tarkastusmenettelyt olivat case-projekteissa vaihte-
1
Niemi, H. 2011. s. 84
100
levia, yleisesti tarkastuksessa luotettiin enemmän visuaaliseen tarkastukseen tai vaihtoehtoisesti ohjelmistojen sisäisiin työkaluihin. Suunnittelijoiden laadunvarmistusta ei
myöskään erityisesti valvota projekteissa, koska sen suoritukseen yleisesti luotetaan ja
tietomallikoordinaattorin tarkastussäännöstöihin perustuva laadunvarmistus kohdentuu
enimmäkseen eri suunnittelualojen osamallien keskinäisiin ristiriitoihin. Suunnittelualojen sisäiset ongelmat ovat ilmenneet vain tietomallikoordinaattorin visuaalisessa tarkastuksessa, tai pahimmassa tapauksessa hyödynnettäessä tietomalleja tuotannon tai laskennan tarpeisiin.
Myöskään tietomallijulkaisuiden yhteydessä julkaistava tarkastusraportit, jollaiset on
esitetty YTV2012 osassa 6, eivät ole vakiintuneet käyttöön projekteissa. Syynä tähän
lienee se, että mallien julkaisuprosessi on nykyiselläänkin melko raskas ja haastatteluiden mukaan tiiviillä kokousvälillä työpanos kohdentuu kokouksessa sovittujen toimenpiteiden suorittamiseen. Eräs haastatelluista suunnittelijoista koki että osamallien tarkastuksessa painopiste tulisi keskittyä tarkastuspisteisiin, joissa tietomallit luovutetaan
muille suunnitteluosapuolille suunnittelun lähtötiedoiksi, erityisesti erityissuunnittelun
loppuvaiheessa. Mikäli vaatimukset tietomallien tarkastukselle käyvät suunnittelijoille
liian raskaiksi, riskinä on että ne sivuutetaan kokonaan. Case-projekteissa työmallikäsitettä suunnittelussa käyttivät lähinnä arkkitehdit, jotka toisinaan joutuivat lähettämään tietomallinsa kokousväliä tiheämmin muille osapuolille suunnittelun tueksi.
Haastatteluissa ilmeni myös, että osalla suunnittelijoista muiden suunnittelualojen mallien hyödyntäminen omien suunnitelmien yhteensopivuuden varmistamiseen laadunvarmistusohjelmistoilla (kuten Solibri Model Checker) on ollut vaihtelevaa. Osa haastatelluista suunnittelijoista vertasi suunnitelmiaan muiden tietomalleihin jatkuvasti suunnittelutyön ohessa, mutta osa on luottanut vertailussa enimmäkseen tietomallikoordinaattorin tarkastukseen ja siinä esille tuotujen virheiden korjaamiseen ja suunnittelutietoa on vaihdettu pääosin 2D-piirrustusten avulla. Tietomallikoordinaattorin tarkastus
on käyty läpi case-projekteissa pääsuunnittelijan johdolla suunnittelijapalavereissa ja
kommentteja on kerätty suunnittelijoilta myös sähköpostin välityksellä tarkastuslomakkeelle. Menettely ei ole edesauttanut muiden mallien hyödyntämistä ja haastatteluissa
yksittäiseksi syyksi nousikin uuden opettelu, sillä case-kohteet olivat osalle suunnittelijoista ensimmäisiä laajempia tietomallinnettuja hankkeita. Oletuksena on, että kun
suunnittelijat kommentoivat suunnitelmaristiriitoja suoraan yhdistelmämallia hyödyntä-
101
en ennen kokousta, he pystyvät jatkossa tehokkaammin havainnoimaan ristiriitoja myös
itse, aina mallijulkaisujen yhteydessä.
Suurin ongelma nykyiseen yhdistelmämallin tarkastusmenettelyyn liittyen, mikä ilmeni
sekä haastatteluissa että Pohjantien koulun suunnittelun palautekeskustelussa on, että
raportoituja virheitä tietomallikoordinaattorin tarkastuksessa on paljon ja niiden käsittelyyn kuluu huomattavan paljon aikaa. Pohjantien koulun suunnittelun palautekeskustelussa kritisoitiin myös että palavereissa käytetään yhteistä aikaa virheiden käsittelyyn,
jotka koskevat vain tiettyjä suunnittelualoja ja olisivat siten myös käsiteltävissä vastuuhenkilöiden kesken palavereiden ulkopuolella. Haastatteluiden mukaan suunnittelijat ja
projektihenkilöstö kokivat kuitenkin, että yhdistelmämallin tarkastuksen läpikäynti ja
mahdolliset suunnittelukokousasiat on luontevampaa käsitellä samana päivänä, sillä
etenkin suunnittelijat kokivat kokousten ja palavereiden vievän aikaa käytännön suunnittelutyöltä etenkin laajoissa hankkeissa, joissa kokousväli on usein pieni. Tällöin kokouspäivät ovat venyneet kestoltaan melko pitkiksi.
Etenkin Pohjantien koulussa, joka oli peruskorjaushanke, koettiin että myös asennettavuuden näkökulma urakoitsijoiden puolelta tulisi saada vahvemmin esille myös yhdistelmämallin tarkastuksessa. Tämä ennaltaehkäisisi ongelmia työmaalla, mutta toisaalta
vähentäisi myös suunnittelijoiden muutostarpeita: Ongelmakohdat monesti ovat asennettavissa näennäisistä ristiriidoista huolimatta ja toisaalta pitkälle vietyjen suunnitelmamuutosten toteuttaminen etenkin TATE-suunnitteluohjelmistoissa on raskasta.
102
3.4.3.2 Suositeltava julkaisu- ja tarkastusprosessi projekteihin
Kuva 26. Suositeltava julkaisu- ja tarkastusprosessi projekteihin. Mukailtu lähteestä:
Niemi, H. 2011. s. 84
1. Suunnittelijat tarkastavat omat osamallinsa visuaalisesti ja ohjelmistojen tarkastustyökaluja käyttäen, korjaavat suunnitteluvirheensä sekä tallentavat mallin
projektipankkiin sekä natiivi- että IFC-muodossa. Samalla suunnittelija täyttää
julkaistavasta mallista tietomalliselostuksen, josta käy ilmi mm. mallin statustieto ja mahdolliset tietomalliohjeesta poikkeavat mallinnustavat. Suunnittelijat
dokumentoivat tietomalleille suoritetut tarkastukset tietomalliselostukseen, ja
painopiste niissä on sovituissa tarkastuspisteissä.
2. Tietomallikoordinaattori tarkastaa, että suunnittelualojen osamallit noudattavat
sovittua mallinnustapaa ja että ne voidaan yhdistää, sekä niihin liittyvät dokumentit on julkaistu. Samalla tietomallikoordinaattori tarkastaa, että tietomallien
tietosisällöt vastaavat ko. suunnitteluvaiheessa sovittua tietosisältöä.
3. Tietomallikoordinaattori tekee kootulle yhdistelmämallille visuaalisen ja ohjelmallisen tarkastuksen säännöstöjä käyttäen, kokoaa raportin olennaisimmasta
törmäyksistä, ristiriidoista ja ongelmista ja luokittele ne esitykseen uusiksi,
avoimiksi, vaikutuksettomiksi tai korjatuiksi. Tietomallikoordinaattori toimittaa
alustavan yhdistelmämallin suunnittelijoille.
103
4. Suunnittelijat käyvät yhdistelmämallin esityksen läpi, lisäävät kommenttinsa
oman suunnittelualansa virheisiin ja toimittavat kommentit tietomallikoordinaattorille BCFzip-muodossa. Tarvittaessa kommentit kerätään myös urakoitsijoilta
liittyen suunnitelmien rakennettavuuteen ja talotekniikan asennettavuuteen.
5. Tietomallikoordinaattori päivittää osapuolten kommentit ja julkaisee yhdistelmämallin ja yhdistelmämallin tarkastusraportin projektipankkiin. Suunnittelualojen väliset ristiriidat ratkaistaan pääsuunnittelijan johtamassa yhdistelmämalli- tai suunnittelijapalaverissa, jossa kirjatut kommentit päivitetään yhdistelmämalliin. Myös tietomallikoordinaattori osallistuu palaveriin.
6. Suunnittelijat korjaavat oman suunnittelualansa virheet ja tekevät oman suunnittelualansa osalta yhdistelmämallipalaverissa sovitut muutokset.
7. Yhdistelmämallipalavereita järjestetään riittävin väliajoin. Yhdistelmämalli käydään läpi ja keskitytään virheraportissa ratkaisematta jääneisiin ongelmiin ja
valvotaan että sovitut korjaustoimenpiteet tulevat tehdyksi.
Epämuodollisiin, workshop-tyyppisiin yhdistelmämallipalavereihin yhdistelmämallin
tuottamiseen voidaan käyttää työmalleja (luku 2.2.3.1), joihin voidaan soveltaa tarvittaessa kevyempää suunnittelijoiden tarkastusmenettelyä. Suunnittelijoilta edellytetään
tietomalliensa tarkastusta projektin tietomalliohjeessa esitetyssä laajuudessa vähintään
seuraavissa tapauksissa:
-
Tietomalli luovutetaan TATE-analyysien tuottamiseen
-
Tietomalli luovutetaan määrä- tai kustannuslaskennan tarpeisiin
-
Tietomalli luovutetaan hankinnan tai tuoteosavalmistuksen (kuten elementit)
tarpeisiin
-
Tietomalli luovutetaan toisen osapuolen suunnittelun lähtötiedoksi ensimmäistä
kertaa
-
Tietomalli luovutetaan tuotantoa ja sen aikataulutusta varten
-
Suunnitteluaikatauluun merkityissä tai suunnittelukokouksessa sovituissa tarkastuspisteissä
104
Suunnittelualakohtaisten tarkastusraporttien sisällön mukaiset säännöstöt ovat olleet
valmiina Solibri Model Checkerissä versiosta 7.1 eteenpäin. Riippumatta siitä, onko
kyseessä virallinen julkaisu vai työmalli, tietomallijulkaisun yhteydessä päivitetään ja
julkaistaan tietomallin tietomalliselostus. Edellisen tarkastuksen päivämäärä kirjataan
tietomalliselostuksen kohtaan Mallille suoritetut tarkastukset (Projektin tietomalliohje).
Suunnittelijat korjaavat oman suunnittelualansa virheet sovittujen toimenpiteiden mukaisesti viimeistään seuraavaan yhdistelmämallipalaveriin mennessä.
Tavoitteet uudelle julkaisuprosessille:
BCFzip-kommentointi
-
Tehostetaan palavereiden ajankäyttöä. Ristiriidoissa pystytään keskittymään
useampaa suunnittelualaa koskeviin virheisiin ja virheisiin, joihin ei löydetä
kommenttikierroksella ratkaisua.
-
Kaikkien osapuolten kommenttien kirjaaminen edesauttaa osapuolten välistä yhteistyötä kokousten ulkopuolella. Korjaustoimenpiteitä voidaan sopia osapuolten
kesken ennen kokousta ja kokouksessa valvotaan toimenpiteiden toteutumista.
-
Mahdollistaa kommenttien keräämisen laajemmin muiltakin kuin palavereihin
osallistujilta.
-
Kommentointi yhdistelmämallin sisällä helpottaa tarkastuksissa ilmenneitten
virheiden paikallistamista, verrattuna excel- tai pdf-tiedostoihin.
-
Kommentointi yhdistelmämallin sisällä kannustaa osapuolia hyödyntämään yhdistelmämallia myös palaverien ulkopuolella.
Virheiden luokittelu
-
Luokittelun avulla:
o Korjatut virheet eivät häiritse tarkastuksen läpikäyntiä, mutta niihin pystytään tarvittaessa palaamaan.
o Virheet, joilla ei ole välittömiä vaikutuksia rakennettavuuteen tai asennettavuuteen voidaan luokitella vaikutuksettomiksi ja niihin voidaan palata tarpeen vaatiessa myöhemmin.
o Tarkasteluvälillä avoimeksi jääneitä virheitä pystytään helpommin valvomaan ja
105
o tietomallien päivityksen myötä ilmenneisiin uusiin virheisiin pystytään
kiinnittämään huomio.
Tutkimuksessa luodut ohjeet yhdistelmämallin tarkastus- ja julkaisumenettelyille Solibri
Model Checkerillä on esitetty liitteessä 2.
3.4.4 Muutosten tiedottaminen ja visualisointi
Osapuolet kokivat haastatteluissa ongelmaksi muutosten tiedottamisen vaikeuden.
Suunnittelijat kokivat projektiluontoisessa suunnittelutyössä haasteelliseksi tunnistaa
heidän omiin suunnittelualoihinsa vaikuttavat muutokset muiden tietomalleista, etenkin
kun projektipankkeihin tulee ilmoituksia useammasta projektista. Muutokset edelliseen
revisioon on usein kirjattu tietomalliselostukseen erillisenä listauksena. Kattavia muutoslistauksia on haastatteluiden mukaan mahdollista tehdä ja niiden huolellinen tekeminen edesauttaa mallien tulkitsemista. Käytännössä niiden laatiminen on puhtaasti käsityötä ja kokemusten perusteella niiden laatu on vaihdellut henkilösidonnaisesti. Ongelmaksi muutoslistauksissa koettiin erityisesti niihin kirjattujen muutosten paikallistaminen tietomalleista, sekä inhimillinen riski että olennaisia asioita jää kirjaamatta.
Etenkin yleissuunnitteluvaiheessa ja toteutussuunnittelun alussa arkkitehdin mallia käytetään erikoissuunnittelun pohjana. Tällöin myös suunnitteluratkaisujen yhteensovittamisesta aiheutuu eniten muutospaineita suunnitelmiin, jolloin muutosten tiedottamisen
merkitys osapuolille korostuu. Tällöin osapuolilta on edellytetty kattavamman tietomalliselostuksen täyttämistä kohdeyrityksen projekteissa.1
Solibri Model Checkerissä on ollut jo pitkään säännöstö muutosten jäljittämiseen ja
suunnittelijaosapuolia on myös kehotettu hyödyntämään tietomallipohjaisia muutostenjäljitystyökaluja muiden suunnittelualojen muutosten selvittämiseen. Koska suunnittelijat kuitenkin kokevat haastatteluiden perusteella jo nykyisellään muutosten etsimisen
aikaa vieväksi, eikä kaikilla osapuolilla ollut käytössään SMC:tä, voidaan olettaa että
kovinkaan moni suunnitteluosapuoli ei hyödynnä muutostenjäljitystoimintoja. Myös
suunnitteluohjelmistoissa on sisäänrakennettuja muutostenjäljitystoimintoja, mutta TATE-ristiinvertailuita lukuun ottamatta ne helpottavat suunnittelijoita lähinnä tunnistamaan omien malliensa muutokset muutoslistausten tekemisen helpottamiseksi.
1
Lemminkäinen Talo Oy. Projektin tietomalliohje. Sisäinen dokumentti.
106
Muutosten tiedottamista projekteissa olisi mahdollista tehostaa hyödyntämällä muutostenjäljitystyökaluja mallijulkaisuiden yhteydessä, tallentamalla valmiiksi ajettu mallirevisioiden vertailu projektipankkiin Solibrin smc-tiedostomuodossa. Tällöin se olisi
kaikkien projektin osapuolten hyödynnettävissä riippumatta käytössä olevista ohjelmistolisensseistä ja osaamistasosta. Aikaa muutosvertailun tuottamiseen menee noin viisi
minuuttia, joten se olisi mahdollista sisällyttää myös tietomallikoordinaattorin/pääsuunnittelijan tehtäviin julkaisuiden yhteydessä. Etenkin arkkitehtimallin objektien sijaintimuutokset, jotka vaikuttavat eniten muihin suunnittelualoihin, ovat Solibrin
revisiovertailulla nopeasti havaittavissa vanhan ja uuden mallijulkaisun värikoodien
avulla.
Suurin hyöty arkkitehtimallin muutosten visualisoinneista lienee yleissuunnitteluvaiheessa ja toteutussuunnitteluvaiheen alussa, jossa erityissuunnitelmia mallinnetaan arkkitehtimallin pohjalta. Myös muiden suunnittelualojen tietomalleista on mahdollista
tehdä muutosvisualisointeja, mutta niillä saavutettu hyöty tulee arvioida tapauskohtaisesti. Esimerkiksi rakennesuunnittelijan mallien muutosvisualisoinnista voisi olla hyötyä peruskorjaushankkeissa, joissa rakennesuunnittelija mallintaa rakennuksen olemassa
olevan rungon.
Toinen aspekti, mikä liittyy muutoksiin, on suunnitelmien valmiusasteen viestiminen.
Haastatteluissa korostui erityisesti muiden tietomallien suunnittelutiedon valmiusasteen
tulkitsemisen vaikeus, johon tietomalliselostus on toistaiseksi ollut ainoa käytäntö.
Lemminkäisen tietomalliasiantuntijat ovat tutkineet mahdollisuutta liittää valmiusastetta
kuvaava sarake arkkitehdin tietomalliselostuksen pitkään muotoon, jossa suunnittelun
alkuvaiheessa suunnittelija kuvaa rakennusosittain käyttämänsä mallinnustyökalut, kuvatasot ja nimeämiskäytännöt. Taulukon käyttöönottoa tulisi testata projekteissa ja sen
käytössä tulisi ensisijaisesti painottaa suunnittelijan arviota siitä, onko rakennusosien
geometriaan tai sijaintiin mahdollisesti tulossa muutoksia.
Haastatteluissa suunnittelun valmiusasteen viestimiseen liittyi myös ongelma siitä, miten tieto valmiusasteesta saadaan suunnittelualoittain työmaalle, kun suunnittelu limittyy päällekkäin rakentamisvaiheen kanssa. Vaihtoehtoja tähän tulisi tutkia erikseen, sillä
suunnittelun valmiusasteen tulisi olla määritelty myös sijaintikohtaisesti. Luultavasti
107
tietomallipohjainen esitysmuoto värikoodein voisi olla ongelmaan liittyen taulukkomuotoista kattavampi.
Tutkimuksessa luodut ohjeet arkkitehtimallin revisiovertailun suorittamiselle on esitetty
liitteessä 4.
3.4.5 Yhteistoimintaa vaativien suunnittelutehtävien ohjeistukset
Kirjallisuusselvityksessä todettiin, että tavoitteet tietomallintamiselle tulisi olla pääosin
määritelty jo suunnittelusopimusneuvotteluissa, muussa tapauksessa muilla hanketekijöillä voi olla vaikutus siihen, minkä tasoisia tietomalleja rakennusprosessin aikana on
mahdollista luoda ja miten tehokkaasti niitä voidaan hyödyntää. Vaatimukset tietomallien tietosisällöille on pystytty määrittelemään melko tarkasti jo YTV2012:ssa. Niitä on
muokattu tarpeisiin sopiviksi onnistuneesti myös kohdeyrityksessä, erityisesti mallien
hyödyntämisen kautta. Koska suunnitelmien kasvanut tarkkuustaso ja vaatimukset tiedon oikeellisuudelle ovat siirtäneet painopisteen urakoitsijoiden asennussuunnittelusta
suunnittelupöydälle, myös merkitys suunnittelutehtävien oikealle järjestykselle, ajoitukselle ja tiedonvaihdon menettelyille on kasvanut.
Projekteissa toimintatapojen muutoksesta on aiheutunut ongelmia erityisesti suunnittelijoiden tiivistä yhteistoimintaa vaativiin tehtäviin. Ongelmat on tiedostettu laajasti aihepiirin kirjallisuudessa ja tutkimuksissa, sekä käytännön kokemuksina projektihenkilöstön taholla, minkä vuoksi ne pystyttiin tunnistamaan mahdollisiksi kipupisteiksi myös
case-tutkimuksen haastattelukysymyksiin. YTV2012 on antanut ohjeita esimerkiksi
reikäsuunnittelun suoritukseen, menemättä kuitenkaan tarpeeksi tekniselle tasolle niin,
että menettelyt olisivat osapuolille aina täysin selvät. Virheettömämmän ja sujuvamman
suunnitteluprosessin varmistamiseksi myös vaatimukset tietomallintamisen tavoitteita
tukeville työmenetelmille tulisi saada mahdollisimman tarkasti sovittua, jotta osapuolet
tiedostaisivat niiden vaatiman työmäärän ja vaikutukset muihin suunnitteluosapuoliin.
Case-projekteissa esiintyi suunnitteluun vaikuttavia, uusien toimintatapojen aiheuttamia
ongelmia seuraavissa suunnittelutehtävissä:
-
Reikä ja varaussuunnittelu
o Pohjantien koulu: Ongelmat liittyen vanhojen rakenteiden varmentamiseen ja reikien merkkaamiseen
108
o Pohjantien koulu: Reikäpiirustusten uudet vastuukysymykset
o Järvenpään vilja: Reikätiedot suunniteltiin ensin 2D-kiertona, jonka
pohjalta ne vietiin kuitenkin tietomalleihin. Myöhemmin otettu käyttöön
tietomallipohjainen varaustietojen siirto, joka on työläämpää mutta johtaa laadukkaampaan lopputulokseen.
-
Alakattosuunnittelu
o Kastellin monitoimitalo: Alakattosuunnittelun pitkittyminen ja suunnittelun aikaiset muutokset
-
Arkkitehti- ja rakennemallien aukkojen kohdistaminen
-
Origon asettaminen
Syinä havaittuihin ongelmiin korostuivat tiedonvaihdon oikea-aikaisuus: lähtötietoja ei
saatu tarpeeksi ajoissa, niitä ei saatu lukittua tarpeeksi aikaisessa vaiheessa muutoksilta
tai tietomallien tietosisällöt eivät kohdanneet suunnitelmien tarpeen kanssa ajallisesti.
Yksi haastatelluista suunnittelijoista totesi, että tavoitteiden ja toimintamenettelyiden
sopiminen dokumentoidusti alkuvaiheessa vähentäisi suunnitteluryhmän jäsenten kokemustasosta johtuvaa vaihtelua tehtävien kulkuun.
Monet haastatelluista suunnittelijoista kritisoivat, että suunnittelutehtävien uudet menettelyt tietomallinnetuissa hankkeissa aiheuttavat heille perinteisiin menettelyihin verraten
merkittävästi lisätöitä, ilman että niitä huomioidaan suunnittelupalkkioissa. Lisäksi
haastatteluissa ilmeni, että niiden aiheuttaman työmäärän arviointi hankkeen alussa on
myös vaikeaa. Uudet menettelyt myös saattavat siirtää suunnitteluun käytettävää työmäärää osapuolelta toiselle.
Oletettavissa on, että tietomallinnettujen hankkeiden yleistyessä ja kokemusten karttuessa myös suunnittelutoimistot haluavat tietää tarkemmin jo suunnittelusopimusneuvotteluissa, miten yhteistoimintaa vaativat suunnittelutehtävät tullaan suorittamaan, pystyäkseen resursoimaan suunnittelun paremmin etukäteen. Työtapojen lisäksi myös uudet
vastuut suunnitelmiin liittyvien piirustusten tuottamisesta tulisi olla määritelty etukäteen
suunnittelusopimuksissa, hankkeen erityispiirteet huomioiden. Tämä tuli esille erityisesti Pohjantien koulun suunnittelun palautekeskustelussa, liittyen reikäpiirustusten tuottamiseen.
109
Tutkimuksen aikana suunnittelu- ja konsulttitoimistojen liitto SKOL ry aloitti talotekniikkaan liittyvien suunnittelutehtävien kehittämisen, tavoitteenaan luoda aikaisemmin
ongelmia aiheuttaneille, talotekniikkaan liittyville tehtäville prosessikuvaukset. Tavoitteena prosessikuvauksille Lean Construction -periaatteiden mukaisesti on varmistaa
prosesseihin liittyvien vaiheiden oikea-aikainen suorittaminen ja minimoida suunnitteluun liittyvä ylimääräinen työ.1 Hankkeesta on vastannut Granlund Oy:n tietomallipäällikkö Tero Järvinen ja hankkeen työryhmään on kuulunut eri suunnittelualoja edustavia
suunnittelutoimistoja. Prosessikuvaukset on laadittu seuraavista suunnittelutehtävistä:
-
Origon asettaminen,
-
alakattosuunnittelu,
-
talotekniikan reikävaraukset, sekä
-
rakennemallin valmiusastevaatimus taloteknisen mallinnuksen aloittamiselle.
Kommenttien keräämiseksi laajemmin osapuolilta, alustavat prosessikuvaukset julkaistiin marraskuussa 2013 ja ne ovat saatavilla SKOL Ry:n www-sivuilla osoitteessa
http://skolry.fi/talonrakennussektori. Prosessikuvaukset on myöhemmin tarkoituksena
julkaista osana BuildingSMART Finlandin IMD-kuvauksia, tai osana YTV2012 päivityksiä.2
Prosessikuvausten käyttöönotosta voisi olla hyötyä myös kohdeyrityksen hankkeissa.
Koska hankkeissa pyritään käyttämään melko usein samoja, hyviksi havaittuja suunnittelutoimistoja, niiden käyttöönottoa voitaisiin arvioida yhdessä suunnittelijoiden kanssa
esimerkiksi meneillään olevien case-hankkeiden suunnittelun palautekeskusteluissa.
Vaikka prosessikuvaukset on laadittu yhteensopiviksi YTV2012 ohjeistuksen kanssa,
mahdolliset ristiriidat muihin sopimusasiakirjoihin, esimerkiksi projektissa viitattuihin
tehtäväluetteloihin tulisi tutkia ennen niiden käyttöönottoa. Lisäksi hankkeen alkuvaiheessa tulisi arvioida, saavutetaanko prosessikuvausten mukaisilla tehtävillä lisäarvoa
suunnitelmille niin, että niiden käyttö on hankkeen erityispiirteet huomioiden kannattavaa: Esimerkiksi asuntotuotannossa alakattosuunnittelu harvemmin aiheuttaa ongelmia.
Vaikka prosessikuvaukset antavat ehdotuksia myös korjausrakentamisen menettelyille
reikäsuunnittelussa, niihin liittyviä ongelmia voi olla vaikeaa ennakoida etukäteen. Huo1
SKOL Ry, http://skolry.fi/talonrakennussektori. Viitattu: 14.12.2013.
SKOL Ry. 2013. Talotekniikan tietomallinnuksen prosessimuutos, hankkeen työpaja 01, muistio. Viitattu: 27.11.2013.
2
110
limatta viittauksista prosessikuvausten käyttöön suunnittelussa, tavoitteet ja vastuut
suunnittelutehtäville hankekohtaiset tekijät huomioiden tulisi sopia erikseen, mieluiten
jo erityissuunnittelun sopimusneuvotteluissa.
Suunnittelijoilla ja projektihenkilöstöllä oli käytännön kokemusta siitä, että parhaat
työmetodit suunnitteluryhmän sisällä kehittyvät, kun samat suunnittelijat jatkavat yhdessä hankkeesta toiseen. Näin kävi esimerkiksi Pohjantien koulussa, jossa etenkin alakattosuunnittelu meni osapuolten mukaan erityisen hyvin kokemukseen perustuen. Suurin hyöty prosessikuvauksista lieneekin hankkeissa, jossa projektiin valitulle suunnitteluryhmälle ei vielä ole vakiintunut yhteisiä käytäntöjä.
3.4.6 Mallien hyödyntämisen näkökulma laadunvarmistuksessa
Haastattelututkimuksessa nousi esille ongelma, että tietomallikoordinaattorin tarkastukset keskittyvät hyvin pitkälti eri suunnittelualojen ristiriitoihin, jolloin muut tietomallien
puutteet ovat jääneet tarkastuksissa vähemmälle huomiolle. Syitä mallien puutteisiin on
tutkittu määrälaskennasta sekä tuotannonohjauksesta laadituissa Lemminkäisen opinnäytetöissä1,2,3, joista tärkeimmät huomiot liittyvät suunnittelijoiden omaan laadunvarmistukseen sekä puutteelliseen suunnittelun ohjaukseen.
Haastatteluissa kohdeyrityksen mallinnusaineistoa luonnehdittiin kattavaksi. Suunnittelun alkuvaiheessa on pystytty määrittelemään mihin malleja tullaan hyödyntämään, niiden tietosisältövaatimukset on asetettu projektikohtaisesti hyödyntämisasteen mukaiseksi ja mallien yleistä rakennetta on ohjeistettu mallinnusohjeissa sekä YTV2012:ssa.
Kuitenkin ongelmaksi muodostuu suunnitteluvaiheessa se, että osapuolet eivät ymmärrä
täysin, mitä vaatimuksia hyödyntäminen määrälaskennassa ja tuotannossa asettaa malleille käytännössä. On havaittu1, että tällä hetkellä hankkeissa tietomalleja hyödyntävät
henkilöt itse tietävät niiden sisällön ohjauksesta eniten.
Suunnittelijoiden ohjaus mallien hyödyntämisen näkökulmasta on ollut kytköksissä
projekteihin sidottuihin henkilöresursseihin. Laajat toimitilakohteet ovat toistaiseksi
olleet tietomallinnettujen hankkeiden joukossa etuasemassa: Korkean tietomallien hyödyntämisasteen ja kohteiden kompleksisuuden vuoksi on varmistettu, että projekteissa
1
Uusitalo, H. 2013.
Ekman, R. 2013.
3
Halonen, A. 2013.
2
111
on käytössä jo alkuvaiheesta lähtien laskennan ja tuotannon henkilöstöä tuomassa esille
mallintamisen tavoitteita, joita on tarvittaessa tarkennettu useammilla palavereilla suunnittelijoiden kanssa. Ohjaus on kuitenkin painottunut projektien alkuvaiheisiin ja casetutkimuksessa löytyi viitteitä siitä, että alkuvaiheessa sovittuja periaatteita ei kaikilta
osin noudatettu, mikä hankaloitti mallien hyödyntämistä myöhemmissä vaiheissa.
Case-kohteena olleessa Järvenpään Viljassa hyödynnettiin eri suunnittelualojen tietomalleista eniten arkkitehtimallia. Vaikka Järvenpään Viljan arkkitehtimalli oli esimerkillisesti laadittu, käytännössä ongelmat asuntotuotannossa korostuvat, johtuen tietomallinnettujen hankkeiden ja tietomallien hyödyntämiseen erikoistuneen henkilöstön vähäisestä määrästä. Myös asuntokohteissa tietomallintamisen tavoitteita on räätälöity mallien projektikohtaisen hyödyntämisen mukaisesti, mutta usein tuotannon tai laskennan
henkilöstö ei ole osallistunut tähän.
Haastatteluissa tehtyjen havaintojen perusteella myös suunnittelijoilla on korkeat intressit siihen, että tietomallintamisen myötä heidän suunnitelmiaan pystytään hyödyntämään laajemmin erilaisiin tarpeisiin. Kuten eräs heistä asiaa luonnehti, osa tämän hetken ongelmista johtuu vaatimusten ymmärtämättömyyteen liittyvästä, ”suttuisesta mallintamisesta”. Vallitsevassa tilanteessa alkuvaiheen määrittelyiden lisäksi suunnittelijat
tarvitsevat palautetta tietomalleistaan, ennen kuin niiden korjaaminen käy liian työlääksi
suunnittelun edetessä. Hyödyntämisen näkökulman huomista suunnittelun aikana olennaisesti vaikeuttaa sen vaatimusten suhteellisuus, jota seuraavat esimerkit kuvaavat:

Rakennusosien nimeämisessä ja tyypeissä on tärkeintä niiden käytön johdonmukaisuus, vaikka niille ei olisi asetettu vaatimuksia.

Vaikka objekti-työkalu suunnitteluohjelmistossa mahdollistaisi rakennusosan
mallintamisen, siitä ei välttämättä saada määriä määrälaskennassa.

Rakennusosien hyödyntämisen kannalta olennaisten attribuuttien ja ominaisuuksien määrittely.

Tuotannon suunnittelua helpottaa tietomallien/rakennusosien lohkottaminen.
Nykyisissä tietomallihankkeissa laskennan henkilöstö on tietomallit saatuaan antanut
palautetta suunnittelijoille niiden puutteista, mutta kiireisemmissä hankkeissa myös jou-
112
tuneet itse korjaamaan puutteita suoraan natiivimalleihin.1,2 Myös rakennemalleja on
toisinaan muokattu projekteissa, jotta ne soveltuvat paremmin tuotannon suunnitteluun
ja aikataulutukseen. Natiivimallien muokkaamiseen liittyy silti ongelma, koska mallin
päivityksen yhteydessä muokattu tieto häviää.
Mallien laatua voisi olennaisesti parantaa projekteissa se, että alkuvaiheessa suunniteltaisiin hallitusti tietty suunnittelualakohtainen palautteenantopiste, joka tarvittaessa voitaisiin lisätä projektin suunnitteluaikatauluun. Tavoitteena ennalta määritetyillä palautteenantopisteillä olisi varmistaa että:

Projektin alkuvaiheeseen sidotusta henkilöstöstä riippumatta tietomallien hyödyntämisen näkökulma saataisiin osaksi projektien laadunvarmistustoimenpiteitä,

alkuvaiheessa sovittuja tietomallintamisen tavoitteita on noudatettu,

tietomallien puutteisiin reagoidaan ennen kuin malleja hyödynnetään ja niiden
korjaaminen käy liian työlääksi suunnittelun edetessä.
Palautteenannon suunnittelussa tulisi huomioida seuraavat asiat:
1. Palautteenantopisteiden ajankohta
-
Pisteiden ajankohta tarpeeksi pitkällä mallintamisen aloittamisesta siten, että
nähdään, onko alussa sovittuja periaatteita noudatettu.
-
Ajankohdan huomiointi siten, ettei puutteiden korjaaminen ole suunnittelijoille
ko. vaiheessa liian työlästä, eikä mahdollisista rakennusosien poistamiseen liittyvästä GUID-tietojen menettämisestä ole haittaa osapuolille.
-
Käytössä alustavat rakennusosamallit siten, että niiden pohjalta voidaan tehdä
päätelmiä mallien todellisesta laadusta. Tietomallien sisältämä suunnittelutieto
voi olla vielä alustavaa, kunhan käytetyt mallintamisen periaatteet käyvät niistä
ilmi.
2. Palautteenannon organisointi
-
Ensisijaisesti siten, että palautteen antaja on osapuoli joka tulee hyödyntämään
malleja projekteissa. Esimerkiksi:
o Arkkitehtimalli: kustannusinsinööri
1
2
Hannuksela, Riikka. Puhelinkeskustelu
113
o Rakennemalli: tuotantoinsinööri
o LVIS-mallit: TATE-urakoitsija
-
Mikäli henkilöitä ei ole organisoitu projektiin alkuvaiheessa, selvitetään onko
palaute mahdollista saada muilta tietomallintamiseen perehtyneiltä tuotannon ja
laskennan henkilöstön edustajilta.
-
Määritellään suunnittelijalle, mitä tarkastuksia malleille tulee suorittaa tarvittaessa ennen palautteen antoa, että palautteessa pystytään keskittymään relevantteihin puutteisiin.
-
Palautteen mukaisesta mallien puutteiden korjaamisesta vastaa suunnittelija, joka on vastuussa toimittamiensa tietomallien laadusta.
3. Palautteen antamiseen liittyvät dokumentit
-
Varmistetaan että suunnittelija on toimittanut tietomalleista julkaistut dokumentit, joiden avulla mallin rakennetta tutkitaan.
-
Edellytetään suunnittelijaa tarvittaessa dokumentoimaan rakennusosien mallintamisen periaatteita tarkemmin.
Suurin hyöty annetusta palautteesta saataisiin, jos mallien puutteista laadittaisiin muistio
tiedoksi projektin osapuolille ja asianomaiselle suunnittelijalle. Palautemuistiot voitaisiin myös toimittaa kohdeyrityksen tietomalliasiantuntijoille, jolloin tietomallintamisen
tukimateriaalia voitaisiin kehittää niissä esitettyjen huomioiden pohjalta tai koota havaintoja ”Huomioi nämä” -tyyppisiksi listoiksi esimerkiksi kohdeyrityksen BIMryhmäsivustolle.
Vielä toistaiseksi tietomallien määrätiedon siirtoon on käytetty Tocomanin iLink4työkalua, joka on asennettavissa Archicadiin, Revitiin sekä Tekla CM:ään. Määrätietoa
on siirretty iLinkillä tarpeiden mukaan Tocomanin TCM PRO -sovellukseen kustannuslaskentaa varten, tai Tocoman Tuotantoon ja Planneriin tuotannon aikataulutusta varten.
Koska iLink4:n korvaava Tocomanin Easy Bim käyttää määrätietojen tuottamiseen
IFC-malleja, korostuu vaatimus sille, että mallit ovat jo lähtökohtaisesti oikein rakennettuja.
Ehdotetut suunnittelualakohtaiset palautteenantopisteet on lisätty tutkimuksessa kehitettyyn tietomallisuunnittelun koordinoimisen tehtäväluetteloon, joka on esitetty liitteessä
1.
114
3.4.7 Solibrin tarkastussäännöstöt
Tutkimuksessa hyödynnettiin Solibri Model Checker/Viewerin versiota 8. Tutkija suoritti työn aikana myös itse Kastellin monitoimitalon lohkon 1 yhdistelmämallin tarkastuksen saadakseen kuvan tietomallikoordinaattorin tarkastuksesta. Vertaillessa casekohteiden tietomallikoordinaattoreiden käyttämiä tarkastussäännöstöjä, kaikki heistä
käyttivät tarkastuksessaan seuraavanlaista yhdistelmää, joka tuottaa melko kattavan
kuvan yhdistelmämallin ongelmakohdista:

Rakennemalli vs. arkkitehtimalli
o Aukkojen tarkastus
o Rakennemallin komponentit ovat arkkitehtikomponenttien sisällä
o Arkkitehtimallin komponentit on peitetty

Suunnittelualojen väliset leikkaukset
o Talotekniikan sisäiset leikkaukset
o Talotekniikka vs. arkkitehtuuri
o Talotekniikka vs. rakenne
Säännöstöt on koottu Solibrin valmiista säännöstökirjastosta ja alasäännöstöt jakautuivat vielä tarkastussääntöihin.
Kastellin monitoimitalon tietomallikoordinaattori Juho Vuolteenaho oli tehnyt rakenneja arkkitehtimallien yhteneväisyyden tarkastamiseen oman säännöstön, joka helpotti
tarkastusta ottamalla huomioon arkkitehtimallin objektien nimeämis- ja luokittelukäytännöt projektissa. Pohjantien koulussa Lemminkäisen tietomalliasiantuntija Artur Virit
oli muokannut tarkastussäännöstöjen toleransseja projektin tavoitteet huomioivaan
suuntaan, sillä oletuksena olevat Solibrin sääntöparametrit on säädetty melko tiukoiksi.
Parametrien muokkaamisesta projektiin sopiviksi esitettiin positiivisia kokemuksia Pohjantien koulun suunnittelun palautekeskustelussa.
Kuten aiemmissa luvuissa todettiin, suunnittelijoiden omat laadunvarmistusmenettelyt
ovat perustuneet suunnittelutoimistojen sisäisiin ohjeisiin, tai suunnittelijan henkilökohtaisiin menettelyihin. Niiden suorittamiseen on luotettu, eikä niiden suorittamista ole
erityisesti valvottu, vaikka tarkastustoimenpiteille on esitetty vaatimuksia projektien
tietomalliohjeissa. Mikäli suunnittelijoiden omat laadunvarmistusmenettelyt laimin-
115
lyödään, monesti suunnittelualakohtaiset ongelmat, esimerkiksi tietomallien sisältämät
päällekkäiset komponentit, joita ei tietomallikoordinaattorin tarkastuksessa tarkasteta,
ilmenevät kuitenkin myöhemmin hyödynnettäessä tietomalleja.1
Suurin osa case-kohteiden suunnittelijoista ei ollut ottanut käyttöön Solibri Model
Checkeriä, joka on Solibrin maksullinen tietomallien tarkastuksen mahdollistava versio.
Kuitenkin myös ohjelmiston ilmaisella versiolla (Solibri Model Viewer) on mahdollista
tutkia tarkastusraportteja tarkastussäännöstöistä, jotka on sisällytetty tietomallikoordinaattorin luomaan yhdistelmämalliin. Tämän vuoksi olisi tarkoituksenmukaista, että
tietomallikoordinaattorin tarkastussäännöstöt jaettaisiin projekteissa kahteen osaalueeseen:
-
Tietomallikoordinaattorin tarkastus
o Sisältäisi esimerkiksi em. säännöstöt, jotka tietomallikoordinaattori raportoisi pääsuunnittelijan käsittelyä varten.
-
Osamallien tarkastukset
o Sisältäisi tarkastussäännöstöt mallien tarkastamiselle suunnittelualoittain.
o Mahdollistaisi myös Solibrissa valmiina olevien YTV2012 tarkastuslistojen sisällyttämisen yhdistelmämalliin.
o Ei tarkastettaisi/raportoitaisi kokouksiin erikseen.
Jaolla voitaisiin saavuttaa pääasiassa seuraavat hyödyt:

Suunnittelijoiden oma laadunvarmistus: Vaikka suunnittelutoimistolla ei olisi
Solibri Model Checkerin lisenssiä, suunnittelijat voisivat tarkastella valmiiksi
ajettuja osamallien tarkastusraportteja, paikallistaakseen oman suunnittelualansa
virheitä.

Suunnittelijoiden tarkastuksen läpinäkyvyys osapuolille: Jo pintapuolisella tarkastelulla saadaan kuva virheistä osamalleissa. Arkkitehti- ja rakennemallien
tarkastuksissa myös virheiden lukumäärästä pystytään tekemään päätelmiä, esimerkiksi yhdistelmämallipalaverissa.
Tietomallin tarkastuksen ajaminen kestää ensimmäisellä kerralla hieman kauemmin,
mutta sen jälkeen tulokset ovat tarkasteltavissa ilman että niitä täytyy erikseen laskea
1
Ekman, R. 2013. s. 34
116
uudelleen. Tarkastussäännöstöjen lisäämisen vaikutukset yhdistelmämallin käytettävyyteen tulee kuitenkin erikseen tutkia. Tutkijalla oli käytössä peruskäyttöön suunnattu
kannettava tietokone, jossa tietomallien pyörittäminen oli ajoittain muutenkin raskasta.
Toisaalta mikäli ajetut tarkastukset hidastavat yhdistelmämallia merkittävästi, ne voidaan sammuttaa normaalikäytön ajaksi ja ottaa käyttöön uudelleen tarpeen vaatiessa.
Kohdeyrityksellä on ollut tavoitteena kehittää käyttöön yleinen tarkastussäännöstö projekteihin, mutta johtuen aiemmista ohjelmiston rajoituksista säännöstöjä ei ole pystynyt
muokkaamaan tarpeeksi vapaasti tarkastuksen helpottamiseksi. Säännöstöpohjaiseen
tarkastukseen on lisätty uusia ominaisuuksia uudemmissa Solibrin versioissa 8.1 ja 9.0,
esimerkiksi alakattojen asennustilan tarkastamisen osalta. Mahdollisesti myös Järvenpään Viljaa koskeva ongelma kipsilevyalakattoihin liittyen pystyttäisiin ohittamaan
näillä versioilla. Uudemmissa versioissa olisi mahdollista lisäksi säätää säännöstöille
erilaisia toleransseja eri tapauksiin, kuten asunto- ja toimitilarakentamiseen.
Kohdeyrityksellä on kehitetty rakennekirjastot asuntotuotantoon Archicadille ja Revit
Architecturen versiolle 2013, sekä mallinnusohjeet näille ohjelmille. Mikäli projekteissa
noudatettaisiin tarkemmin mallinnusohjeissa esitettyjä tietomallien objektien nimeämiskäytäntöjä, niiden käytölle pystyttäisiin laatimaan myös helposti valvontasäännöstöjä,
joita voitaisiin tarvittaessa muokata asuntotuotannossa projektikohtaisesti sovittujen
periaatteiden mukaisesti.
3.4.8 Solmutyöskentelyn mahdollisuudet yhteistoimintaa ja ongelmanratkaisua vaativissa suunnitteluvaiheissa
Etenkin elinkaarihankkeissa korostuu tavoite sille, että suunnitteluprosessin aikana luodut suunnitteluratkaisut ovat optimoituja elinkaaren aikaisen kokonaistaloudellisuuden
sekä riskienhallinnan osalta koko palvelujakson aikana. Mahdollisimman optimaalisen
ratkaisun luominen ei ole mahdollista vain yhden osapuolen tuottamana, vaan se edellyttää tiedonvaihtoa kaikkien projektin suunnitteluvaiheen toimijoiden välillä. Paras
lähestymistapa suunnittelulle olisi tällaisissa tilanteissa se, että suunnitelmat suunnitellaan jo alusta alkaen yhteistyössä optimaalisiksi, sen sijaan että muu suunnittelu sovitetaan yhden osapuolen luomiin raameihin. Usein jälkimmäisessä tapauksessa suunnitteluratkaisujen optimointi toteutetaan pääosin kompromisseina alkuperäisiin suunnitelmiin.
117
Erääksi tärkeimmistä tietomallinnuksen tuomista hyödyistä on esitetty osapuolten välisen yhteistyön paranemista. Osapuolten välisen yhteistyön kehittämiseksi, samanaikaisesti tietomallintamisen prosessien kehittämisen kanssa on tutkittu myös integroivia
projektitoimituksen (Integrated project delivery, IPD) malleja. IPD:n on odotettu yhdistävän ihmiset, järjestelmät, liiketoimintarakenteet ja käytännöt prosessiksi, joka yhteistyön avulla tuo esille osapuolten erilaiset kyvyt ja näkökulmat, tavoitteenaan minimoida
hukkaa ja parantaa tehokkuutta kokonaisvaltaisesti rakennusprosessin kaikissa vaiheissa.1
IPD:n luomien yhteisten tavoitteiden tukemiseksi on luotu sen sovellutus2 ”big room” työskentely, jossa projektin osapuolet työskentelevät suunnittelun ajan samoissa tiloissa
tiedonvaihdon maksimoimiseksi, ja toisaalta päätöstenteon vaatiman ajantarpeen minimoimiseksi. Big Room on alun perin luotu toimintatavaksi laajoissa sairaalahankkeissa,
jotka työmäärältään mahdollistavat projektin osapuolten sitouttamisen yhteen hankkeeseen. Osana RYM Oy:n PRE-ohjelman Model Nova -työpakettia on tutkittu solmutyöskentelyn soveltamista samoihin tavoitteisiin, mutta Suomen toimintaympäristössä, jossa
hankkeet ovat pääsääntöisesti pienempiä ja projektin toimijat työskentelevät useassa eri
hankkeessa samanaikaisesti. Erona big roomiin, solmutyöskentelyssä osapuolet kokoontuvat pariksi päiväksi ennalta määritellyissä, kriittisimmissä suunnitteluprosessin vaiheissa, joissa intensiivisestä yhteistyöstä hyödytään eniten.3 Solmutyöskentely eroaa
tiimityöstä siinä, että osapuolia yhdistävät yhteiset tavoitteet, eikä kuuluminen samaan
ryhmään.
Solmutyöskentelyn teoreettinen viitekehys perustuu aiemmin luotuun malliin, jota on
testattu Model Nova -työpaketissa rakennusalan toimintaympäristössä. Solmutyöskentelyn hyödyntämistä pilotoitiin koulu- ja päiväkotirakennuksen luonnossuunnitteluun
Kuopion lähistöllä.4 Model Nova -työpaketti kehitti casessa tilaajalle luonnossuunnitelmia kahteen eri kohteeseen, joista toinen oli olemassa oleva suojeltu rakennus ja toinen
tyhjä tontti, johon rakennettaisiin uudisrakennus. Tarkoituksena luonnoksilla oli tukea
tilaajan päätöksentekoa uuden koulurakennuksen sijaintiin liittyen.5 Suunnittelua varten
muodostettiin kummallekin sijainnille työryhmät, jotka koostuivat arkkitehdeista, ra1
The American Institute of Architects (AIA). 2007.
Kerosuo, H. et al. 2013a. s. 2
3
4
Lavikka, R. 2013 et al. s. 5
5
2
118
kennesuunnittelijoista, LVI-suunnittelijoista, elinkaarikonsulteista, projektinjohtokonsulteista sekä kustannussuunnittelijoista. Työskentelysessiot pidettiin kahtena päivänä,
joissa tavoitteena oli luoda erilaisia tilaajan tarpeisiin soveltuvia ratkaisuja, joita vertailtiin myös kustannusten, sisäilmaolosuhteiden ja energian kulutuksen näkökulmasta.1
Aiheeseen liittyvissä tutkimuksissa korostettiin, että edellytyksenä solmutyöskentelyn
onnistumiselle on huolellinen suunnittelutehtävän valmistelu, johon olennaisena osana
kuuluu tarvittavien lähtötietojen hankkiminen, sekä yhteisten päämäärien asettaminen
osapuolten kesken. Taija Nikun diplomityössä2 ja Model Nova -työpaketin osana aiheesta laadituissa artikkeleissa on tunnistettu vaiheet solmutyöskentelyn järjestämiselle:
Ennen työskentelyä:
1. Määritellään työskentelylle yhteiset päämäärät.
2. Määritellään yhteiset työskentelytavat, käytettävä teknologia, sekä käytössä olevan suunnittelutilan vaatimukset.
Työskentelyn aikana:
3. Varmistetaan, että käytettävä teknologia ja tekninen ympäristö toimii ja tukee työskentelyä. (Esim. käytössä olevien ohjelmistojen yhteensopivuus, verkkolevyt tiedon vaihtoa varten, videotykit jne.)
4. Valitaan työryhmän johtaja kehittämään keskustelua ja
varmistamaan tavoitteelliset tulokset.
5. Varmistetaan, että osapuolet ovat motivoituneita työskentelemään yhdessä.
Työskentelyn jälkeen:
6. Esitetään luodut ratkaisut tilaajalle ja/tai loppukäyttäjälle.
1
2
Niku, T. 2013.
119
Kuva 27. Solmutyöskentelyn vaiheet. Lähde: Lavikka, R. et al. 2013. s. 10
Tutkimuksissa on esitetty case-tapauksen havaintoihin perustuen solmutyöskentelyllä
saavutettuja sekä oletettavissa olevia hyötyjä, joita ovat mm.:
-
Samassa tilassa työskenneltäessä suunnittelijat saavat tarvitsemansa tiedon muilta osapuolilta nopeammin, mikä nopeuttaa suunnittelua. 1
-
Suunnittelu on rytmitettävissä ja koordinoitavissa paremmin työskenneltäessä
samassa tilassa.2 Esimerkiksi yhdelle ehdotukselle voidaan tehdä kustannus- ja
taloteknisiä analyysejä samanaikaisesti kun muut osapuolet luovat seuraavaa ehdotusta.
-
Suunnittelu oli erittäin tuloksellista, kaksi ryhmää loi kahden päivän aikana yhteensä kuusi luonnosvaihtoehtoa, mihin normaalissa suunnitteluprosessissa olisi
kulunut useita päiviä tai viikkoja. 3
-
Työskentelyn aikana osapuolet oppivat enemmän toistensa työstä.4
-
Tavoitteet suunnittelulle määriteltiin yhdessä, mikä edesauttoi niihin sitoutumista.5
-
Kun suunnitelmat luodaan yhdessä, on oletettavissa että ne ovat yhteensopivampia, mikä voi vähentää törmäystarkastusten vaatimaa ajankäyttöä.6
-
Luoduista ehdotuksista voidaan valita optimaalisin ja tilaajan tarpeisiin parhaiten soveltuva ratkaisu.
1
3
Kerosuo, H. et al. 2013a. s. 4-5
4
5
6
2
120
Etenkin kohdeyrityksen elinkaarihankkeet tarjoavat lukuisia mahdollisuuksia solmutyöskentelyn hyödyntämiselle. Solmutyöskentelyn ”solmujen” määrittelemisessä Kerosuo ja muut1 keskittyvät tutkimuksessaan tiettyihin ennalta määriteltyihin, kriittisiin
hankkeen vaiheisiin, joita voisivat olla esimerkiksi elinkaarihankkeen tarjousvaiheen
luonnosten laatiminen. Niku 2 sen sijaan esittää tutkimuksessaan mahdollisuuden, että
solmutyöskentely voisi olla sovellettavissa myös spontaaneihin, yhteistä päätöksentekoa
vaativiin tapahtumiin, esimerkiksi suunnitteluperiaatteiden äkillisiin muutoksiin. Tällainen voisi olla esimerkiksi Harri Niemen diplomityössään kuvaama3, väestönsuojatilojen
mitoitusperiaatteiden muuttuminen kesken suunnittelun Kuopion elinkaarihankkeessa.
Vaikka solmutyöskentely oli pilottikohteessa erittäin tuloksellista, osapuolet kokivat sen
vaativan intensiivisen työskentelyn erittäin raskaaksi.4 Rakennusalan toimintaympäristössä todellista yhteistyötä osapuolten välille on sanottu rajoittavan kulttuurihistoriallisesti muodostuneet rajat. Myös solmutyöskentelylle on esitetty kritiikkiä siitä, että vaikka osapuolet työskentelevät samassa projektissa, se ei tarkoita että he olisivat tarpeeksi
motivoituneita työskentelemään yhteisten tavoitteiden eteen erittäin intensiivisesti, tai
että osapuolilla edes olisi yhteiset tavoitteet.5 Model Nova -työpaketin tutkimus ei ole
kaikilta osin yleistettävissä normaaleihin hankkeisiin, sillä suunnitteluryhmät olivat
muodostettu PRE-hankkeen seminaareissa, joissa osapuolet tunsivat toisensa entuudestaan ja heitä motivoi yhteiset tavoitteet luoda uusia toimintamalleja alalle.6 Big room
sen sijaan on kehitetty osana IPD:tä, jossa osapuolia motivoivat erilaiset, yhteiset sopimusmallit.
Suurin yksittäinen haaste solmutyöskentelyn käyttöönottoon kohdeyrityksen hankkeissa
liittyykin osapuolten motivoimiseen vaativaan ja intensiiviseen työskentelyyn asetettujen tavoitteiden eteen. Ongelmat korostuvat etenkin haastatteluissa ilmenneistä näkökulmista, joissa suunnittelijat kritisoivat suunnittelupalkkioiden riittävyyttä suhteessa
tietomallintamisen aiheuttamaan työmäärään. Osapuolten sitoutuminen tavoitteisiin,
sekä sitä tukevat palkitsemis- ja sopimusmallit solmutyöskentelyyn edellyttävätkin jatkotutkimusta, ennen sen soveltamista nykyisiin hankkeisiin.
1
Kerosuo, H. et al. 2013b. s. 14
Niku, T. 2013. s. 74
3
Niemi, H.2011. s. 40
4
Kerosuo, H. et al. 2013b. s. 13
5
Bishop, D. et al. 2008. s. 5
6
2
121
Huolimatta soveltamisen haasteista, myös monet haastatelluista suunnittelijoista esittivät näkökulmia, että tilausta uusille yhteistyötä ja tiedonvaihtoa edistäville työskentelytavoille on myös suunnittelijoiden keskuudessa. Nykytilaa joissain projekteissa alalla
voi kuvata erään pitkän uran alallansa tehneen suunnittelijan esittämä kanta:
…niin että suunnittelukokouksissa on kuitenkin niin paljon niitä osapuolia mukana, että
siellä sitten viisi ihmistä istuu turhaan sen takia. Ne ei ole enää niin kuin perinteisiä suunnittelukokouksia, missä suunnitellaan. Ne olivat sellaisia 80-luvulla, 90-luvulla, muttei
enää 2000-luvulla. Ovat saaneet virallisen muodon, mutta sehän johtuu tästä yrityskulttuurista kun on pörssiyhtiö niin… Kyl silloin joutuu raportoimaan joka ikisen liikkeen ja se on
muuttunut maailma.
122
4 Tutkimustulosten arviointi
4.1 Keskeisten tulosten suhde aiempaan tietoon
Tutkimuksen keskeisimmät tulokset koskivat suunnittelun tiedonvaihto-, laadunvarmistus- ja yhteistoimintamenettelyitä. Periaatteet toiminnalle tietomallinnetuissa hankkeissa
on luotu osana kansalliseksi käytännöksi muodostuneessa YTV2012-ohjeistuksessa,
joka on kehitetty vuonna 2007 julkaistuista Senaatti-kiinteistöjen tietomallivaatimuksista. Lisäksi monia tietomallintamisen prosesseja on kehitetty aiheesta tehdyissä opinnäytöissä sekä osana yritysten sisäistä tutkimusta, jotta suunnittelunohjauksella pystyttäisiin
vastaamaan paremmin myös kohdeorganisaatioiden tarpeisiin hyödyntää tietomallintamista. Periaatteet toiminnalle on kehitetty muutaman viime vuoden aikana, joten kaikkia prosesseihin liittyviä ongelmia ei ole vielä ehditty tutkia. Lisäksi osapuolten kokemus tietomallintamisesta on projekteissa lisääntynyt, minkä johdosta erityisesti tiedonvaihdolle on syntynyt uusia tarpeita. Tutkimus osoitti, että moniin nykyisiin toimintatapoihin liittyy ongelmia, joiden osalta myös niihin liittyvää ohjeistusta tulee kehittää,
täsmentää ja täydentää.
Uutuusarvoa yhteistoimintaan erityisesti case-organisaation projekteissa pyrittiin tuomaan esittelemällä uusia, osittain päällekkäisesti tutkimuksen kanssa kehitettyjä toimintamenettelyitä, joita olivat SKOL Ry:n tietomalliprosessit, sekä Model Novatyöpaketissa kehitetty solmutyöskentelyn soveltaminen tietomallinnetuissa hankkeissa.
4.2 Tulosten luotettavuus
Kirjallisuustutkimuksen teoria perustui tietomallinnetun rakennushankkeen suunnittelun
lähtökohtiin, tiedonvaihdon teknologiaan ja IFC-mallien hyödyntämiseen sekä tietomallinnetun rakennushankkeen vaiheisiin ja niihin liittyviin tiedonvaihtotarpeisiin. Kirjallisuustutkimus antoi hyvän peruskuvan tutkimukseen liittyvistä aiheista, mutta niitä oli
käsitelty varsin yleisellä tasolla ja erityisesti eri suunnitteluvaiheisiin liittyviä ongelmia
oli kuvattu opinnäytetöitä lukuun ottamatta kirjallisuudessa vähäisesti.
Case-tutkimuksessa haastateltiin laajasti projektin eri osapuolia, mikä mahdollisti erilaisten näkökulmien saamisen tutkituista aiheista ja siten luotettavan kuvan muodosta-
123
misen. Tärkeänä havaintona tutkimuksessa voidaan pitää osapuolten erilaisia tarpeita
tietomalleille ja niihin liittyville prosesseille, joten yhtä luotettavaa kuvaa tutkituista
aiheista ei olisi ollut mahdollista muodostaa haastattelemalla esimerkiksi pelkästään
suunnittelijoita. Haastattelut nauhoitettiin ja litteroitiin sanatarkasti, mikä pienensi väärintulkintojen riskiä ja mahdollisti haastatteluiden tarkemman analysoinnin keskeisten
tulosten muodostamisessa.
Teemahaastatteluiden runko perustui yleisissä tietomallivaatimuksissa esitettyyn tietomallinnetun rakennushankkeen kulkuun, joka poikkesi jonkin verran osapuolten näkökulmista rakennushankkeen kulusta. Asuntokohteessa osapuolten näkökulma perustui
pääosin RT-kortissa 10-10387 esitettyyn talonrakennushankkeen kulkuun, mutta myös
toimitilakohteissa osapuolten näkemys erosi jonkin verran YTV2012:ssa esitetystä mallista, etenkin elinkaarihankkeiden erityispiirteiden osalta. Tutkimusmenetelmänä teemahaastattelu kuitenkin oli tarpeeksi joustava huomioimaan ongelman.
Koska tutkimuksen keskeisimpänä tutkimusaineistona toimivat haastattelut casekohteissa, eräs tärkeimmistä tutkimustulosten luotettavuuteen vaikuttavista tekijöistä on
tutkijan omat tulkinnat haastatteluissa esitetyistä näkemyksistä. Koska kaikissa casekohteissa tuotettiin lopulta laadukkaat suunnitelmat ja osapuolet olivat pääosin tyytyväisiä suunnitteluprosessin kulkuun, tulosten luotettavuuteen vaikuttavana riskinä on tutkijan havainnoille antama merkitys niiden vaikutuksesta suunnitteluprosessin kokonaisuuteen. Esitettyjen ongelmien luotettavuutta kuitenkin tukee se, että ne pääosin perustuivat
usean haastateltavan samoissa projekteissa tekemiin havaintoihin ja yksittäisten mielipiteiden esittämistä pyrittiin johtopäätöksissä välttämään.
Tutkimuksessa tuli vastaan erityisesti ohjelmistojen nopea kehittymistahti. Tutkimuksessa sovellettiin Solibri Model Checkerin versiota 8.0, jota käytettiin suunnittelun aikana case-kohteissa. Myöhemmin julkaistut versiot 8.1 ja 9.0 sisältävät uusia ominaisuuksia, jotka saattaisivat mahdollistaa monen tutkimuksessa esitetyn ongelman ratkaisemisen paremmin. Myös tutkimuksen osana laaditut ohjeet on laadittu Solibrin versiota
8.0 hyödyntäen. Vaikka ohjelmiston toiminnallisuudet ovat pääosin pysyneet samoina,
ohjeiden toimivuus uusilla versioilla tulisi testata ja päivittää versiomuutosten osalta.
124
4.3 Tulosten yleistettävyys
Tutkimustulosten yleistettävyyttä parantaa se että tutkimuksessa haastateltiin rakennushankkeen useita eri osapuolia ja tarkasteltiin asuntokohdetta sekä kahta elinkaarihanketta, joiden osalta tulokset ovat yleistettävissä laajoihin toimitilakohteisiin. Monien tutkimuksessa tehtyjen havaintojen yleistettävyyttä tukee se, että kaikissa kolmessa casekohteessa raportoitiin samantyyppisiä havaintoja. Kahden eri hanketyypin erot pyrittiin
kuitenkin tuomaan tarpeellisin osin esille tutkimuksen tuloksissa, mikä mahdollistaa
niiden soveltamisen erityyppisiin hankkeisiin.
Vaikka tutkimuksen tulokset nojaavat Lemminkäisen toimintajärjestelmään ja suunnittelunohjauksen prosesseihin, ovat ne pääosin sovellettavissa myös muiden rakennusalan
toimijoiden käyttöön. Tutkimustulosten hyödyntäminen kuitenkin edellyttää, että kohdeorganisaation tietomallintamisen prosessit ja niihin liittyvä osaaminen ovat samalla
tasolla kuin case-organisaatiossa.
Tutkija perehtyi kolmeen case-kohteeseen kerrallaan hyvin lyhyen aikaa, mutta havaintoja case-kohteista tehtiin laajasti eri osapuolilta. Palautetta työn tuloksin liittyen saatiin
tutkimuksen tilaajaorganisaation henkilöstöltä, mutta toimiakseen ne vaatisivat myös
testausta käytännön toiminnassa projekteissa. Olennaisena osana tulosten testausta tulisi
arvioida niillä saavutettavaa lisäarvoa suhteessa mahdollisesti lisääntyvään työmäärään.
Monia tutkimuksessa esitettyjä havaintoja käsiteltiin vain pinnallisesti, joten ollakseen
yleistettävissä, tulisi niihin liittyvän jatkotutkimuksen tarve myös arvioida tarkemmin.
125
5 Johtopäätökset
Tietomallintaminen tulee huomioida osana suunnittelun organisointia ja ajallista hallintaa muutenkin kuin tietomallintamiseen liittyvien kokouskäytäntöjen ja tarkastuspisteiden osalta. Tietomallinnetussa hankkeessa on olennaista, että piirustustarpeiden lisäksi
hankkeessa pystytään määrittelemään vaadittava tietomallien tietosisältö suunnittelualoittain myös suunnittelun ajallisessa yhteydessä. Vaikka perusperiaatteet osapuolten
tiedonvaihtotarpeille esitetään suunnitteluaikataulussa, suunnittelun sujuvuuden kannalta on olennaista, että niitä tarkennetaan myös lyhyemmällä aikavälillä. Lyhyen aikavälin
tiedonvaihtotarpeiden tarkentaminen tulee tapahtua suunnittelijalähtöisesti, sillä ainoastaan he pystyvät tarkasti määrittelemään mitä tietoa ja vaiheita suunnittelutehtävien suorittaminen edellyttää myös muilta osapuolilta. Huolimatta siitä että projektien yhteistoiminta- ja kokouskäytännöt mitoitetaan hankkeen laajuuden ja kompleksisuuden mukaan, olennaista on että tiedonvaihtotarpeiden mukaisille lähtötiedoille asetetaan yhteisesti lukitsemispäivämäärät, joista poikkeaminen tulee tiedottaa muille osapuolille selkeästi.
Tarve tietomallintamisen koordinoimiselle on kasvanut hankkeissa erityisesti tiedonvaihtoon liittyvien prosessien monimutkaistuessa tietomallintamisen yleistymisen, sekä
aiempaa laajemman tietomallien hyödyntämisen kautta. Osittain myös YTV2012:ssa
tietomallintamisen koordinoiminen on henkilöity tietomallikoordinaattorille. Projektin
osapuolten erilaiset tarpeet huomioiden, odotukset tietomallikoordinaattoriksi nimetyn
henkilön tehtäville ovat kasvaneet niin laajoiksi, että harvoissa tapauksissa yhden henkilön osaaminen mahdollistaa niiden suorittamisen. Tietomallintamisen koordinoiminen
tulisikin nähdä joukkona tehtäviä, joiden suorittaminen on edellytys tietomallinnetun
rakennushankkeen johtamisen kannalta. Tehtävät tulee organisoida projektin alkuvaiheessa oikeille henkilöille, jotta tarvittava osaaminen ja osapuolten erilaiset tarpeet
koordinoimiselle tulee täytettyä.
Lemminkäinen Talo Oy:n hankkeissa on havaittu, että osaavien projekteihin sidottujen
henkilöiden tehtävänkuvia on mahdollista laajentaa myös heidän normaalien työtehtäviensä ulkopuolelle, esimerkiksi suunnittelunohjaukseen. Tietomallintamisen tavoitteita
tukeviin tuloksiin päästään parhaiten, kun yksittäisiin tietomallintamisen koordinointiin
126
liittyviin tehtäviin voidaan tarvittaessa liittää niiden suorittamista tukevaa osaamista
laajemmin, jolloin niiden suorittaminen ei tukeudu vain yksittäisen henkilön kompetenssiin.
Case-kohteena Järvenpään Vilja osoitti, että myös pääsuunnittelija voi tietomallinnetussa rakennushankkeessa menestyksekkäästi vastata yhdistelmämallien tarkastuksista,
mutta tehtävän edellyttämä työmäärä tulee arvioida suhteessa projektin laajuuteen ja
kompleksisuuteen. Huolimatta tarkastuksen suorittajasta, vastuu esille tuotujen ongelmien käsittelystä ja eri suunnittelualojen suunnitelmien yhteensovittamisesta on pääsuunnittelijalla. Onnistunut tietomallien laadunvarmistus- ja julkaisuprosessi tähtääkin
siihen, että yksittäistä tai kahta suunnittelualaa koskevat ristiriidat saadaan eliminoitua
ennen yhteistä käsittelyä, ja ajankäyttö suunnittelijoiden palavereissa saadaan kohdennettua suunnittelijoiden yhteistoimintaa vaativiin ongelmiin, joiden ratkaisua pääsuunnittelija on oikea henkilö johtamaan.
Suunnitelmien tarkkuustason kasvaminen ja tiedonvaihtoon liittyvien prosessien monimutkaistuminen on vaikuttanut erityisesti suunnittelijoiden yhteistoimintaa vaativiin
suunnittelutehtäviin. Tehtävät vaativat aiempaa tarkempaa sopimista niiden suorittamiseen liittyvistä menettelyistä, jotta tiedonvaihto on hallittua, asiat tehdään oikeassa järjestyksessä ja tehtäviin liittyvä työmäärä on selvillä osapuolille jo alusta alkaen. Projekteissa on havaittu, että suunnitteluryhmän toimintatavat ovat kehittyneet, kun samat
suunnittelijaosapuolet ovat jatkaneet työskentelyä yhdessä hankkeesta toiseen. Kuitenkin muodostettaessa uutta suunnitteluryhmää, suunnittelijoiden aikaisemmalla tietomallintamisen kokemuksella on vaikutusta myös yhteistoimintaa vaativien suunnittelutehtävien kulkuun.
Aiempaa parempiin tuloksiin on mahdollista päästä myös soveltamalla suunnitteluun
ennakkoluulottomasti uusia, yhteistoimintaa edistäviä toimintatapoja, jotka mahdollistavat sen, että suunnitelmat tehdään yhteensopiviksi ja optimoiduiksi jo lähtökohtaisesti.
5.1 Jatkotutkimusmahdollisuudet
Monet tutkimuksessa esitetyt havainnot ja tulokset tarjoavat aiheita jatkotutkimukselle,
joita ovat esimerkiksi:
127
-
Suunnittelutiedon ja tietomallien valmiusasteen viestiminen muille suunnittelijoille sekä tuotanto-organisaatioille
o Valmiusasteen dokumentointi osana tietomallien julkaisumenettelyitä
o Tietomallipohjaiset visuaaliset työkalut valmiusasteen viestintään, erityisesti tuotantoa varten
-
Kohdeyrityksen TATE-mallinnusaineiston kehittäminen
o Tietomallintamisen tasot
o Suunnittelutoleranssit toimitila-, peruskorjaus- ja asuntotuotantokohteissa
-
Yhdistelmämallin tarkastussäännöstöjen kehittäminen
o Tapaukset asunto- ja toimitilakohteisiin, niiden erityispiirteet tunnistaen
ja huomioiden
o Kehitetyn tarkastussäännöstön jako raportoitaviin ja laadunvarmistuksen
läpinäkyvyyttä parantaviin, ei-raportoitaviin alasäännöstöihin
-
Reikä- ja varaussuunnitteluprosessin kehittäminen erityisesti peruskorjauskohteissa, huomioiden olemassa olevan rakennuksen inventointimallin tuottaminen
-
Solmutyöskentelyn soveltaminen yhteistoimintaa ja ongelmanratkaisua vaativissa suunnittelutehtävissä
o Sovellettavat suunnitteluvaiheet ja -tehtävät
o Sitouttaminen ja palkitseminen, työskentelyä tukevat sopimusmallit
128
Lähteet
Kirjallisuus
Aaltonen, M. 2012. Suunnitelmien yhteensovittaminen tietomallia hyödyntävässä rakennushankkeessa. Julkaistu: Aalto-yliopisto, Aalto PRO. 2013. 34. rakennuttajakoulutuksen tutkielmat. Helsinki: Unigrafia Oy. 356 s. ISBN 978-952-60-5239-7.
Bishop, D. ,Felstead, A., Fuller, A., Jewson, N., Unwin, L. & Kakavelakis, K. 2008.
Constructing learning: adversarial and collaborative working in the British construcion
industry. Cardiff: Cardiff School of Social Sciencess, Cardiff University. 38 s.
Eastman, C. & Teicholz, P. & Sacks, R. & Liston, K. 2011. BIM Handbook: a guide to
building information modeling for owners, managers, designers, engineers and contractiors. 2. painos. Hoboken, New Jersey: John Wiley & Sons Inc. 626 s. ISBN 978-0-47054137-1.
Ekman, R. 2013. Tietomallin hyödyntämien rakennusliikkeen oman asuntotuotannon
määrä- ja kustannuslaskennassa, insinöörityö. Raasepori: Ammattikorkeakoulu Novia.
40 s.
Finnmap Consulting Oy & Rakennusteollisuus RT ry. 2004. Tuotemallinnus rakennesuunnittelussa – Perusteet ja ohjeita I – Pro IT.
Gijezen, S., Hartmann, T., Veenvliet, K. Th., Hendriks, H. & Buursema, N. 2010. Organizing 3D building information models with the help of work breakdown structures to
improve the clash detection process. Enschede: University of Twente. 30 s.
Hirsijärvi, S. & Hurme, H. 2000. Tutkimushaastattelu – Teemahaastattelun teoria ja
käytäntö. Helsinki: Helsinki University Press. 213 s.
Jørgensen, K. A., Skauge, J., Christiansson, P., Svidt, K., Sørensen, K. B., & Mitchell,
J. 2008. Use of IFC model servers-modelling collaboration possibilities in practice.
Aalborg: Department of Production, Aalborg University. 60 s.
129
Kallio, T. 2013. Tietomalli pääsuunnittelijan työkaluna – Muuttuvat ohjeet ja määräykset. Julkaistu: Aalto-yliopisto, Aalto PRO. 2013. 12. Pääsuunnittelijakoulutuksen tutkielmat. Helsinki: Unigrafia Oy. 410 s. ISBN 978-952-60-5087-4.
Karhu, V., Hannus, M. & Pellosniemi, J. 1994. Elementtirakennuksen tuotemallipohjainen arkkitehtisuunnittelu. VTT Tiedotteita 1568. Espoo: Valtion teknillinen tutkimuskeskus (VTT). 97 s + liit. ISBN 951-38-4662-8
Kerosuo, H., Mäki, T., Korpela, J. 2013a. Knotworking – A novel BIM-based collaboration practice in building design projects, konferenssijulkaisu. Helsinki: Helsingin yliopisto. 7 s.
Kerosuo, H., Mäki, T., Korpela, J. 2013b. Knotworking in and for collaboration between designers in building design, konferenssijulkaisu. Helsinki: Helsingin yliopisto.
16 s.
Lavikka, R., Niku, T. & Lehtinen, T. 2013. Bringing the design team together: coordinating inter-organizational design work using an agile co-working method, konferenssijulkaisu. The 19th International CIB World Building Congress. Brisbane: Queensland
University of Technology. 12 s.
Mäki, T., Korpela, J. & Kerosuo, H. 2013. LastPlanner tietomallinnetun hankkeen
suunnittelunohjauksessa. Julkaistu: Rakentajain kalenteri 2013. Helsinki: Rakennustieto
Oy ja Rakennustietosäätiö RTS. s. 204-208. ISSN 0355-550X.
Mäki, T., Paavola, S., Kerosuo, H., Miettinen, R. 2012. Tietomallintamisen käytöt rakentamisessa. Julkaistu: KONSEPTI – Toimintakonseptin uudistajien verkkolehti, 7 (12). Helsinki: Toiminnan, kehityksen ja oppimisen tutkimusyksikkö, Helsingin yliopisto.
19 s.
Niemi, H. 2011. Tietomallien käyttö elinkaarihankkeiden suunnittelu ja toteutusvaiheissa, diplomityö. Espoo: Aalto-Yliopisto, Rakennetekniikan laitos. 110 + 14 s.
Niku, T. 2013. Knowledge transfer through agile co-working methods in construction
project networks, diplomityö. Espoo: Aalto-yliopisto. 98 s.
130
Niskakangas, V. 2013. Tietomallinnetun rakennushankkeen suunnittelunohjaus, diplomityö. Tampere: Tampereen teknillinen yliopisto. 56 + 35 s.
Palos, S. 2010. Tietomalliprosessi - Tietomallitiedon käyttö suunnittelussa, rakentamisessa ja ylläpidossa. Tampere: Tampereen teknillinen yliopisto. 62 + 101 s.
Patel, A. 2011. The Last Planner system for reliable project delivery. Arlington: University of Texas. 75 s.
Penttilä, H. 2009. Rakennushankkeen osapuolten vaatimukset tietomalleille – Tietomallihankkeen osapuolten kelpoisuusedellytykset. Julkaistu: Rakentajain kalenteri 2009.
Helsinki: Rakennustieto Oy ja Rakennustietosäätiö RTS. s. 344-350. ISSN 0355-550X.
Penttilä, H., Nissinen, S. & Niemioja, S. 2006a. Tuotemallintaminen arkkitehtisuunnittelussa – Pro IT. Helsinki: Rakennustieto Oy.
Penttilä, H., Nissinen, S. & Niemioja, S. 2006b. Tuotemallintaminen rakennushankkeessa - yleiset periaatteet - Pro IT. Helsinki: Rakennustieto Oy. 64 s.
Rakennustieto Oy. 2010. RT 10-10992 Tietomallinnettava rakennushanke – ohjeita
rakennuttajalle. Helsinki: Rakennustietosäätiö RTS. 13 s.
Rantala, M. 2009. Tietomallintamisen tavoitteet, vaatimukset ja hyödyt tilaajan näkökulmasta – Case: Espoon Sairaala. Julkaistu: Teknillinen korkeakoulu, koulutuskeskus
Dipoli. 2009. 31.Rakennuttajakoulutuksen tutkielmat. Espoo: Aalto-yliopisto.
Shen, W., Hao, Q., Mak, H., Neelamkavil, J., Xie, H., Dickinson, J. & Xue, H. 2010.
Systems integration and collaboration in architecture, engineering, construction, and
facilities management: A review. Julkaistu: Advanced Engineering Informatics, 24(2), s.
196-207.
Suomen RakMK A2. 2002. Rakennuksen suunnitelmat ja suunnittelijat. Määräykset ja
ohjeet 2002. Helsinki: Ympäristöministeriö, Asunto ja rakennusosasto.
The American Institute of Architects (AIA). 2007. Integrated Project Delivery: A
Guide. 1. versio. Kalifornia: The American Institute of Architects. 62 s.
131
Tuuhea, S. 2010. Tietomalli pääsuunnittelijan työkaluna – koordinointi vai tietomallikoordinaattori. Julkaistu: Aalto-yliopisto, koulutuskeskus Dipoli. 2010. 10. Pääsuunnittelijakoulutuksen tutkielmat. Espoo: Aalto-yliopisto. ISBN 978-952-60-3563-5.
Uusitalo, H. 2013. Tietomallipohjaisen määrienhallinnan hyödyntäminen rakennustuotannossa, diplomityö. Tampere: Tampereen teknillinen yliopisto. 73 + 23 s.
van Berlo, L. A. H. M. et al. 2012. Collaborative engineering with IFC: new insights
and technology. Reykjavik: Taylor & Francis Group, London. s. 811-818
Yin, R. K. 2009. Case study research: design and methods. 4. Painos. Thousand Oaks,
CA: Sage Pubilications. 219 s. ISBN 978-1-4129-6099-1.
Muut lähteet
Arkkitehtitoimisto Kaipainen Oy, http://www.kaipainen.fi. Viitattu: 23.5.2013.
Asunto-, toimitila- ja rakennuttajaliitto RAKLI ry. 2003. E-EHYT IFC-selvitys – IFC:n
tuki kiinteistöjen elinkaarihallinnan ydintiedoille sähköisissä huoltokirjoissa. 14 s.
Asunto-, toimitila- ja rakennuttajaliitto RAKLI ry. Rakennushankkeen johtamisen ja
suunnittelun tehtäväluetteloiden uudistaminen. ARK 12, HJR 12, PSU 12, RAK 12, TATE
12.
Saatavissa:
http://www.rakli.fi/linkit/kehitysjaprojektit/telu2012.
Viitattu:
5.4.2013
Betoniteollisuus Ry, http://www.elementtisuunnittelu.fi. Viitattu: 20.8.2013.
buildingSMART International, http://www.buildingsmart-tech.org. Viitattu: 13.3.2013.
buildingSMART International, http://www.ifcwiki.org. Viitattu: 11.3.2013.
COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 1:
Yleinen osuus. Versio 1.0. 21 s.
Lähtötilanteen mallinnus. Versio 1.0. 25 + 7 s.
Arkkitehtisuunnittelu. Versio 1.0. 24 s.
132
Talotekninen suunnittelu. Versio 1.0. 42 + 14s.
Rakennesuunnittelu. Versio 1.0. 19 + 9 s.
Laadunvarmistus. Versio 1.0. 26 s.
Määrälaskenta. Versio 1.0. 24 s.
Havainnollistaminen. Versio 1.0. 14 s.
Mallien käyttö talotekniikan analyyseissa. Versio 1.0. 15 s.
Energia-analyysit. Versio 1.0. 19 + 3 s.
Tietomallipohjaisen projektin johtaminen. Versio 1.0. 24 + 3 s.
Tietomallien hyödyntäminen rakennuksen käytön ja ylläpidon aikana. Versio 1.0. 22 s.
Tietomallien hyödyntäminen rakentamisessa. Versio 1.0. 21 s.
Järvinen, T. Blogi: http://tietomalli.blogspot.fi. Viitattu: 20.8.2013.
Lemminkäinen Talo Oy. BIM-SLU1 – Tietomallien käyttö suunnittelussa. Sisäinen dokumentti.
Lemminkäinen Talo Oy. BIM-SLU8 – Yhdistelmämallin käyttö suunnittelun ohjauksessa. Sisäinen dokumentti.
Lemminkäinen Talo Oy. Projektin tietomalliohje. Sisäinen dokumentti.
133
Lemminkäinen PPP Oy, http://www.lemminkäinen.fi/PPP. Viitattu 18.3.2014.
Puuinfo Oy. Ouluun mittava monitoimitalo puun ja betonin yhdistelmärakenteena.
http://www.puuinfo.fi/ajankohtaista/ouluun-mittava-monitoimihalli-puun-ja-betoninyhdistelmarakenteena. Viitattu 18.3.2014.
Structured
Analysis
Wiki.
http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_15. Viitattu 20.6.2013.
Suunnittelu-
ja
konsulttitoimistojen
liitto
SKOL
Ry,
http://skolry.fi/talonrakennussektori. Viitattu: 14.12.2013.
Suunnittelu- ja konsulttitoimistojen liitto SKOL Ry. 2013. Talotekniikan tietomallinnuksen prosessimuutos, hankkeen työpaja 01, muistio. Viitattu: 27.11.2013.
Suunnittelu- ja konsulttitoimistojen liitto SKOL Ry. 2013. Talotekniikan tietomallinnuksen prosessimuutos, projektisuunnitelma. Viitattu: 29.7.2013.
Haastattelut
Katja Laine, Lemminkäinen Talo Oy. Haastattelu, Järvenpää 28.5.2013
Markku Kaakinen, LVI-insinööritoimisto Plan-Air Oy. Puhelinhaastattelu 29.5.2013
Jukka Pietiläinen, Anders Westerlund, Johan Sund, Ins. Tsto Gabrielsson & Pietiläinen
Oy. Haastattelu, Järvenpää 31.5.2013
Petri Saarelainen, Arkkitehtitoimisto Lahdelma & Mahlamäki Oy. Haastattelu, Helsinki
3.6.2013
Antti Konola, Arkkitehtitoimisto Kaipainen Oy. Haastattelu, Hämeenlinna 5.6.2013
Antti Mustalammi, Optiplan Oy. Puhelinhaastattelu 13.6.2013
Jarkko Mäenpää, Lemminkäinen Talo Oy. Haastattelu, Hyvinkää 25.6.2013
Tapio Mehtälä, Insinööritoimisto Sähkötele Oy. Puhelinhaastattelu 5.6.2013
Kai Häkkinen, WSP Finland Oy. Haastattelu sähköpostin välityksellä
134
Juho Vuolteenaho, Gravicon Oy. Haastattelu sähköpostin välityksellä
Mikko Mäläskä, Lemminkäinen Talo Oy. Haastattelu, Oulu 16.5.2013
Hannu Anttonen, Lemminkäinen Talo Oy. Haastattelu, Helsinki 28.6.2013
Riikka Hannuksela, Lemminkäinen Talo Oy. Puhelinkeskustelu 15.8.2013
Artur Virit, Matti Partanen, Lemminkäinen Talo Oy. Haastattelu, Helsinki 26.8.2013
Matti Varstala, Lemminkäinen Talo Oy. Haastattelu, Helsinki 27.8.2013
-
Osallistujat:
o Matti Varstala, Lemminkäinen Talo Oy
o Juha From, Lemminkäinen Talotekniikka Oy
o Annikki Karppinen, Lemminkäinen Talo Oy
o Tomi Perko, Arkkitehtitoimisto Perko Oy
o Antti Tikkanen, Lemminkäinen Talo Oy
o Markku Hyvönen, Lemminkäinen Talo Oy
o Hannu Kela, Lemminkäinen Talo Oy
o Petri Korhonen, Granlund Kuopio Oy
o Toni Ollikainen, Granlund Kuopio Oy
o Hannu Kuokkanen, Rakennussuunnittelutoimisto Nylund Oy
o Mikko Mattila, Lemminkäinen Talotekniikka Oy
o Jani Halonen, Lemminkäinen Talotekniikka Oy
o Pentti Holopainen, Lemminkäinen Talo Oy
o Ari Kakkinen, Lemminkäinen Talotekniikka Oy
o Mika Kukkonen, Lemminkäinen Talo Oy
o Jukka Vasara, Granlund Kuopio Oy
o Jaakko Kinnari, Lemminkäinen Talo Oy
Liite 1
H = hyväksyy
V = vastaa
A = avustaa
O = osallistuu
H
A
N
K
K
E
E
N
J
O
H
T
A
M
I
S
E
N
T
E
H
T
Ä
V
Ä
T
T
I
E
T
O
M
A
L
L
I
A
S
I
A
N
T
U
N
T
I
J
A
T
i- i
Huomiot
/
Asiakirja
Ku
kt
oj
e
Pr
Pr
oj
e
kt
ip
ää
llik
kö
st nsin : PP
an
ö
T u nu öri
:P
si
ot
I
an nsi
n
t
Pr
oi
ö
ns ör
oj
i:
ek
in
KI
L M tin ö ö r
K: tiet i: T
o
I
n
P ä tie m a
l
t
l
o
äs
m ik o
u
o
a
K o u n n llia r d i
n
si
. S itt
an aa
uu elij
tt
tu
a:
M
n t o r i:
uu nni
P
i
ja
T
tte
S
:T K
o
M s a p lija
M
uu
A
u
os oli 1
ap
:
uo M O
li
1
2:
M
O
2
Tietomallisuunnittelun koordinoimisen tehtävätaulukko
Projekti:
YA-432101234 Esimerkki
Tietomallikoordinoinnin tehtävä
Lähtötietomallien määrittely/tilaaminen
Tietomallinnuksen tavoitteiden,
käyttötarkoitusten ja vaadittavan ohjeistuksen
määrittely
Projektin tietomalliohjeen laadinta
Tietomallintamisen aloituspalaveri(t):
Tavoitteiden ja ohjeistuksen täsmentäminen
Tietomallien suunnittelualakohtaisten
tietosisältötaulukoiden laadinta
Tietomallien tietosisältötaulukoiden läpikäynti
ja täsmentäminen ao. suunnittelijoiden kanssa,
sekä ristiinvertailu
Tietomallintamisen tehtävien määrittäminen
suunnitteluaikatauluun
Visualisointien ja analysointien (esim. energia,
olosuhteet, valaistus) tarpeen, vaatimustason
ja edellytysten määrittely
Vaatimusmallin hyväksyminen
Projektipankin hallinnointi
Tietomallien julkaisusyklien määrittäminen
Periaatteet työmallien käytölle
Projektin tietomalliohjeen päivittäminen ja
ylläpito sovittujen muutosten osalta
Yhteydenpidon ja raportoinnin vaatimusten
määrittäminen
Kokouskäytäntöjen koordinointi
Toteumamallien tietosisällön täsmentäminen
Tietomallien hyödyntämisen
palautteenantopisteet: kommenttien
kerääminen ja puutteiden korjaaminen
(laskenta & tuotanto)
Käytön- ja ylläpidonaikaisten tietomallien
tietosisällön määrittäminen
Ohjelmistoihin ja yhteistoimintaan liittyvä
tekninen tuki
Tuki liittyen mallinnustapoihin, Lemminkäinen
Talo Oy:n aloituspohjiin ja ohjeistuksiin
Tarvittavien koulutusten järjestäminen
Lemminkäinen Talo Oy:n henkilöstölle ja
suunnitteluryhmälle
Tarkennukset:
Osallistuminen asiantuntijana kokouksiin
Liite 1
H = hyväksyy
V = vastaa
A = avustaa
O = osallistuu
P
Ä
Ä
S
U
U
N
N
I
T
T
E
L
I
J
A
N
Tietomallikoordinoinnin tehtävä
Vaatimusmallin laatiminen ja päivittäminen
suunnittelun edetessä
Sopiminen mallinnuksen laadusta ja
laajuudesta
Suunnitteluaikataulun tarkistaminen
tietomallintamisen erityispiireet huomioiden
Eri suunnittelualojen yhteistyön järjestämisestä
huolehtiminen
Suunnittelukoordinaatiston määrittäminen
Suunnitteluryhmän
yhteensovittamisen/laadunvarmistuksen
johtaminen
Tietomallikoordinaattorin raportoimien
virheiden läpikäynti ja kommentointi
suunnittelijoiden kanssa
Suunnittelija / yhdistelmämallipalaverit ja katselmukset suunnitelmien yhteensopivuuden
toteamiseksi ja toimenpiteet korjauksiin liittyen
i- i
Huomiot
/
Asiakirja
Ku
kt
oj
e
Pr
Pr
oj
e
kt
ip
ää
llik
kö
st nsin : PP
an
ö
T u nu öri
:P
si
ot
I
an nsi
n
t
Pr
oi
ö
ns ör
oj
i:
ek
in
KI
L M tin ö ö r
K: tiet i: T
o
I
n
P ä tie m a
l
t
l
o
äs
m ik o
u
o
a
K o u n n llia r d i
n
si
. S itt
an aa
uu elij
tt
tu
a:
M
n t o r i:
uu nni
P
i
ja
T
tte
S
:T K
o
M s a p lija
M
uu
A
u
os oli 1
ap
:
uo M O
li
1
2:
M
O
2
Tietomallisuunnittelun koordinoimisen tehtävätaulukko
Projekti:
YA-432101234 Esimerkki
TELU2012: ARK12 C2, D3
TELU2012: PS12 C4.1
TELU2012: PS12 C.4.4
ml. kohdistusobjekti
TELU2012: PS12 D4
TELU2012: PS12 D4
TELU2012: PS12 D4
T
E
H
T
Ä
V
Ä
T
M
A
L
L
I
E
N
Y
H
D
I
S
T
Ä
M
I
N
E
N
J
A
K
O
O
R
D
I
N
O
I
N
T
I
Hankkeessa käytettävien
tarkastussäännöstöjen määrittäminen (Solibri)
Tietomallitoimitusten valvonta: mallijulkaisujen
dokumentointi ja julkaisuajankohdat
Mallien tietosisällön valvonta: Sovittu
tietosisältö julkaisuhetkellä/hankevaiheessa
Tietomallien revisiovertailut mallijulkaisuiden
yhteydessä projektipankkiin
Suunnittelualakohtaisten mallien
yhdistämisedellytysten toteaminen
Mallien yhdistäminen tarkastuspisteissä
Yhdistelmämallin visuaalinen tarkastus
virheiden raportointi
Yhdistelmämallin tarkastaminen sovituilla
säännöstöillä
virheiden raportointi
Solibri-esityksen laatiminen yhdistelmämallin
virheistä
Kommenttien kerääminen osapuolilta ja
päivittäminen esitykseen ennen yhteistä
läpikäyntiä (bcfzip-muodossa Solibrilla)
Tarkastusraportin tulostaminen ja julkaisu
yhdistelmämallista
Yhdistelmämallin julkaisu projektipankkiin
Solibri-esityksen päivittäminen ja ylläpito
virheiden osalta yhteisen läpikäynnin jälkeen
Raportoitujen virheiden luokittelu esityksen
päivättämisen yhteydessä
Virheetön yhdistelmämalli: raportoitujen
virheiden korjaamisen valvonta
Tietomallipalaverit / tietomalliasioiden käsittely
palavereissa
Uudet, avoimet,
vaikutuksettomat, korjatut, kts.
Liite 2
1 (9)
Yhdistelmämallin ja esityksen luominen (tietomallikoordinaattori)
Suunnittelijat julkaisevat mallinsa IFC- ja natiivimuodossa projektipankkiin sovittuina
ajankohtina. Tietomallikoordinaattori varmistaa että suunnittelijat julkaisevat mallijulkaisujensa yhteydessä tietomalliselostuksen ja että mallit ovat yhdistettävissä. Tähän
kuuluu hankkeen alkuvaiheessa esimerkiksi yhtenevän suunniteltukoordinaatiston ja
lohkojaon tarkistaminen. Mahdollisista mallien puutteista annetaan palaute aina suunnittelijoille, jotka korjaavat puutteet natiivimalleihinsa ja tuottavat uuden IFC-mallin.
Yhdistelmämalli luodaan Solibri Model Checker -ohjelmalla tuomalla projektipankista
ladatut IFC-tiedostot Tiedosto-välilehden Avaa-toiminnolla. IFC-tiedostojen tuomisen
yhteydessä avautuu ikkuna, josta asetetaan suunnittelualakohtaisille malleille oikeat
suunnittelualat ja havainnolliset lyhenteet.
Kuva 1. IFC-tiedostojen tuonti Solibriin.
Mallien lisäyksen jälkeen asetetaan Tiedosto-välilehdeltä Päivitä malleja -kohdasta kansio, johon projektipankista tuodut, uusimmat suunnittelualakohtaiset IFC-mallit tallennetaan julkaisujen yhteydessä. Asetettava kansio sijaitsee fyysisesti tietomallikoordinaattorin tietokoneella tai yhteisellä verkkolevyllä. Mallien päivittäminen on tärkeää
asettaa tarkastamisen helpottamiseksi: Uusina virheinä tarkastuksessa näkyvät jatkossa
vain ne virheet, joiden osalta suunnittelijat ovat päivittäneet mallejaan. Tämä vähentää
merkittävästi tietomallikoordinaattorin työtä. Suositeltavaa on käyttää Päivityskehotusvalintaa, jolloin Solibri varmistaa aina käyttäjältä uusien mallien tuonnin.
Liite 2
2 (9)
Kuva 2. Mallien päivityskansion asettaminen.
Tietomallikoordinaattori tarkastaa yhdistelmämallin ohjelmallisesti projektin alussa
määritellyillä tarkastussäännöstöillä, sekä visuaalisesti ”kävelemällä” mallin läpi. Ohjelmallinen tarkastus suoritetaan Solibri Model Checkerin Tarkastus-välilehdellä, jossa
tarkastussäännöstön esille tuomat virheet luokitellaan Tulokset-listasta hiiren oikealla
napilla hyväksytyiksi tai hylätyiksi.
Kuva 3. Virheiden hyväksyminen ja hylkääminen.
Korjausta vaativat virheet asemoidaan havainnolliseen kuvakulmaan. Visualisoinnin
apuna virheen esilletuomisessa voi käyttää merkintä- ja leikkaustyökaluja. Uusi esitys
Liite 2
3 (9)
luodaan ensin Kommunikointi-välilehdellä Uusi esitys -valinnasta, jonka jälkeen esitykseen lisätään kalvoja Uusi ilmoitus -valinnalla. Aukeavaan ikkunaan syötetään virheen
sisältöä kuvaava kommentti. Kommentin eteen on hyvä syöttää virhettä koskevien
suunnittelualojen lyhenteet, esimerkiksi ARK vs. LVI.
Kuva 4. Ilmoituksen luominen.
Suoritettuaan tarkastuksen tietomallikoordinaattorilla on alustava esitys virheistä. Tietomallikoordinaattori tallentaa esityksen projektipankkiin 2-3 päivää ennen yhdistelmämallipalaveria ja lähettää suunnittelijoille tiedon sähköpostilla.
Tietomallikoordinaattorin tarkastuksen kommentointi (suunnittelijat)
Yhdistelmämallien kommentointi edellyttää että suunnittelijat ottavat käyttöönsä vähintään Solibri Model Viewerin, joka on ladattavissa ilmaiseksi Solibrin www-sivuilta. On
tärkeää varmistaa, että kaikilla projektin osapuolilla on käytössään sama Solibri-versio,
joka on määritelty projektin tietomalliohjeessa. Ensimmäisellä käynnistyskerralla projektin osapuolet asettavat Tiedosto-välilehdeltä kohdasta Yleistä käyttäjäkohtaiset perustiedot. Perustiedoissa voidaan käyttää nimikirjaimina myös suunnittelualojen lyhenteitä.
Liite 2
4 (9)
Kuva 5. Käyttäjän perustiedot Solibri Model Viewerissä.
Saatuaan tiedon yhdistelmämallin alustavasta julkaisusta suunnittelijat lataavat yhdistelmämallin projektipankista ja avaavat sen Solibri Model Viewerillä.
Suunnittelijat käyvät läpi Kommunikointi-välilehdellä tietomallikoordinaattorin esityksen, ja kommentoivat omaa suunnittelualaansa koskevia virheitä. Kommentointi suoritetaan viemällä osoitin Esitys-näkymän ilmoituslistassa olevan ilmoituksen päälle ja painamalla hiiren oikeaa nappia. Avautuvasta ponnahdusikkunasta valitaan kohta Muuta
ilmoitusta. Avautuvasta ikkunasta lisätään ilmoitukseen kommentti painamalla kommenttialueen vieressä olevaa Lisää-painonappia. Kommenttia on mahdollista muokata
myöhemmin Muokkaa-painonapista, mutta vain omien kommenttien muokkaaminen on
mahdollista.
Liite 2
5 (9)
Kuva 6. Lisätyn kommentin edessä näkyy kommentoijan nimikirjaimet ja kommentin
lisäyspäivämäärä.
Suoritettuaan tietomallikoordinaattorin ilmoitusten kommentoinnin, suunnittelija tallentaa
kommenttinsa
Kommunikointi-välilehden
yläreunassa
olevasta
Raportoi-
painikkeesta. Kommentit tallentuvat avoimessa BCFzip-muodossa. Tallennettu tiedosto
on tiedostokooltaan hyvin pieni, joten se voidaan lähettää tietomallikoordinaattorille
esimerkiksi sähköpostin liitetiedostona.
BCFzip (Bim Collaboration Format zip) on Solibrin ja Teklan yhteistyössä kehittämä
avoin tiedonsiirtostandardi, jonka käyttöönottoon on osallistunut useita ohjelmistotaloja,
mm. Autodesk.1 Teoriassa tietomallikoordinaattorin esitysten kommentointi on mahdollista myös muilla formaattia tukevilla ohjelmistoilla, kuten Tekla BimSightilla, mutta
käytännössä tällä hetkellä kommentit eivät siirry ohjelmasta toiseen virheettömästi, johtuen formaattirajapintojen implementoinnista ohjelmistoihin. Tämän vuoksi kaikkien
projektin osapuolien on syytä käyttää kommentointiin Solibri Model Vieweriä tai
Checkeriä.
1
Eastman. 2011. s. 134
Liite 2
6 (9)
Kommenttien päivittäminen ja yhdistelmämallin julkaisu (tietomallikoordinaattori)
Saatuaan suunnittelijoiden kommentit bcfzip-muodossa, tietomallikoordinaattori päivittää ne esitykseensä Kommunikointi-välilehdellä painamalla päivitettävää esitystä hiiren
oikealla napilla. Avautuvasta ponnahdusvalikosta valitaan Päivitä esitys BCFtiedostosta ja avataan suunnittelualojen lähettämät bcf-tiedostot yksitellen.
Kuva 7. Kaikkien suunnittelualojen kommentit päivitettyinä tietomallikoordinaattorin
esitykseen.
Kommenttien päivityksen jälkeen tietomallikoordinaattori luo tarkastusraportin Tarkastus-välilehdellä Raportoi-valinnasta. Raportti luodaan kuvassa 8. näkyvillä valinnoilla.
Tarkastusraportti tallentuu Excel-muodossa ja siitä saadaan yleiskuva suunnittelualakohtaisten IFC-tiedostojen julkaisuajankohdista sekä tietomallikoordinaattorin käyttämistä tarkastussäännöstöistä ja virheluokitteluista. Halutessaan tietomallikoordinaattori
voi kirjoittaa yleiskuvauksen tarkastuskohtien tilasta tarkastusraportin kommenttikenttään. Esimerkki Solibrilla luodusta tarkastusraportista on esitetty diplomityön liitteessä
3.
Tietomallikoordinaattori julkaisee kommenteilla päivitetyn yhdistelmämallin sekä luodun tarkastusraportin projektipankkiin ennen yhdistelmämallipalaveria.
Liite 2
7 (9)
Kuva 8. Tarkastusraportin luominen
Esityksen luokittelu (tietomallikoordinaattori)
Suunnittelijoiden kommentoitua tietomallikoordinaattorin tarkastuksen ennen yhteistä
palaveria, ajankäyttö voidaan kohdistaa paremmin suunnittelijoiden yhteistoimintaa
vaativiin ongelmiin, suunnittelualakohtaisten puutteiden sijaan. Tietomallikoordinaattorin tarkastuksen läpikäyntiä johtaa kokouksessa pääsuunnittelija, joka lisää kommentit
ja korjausten vaatimat toimenpiteet esitykseen. Tarvittaessa pääsuunnittelija voi lähettää
kommentit tietomallikoordinaattorille bcfzip-muodossa, mutta on suositeltavaa että
myös tietomallikoordinaattori osallistuu yhdistelmämallipalaveriin ja lisää kommentit
suoraan palaverissa. Sovitut korjaustoimenpiteet ja esille tulleet ongelmat pyritään ratkaisemaan seuraavaan palaveriin mennessä. Vastuu siitä, että tarvittavat korjaukset tulee
tehdyksi, on pääsuunnittelijalla.
Ennen seuraavaa palaveria suunnittelijat julkaisevat projektipankkiin IFC-muodossa
seuraavat revisiot malleistansa, joiden pohjalta tietomallikoordinaattori päivittää yhdistelmämallin (kts. Yhdistelmämallin ja esityksen luominen) ja tarkastaa uudet suunnitelmaristiriidat.
Tietomallikoordinaattori luo Kommunikointi-välilehdellä Uusi esitys-toiminnolla seuraavat esitykset, joihin ilmoitukset jatkossa luokitellaan:
-
Uudet
Liite 2
8 (9)
o Suunnittelukokousvälillä mallien päivittämisen myötä ilmenneet uudet
virheet, jotka luodaan luokittelun alle Uusi ilmoitus -valinnalla
-
Avoimet
o Tietomallikoordinaattorin aikaisempiin suunnittelukokouksiin raportoimat virheet, joita ei ole suunnittelukokousvälillä ratkaistu
-
Vaikutuksettomat
o Virheet, jotka eivät vaikuta rakennettavuuteen tai asennettavuuteen, eivätkä aiheuta välittömiä toimenpiteitä (siirretään omaan esitykseen, jotta
niihin voidaan palata tarpeen mukaan myöhemmin)
-
Korjatut
o Virheet jotka on korjattu suunnittelukokousvälillä tai aikaisemmin (jotta
niihin voidaan tarpeen vaatiessa myöhemmin palata)
Ilmoituksia siirretään luokittelusta toiseen painamalla siirrettävää ilmoitusta hiiren oikealla napilla ja valitsemalla Leikkaa-toiminto. Tämän jälkeen valitaan Esitys-kentästä
luokittelu, johon ilmoitus on tarkoitus siirtää. Ilmoitus liitetään valittuun luokitteluun
painamalla ilmoituslistakentässä hiiren oikeaa nappia ja valitsemalla Liitä-toiminto.
Tällä hetkellä on mahdollista siirtää kommentteja BCFzip-muodossa vain yhdestä esityksestä kerrallaan, joten suunnittelijoiden tulee siirtää kommentit erikseen Uudet-,
Avoimet-, Vaikutuksettomat- ja Korjatut-luokitteluista tietomallikoordinaattorille, mikäli niihin tulee kirjauksia.
Liite 2
Kuva 9.
9 (9)
Liite 3
Liite 4
1 (3)
Arkkitehtimallin muutosten visualisoinnin suoritus
Tiedosto-välilehdellä avataan ensin vanhempi vertailtavista IFC-malleista, sitten uudempi. Avautuvasta ikkunasta mallit nimetään Lyhenne-kohdassa niin, että julkaisut
voidaan erottaa toisistaan.
Kuva 1. Mallien julkaisurevisioiden nimeäminen
Tarkastus-välilehdellä valitaan Tarkastus-listan yläreunassa oleva kansiokuvake. Avautuvasta ikkunasta valitaan Lisää säännöstöjä -painike, josta avataan säännöstö Mallien
revisioiden vertailu – arkkitehti.
Liite 4
2 (3)
Kuva 2. Tarkastussäännöstön valinta.
Tämän jälkeen valitaan Tarkastus-listan yläreunasta painike Tarkasta ja odotetaan että
Solibri suorittaa tarkastuksen.
Säännöstö luokittelee revisioiden väliset muutokset lisättyihin, poistettuihin ja muutettuihin objekteihin. Myös arkkitehtimallin tilojen muutoksille suoritetaan vertailu. Tarkastuksen tuloksia selataan Tulokset-listassa. Valitsemalla tarkastuslistassa yksittäisiä
muutoksia, nähdään Info-sarakkeessa tarkka kuvaus, miten objektia on muutettu. Aiemman mallirevision objektit näkyvät tarkastustuloksissa punaisina ja uuden revision
sinisinä. Revisiovertailu voidaan tallentaa smc-tiedostomuodossa esimerkiksi projektipankkiin, ja sen tulosten visuaaliseen tarkasteluun ja tarkastusraportin tutkimiseen on
mahdollista käyttää myös ilmaista Solibri Model Vieweriä.
Liite 4
3 (3)
Kuva 3. Revisiovertailusta voidaan havaita, että alakattokorkoa on laskettu edellisestä
mallirevisiosta.
Kuva 4. Muutoserittely tarkastuksen Info-kentässä.

aalto-yliopisto suunnitelmien yhteensovittaminen ja

Transcription

Similar documents

Laadukas suunnittelu entistä tärkeämpää

Eriste- ja kulutuskerroksena käytettävä tiivis

Tietomallintamisen aiheuttamat muutostarpeet suurten

Urheilijat hallista hankeen

Diplomityö, Sakari Tohmo - Tampereen teknillinen yliopisto

Käyttöohje

P-News nro 1/2010