AALTO-YLIOPISTO Insinööritieteiden korkeakoulu Rakenne- ja rakennustuotantotekniikan koulutusohjelma Rakennusmateriaalit ja tuotantotekniikka

Transkriptio

1 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

2 Aalto-yliopisto, PL 12100, AALTO Diplomityön tiivistelmä Tekijä Jaakko Kinnari Työn nimi Suunnitelmien yhteensovittaminen ja tiedonvaihdon tarpeet tietomallinnetussa rakennushankkeessa Laitos Rakennustekniikan laitos Professuuri Rakentamistalous Työn valvoja Professori (ma.) Arto Saari Työn ohjaaja(t)/työn tarkastaja(t) DI Annikki Karppinen, Lemminkäinen Talo Oy Professuurikoodi Rak-63 Päivämäärä Sivumäärä 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

3 Aalto University, P.O. Box 12100, FI AALTO 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 Thesis supervisor Professor (acting) Arto Saari Code of professorship Rak-63 Thesis advisor(s) / Thesis examiner(s) M.Sc. (tech.) Annikki Karppinen, Lemminkäinen Talo Oy Date Number of pages 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

4 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 Jaakko Kinnari

5 5 Sisällys 1 Johdanto Tutkimuksen tausta Tutkimusongelma ja tavoitteet Tutkimuksen rajaus Kirjallisuusselvitys Tietomallipohjaisen suunnittelun lähtökohdat Tietomallipohjaisen suunnittelun erot perinteiseen rakennushankkeeseen Mallintamisen tavoitteiden määrittely Tietomallihankkeen koordinointi ja osapuolten vastuut Yhdistelmämallien käyttö tietomallinnetussa rakennushankkeessa IFC-tiedonsiirtostandardi Natiivimallit Tiedonsiirto projektissa ja mallien yhdistäminen IFC- ja yhdistelmämallien käyttökohteet Tietomallinnetun hankkeen vaiheet ja tietomallien tietosisällöt Tarveselvitys ja hankesuunnittelu Ehdotussuunnittelu Yleissuunnittelu Toteutussuunnittelu Rakentaminen Haastattelututkimus kohdeyrityksessä Tutkimusmenetelmät ja tutkimusaineisto Case-kohteiden tarkastelu Kastellin monitoimitalo Järvenpään Vilja... 60

6 Pohjantien koulu Haastattelut case-kohteissa Suunnitteluun varattu aika Suunnittelun kokouskäytännöt Suunnitteluaikataulut ja tiedonvaihtotarpeiden tarkentaminen suunnitteluaikataulusta Mallinnusaineisto ja mallien hyödyntämisen määrittely projektin alkuvaiheessa Projektipankki ja muut tiedonsiirto- ja kommunikointivälineet Mallien päivitystiheys Tietomalliselostus Suunnitelmien valmiusaste ja suunnitelmamuutokset Tietomalleista tuotetut suunnitelmat Suunnittelijoiden omat laadunvarmistusmenettelyt Tietomallikoordinaattorin rooli Reikä- ja varaussuunnittelu Alakattosuunnittelu Muut tiivistä tiedonvaihtoa vaativat suunnittelutehtävät IFC-tiedonsiirtoformaatin ongelmat Muiden suunnittelualojen mallien hyödyntäminen As-built mallien tuottaminen Mallien luovuttaminen natiivimuodossa Keskeiset tulokset ja toiminnan kehitysehdotukset Ajallisen hallinnan ja suunnittelutiedonvaihdon erityiskysymykset Tietomallien koordinoimisen tehtävien jakaminen osapuolten tarpeiden mukaan Mallien julkaisuprosessin kehittäminen... 99

7 Muutosten tiedottaminen ja visualisointi Yhteistoimintaa vaativien suunnittelutehtävien ohjeistukset Mallien hyödyntämisen näkökulma laadunvarmistuksessa Solibrin tarkastussäännöstöt Solmutyöskentelyn mahdollisuudet yhteistoimintaa ja ongelmanratkaisua vaativissa suunnitteluvaiheissa Tutkimustulosten arviointi Keskeisten tulosten suhde aiempaan tietoon Tulosten luotettavuus Tulosten yleistettävyys Johtopäätökset Jatkotutkimusmahdollisuudet Lähteet 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 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 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

