aalto-yliopisto suunnitelmien yhteensovittaminen ja
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 Eastman, C. et al. 2011. s. 2 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 Penttilä, H. et al. 2006b. s. 9 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. Eastman, C. et al. 2011. s. 139 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 Penttilä, H. et al. 2006b. s. 38 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 Eastman, C. et al. 2011. s. 157 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. rakenne- ja 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 Eastman, C. et al. 2011. s. 272 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 Eastman, C. et al. 2011. s. 272 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 Uusitalo, H. 2013. s. 42 YTV2012, Osa 7. 3 Uusitalo, H. 2013. s. 25 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 rakenne- ja 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 Pääsuunnittelija/Arkkitehti 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 Pääsuunnittelija/Arkkitehti 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 Penttilä, H. et al. 2006a. 2 50 Lähtötiedot: Ehdotussuunnittelun valittu tilamalli, alustava rakennemalli, tilavarausmalli Vaiheen tuotokset: Alustava rakennusosamalli Rakennesuunnittelija 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. RAKLI ry. TELU2012, TATE 12. 3 RAKLI ry. TELU2012, TATE 12. 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. Pääsuunnittelija/Arkkitehti 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) Rakennesuunnittelija Toteutussuunnitteluvaiheessa rakennesuunnittelijan tietomallin tulee vastata arkkitehtimallia ja malli kehitetään rakentamisvaiheen tarkennuksia lukuun ottamatta toteutustar1 YTV2012, Osa 3. Penttilä, H. et al. 2006a. 3 Penttilä, H. et al. 2006a. 4 Penttilä, H. et al. 2006a. 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-, rakenne- ja 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- Pää/arkkitehtisuun Rakennesuunnittelija dinaattori nittelija (toimi Kustannusinsinööri myös hankkeen tie- LV-suunnittelija (puhelinkeskuste- tomallikoordinaat- IV-suunnittelija lu) torina) Sähkösuunnittelija TATE-urakoitsijat Pää/arkkitehtisuun 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 Anttonen. Haastattelu, Helsinki 28.6.2013 Anttonen. Haastattelu, Helsinki 28.6.2013 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 Varstala. Haastattelu, Helsinki 27.8.2013 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 3.3.2.1 Kastellin monitoimitalo 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 Häkkinen. Haastattelu sähköpostin välityksellä. 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. 3.3.2.2 Järvenpään Vilja 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 Mäenpää. Haastattelu 25.6.2013 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 Varstala. Haastattelu, Helsinki 27.8.2013 Pohjantien koulun suunnittelun palautekeskustelu, Kuopio. 5.9.2013 3 Pohjantien koulun suunnittelun palautekeskustelu, Kuopio. 5.9.2013 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 3.3.3.1 Kastellin monitoimitalo 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 Anttonen. Haastattelu, Helsinki 28.6.2013 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. 3.3.3.2 Järvenpään Vilja 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 Anttonen. Haastattelu, Helsinki 28.6.2013 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 Mäenpää. Haastattelu 25.6.2013 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 Varstala. Haastattelu, Helsinki 27.8.2013 Varstala. Haastattelu, Helsinki 27.8.2013 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 Varstala. Haastattelu, Helsinki 27.8.2013 Anttonen. Haastattelu, Helsinki 28.6.2013 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 Pohjantien koulun suunnittelun palautekeskustelu, Kuopio. 5.9.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 Mäenpää. Haastattelu, Hyvinkää 25.6.2013 Konola. Haastattelu 5.6.2013 3 Varstala. Haastattelu, Helsinki 27.8.2013 4 Mustalammi. Puhelinhaastattelu 13.6.2013 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 Virit, Partanen. Haastattelu, Helsinki 26.8.2013 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 Virit, Partanen. Haastattelu, Helsinki 26.8.2013 Mäenpää. Haastattelu, Hyvinkää 25.6.2013 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 Virit, Partanen. Haastattelu, Helsinki 26.8.2013 Konola. Haastattelu 5.6.2013 3 Anttonen. Haastattelu, Helsinki 28.6.2013 4 Häkkinen. Haastattelu sähköpostin välityksellä. 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 Mustalammi. Puhelinhaastattelu 13.6.2013 Pietiläinen, Westerlund, Sund. Haastattelu, Järvenpää 31.5.2013 3 Mustalammi. Puhelinhaastattelu 13.6.2013 4 Mustalammi. Puhelinhaastattelu 13.6.2013 5 Pietiläinen, Westerlund, Sund. Haastattelu, Järvenpää 31.5.2013 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 Pohjantien koulun suunnittelun palautekeskustelu, Kuopio. 5.9.2013 Varstala. Haastattelu, Helsinki 27.8.2013 3 Pohjantien koulun suunnittelun palautekeskustelu, Kuopio. 5.9.2013 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 Mäenpää. Haastattelu, Hyvinkää 25.6.2013 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 Varstala. Haastattelu, Helsinki 27.8.2013 3 Pohjantien koulun suunnittelun palautekeskustelu, Kuopio. 5.9.2013 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 Pohjantien koulun suunnittelun palautekeskustelu, Kuopio. 5.9.2013 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 Anttonen. Haastattelu, Helsinki 28.6.2013 3 Anttonen. Haastattelu, Helsinki 28.6.2013 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. Mäenpää. Haastattelu, Hyvinkää 25.6.2013 Varstala. Haastattelu, Helsinki 27.8.2013 3 Anttonen. Haastattelu, Helsinki 28.6.2013 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 Mäenpää. Haastattelu, Hyvinkää 25.6.2013 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 Virit, Partanen. Haastattelu, Helsinki 26.8.2013 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 Kerosuo, H. et al. 2013a. s. 2 4 Lavikka, R. 2013 et al. s. 5 5 Lavikka, R. 2013 et al. s. 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 Kerosuo, H. et al. 2013a. s. 3 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 Kerosuo, H. et al. 2013a. s. 2 Kerosuo, H. et al. 2013a. s. 3 3 Kerosuo, H. et al. 2013a. s. 4-5 4 Kerosuo, H. et al. 2013a. s. 6 5 Lavikka, R. 2013 et al. s. 9 6 Lavikka, R. 2013 et al. s. 9 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 Lavikka, R. 2013 et al. s. 11 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. COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 2: Lähtötilanteen mallinnus. Versio 1.0. 25 + 7 s. COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 3: Arkkitehtisuunnittelu. Versio 1.0. 24 s. 132 COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 4: Talotekninen suunnittelu. Versio 1.0. 42 + 14s. COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 5: Rakennesuunnittelu. Versio 1.0. 19 + 9 s. COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 6: Laadunvarmistus. Versio 1.0. 26 s. COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 7: Määrälaskenta. Versio 1.0. 24 s. COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 8: Havainnollistaminen. Versio 1.0. 14 s. COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 9: Mallien käyttö talotekniikan analyyseissa. Versio 1.0. 15 s. COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 10: Energia-analyysit. Versio 1.0. 19 + 3 s. COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 11: Tietomallipohjaisen projektin johtaminen. Versio 1.0. 24 + 3 s. COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 12: Tietomallien hyödyntäminen rakennuksen käytön ja ylläpidon aikana. Versio 1.0. 22 s. COBIM -hankkeen osapuolet. 2012. YTV Yleiset tietomallivaatimukset 2012 Osa 13: 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 Pohjantien koulun suunnittelun palautekeskustelu, Kuopio. 5.9.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ä.
© Copyright 2024