Tate-mallinnus rinnakkaisen suunnittelun ja toteutuksen hankkeissa

SKOL ry, Talotekniikan toimialaryhmä on julkaissut ehdotuksen toimintamalliksi hankkeissa, joissa aletaan rakentaa ennen kuin on suunniteltu.

Tätä kutsutaan yleisesti projektinjohtourakoinniksi, mutta asia pätee myös muihin urakkamuotoihin, joissa tehdään läheistä yhteistyötä suunnittelijan ja pääurakoitsijan välillä, kuten esim. allianssihankkeet.

Speksi on ladattavissa osoitteessa:
https://skol.teknologiateollisuus.fi/fi/ajankohtaista/tate-mallinnus-rinnakkaisen-suunnittelun-ja-toteutuksen-hankkeissa

Talotekniikan toimialaryhmä on tunnistanut ongelmaksi sen, että toteutustason suunnitelmat joudutaan viemään liian pitkälle ilman selkeää ymmärrystä siitä, mitä tullaan oikeasti rakentamaan. Projektinjohtourakoitsija haluaa kilpailuttaa tate-urakoinnin kiinteällä hinnalla, jolloin he vaativat "täydellisiä" suunnitelmia vaiheessa, jossa ei ole vielä tietoa, mitä tullaan tekemään. TATE tekee siis toteutustason suunnitelmat aivan liian aikaisessa vaiheessa hanketta.

Valitettavasti TATE-suunnittelu on ravintoketjussa niin alhaisessa asemassa, että tähän vaatimukseen yleisesti suostutaan. Sen jälkeen alkaa suunnitelmien korjausrumba, kun muutetaan jo tehtyjä suunnitelmia uuden tilaohjelman / käyttäjän muutosten johdosta. Tarkkuustaso murenee käsiin ja ollaan tilanteessa, jossa suunnitelma ei enää ehkä olekaan asennuskelpoinen.

Yleissuunnitteluvaiheessa on täysin OK muuttaa kaikkea. Yleissuunnittelu on sitä, että haetaan tilannetta, jota halutaan rakentaa. Toteutusvaiheessa tätä ylellisyyttä ei voi olla olemassa.