10 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 11 2 Kirjallisuusselvitys 2.1 Tietomallipohjaisen suunnittelun lähtökohdat 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 RT Eastman, C. et al s Penttilä, H. et al s Eastman, C. et al s. 2

12 12 Kuva 1. Tietomallinnetun ja perinteisen hankkeen väliset erot tietovarannon kertymisen ja suunnittelupanoksen aikaistumisen näkökulmista. Lähteet: Rakennustieto Oy RT , Eastman, C. et al 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 RT Penttilä, H. et al. 2006b. s. 9 3 Penttilä, H. et al. 2006b. s. 9 4 Penttilä, H s. 347

13 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 YTV 2012, Osa 1. 3 YTV2012, Osa 11.

14 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 Tietomallihankkeen koordinointi ja osapuolten vastuut 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. 2 YTV2012, Osa 1. 3 YTV2012, Osa 6.

15 15 nettelyin. Laadunvarmistuksen lisäksi tilaajan tulee valvoa että mallien tietosisällöt ja vaatimukset vastaavat sopimuksia ja aikatauluja kussakin hankkeen vaiheessa 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 s. 78

16 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 vastuulla 1, 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 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. 2 YTV2012, Osa YTV2012, Osa 6. 4 RakMK A

17 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 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 A

18 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 useasti 1 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 Yhdistelmämallien käyttö tietomallinnetussa rakennushankkeessa 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 Tuuhea, S s buildingsmart International, Viitattu:

19 19 Kuva 2. IFC-tiedonsiirto. Lähde: RAKLI ry 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 Versiot eivät ole keskenään täysin yhteensopivia, joten pro- 1 Penttilä, H. et al. 2006b. 2 Eastman, C. et al s buildingsmart International, Viitattu:

20 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 s Penttilä, H. et al. 2006b. 3 Niemi, H s van Berlo, L. A. H. M s. 5 5 Penttilä, H. et al. 2006b. s. 38

21 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 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 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 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 YTV2012, Osa YTV2012, Osa 1.

23 23 Kuva 4. Mallien tiedonsiirto. Kuvassa nuolet kuvaat tiedon kulun suuntaa. Lähde: van Berlo, L. A. H. M 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 muu- 1 YTV2012, Osa 6.

24 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 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 Niemi, H Niskakangas V

25 25 Kuva 5. Mallien julkaisu Lemminkäinen Talo Oy:ssä. Lähde: Niemi, H 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

26 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 YTV2012, Osa 3. 2 YTV2012, Osa 3.

27 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 IFC- ja yhdistelmämallien käyttökohteet 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 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. 2 YTV2012, Osa 8. 3 YTV2012, Osa 8. 4 Aaltonen, M s YTV2012, Osa 8.

29 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: 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 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 31 Kuva 7. Mallinkatseluohjelmilla voidaan esimerkiksi tarkastella huoltoreittien mitoitusta ylläpitojaksoa varten. Kastellin monitoimitalo, Oulu. Suunnittelutilanne 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 s YTV2012, Osa 8. 3 Palos, S s. 25

32 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 ), 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 s Lemminkäinen Talo Oy. BIM-SLU1 Tietomallien käyttö suunnittelussa. Sisäinen dokumentti. 3 YTV2012, Osa 8.

33 33 Kuva 8. Arkkitehdin tilaryhmämalli. Kastellin monitoimitalo, Oulu. Suunnittelutilanne

34 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 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. Vakiin- 1 Lemminkäinen Talo Oy. BIM-SLU8 Yhdistelmämallin käyttö suunnittelun ohjauksessa. Sisäinen dokumentti.

35 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 s Betoniteollisuus Ry, Viitattu: Järvinen, T. Blogi: Viitattu:

36 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 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 YTV2012, Osa 6. 2 Niemi, H s. 88

37 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 ). 1 Kuva 11. Kastellin monitoimitalon 1. lohkon visuaalinen tarkastelu, alakatot piilotettuna. Kastellin monitoimitalo, Oulu. Suunnittelutilanne 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 Niemi, H s Eastman, C. et al s. 272

38 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 s esim. Gijezen, S. et al s. 4 3 YTV2012, Osa 6.

39 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 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 s. 42

40 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 s YTV2012, Osa 7. 3 Uusitalo, H s. 25

41 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 Karhu, V. et al S

42 42 Kuva 14. Tietomallit hankkeessa vaiheittain. Lähde: YTV2012, Osa 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 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 YTV2012, Osa YTV2012, Osa 3. 4 Penttilä, H. et al. 2006a. 5 YTV2012, Osa 11.

44 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 YTV2012, Osa 1. 3 Niskakangas, V

45 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. 2 YTV2012, Osa 3. 3 YTV2012, Osa 5. 4 YTV2012, Osa 5.

46 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. 2 YTV2012, Osa YTV2012, Osa 4. 4 YTV2012, Osa 4. 5 YTV2012, Osa 9.

47 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 Yleissuunnittelu Kuva 17. Tiedonvaihto yleissuunnitteluvaiheessa.

49 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 RAKLI ry. TELU2012, TATE YTV2012, Osa 3. 4 Penttilä, H. et al. 2006a.

50 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. 2 Finnmap Consulting Oy & Rakennusteollisuus RT ry RAKLI ry. TELU2012, RAK YTV2012, Osa 4.

51 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, E- luku, 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. 2 RAKLI ry. TELU2012, TATE RAKLI ry. TELU2012, TATE YTV2012, Osa 10.

52 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. 2 YTV2012, Osa YTV2012, Osa 1.

53 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 toteutustar- 1 YTV2012, Osa 3. 2 Penttilä, H. et al. 2006a. 3 Penttilä, H. et al. 2006a. 4 Penttilä, H. et al. 2006a.

54 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 TA- TE-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. 2 YTV2012, Osa 3. 3 YTV2012, Osa 10.

55 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 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 s Yin, R. K s Yin, R. K s Yin, R. K s

57 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 s Hirsijärvi, S. et al s Yin, R. K s Yin, R. K s. 107

58 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, Oulu Järvenpään Vilja Projektipäällikkö Tuotantoinsinööri Tuotantoinsinööri Pää/arkkitehtisuun Projektijohtaja Projektipäällikkö nittelija Tietomallikoor- Pää/arkkitehtisuun Rakennesuunnitte- dinaattori nittelija (toimi lija Kustannusinsinööri myös hankkeen tie- LV-suunnittelija (puhelinkeskuste- tomallikoordinaat- IV-suunnittelija lu) torina) Sähkösuunnittelija Pää/arkkitehtisuun Rakennesuunnitte- TATE-urakoitsijat nittelija luryhmä Rakennesuunnitte- LVI-suunnittelija lijan tietomalliasiantuntija LVI-suunnittelija Sähkösuunnittelija

59 Case-kohteiden tarkastelu 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 rm 3. 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: - 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

60 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 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 rm 3. Hankeosapuolet: - Tilaaja: Lemminkäinen Talo Oy / As. Oy Järvenpään Vilja

61 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 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 m 3. 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: - Tilaaja: Kuopion kaupunki, Kuopion kaupungin tilakeskus 1

62 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 Haastattelut case-kohteissa Suunnitteluun varattu aika 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 L1- tason luonnokset arkkitehtisuunnitelmista. Tieto tarjouskilpailun voittamisesta tuli loppuvuodesta 2011 ja sopimus Oulun kaupungin kanssa piti päästä tekemään alkuvuodesta 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 raken- 1 Anttonen. Haastattelu, Helsinki

63 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 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 Anttonen. Haastattelu, Helsinki Pietiläinen, Westerlund, Sund. Haastattelu, Järvenpää