Tästä syystä projektinjohtourakoissa pitää kunnioittaa erittäin hyvää speksiä kiinteän perusosan ja muuntuvan tilaosan periaateista (Kiiras / Kruus, esim.  SUKE seminaari vuodelta 2006:  https://skol.teknologiateollisuus.fi/sites/skol/files/SUKEseminaari0606.pdf )

Lisäksi SKOL speksissä on ensimmäiset ajatukset esivalmistettavien TATE-komponenttien suunnitteluprosessista. Tästä asiasta kuullaan varmastikin vielä lisää, kunhan ajatukset selkeytyvät asian suhteen ja päästään betoniurakoitsijoiden kanssa yhteisymmärrykseen siitä, mitä tuo tarkoittaa suunnittelu- / rakentamisprosessissa.

Suunnittelijalle tuo voi olla aivan loistava juttu. Voidaan ehkä tehdä yleissuunnitelma hieman täydennetyllä tasolla ja sen jälkeen tate-urakoitsijan / esivalmistusyrityksen kanssa yhdessä toteustason tietomalli.

Tämä on mahdollista, kun urakoitsijalle ja suunnittelijalle annetaan mahdollisuus toimia yhteistyössä.


Kuukauden kuva:

API nana ko?

Nyt alkaa rakennusalallakin näkyä sana "API" siellä sun täällä.

Huom! tämän blogin alaosassa on kaksi haastetta rakennusalalle (tiedän, että suurin osa ei jaksa lukea tätä loppuun asti...)

---

Open API ja REST API. Documented API. JSON.... jne. Näitä viljelevät ne kaverit, jotka eivät tajua mitä tuo tarkoittaa - kuten minäkin.

Olen yrittänyt opiskella APIen mahdollisuukisa tämän vuosikymmenen alusta lähtien, kun meidän firman softa-arkkitehti sellaiset minulle esitteli. Käsittääkseni / toivottavasti tämä on nyt meidän firman viimeisintä hottia:
https://designer-demo.granlunddesigner.fi/api/index

Ihan turha kysyä minulta mitä nuo tarkoittavat, mutta tiedän sen, että kun niitä lukee joku toisen firman devaaja ja hän haluaisi saada meiltä jonkun kiinteistön pumpun tiedot, niin me saadaan se hänelle toimitettua ilman yhtään ylimääräsitä työtä. Kunhan me luotetaan hänen softaan, kunhan meillä on kiinteistöomistajan oikeus jakaa se tieto.

Nyt päästään moneen herkulliseen asiaan kiinni. Saako tietoa jakaa ilman, että olemme sopineet tiedon antajan kanssa asiasta?

Mitä kun (ei jos) haemme tietoa monesta eri lähteestä ja muodostamme näistä tiedoista sellaista tietoa, jota ei ole olemassa? Onko tuo tieto meidän tietoa vai pitääkö meidän kysyä joltakin, että "Teidän tietoa on käytetty tämän tiedon tuottamiseen arviolta 12% verran. Saatte meiltä 1% alennuksen Saas -palvelustanne" ?

Esimerkki:
Haen lämpötiloja kiinteistöstä A1 olevilta toimistohuoneilta. Samalla haen ilmatieteenlaitokselta avoimen datan kautta ulkoilman lämpötiloja. Teen näiden kahden eri arvon kanssa trendikäyrän vuoden ajalta.
Sitten teen saman kiinteistölle A2 ja sen toimistohuoneille.
ja A3:selle. Ja neloselle jne.

Tiedän kaikien kohteiden pinta-alan avoimen kaupunkimallin kautta. Tiedän näiden kiinteistöjen nykyarvon. Tiedän näiden kiinteistöjen aurinkoenergiapotentiaalin avoimen datan kautta. Tiedän energiankulutuksen koska mittaamme sitä. Ja sen saan myös energialaitokselta. Tiedän sairaspoissaolot. Tiedän henkilöstön vaihtuvuuden.

Ym. tiedoista pystymme muodostamaan todella paljon uutta tietoja, joka palvelee kiinteistömassojen omistajaa. Mutta voisiko sitä tietoa jakaa myös muille? Edes anonyyminä, neliöpohjaisena tunnuslukutietona?

Jotta ym. skenaario on mahdollinen, niin tiedon pitää olla käytettävissä valituille softatoimittajille / yhteistyökumppaneille. Kukaan ei tee softaa, jos lopputuloksista pitää maksaa ensimmäisen tiedon tuottajalle. Vai maksaako?

Ensimmäisen tiedon tuottaja on triggeri, joka laukaisee koko analyysin eteenpäin. Tuosta triggeristä pitäisi olla hyötyä kaikille, jotka samaan kelkkaan lähtevät.

Ja sitten asian pihvi businessporukoille; miten tästä tehdään rahaa?
Vastaus: Lohkoketjuilla.

lämpötila / aikayksikkö = rahan arvoinen tieto.

Kun lähetän (siis joku kysyy sitä) APIn kautta lämpötilatiedon softa b:eelle, tienaan lohkoketjun kautta siitä 0,01 senttiä. Jos tämän minulta tulleen alkuperäisen lämpötilan lähettää softa  b eteenpäin soft c:lle, niin saan siitä 0,01+0,01 senttiä. jne. jne.... jne^2.
Rahantuloa ei voi estää...

Blockchainin kautta originaalin tiedon tuottaja tienaa, transaktio on jäljitettävissä ja todistettavissa automaattisesti, ilman ihmisen työtä.

Kun softa b rikastaa omalla softalla minulta saatua tietoa, ja tämä rikastettu tieto on sellaista, jota itsekin tarvitsen niin me olemme lukittauduttu toisiimme. Saan siis ilmaiseksi tietoa, jota tarvitsen jonkun toiminnallisuuden toteuttamiseksi.

Tämä tarkoittaa sitä, että kannattaa tehdä itsensä niin tarpeelliseksi, että sinun tietoja hyödyntävä softa ei pysty toimimaan jollet pysty tarjoamaan tietoa heille.

Pitää olla kaikkien kilpailijoiden paras kaveri.

Tiedon jakaminen on uusi Musta.

Tiedon jakaminen laajentaa muut softat myyntiyksiköiksi.


Haaste 1
Haastan kiinteistöomistajat jakamaan omien kiinteistöjen tietoja avoimeen rajapintaan.

Esim. €/m2 , kWh/m2 tai muilla "anonyymisillä" arvoilla. Tai jos olette todella edistyneitä, juuri niillä mittaustuloksilla, jotka olette tehneet kiinteisössä. Eli yksittäisen tilan lämpötila, kosteus, äänitaso, viihtyvyys, ilman laatu rakennuksen sisällä ja ulkopuolella...

Näin voisimme rakentaa Suomessa tietokannan, josta oikeasti tiedämme  miten eri tyyppisillä kiinteistöilä menee. Ja en tarkoita pelkkää energiaa, koska se on jo arkipäivää. Tarkoitan esim. todellisia siivouskustannuksia, käyttäjätyytyväisyyttä, vuokralaisten vaihtuvuutta, kahvinkeittimen täyttöastetta...

Ongelma 1: minne sitä tietoa talletetaan? Mikä avoin rajapinta? Missä?

Haaste 2:
Kaikki puhuu "Väylästä" jonne tieto laitetaan ja sitten se on jotenkin simbsalabBIM kaikkien käytettävissä.

Haastan rakennusalan tekemään "Väylän" vaatiman API speksit.

---
Meidän pitää sopia yhteisesti API VÄYLÄ. Ei muuta. Ei tarvitse sopia, kuka ylläpitää sitä. Ei tarvitse hypätä ylimmälle portaalle yhdellä hypyllä.

Kun API väylä on speksattu, voi softafirmat alkaa tehdä omia APEja siihen yhteensopiviksi. Vasta sen jälkeen, kun rakennusala pystyy osoittamaan yhteisen suunnana tiedon jakamisesta, voivat useat eri softatoimittajat alkaa tehdä siihen rajapintaan soveltuvia ohjelmistoja.

Tarkoitus ei ole tallettaa mitään API väylään (poislukien käyttäjien / firmojen tunnistautuminen). Tiedon tallennuksen hoitaa softat, jotka tukevat speksattua API väylää.

Kiinteistön omistaja voi valita itsellensä sopivat palveluntuottajan. Ja vaihtaa sitä toiseen, jos homma ei toimi. Uusi palveluntuottaja saadaan leivottua helposti olemassa olevaan systeemiin, sillä rajapinnat ovat tehty yhteisellä speksillä.

Rakennusalan pitää ensiksi sopia, minkälaisia API rakenteita tehdään. Siis näin yksinkertaisia speksejä koodareiden mietittäksi:
- Anna minulle kiinteistön nimi
- Anna minulle kiinteistön osoite
- Anaa minulle kiinteistön ikkunat
- Anna minulle kiinteistön ikkunat ja sen propertyt
- Anna minulle kiinteistön ikkunoiden propertyistä U-arvo
- Jaa kiinteistön ikkunat
- Jaa kiinteistöin ikkunann U-arvo
- Jaa ihan mitä vaan mitä ollaan löydetty

Ym. tarkoittaa sitä, että ei pidä määritellä, missä tieto on, vaan pitää määritellä rajapinnat.
Sen jälkeen kun olemme tehneet rajapinnat, softavalmistajat pystyvät tekemään softaa sen päälle.

Use-caset tulevat sen jälkeen, kun tiedetään, mitä tietoa on tarjolla.

Näin pääsemme avoimeen rajapintamäärittelyyn Suomen kiinteistöjen osalta. Näin saadaan softaa joka pystyy luottamaan avoimiin rajapintoihin.

Kun määrittelemme esim. buildingSMARTin kautta APIen tietosisältövaatimukset, pääsemme tasolle, jota ei muualla ole.

Ym. tekstistä päästään hienosti semanttiseen webiin, jota on tutkittu Drumbeat hankkeessa:
http://www.drumbeat.fi/
http://www.drumbeat.fi/pdf/RESTinterface.pdf


BIM Level 3 UK:ssa ei ole mitään meille Suomalaisille, me ollaan sentään jo 100 vuotiaita! Siis teinejä verrattuna britteihin, virtaa riittää.


Viikon kuva:
Suomi 100
Tosi mukavaa olla Suomalainen

Allianssien kilpailuasetelmat tarjousvaiheessa

Lensin tänään pihalle erään allianssihankkeen valmennustilaisuudesta, jossa tähdätään hyvään lopputulokseen kehitystyöpaissa ja tietenkin hankkeen voittamiseen.

Alkutilanne:
Olen mukana ryhmittymässä A, joka tarjoaa kohdetta B.
Muutaman kuukauden päästä minut kutsuttiin ryhmään C joka tarjoaa kohdetta D.

Olin ryhmän C valmennustilaisuudessa, jossa tajusin että tämän hankkeen pääurakoitsija on tarjoamassa myös hankkeen B kohdetta eri suunnittelijatiimillä.

Minulla on tässä ilmeisestikin selvä eturistiriitaongelma.

Ensimmäisen tauon jälkeen ilmoitin kaikille tästä tilanteesta. Pienen sekavuuden ja yleisen kommentoinnin jälkeen minulle tultiin kertomaan, että eturistiriita on selvä, kohteen B asioita aiotaan hyödyntää kohteen C pääurakoitsijan toimesta. Näitä suuria salaisuuksia ei voi minulle paljastaa.

Voin sanoa, että ryhmän C pääurakoitsijan ideat eivät ole välttämättä minulle ihan suuria yllätyksiä, koska olen ollut heidän kehittäjien kanssa tekemisissä viimeiset 10 vuotta, samoissa kehityshankkeissa, samoilla ajatuksilla. Olen myös ollut heitä kouluttamassa tietomallipohjaisen suunnittelun prosesseista.

Ihan looginen valinta on, että minulle ilmoitettiin olevani vapaa poistumaan valmennustilaisuudesta / ryhmän C allianssiprojektista (siis pääurakoitsijan päätöksellä, ei allianssin).

Siitä ei ollut mitään juttua, että edustamassani toimistossa on ~850 henkeä töissä. Olen lähes varma, että joku meistä on aina jossain allianssissa mukana ilman että muu firma / toisen osapulen yritys siitä tietää. Sen kyllä tiedän, että osassa projekteja allekirjoitetaan NDA -julistuksia, joita ei oltu tässä tehty - joskin se olisi ollut loppupeleissä kuitenkin aikamoista hurskastelua.

Ym. tilanne kuvaa asiaa, joka minulle ei ole tullut aikaisemmin mieleen. Kun allianssihankkeet leviävät Suomessa, niin miten niiden tekijät lukumäärällisesti riittävät? Nyt kysytään projekteihin henkilöitä nimillä, tarjouksissa. Joissakin hankkeista on aivan käsittämätön suuri rahallinen sakko sille, jos projektihenkilökuntaa vaihdetaan kesken hankkeen. Suurin piirtein pitää kuolla tai vaihtaa alaa, jos haluaa päästä eroon projektista.

Tällä hetkellä allianssit muodostetaan yleensä isoihin projekteihin. Nämä hankeet kestävät 1-5 vuotta (tai 20v, sekin on jo koettu...).

Kysymykseni on:
Miten yritykset voivat sitoa firman SKOL01-02 kaverit hankkeisiin niissä vaadituilla spekseillä viiden vuoden projektiin ilman eturistiriitoja?

Oma vastaukseni on: Ei mitenkään.

Nykyiset vaatimukset tarkoittavat sitä, että Suomessa voi olla käynnissä vain 4-8 talonrakennuksen allianssihanketta projekteissa, joiden suuruus on yli ~50M€ (täysin hatusta heitetyt numerot). Pätevyydet täyttäviä ammattilaisia ei löydy ja yritykset alkavat fiksata henkilöitä useisiin projekteihin. Tämä ei voi olla Allianssin tarkoitus. Pitää hyväksyä, että on olemassa ykkös- ja kakkosketjuja. Kukaan ei halua kolmosketjua, vaikka se voi olla "nälkäinen" ja ylittää ykkösketjun tuotokset.

Itse valitsisin kolmosketjun. Siellä on henkilöt, jotka haluavat muutosta - jota uudet toimintamallit edellyttävät. Heillä on halu näyttää, että "täältä tullaan". He ovat irti vanhoillisista metodeista, osaavat oikeasti ryhmätyön filosofian ja pitävät sitä normaalina tapana toimia hankkeissa. Kun nämä henkilöt hommataan eri firmoista niin löydetään yhteiseen hiileen puhaltava, nälkäinen nuorisojoukko - jotka ovat täysin oman alansa ammattilaisia.

Kenellekään ei pitäisi opettaa yhteistyötä, se pitää tulla sydämestä.

Sanon tämän lauseen siksi, että ryhmässä C (josta lensin pihalle) ei oltu (vielä) pääurakoitsijan toimesta ymmäretty Allianssin syvintä merkitystä - me teemme tämän yhdessä!

Pääurakoitsija tietää, mitä pitää tehdä kehitystyöpajassa mutta väitän, että he eivät ymmärrä, mitä pitää tehdä kehitystyöpajassa.

Me olemme Allianssi. Siihen kuuluu myös käyttäjä ja tilaaja.

Viitaten edellisiin kirjoittamaani blogeihin:
Rakennusala, Yhteistyötä!

Ymmärtäkää kokonaisuus.


Viikon mietelause:
Mukavinta oli, että ym. kakkoshankkeen (C) uloskävelyn jälkeen minulle tuli kahdesta eri firmasta viesti, jonkan sisältö oli yhteenvedettynä: "Olisi tuon teron tietoja / ymmärrystä voinut tässä kyllä käyttää hyväksikin..."

Vieraskynä: TATE-tietomallien käyttö työmaalla

Johanna teki alkuvuodesta osana YAMK opinnäytetyötä kyselyn Talotekniikan tietomallien käytöstä työmaalla, http://tietomalli.blogspot.fi/2016/12/osallistu-tate-tietomallikyselyyn.html

Tässä tuloksia:

---

Kyselytutkimustulokset ”TATE –tietomallien suunnittelumenetelmien kehittäminen ja mallien käyttö työmaalla”.

Kyselytutkimukseni sulkeutui virallisesti 31.1.2017 vastaajamäärän ollessa 42 vastausta. Vastauksista eroteltuna tästä porukasta 11 vastaajaa on yksiselitteisesti työmaaorganisaatioista ja 31 vastaajaa edusti erilaisia suunnittelu –tai ylläpitotehtäviä. Mielenkiintoista kyselyn tuloksista oli havaita, että niin suunnittelijoidenkin kuin työmaaväen näkemykset eivät poikenneet merkittävästi toisistaan. Tässä kirjoituksessa on lyhyt katsaus kyselyn tuloksiin. Tarkempi analysointi jää luettavaksi opinnäytteestä, joka valmistunee kesän aikana. Kiitos vielä kaikille vastaajille.

Kyselututkimuksen vastausten perusteella Talotekniikan tietomalleja käytetään niin suunnittelijoiden kuin työmaaväen osalta suunnittelun ja havainnollistamisen apuna, tormäsystarkasteluiden tuottamiseen, sekä kustannuslaskentaan. Näiden lisäksi suunnittelijat käyttävät malleja Energiasimulointien tuottamiseen, yhteensovittamiseen, markkinointiaineistojen tuottamiseen, auditointiin sekä tekniseen verkostolaskentaan. Työmaalla malleja käytetään puolestaan asennustöiden suunnitteluun ja etenemisen seurantaan, töiden ennakointiin, laadunvarmistukseen, suunnittelunohjaukseen ja valvontaan.

Kun kysyin vastaajilta mitä malleista heidän mielestään mahdollisesti tällä hetkellä uupuu, moni vastaaja korosti suojaetäisyyksien, tilavarausten, haalaus-ja huoltoreittien ja kannakkeiden puutteellista huomioimista tai malleista puuttumista. Vastauksista korostui myös eristysten puutteellinen mallinnus, joka ymmärrettävästi aiheuttaa ongelmia mm. kustannus –ja massalaskennassa. Laskentaan kuin tuotteiden (jopa väärien) käyttöön liittyen toivottiin LVI-numeroita liitettäväksi talotekniikkakomponentteihin. Vaatimusmallin käyttöä toivottiin, uskoakseni monestakin syystä koska tämän mukana siirtyy tilatiedon lisäksi mm. talotekniset mitoitusperusteet. Edellä mainittuihin löytyi komppaajia niin suunnittelijoiden kuin työmaan puolelta. Suunnittelijoiden joukosta nousi esiin em. lisäksi kappaleiden massatietojen puuttuminen. Tässä vaiheessa myönnän, että kaiken kiteyttävä vastaus oli kuitenkin ”asentajan käsi”.

Kyselyni yksi keskeisimmistä kysymyksistä oli kartoittaa vastaajien näkemyksiä siitä, pitäisikö malleista tarkastaa muutakin kuin pelkkää komponenttitörmäilyä? Mallien muu varsinainen tarkastaminen on tällä hetkellä lapsen kengissä ja käytännössä manuaalista työtä joka tehdään surffaamalla mallissa. Eikö olisi hienoa, kun voisit nappia painamalla saada ilmoituksen esimerkiksi kaikista komponenteista jotka osuvat komponentille määrätyn huoltotilan alueelle? Tai vaikkapa tarkastaa, että palohyllyjen yläpuolella k.o kerroksessa ei ole muuta tekniikkaa? Tai tarkastella, että vaatimusmalli vastaisi suunniteltua – ilman manuaalista työtä? Samaa periaatetta voi toteuttaa myös siihen, että tarkastetaan esim. että tietynlaisilla komponenteilla on määrätty tietosisältö – tätä voisikin sitten soveltaa aika laajalla spektrillä.

Ilokseni pystyin toteamaan, että lähes kaikki vastaajat toivat oman näkemyksensä esiin korostaen nimenomaan asennettavuuden ja huolto –ja haalausreittien, suojaetäisyyksien ja mitoitusarvojen tarkastamista.

Seuraavaa diagrammia tutkiessa täytyy korostaa, että ”Ei” vastaajat olivat kaikki suunnittelijapuolen edustajia, jotka korostivat pääasiassa kustannuspuolta. Urakoitsijoiden edustajista kaikki vastaajat olivat sitä mieltä, että yhteisesti sovitun aikataulun puitteissa suunnittelijan läsnäolosta olisi suuri hyöty ja se parantaisi mm. aliurakoitsijoiden kynnystä lähestyä suunnittelijaa pienemmissäkin asioissa. Hyvänä puolena pidettiin myös sitä, että asioiden selvittäminen nopeutuu ja että suunnittelija voisi samalla ylläpitää ns. ”as built” mallia, jolloin suunnitelmat vastaisivat lähes reaaliaikaisesti asennettua.  

Massalistojen käyttö urakkalaskennan apuna jakaa mielipiteitä. MagiCAD:sta tai mallista tuotetun massalistan juridista pätevyyttä ja sitovuutta kyseenalaistetaan, jonka vuoksi osa vastaajista näkee massalistan käytön enemmänkin suuntaa-antavana ja harkinnanvaraisena. Eräs LVI –ryhmänjohtaja osaa sanoa, että kertyneellä näppituntumalla putkipuolen listat ovat 60% ja IV 90% oikeassa. Putkipuolella ongelmia teettää suunnitteluohjelmiston kyky luokitella komponentteja jolloin listojen ulkopuolelle jää komponenttityypit kuten kaulus. Ohjelma ei myöskään tee eroja T-kappaleiden ja istutusten välillä, eikä erottele laippatyyppejä.

Massalistojen käyttöä pystyy kuitenkin näkemykseni mukaan laajentamaan pelkän komponenttilaskennan ulkopuolelle, vaikka sekin olisi syytä saada kuntoon. MagiCAD Bill of Materials ja Magi Export mahdollistavat hyvin yksilöllisen komponenttijaon luomisen mm. arvokkaammille verkostolaitteille. Saman pystyy tekemään IFC:stä esim. Solibri Model Checkerissä, jossa toiminto on sikäli parempi, että komponentilta löytyessä tarvittavat tiedot Solibri osaa ryhmitellä samat komponentit samalle riville. MagiCAD ei osaa.

Kyselytutkimuksesta heränneitä kommentteja voi laittaa sähköpostitse.

Johanna Lankinen

LVI-Projektipäällikkö

Granlund Oy

johanna.lankinen (at) granlund.fi

--EOF--

Bloginpitäjän huomio kohdistuu teemaan "Suunnittelija työmaalle". Suunnittelijan kohdalla asia tyrmätään ymmärrettävästi siksi, että sitä ei ole tilattu suunnittelusopimuksessa. Urakoitsija kuitenkin haluaisi saada tukea tietomallin tulkinnassa.

Mitä jos tilaaja tilaisi työmaavaiheessa nuoren, SKOL 04-05 luokan suunnittelijan työmaalle vaikkapa yhden päivän ajaksi / viikko?

Kokemuksesta tiedän, että tästä hyötyvät kaikki:

- Urakoitsija saa henkilön, joka osaa kaivaa mallista tietoja

- Urakoitsija saa heti vastauksen muutosehdotuksiin. Järjestelmien toimivuuden ja yhteensovittamisen kokonaiskuva on paremmin hallussa suunnittelijalla kuin urakoitsijalla.

- Tilaaja saa suunnitelman mukaisen asennuksen + as-built tason mallin koska sitä päivitetään yhdessä urakoitsijan kanssa. Ei enää "punakyniä".

- Nuori suunnittelija saa mielettömän mahdollisuuden olla työmaalla ja oppia miten sitä johdetaan. Mitä asentaja ajattelee, mitkä asiat ovat tärkeitä asennuksen kannalta. Seuraava kohde, jonka suunnittelija tekee, on varmasti asennettavuudeltaan parempi.

Tilaajat; miljoonahankkeessa 10.000e ei voi olla paljon.

teroj

Tiedon epävarmuus

Lähitulevaisuudessa kaikki tieto on pilvessä, ehkä myös 3d-mallit.

Tieto on hajautettu objektitasolle, kuten nyt toimitaan IFC-malleissa. Venttiili tietää olevansa venttiili ja sille on liitetty lisäinformaatiota attribuuteilla. Venttiili tulee tietämään itsestään paljon muutakin, jota ei ole sille erikseen koodattu.

Kun sanon ym. lauseen ylläpidon ammattilaisille, saan sääliviä katseita. Isoa tietomäärää ei pysty kuulemma hallitsemaan ja pikkuosilla ei ole merkitystä kokonaisuuden kannalta. Tietoa pitää pystyä päivittämään, isoa massaa on vaikea (mahdoton) hallita. Minun vastaus siihen on, että pitäisi päästä pois excelistä / perinteisistä hierarkisista tietokantanäkymistä kohti tiedonhallintaa ja sitä kautta koota iso kuva perustuen pienempiin palasiin. Tällä matkalla olen alkukuopassa, työ jatkuu.

Pitää pystyä elämään epävarmuuden kanssa.

Lisäinformaation oikeellisuudesta ei ole mitään määritelmää. Kun luovutan mallini toiselle osapuolelle, toinen osapuoli ei pysty tietämään, mikä tieto on totta, arvausta tai pahimmassa (sekä normaalimmassa) tapauksessa: "Se ohjelma vaan laittoi sen tiedon sinne".

Tässä piilee tietomallien tulevaisuuden suurin ratkaistavissa oleva ongelma.
Olemme ohittaneet sen pisteen, että suunnittelijat eivät osaa käyttää softaa.
Olemme ohittaneet sen pisteen, että mallinnettaisiin vanhalla piirustusprosessilla.
Olemme ohittaneet sen pisteen, että tilaaja ei tietäisi, miten malleja haluaa käyttää rakentamisessa.

Tietomalliselostukset, dokumentit yms. yleismaailmalliset julkilausumat eivät kerro mitään. Tiedon on oltava sisällä objektissa. Jokaisen mutterin pitää tietää minimissään oma syntymäajankohta, kuka minut suunnitelmaan sijoitti, kuka minut muutti, kuka minut deletoi. Kaikille asioille tultava ajankohta objektille. Näitä asioita ei suunnittelija objektille anna, softa hoitaa sen.

Tulemme kohtaamaan ongelmia, kun tietosisältöön ei voi luottaa. En usko, että paperilla olevat taulukkomuotoiset LoDit asiaa selvittävät. Onko se muuten Level of Details vai Development... sen kanssa saa aina hyvin kulumaan puolisen tuntia bim-palavereissa. Eräs proffa esitti, että pitäisi olla LoE, Level of Estimation -> olen valitettavasti samaa mieltä. Nämä asiat pitää olla rakennettuna softaan sisälle, pilveen koko suunnitteluryhmän käytettäväksi. Softan tulee tukea prosessia / suunnitelman kehittämistä, tiedon luonti ja oikeellisuuden arvaus ei voi olla ihmisen viitseliäisyyden varassa.

Vanha viisaus on ollut, että: "Epävarmuuden kanssa on kyettävä elämään". Miksi pitäisi arvata jotain asiaa, jos joku kuitenkin tietää oikean vastauksen? Miksei se tieto voisi olla googlemaisesti semanttisessa webissä josta löydän tiedon muutaman hakusanan avulla?

Kun tähän päästään, minulla tulee olla kyky analysoida, onko saamani tieto totta vai ei. Samalla logiikalla kuin nykyisinkin - etsin googlella tietoa, saan paljon vastauksia joista 98% on turhaa, mutta yleensä ensimmäisten kymmenen vastauksen joukossa on ratkaisu. Tai ainakin kun klikkaan ensimmäistä ratkaisua, pääsen syvemmälle uusiin mahdollisuuksiin ja sitten löydän haluamani informaation.

Iso muutos on se, että virallista, oikeaa tietoa ei ole olemassa. On vain se tieto, joka on tarjolla siinä hetkessä, kun sitä kysytään. Sillä tarkkuudella, kun se on pystytty toimittamaan ko. projektin vaiheessa.

Tähän ollaan jo otettu ensiaskeleet nykyisessä rakentamisprosessissa. On hyväksytty, että IFC-mallit talletetaan esim. viikoittain työmaan käyttöön. Muutospiirustukset laitetaan kuitenkin harvemmin, kun on tehty "isoja" muutoksia. Työmaalla on siis mahdollisimman ajankohtainen tieto IFC-malleissa, mutta piirustukset laahaavat perässä. En ole kuullut yhdeltäkään työmaalta, että tämä olisi ongelma. Muutospiirustuksia käytetään vain lisälaskujen viitteinä.

Toinen esimerkki on energiasimuloinnit. Ne kuuluu tehdä siinä vaiheessa projektia, jossa on mahdollisuus vaikuttaa rakennuksen energiakäyttäytymiseen (hankevaihe/ehdotussuunnittelu). Kukaan ei kuvittele silloin tulevan lopullisia energiankulutustietoja. Mutta saamme eri vaihtoehtojen vaikutukset selville, jonka perusteella voidaan tehdä päätöksiä etenemisestä. Siis paras käytettävissä oleva tieto siinä ajankohdassa kuin simulointi on tehty.

Tarvitsen ohjelmistoja, jotka kommunikoivat toistensa välillä pilven sisällä. Tähän tarvitsen pilviservereitä, jotka hoitavat kommunikoinnin ilman, että minä teen mitään. Minun tehtävä on syöttää parasta mahdollista tietoa pilveen Toisen projektissa mukana olevan velvollisuus on käyttää sitä tietoa, jos sattuu / haluaa sen jostain löytää.

"Jos sattuu / haluaa sen jostain löytää". Mahdoton ajatus perinteisillä sopimusmalleilla.

Viikon kuva:

Yksi näistä palloista (simuloinneista) on oikea vaihtoehto:

Matkaraportti: Norja

Kävin kääntymässä muutaman päivän Norjassa tutustumassa TATE-suunnittelun saloihin IFC:n luvatussa maassa.

Ensialkuun on todettava, että ei huhut Norjan edistyksellisyydestä ole turhia. He ovat noin valovuoden meitä edellä. Tai ehkä kaksi.

Ensimmäinen kohde oli Norconsult, http://www.norconsult.com/ jossa esiteltiin 80.000m2 toimistokohde http://fornebuporten.no/ . Jos suoraan sanotaan, niin oli ihan niin kuin meillä Suomessa oleva iso kohde. Tai ainakaan en päässyt jyvälle erinomaisuudesta.

Toisaalta, mallit, aikataulu ja budjetti oli kunnossa. Suunnittelijalla  oli hyvä yhteisymmärrys urakoitsijan kanssa. Tiedot olivat malleissa standardin mukaisissa paikoissa. Kohdetta oli kuulemma kiva suunnitella. Kaikki hilanvitkuttimet vaatimustenhallinnasta BCF-kommunikointiin oli käytössä.

Toinen kohde oli COWI, http://www.cowi.com/ jossa esiteltiin Oslon lentokentän 120.000m2 laajennusta http://www.airport-technology.com/projects/oslo-airport-terminal-2/ . Kohteen suunnittelijat ja urakoitsijat olivat lentokentän vieressä olevassa toimistorakennuksessa. Oven yläpuolella luki ”T2_Team”.

Astuin sisään toimistoon, infoscreeni löytyi aulasta ja portaiden yläpäästä avokonttori. Mentiin isoon neukkariin, jossa viriteltiin tietokoneet kuntoon ja vaihdeltiin kuulumisia. Kaikki oli kuten IPD –hankkeessa, bigroom kunnossa ja eri osapuolet saman katon alla tekemässä töitä.

Aloitimme palaverin, kaveri esitteli toimintaa hankkeessa. On se vain kummallista, että sellaiset asiat kuin yhteistyö, mallien oikeellisuus, tietosisällön standardisointi ja tiedonhallinta ovat itsestäänselvyyksiä kun kaveri esittelee kohdetta. Monta sellaista asiaa tuli eteen, jossa joku suomalainen olisi pysähtynyt ja esittänyt kuinka hienosti esim. ”ulkoseinien U-arvojen päivittäminen onnistui Revitin ja Excelin linkkauksella”. Nuo jutut oli itsestäänselvyyksiä, eivät erityisen esityksen  arvoisia.

Viikoittain käydään kuulemma läpi, mitä tehdään ensiviikolla ja miten viime viikko meni. Tarkistetaan tietotarpeet ja kerrotaan, mitä ollaan tehty.

Aloin kysellä, että miten te kutsutte tätä avokonttoria - kenties Bigroomiksi? Kaveri ei ollut koskaan kuullut termiä. Vastasi, että tämä on tiimityöskentelytila, ollaan tultu tänne viimeiset 5 vuotta duuniin.

Kysyin, onko tämä IPD tai Allianssi –projekti, jossa ydinryhmä on yhteisvastuullinen tappioista ja voitoista. Kaveri kertoi, että ei tiedä sopimustekniikasta paljoakaan, mutta sellainen käytäntö on, että jos kaikki pärjäävät, niin se näkyy hänen tilipussissa. Eli motivaatio hankkeen onnistumiselle on olemassa. Ei siis pelkästään palkkio firmalle, vaan myös hankkeeseen osallistuville työntekijöille.

Sivuhuomiona se, että hankkeeseen osallistuvien käyntikortitkin olivat hankkeeseen liittyviä – eivät siis oman firman logolla varustettuja pahvinpaloja.

Pitää myöntää, että kuka hanketta on vetänytkään, niin hienosti on onnistuttu hukuttamaan tekniset termit kuten Lean ja IPD pois henkilökunnalta. On osattu tuoda esiin ne elementit, jotka ovat yhteistoiminnalle tärkeitä ilman että ollaan kyllästetytty porukka erilaisilla lyhenteillä, kuten IPD, Lean, BIM, Last Planner jne.

Muita huomioita Norjasta:

- Vaatimustenhallinta. Molemmissa projekteissa käytössä yhteisillä ohjelmistoilla eri suunnitteluosapuolten ja käyttäjien välillä

- Energiasimuloinnit. Lämpöhäviöt, laiteluettelot jne. alkuvaiheen mitoitukset jäivät minulle mysteereiksi. Veikkaan syynä olevan se, että esittelijät olivat toteutusvaiheen kavereita. Kumpikin sanoi käyttävänsä ”rule of thumb” metodia mitoituksissa. Tuo ei voi mielestäni pitää paikkaansa, sen verran oli bimiä esityksissä. Tai sitten ymmärsin jotain väärin.

- Standardisointi. http://www.statsbygg.no/Om-Statsbygg/About-Statsbygg/ ,eli Statsbygg (paikallinen Senaatti kiinteistöt) on julkaissut vuosia sitten omat vaatimuksensa ja niitä noudatetaan yleisesti. Molemmilla firmoilla oli Revit Templatet viritetty omaan prosessin + Statsbyggin vaatimusten mukaisesti. Molemmat firmat (ja NTI CADcentral, www.nticad.no) sanoivat, että templaten tekeminen kunnolla on avain onneen. Jos oikein ymmärsin, niin mallit ovat koneluettavia.

-  Raha. Kyllähän se näkyi, mutta en millään haluaisi sanoa että: ”Onhan se helppoa kun on rahaa”. Ihmiset sitä työtä tekevät. Toisaalta, on se helpompaa kun saa ostettua mitä haluaa esim. ohjelmistolisenssien / tekniikan suhteen…

- 3D. Grafiikan erottaminen tietosisällöstä oli selviö. Eli klikkaamalla objektia tieto pitää tulla jostain pilvipalvelusta. Hienoa saada vahvistus omille luuloille – harmi vain että nämä kaverit tekevät sitä jo käytännössä.

- Yhteistyö. Vaikutti siltä, että urakoitsijan ja suunnittelijan välillä ei ollut isoa rotkoa. Molemmat ymmärsivät toisiansa, tai niin ainakin suunnittelijat minulle kertoivat.

Yritin keksiä jotain negatiivistakin tästä reissusta. Ei meinaa löytyä.

Kenties lopputulema on se, että tulen olemaan työpaikkani kallein henkilö seuraavien 1-5 vuoden aikana - liittyen prosessi-, koulutus- ja ohjelmistomuutoksiin.

 Päivän kuva:

Ilman piristeitä?

Big Room

Sana Big Room on löytynyt kiitettävällä frekvenssillä niissä tarjouspyynnöissä, joissa on panostettu yhteistyön mahdollistamiseen suunnittelu- / rakentamisprosessin aikana.

Mielestäni on havaittavissa, että tuo sana tarkoittaa eri asiaa eri henkilöillä. Sama juttu, kun puhutaan tietomallintamisesta ja "tietomallintamisesta". Kaksi henkilöä voi puhua tunnin keskenänsä huomatakseen, että tarkoittavat aivan eri asiaa, puhe etenee kuitenkin samoilla termeillä.

Tässä oma mielipiteeni siitä, mitä Big Room tarkoittaa.

Big Room on avokonttori, jossa työskentelee virtuaalinen yritys.

Big Roomiin tullaan aamulla töihin ja sieltä lähdetään kotiin työpäivän loputtua.

Big Roomissa on useiden eri firmojen henkilöitä työssä.

Big Roomin vieressä on rakennettava kohde.

Big Room ei ole työpaja. Big Room ei ole Solmutyöskentelyä ( [c] HY Cradle)

Big Roomissa voi olla työpajoja. Big Roomissa voi olla Solmutyöskentelyä

Big Room ei ole iso neukkari.

Tuon tämän asian esille, sillä vaikuttaa siltä, että normaaleja työpajoja aletaan sekoittaa Big Room työskentelyyn. Pidetään työpajat työpajoina ja yhteisissä tiloissa tehtävä työnteko erillään toisistaan.

Ym. asian sekavuuteen vaikuttanee myös se, että rakennusalalla on kokemusta vielä vähän todellisesta Big Roomista, siis siitä, missä mukana on myös urakoitsija eikä pelkästään tilaaja ja suunnittelijat. Infralla tämäkin asian on jo koeponnistettu sekä hyväksi havaittu.

Allianssin kehitysvaihe vaikuttaa olevan selvästikin työpajatoimintaa - ja hyvä niin. Parin päivän pyrähdyksiä jossa on firmojen ykkösketju tekemässä suuret linjat kuntoon. Sitten mennään omalle toimistolle ja tehdään sovitut asiat + valmistellaan seuraavan työpajan agenda.

Kun projektissa päästään eteenpäin ja aletaan tehdä toteutussuunnittelua, vaihtuu porukka ja yhteistyö muuttuu aktiivisemmaksi - läsnäoloa tarvitaan enemmän.

Talotekniikalle on erittäin tärkeää, että Big Roomissa on mahdollista tehdä myös muiden kohteiden suunnittelua. Vaatii erittäin ison kohteen, että projektinvetäjä olisi 100% siinä kiinni. Mallintavalle suunnittelijalle se ei kuitenkaan ole ongelma, ajankäyttö kohdistuu aktiivisesti kohteeseen.

Big Roomin kokoukset / työt tulee aikatauluttaa. Pitää sopia vakiokokousajat ja kuka on paikalla minäkin päivänä. Mitä ylemmälle hierarkiassa mennään, sitä vähemmän he ovat läsnä. Kun ylätason kaverien kokoustarve kartoitetaan, niin heidän työpanos saadaan osumaan täsmäiskuna aktiiviselle kohteelle.

Big Roomin tekninen varustus ja laajuus tulee aiheuttamaan alussa varmasti keskustelua. Jotta työskentely on mahdollista erikseen rakennetussa uudisrakennuksessa (malli: työmaatoimisto + vähän enemmän) tai lähistöltä löydettävissä olevassa tyhjässä kiinteistössä, sinne pitää rakentaa tietotekninen ympäristö.

On huomioitavaa, että projektipankkia ei Big Roomissa tarvita. Työskentely-ympäristö on yhteinen, tiedostot ovat hallinnassa kuten firmojen omilla servereillä on totuttu työskentelemään. Tarvitaan oikea dokumenttienhallintajärjestelmä tai ainakin yhteisesti sovittu logiikka tiedostojen tallentamiselle.

Tietotekniset asiat ovat kuitenkin helpoin asia, sillä vaikein on sosiaalisen aspektin huomioiminen. Miten yhdistää toisilleen tuntemattomat henkilöt toisiinsa - firmarajojen yli? Tiimihengen luominen vaatii monta illallista,  jääkiekko-ottelua ja museossa käyntiä.

Tietoteknisen ympäristöön liittyviä asioita ovat ainakin:
- Sisäverkko Wifillä on välttämättömyys
- Verkkotulostimet, NFC:llä, pilvitulostuksella
- Sisäinen tiedostopalvelin. Onko NAS purkki vai jotain ammattimaisempaa
- Pilvipolitiikka. Onko Google Drive/Dropbox/OneDrive/Box mahdollista käyttää? Tietoturva? Vai luodaanko esim. OwnCloud?
- Mallien jakaminen, tiimityöskentely (Tekla, Revit, ArchiCAD) (onneksi tämä ei ole edes mahdollista MagiCADillä tai CADSsillä...)
- Missä mallit fyysisesti ovat? Missä ovat natiivit "äitimallit"?
- Virallisen yhdistelmämallin sijainti Big Roomin serverillä?
- Dokumenttienhallinta? Projektipankit?
- Etätyöskentelyn mahdollistaminen. VPN vai Citrix?
- VPN: helppo
- Citrix: tietoturvallinen, personoitu, skaalautuva, paras ja kallein
- Videoneuvottelujärjestelmä, Lync vai jotain muuta?
- Smartboardeista plussaa. Ja varsinkin, jos niitä osaa käyttää muunakin kuin videotykkinä.
- Screenejä seinillä, jossa pyörii kohteen mittarointitietoja; ollaanko taloudellisessa tavoitteessa, mitä kokouksia on tulossa, mihin asiaan tulee keskittyä erityisesti, koska on seuraava sauna-ilta...
- Screeni, jossa kerrotaan kohteessa työskentelevistä ihmisistä, nimi, kuva, toimenkuva jne.
- Screeni, jossa pyörii kohteen virallinen yhdistelmämalli
- Palautescreeni, jonne voi nimettömänä tai nimellä antaa kommentteja kohteen etenemisestä, parannusehdotuksia jne.
- Kohteen www-sivut, infokanava, intra, blogi, wiki tms.


Lisäksi tulee huomioida:
- Vartiointi, hälytykset
- Tietoturvallisuus
- Tilantarve, osa porukasta on paikalla 1 pvä / vko, osa 3 ja joku aina.
- Kaikki neukkarivarustus pyörillä (isoilla). Pöydät / tuolit liikuteltavia.
- Big Roomin layout tulee muuttumaan pari kertaa työn edetessä. Alussa on hyvä sekoittaa eri suunnittelualoja, lopussa on hyvä ryhmittää samanhenkinen porukka yhteen kasaan.
- Neukkareita, hiljaisia huoneita jne. tarvitaan aina
- Min. yksi oikeasti iso neukkari.
- WC + keittiö olisi kiva
- Last Plannerille iso seinä
- Käyttäjien osallistuttaminen
- Käyttäjille tila, jossa he voivat käydä tutustumassa kohteeseen. "Showroom".


Kun kaikki ym. jutut laskee euroiksi, ollaan helposti kuusinumeroisessa luvussa, eikä ensimmäinen numero ole välillä 1-3.

Se ei tunnu missään, jos kohteen hintalappu on miljardi.

Viikon kuva:

Mittarointia ameriikan malliin

Talotekninen suunnittelija + Arkkitehti

Välillä tuntuu, että me talotekniset suunnittelijat olemme arkkitehdin pahimpia vihollisia.

Oikeasti me haluaisimme olla heidän parhaita kavereita ja auttaa heitä tekemään parasta mahdollista arkkitehtuuria parhaimmalla mahdollisella elinkaarikustannuksella, käyttäjien viihtyvyydellä sekä sisäympäristöolosuhteilla.

Ehdotussuunnitteluvaiheessa kerromme TATE-tilavarausten vaatimat tilantarpeet perustuen käyttäjän/tilaajan/arkkitehdin hyväksymään tilaohjelmaan.

Ja sitten ne tilatarpeet muodostuvat arkkitehtisuunnitelmiin iv-konehuoneina, iv-kuiluina, hormistoina jne.

Nämä tarpeet me tarkastamme ark-mallipäivityksen yhteydessä ja kuinka ollakkaan - yleensä sovitut konehuoneet ja kuilut ovat pienentyneet siitä, mitä ollaan sovittu keskinäisessä palaverissa.

Nyt tuli esille hieno kohde. Tämä asia kerrottiin meille selvästi etukäteen.

Lainaus pitkähköstä sähköpostiviestistä:

"HUOM!
- Olemme hieman pienenetäneet pääsuunnittelijan pyynnöstä IV-kuiluja, jotta ne mahtuvat paremmin 3.kerrokseen."

Toivottavasti eteen tulee lisää vastaavaa toimintaa.

Nyt pystymme reagoimaan asiaan ennen kuin mitään on rakennettu - tätäkään asiaa ei tarvitse ihmetellä työmaalla kun kamat ei mahdu liian pieneen kuiluun. Voimme reagoida asiaan jo suunnitteluvaiheessa (toistamiseen/kolmanteen/neljänteen kertaa.).

Rakennusala: Yhteistyötä!

Kun homma lähtee lapasesta

Muutaman kerran on tullut eteen tilanne, että ei pysty ymmärtämään toisen osapuolen ajatuksia.

Tai sitten kyseessä on normaali tilanne, jossa etsitään syyllistä ja oma vastuu pyritään siirtämään ravintoketjun seuraavalle osapuolelle.

Tässä sähköpostikeskustelua oikeasta kohteesta, jonka LVI-suunnittelutoimiston tiedän olevan TOP15 joukossa Suomen TATE-mallinnuksen piirissä. (LVI-suunnittelijan lupa julkaisulle saatu)

LVI-suunnittelija:
(edit)
"Tarkasta tietomallista on tullut työmaan jarru. Urakoitsijan alustava arvio seinärei’itysten korjaamisesta on xxxxx €.

Arviosta puuttuu vielä mahdolliset tekniikka-asennusten tietomallista aiheutuneet kustannukset.

Voisitko kertoa, mitä suuruusluokkaa yo. kohteen tietomallin päivitys YTV-mallista malliksi, jossa sallitaan 25 mm:n törmäilyt.

"

(edit)

Minä:

"

Terve xxccyy,

Minun mielestä tämä ei ole ollenkaan tietomalliasia.

Urakoitsija ei voi tehdä reikiä mitoittamattomien pohjapiirustusten / tietomallin perusteella.

Jos oikein yritetään tarkkuustasoa hakea, niin olisikohan toleranssi se, minkä 1:50 mittatikulla pohjakuvista saa mitattua?

SKOL ohjeistus reikävarausten teosta löytyy täältä:

http://www.skolry.fi/sites/default/files/SKOL_TATE_prosessikuvauksia_201406.pdf

Olen tuon hankkeen vetänyt, rakennesuunnittelijat ovat sen hyväksyneet skollissa

Jos teille ei ole etukäteen kerrottu, että rei'ät tullaan tekemään mallin perusteella (muihinkin seiniin kuin kantaviin) niin vähimmäisvaatimus mielestäni on, että siitä teille etukäteen kerrotaan jotta voitte kertoa, onko se edes mahdollista.

En valitettavasti pysty antamaan arviota ajankäytöstä, en tiedä toimintatapojanne. Mutta sen tiedän, että päivittämisessä ei ole mitään järkeä. Tietomallin tarkoitus ei ole olla 1:1 graafinen näkymä rakennettavasta kohteesta, vaan se on suunnitelma. Jos sitä aiotaan käyttää esim. esivalmistusten, reikien tms. tekoon kokonaisvaltaisesti, niin sitten se pitää tehdä tätä käyttötarkoitusta silmälläpitäen. Käytännössä mallinnuksen silloin tekee siis urakoitsija (kuten keskieuroopassa/jenkeissä)

Jos reikiä halutaan tehdä mallien perusteella, niin ne tulee tehdä reikävarausobjektien kautta, jotka on suunnittelija tehnyt, konnari hyväksynyt. Ei siis tasokuvin kanavien / putkien perusteella.

Kummallisesti tämä tietomallinnus tuntuu välillä hämärtävän ihan normaaleja suunnittelu- ja työmaatoimintakäytäntöjä. Ei vanhat säännöt ole minnekään kadonneet, työkalut ja prosessit ovat vain uusia (niin, jos olette tehneet suunnittelun kuten ennenkin muuttamatta toimintatapoja suunnittelutiimin yhteistyössä / työmaan keskuudessa, niin ongelmia alkaa tulla… tietoa on liikaa, sen oikeellisuutta pitää pystyä tarkastelemaan).

Tuo 25mm "toleranssi" hämää minua. TATE-kamat ovat eriarvoisia sijaintejansa suhteen eri osissa rakennusta. Näkyvillä olevat kamat varmaankin tulisi olla kohtalaisen tarkasti, mutta esim. iv-konehuoneessa tuo tarkkuus on sulaa hulluutta. Eli mielestäni ei voi katsoa suoraan mihinkään numeroarvoon, pitää osata / pystyä käyttämään järkeä.

Jotenkin minusta tuntuu, että suunnittelun ohjaus tai luulot tietomallintamisen tarkkuudesta ovat lähteneet käsistä. Jälkikäteen näiden asioiden perkaaminen on harmittavaa. Pitäisi olla ennen mallinnusta selvillä, mihin käyttötarkoitukseen sitä tullaan käyttämään. Kaikki ei ole mahdollista – joillakin voi olla luulo, että kun tehdään YTV:n mukaisesti, niin sitten on vaikka mitä mahdollisuuksia. Ei ole, ne pitää osata kertoa ennen mallinnusta.

teroj

"

Kommenttina tuohon viimeiseen kappaleeseen: Ei sellaista henkilöä ole olemassa, joka pystyy kertomaan hankkeen alkuvaiheessa, mitä tullaan tekemään ja miten. Tuo on utopiaa. Mutta se ei ole, että hommataan hankkeeseen kehitysvaihe, jossa kerätään ammattitaito samaan avokonttoriin ja mietitään, mitä tulisi tehdä - sen perusteella sitten aletaan tehdä vaatimuksia.

Jumalauta- yhteistyötä, toisen työn merkityksen ymmärtämistä ja kunnioitusta.

Circle - DNA

Viikon kuva:

Tästä palkista tehdään pienoiselokuva erään  ex-suomalaisen firman markkinointitarkoituksiin.

Uusi innovaatio: Yhteistyö

Pikkuhiljaa alkaa löytyä netistä kirjoituksia, joissa ilokseni tarraudutaan rakennushankkeen syvimpään olemukseen - yhteistyöhön.

Savolaiset hahmottavat asian näin:
http://www.rakennusteollisuus.fi/RT/Ajankohtaista/Yhteisty%C3%B6ll%C3%A4+onnistunut+rakennushanke/

Ja Senaatti-kiinteistöt näin:
http://www.rakennuslehti.fi/blog/viewentry/?entry_id=325

Hienoja kirjoituksia, tunnelin päässä näkyy valoa.

Toivon todella, että nyt kun tilaajat / rakennuttajat ovat heränneet, niin he myös osoittavat toimillaan sanojensa painon. Olisi sääli, jos nuo kirjoitukset jäävät seminaaripuheiksi.

Senaatin kärkihankkeilta odotan paljon, se viitoittaa tietä tulevaisuuteen, sen perusteella Senaatti-kiinteistöt on palannut rohkeasti Suomen rakennuttamisen kärkikastiin muutaman vuoden pienen hapuilun jälkeen.

Viikon kuva:
Rakennushankkeen kolme tukijalkaa