64 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 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 Mäenpää. Haastattelu, Hyvinkää Varstala. Haastattelu, Helsinki Varstala. Haastattelu, Helsinki

65 65 suunnitteluun on aiheuttanut myös korjauskohteiden yllätyksellisyys, ja aikaa on vienyt myös suunnitelmien hyväksyttäminen tilaajalla sekä osana rakennuslupaprosessia Suunnittelun kokouskäytännöt Taulukko 2. Kokouskäytännöt projekteissa kuukauden syklillä. vko vko 2 vko vko Kastellin moni- Suunnittelijoiden Suunnittelijoiden palaveri + toimitalo palaveri Suunnittelukokous Järvenpään Vilja Suunnittelukokous + yhdistelmämallin läpikäynti Pohjantien koulu LastPlanner-kokous Suunnittelukokous + yhdistelmämallin läpikäynti 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 vapaamuotoisempi 2 ja ne toimivat ensisijaisesti suunnittelijoiden yhteensovittamis- ja keskustelukanavana. Palavereissa käytiin tavanomaisesti läpi myös tietomallikoordinaatto- 1 Häkkinen. Haastattelu sähköpostin välityksellä. 2 Mäläskä. Haastattelu

66 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 Anttonen. Haastattelu Häkkinen. Haastattelu sähköpostin välityksellä. 4 Saarelainen. Haastattelu Kaakinen. Puhelinhaastattelu

67 67 tiivistä suunnittelijoiden välistä tiedonvaihtoa kokousten ulkopuolella. Projektijohtaja piti eräänä ongelmana tiedonvaihdossa suunnittelijoiden fyysistä etäisyyttä. Jos suunnittelijat olisivat samalla paikkakunnalla, tiedonvaihto voisi olla osapuolille luontevampaa. Mikäli kokousten ulkopuolella ei ole tarpeeksi tiedonvaihtoa, niissä helposti käytetään yhteistä aikaa asioihin, jotka olisivat suunnittelijoiden keskinäisesti ratkaistavissa pienemmillä porukoilla. Videoneuvottelut mahdollistaisivat kanssakäymisen lisäämistä, mutta käytännössä usein vastaan tulevat tekniset ongelmat, varsinkin jos videoneuvotteluissa pyöritellään tietomalleja, eivätkä ne siten ole aina rinnastettavissa suunnittelijoiden normaaleihin tapaamisiin Järvenpään 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 Laine Haastattelu Mustalammi. Puhelinhaastattelu Laine Haastattelu Mäenpää. Haastattelu Konola. Haastattelu

68 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 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 Pohjantien koulun suunnittelun palautekeskustelu, Kuopio Pohjantien koulun suunnittelun palautekeskustelu, Kuopio

69 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 s Suunnitteluaikataulut ja tiedonvaihtotarpeiden tarkentaminen suunnitteluaikataulusta 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

70 70 Kohteen projektijohtaja piti suunnitteluaikataulun laatimista Kastellissa erittäin haastavana, johtuen juuri koko rakennusmassan suunnittelun ja tuotantopiirrustusten suunnittelun päällekkäisyydestä. 1 Pääasiassa erityissuunnittelun aikatauluttaminen on helpompaa sillä suunnitteluratkaisut kulminoituvat yhdellä lohkolla, toisin kuin arkkitehtisuunnittelu, jota viedään eteenpäin enemmän myös kokonaisuuden ehdoilla. Haastateltavien mukaan tietomallintaminen tuo omat ongelmansa tiukassa, jatkuvasti muutoksen alla olevassa suunnitteluaikataulussa. Tuotantoon sekä kohteen tilaajan suunnitelmien hyväksyttämiseen käytetään pääasiassa 2d-suunnitelmia, jotka tuotetaan tietomalleista. Tällöin myös tietomallien tietosisällöt ja mallintamisen tarkkuustaso pitäisi pystyä määrittelemään myös osana suunnitteluaikataulua tarvittavien suunnitelmadokumenttien kautta, mikä suoraviivaisemmissa kohteissa on helpompaa. Suunnittelijat antoivat haastatteluissa esimerkkejä etenkin poikkeavista rakenneratkaisuista, joissa suunnittelua jouduttiin tekemään tästä johtuen 2D:nä. Projektin alkuvaiheessa tulisi olla aikaa miettiä, millä tarkkuustasolla mitäkin suunnitelmakokonaisuuksia kannattaa toteuttaa, ja samalla huomioida että suunnitelmien tuottaminen tietomalleista kaikilta osin ei ole kovinkaan automaattista Järvenpään 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.: - Määrä- ja kustannuslaskenta - Maanrakennustöiden tarjouspyyntöaineisto - Elementtitoimituksen tarjouspyyntöaineisto - LVIS-urakkalaskenta-aineisto - Ennakkomarkkinointi - Markkinointi 1 Anttonen. Haastattelu, Helsinki

71 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 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

72 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 Varstala. Haastattelu, Helsinki Varstala. Haastattelu, Helsinki

73 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 , 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 Anttonen. Haastattelu, Helsinki Virit, Partanen. Haastattelu, Helsinki

74 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 TATEsuunnittelijat, 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 TATEsuunnitelmista urakoitsijalle toimitti LVI-suunnittelija. 1 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 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 Kaakinen. Puhelinhaastattelu Pohjantien koulun suunnittelun palautekeskustelu, Kuopio

75 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ä 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 ilmen- 1 Mäenpää. Haastattelu, Hyvinkää Konola. Haastattelu Varstala. Haastattelu, Helsinki Mustalammi. Puhelinhaastattelu Mäläskä. Haastattelu, Oulu

76 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 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 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äiritse- 1 YTV2012: Osa 1 2 Virit, Partanen. Haastattelu, Helsinki

77 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 Magi- CAD-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 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 79 myös rakennusosittain suunnittelun valmiusasteet. He eivät kuitenkaan osanneet sanoa, tullaanko taulukko ottamaan tulevaisuudessa käyttöön 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ä 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 Virit, Partanen. Haastattelu, Helsinki Mäenpää. Haastattelu, Hyvinkää

80 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 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 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 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 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. Koh- 1 Virit, Partanen. Haastattelu, Helsinki Konola. Haastattelu Anttonen. Haastattelu, Helsinki Häkkinen. Haastattelu sähköpostin välityksellä.

83 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 LVISsuunnittelijoille, 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 Pietiläinen, Westerlund, Sund. Haastattelu, Järvenpää Mustalammi. Puhelinhaastattelu Mustalammi. Puhelinhaastattelu Pietiläinen, Westerlund, Sund. Haastattelu, Järvenpää

84 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 Varstala. Haastattelu, Helsinki Pohjantien koulun suunnittelun palautekeskustelu, Kuopio

85 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ää

86 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ää 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ää Varstala. Haastattelu, Helsinki Pohjantien koulun suunnittelun palautekeskustelu, Kuopio

87 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 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 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 jou- 1 Pohjantien koulun suunnittelun palautekeskustelu, Kuopio

89 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 IFCtiedostoista (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 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 Anttonen. Haastattelu, Helsinki Anttonen. Haastattelu, Helsinki

90 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 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, - 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. 1 Mäenpää. Haastattelu, Hyvinkää Varstala. Haastattelu, Helsinki Anttonen. Haastattelu, Helsinki

91 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 Keskeiset tulokset ja toiminnan kehitysehdotukset Ajallisen hallinnan ja suunnittelutiedonvaihdon erityiskysymykset 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ää

92 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 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 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 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 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ä tutkimuksissa 1 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

96 96 Kuva 24. Suunnittelun kokouskäytännöt osana suunnitteluaikataulun tarkentamista. Mukailtu lähteestä: Patel, A 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 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 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 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 99 Kehitetty tietomallien koordinoimisen tehtäväluettelo on esitetty liitteessä Mallien julkaisuprosessin kehittäminen Havaitut ongelmat nykyisessä julkaisuprosessissa Kuvassa 25. on esitetty haastatteluissa ilmenneet ongelmat liittyen luvussa 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 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 s. 84