perjantai 29. marraskuuta 2013

SKOL ry: TATE-tietomalliprosesseja kommentoitavana

SKOL ry:n Talotekniikkaryhmä  käynnisti vuoden 2013 alussa projektin, jonka tarkoituksena on kerätä prosessikuvauksia niistä tietomallisuunnittelun osa-alueista, joissa on havaittu haasteita - ainakin talotekniikan näkökulmasta. Tarkennuksena se, että haasteet eivät ole lakiteknisiä, joku voisi niitä ongelmiksikin sanoa.

Työhon perustettiin paras A-ryhmä, eli kyseltiin SKOLlin taloteknistä suunnittelua harjoittavilta toimistoilta halukkuutta osallistua talkoisiin. Työporukkaan ilmottautui lopulta firmat: AX-suunnittelu, Granlund, Hepacon, Lausamo, Maaskola, Pöyry, Talokeskus, Wise Group ja Äyräväinen.

Rakennepuolen kommentoinneissa kunnostautuivat A-Insinöörit, Finnmap ja Ramboll.
Arkkitehtipuolelta saatiin myös hyviä kommentteja, joiden kautta hiottiin prosessia kaikille yhteensopiviksi.

Prosesseiksi valittiin useiden vaihtoehtojen joukosta:
- Alakattosuunittelu
- Reikäkuvasuunnittleu
- Rakennemallin valmiusastevaatimus ennen TATE-mallinnuksen aloittamista

Kaupanpäälle tuli kuvaus siitä, miten origo laitetan paikalleen ja hieman sanastoa tietomalliteknisistä termeistä (koskien näitä prosessikuvauksia, mitään akateemistä tutkimusta sanastosta ei lähdetty tekemään)

Kommentointiversio prosesseista löytyy SKOLlin sivuilta:
http://www.skolry.fi/talonrakennussektori

Suora linkki kuvaukseen:
http://www.skolry.fi/sites/default/files/SKOL_TATE_prosessikuvauksia_201311.pdf

(edit: linkki lopulliseen kuvaukseen:
http://www.skolry.fi/tiedotteet/talotekniikkasuunnittelun-tietomalliprosessia-p%C3%A4ivitetty-ty%C3%B6njaosta-hyv%C3%A4-sopia-etuk%C3%A4teen )

Käykää lataamassa, lukeaa ja kommentoikaa. Julkaisu tehdään vuoden 2014 alussa.

On tiedossa, että ohjeet ovat tylsää luettavaa ja todellisuudessa niitä katsotaan varmaankin sitten, kun on ongelmia toteutuksen kanssa (=etsitään syyllistä). Mutta rautalankaa on vaikea vääntää, jos sitä ei edes yritä taivuttaa.

 Toivottavasti mahdollisimman moni tilaaja viittaa näihin prosesseihin, kun tilataan tietomallisuunnittelua. Eli kolme lausetta suunnittelun tarjouspyyntöön, joka on tehty  TATE12 tehtäväluettelon mukaisesti:
- Kohde mallinnetaan "Yleiset Tietomallivaatimukset 2012" mukaisesti, viitaten tehtäväluettelossa valittuihin tehtäviin.
- Kohteessa noudatetaan SKOL ry:n tietomallinnusprosesseja (http://www.skolry.fi/talonrakennussektori )
- Tietomallien käyttötarkoitus on: xxx, yyy, zzz

Ja kyllä, tuo tilaus on tehtävä myös ARK ja RAK suunnittelijoille - yhteispeliähän tässä tehdään, ei riitä että yksi osapuoli noudattaa jotain ohjetta.

Viikon kuva:
Alakattosuunnittelua yleis- ja toteutussuunnitteluvaiheessa








lauantai 23. marraskuuta 2013

BIM vuonna 2013

Minua haastateltiin NSS:n toimesta Plaani -lehteen muutamia viikoja sitten.

Taustana on projekti:
http://www.skolry.fi/tiedotteet/skol-kehitt%C3%A4%C3%A4-talotekniikkasuunnittelun-tietomalliprosesseja

Kun prosessikuvaukset ovat virallisesti julkaisu- / kommentointikelpoisia, laitan linkkiä tänne blogiin.

Lopputulos varmaankin ilmestyy Plaani 2013/4 lehdessä, lisätietoa täältä:
http://nssoy.fi/index.php/plaani

Omalta osalta homma lähti lapasesta, eli kirjoittelin ummet ja lammet toimittajalle. Koko juttu ei voi millään mahtua itse lehteen, mutta tänne blogiinhan se mahtuu... eli alla vastaukseni toimittajan kysymyksiin:

---
                                                                                                                                                            14.10.13                                                                                                                                                  Plaani 4/13

SKOL:n talotekniikkasuunnittelun tietomalliprosessien kehityshanke
Tietomallipäällikkö Tero Järvinen, Granlund Oy

Hankkeen tausta ja tavoitteet?  
  • Vuosina 2011-12 päivitettiin Senaatin vuonna 2007 julkaisut tietomallisuunnittelun   vaatimukset ja julkaistiin Yleiset tietomallivaatimukset 2012. SKOL suunnitteli jo tuolloin suunnitteluprosessien kehittämistä edistävää projektia.  Miten nyt valmistuva hanke eroaa  YTV:n ohjeista ja siinä kuvatusta tietomallintamisen suunnitteluprosessista?


Nyt tehtävät ohjeet menevät tarkemmalle, tekniselle tasolle kuin YTV:ssä pystytään menemään. Koska SKOLin prosessikuvauksissa voidaan valita muutamia haasteellisiksi havaittuja prosesseja, niin pystymme rajaamaan näkökulmaa paremmin
  • Miten hanke on edennyt ja keitä mukana?

Hanke etenee alkuvuonna asetetussa aikataulussa. Toimimme siten, että minä teen alustavan rungon prosessikuvauksesta ja sitten käymme sen työpajatyyppisesti läpi muiden suunnittelutoimistojen edustajien kanssa. Näin mahdollistamme sen, että näkemys ei jää yhden osapuolen toimintatavoista riippuvaiseksi.
Mukana työpajoissa on ollut henkilöitä suurimmista suomalaisista taloteknisistä suunnittelutoimistoista, mm. Pöyryltä, Wise Groupilta, AX-Suunnittelusta, Hepaconilta, Lausamolta, Maaskolalta, Äyräväiseltä ja Talokeskukselta. Ja tietenkin meiltä, eli Granlundilta.

  • Millaisia käytännön ongelmia projektin tavoitteissa mainituista perinteisestä               suunnitteluprosessista ja tiedonvaihtoaikataulusta on aiheutunut?

Tietomallipohjainen suunnittelu on siinä mielessä hieno juttu, että se laittaa suunnittelijat oikeasti ajattelemaan. Jotta asioita voidaan mallintaa fiksusti, tulee asioita ensiksi suunnitella ja aikatauluttaa. Tietomallipohjainen suunnittelu palauttaa siis meidän suunnittelijat ajassa taaksepäin ja tuo yhteistyön ja suunnitelmallisuuden takaisin.

Liian usein ”perinteiset” suunnittelumetodit ajavat siihen, että suunnittelijoiden välillä ei saada käyttää omaa kaupunkilaisjärkeä vaan tehdään sitä mitä on tilattu – vain omasta näkökulmasta katsoen. Valitettavasti perinteiset sopimusmallit ohjaavat tähän tilanteeseen, sillä vaikka esim. sähkösuunnittelijan olisi järkevää mallintaa reikävaraukset mallipohjaisesti jotta rakennesuunnittelijan päässä olisi reikävaraushallinta yksinkertaisempaa, niin sitä ei tehdä koska sitä ei ole tilattu. Ei pystytä eikä haluta katsoa kokonaisuutta, koska osaoptimoidaan omaa suoritusta .
  • Mitä tarkoittaa se, että suunnitteluprosessi muutetaan ”Lean Construction” -periaatteita   noudattavaksi?

Olen puolileikilläni sanonut, että Lean Construction tarkoittaa puiden halailemista. Käytännössä Lean Construction minun ajatuksissani tarkoittaa yhteistoiminnallista suunnittelutapaa, niiden töiden tekemistä, joista asiakas on valmis maksamaan ja josta he hyötyvät. Helpoin vastaus Lean –ajatteluun on ”hukan minimointi”, mutta tuo on mielestäni lähinnä seuraus siitä, kun toimitaan siten että kunnioitetaan toisen ihmisen työntekoa ja tehdään itse se, mitä on luvattu tehdä.

Tavoite?
Tarkoituksena luoda:
  • Ohjeellinen kaikkia suunnittelualoja koskeva suunnitteluprosessin kuvaus
  • Kaikkien suunnittelualojen välinen tiedonvaihtoaikataulu
  • Projekti on loppusuoralla, toteutuvatko tavoitteet?


Asiasisältö saadaan kerättyä ja kirjoitettua, mutta olisin toivonut enemmän visuaalisempaa lopputulosta. Nythän prosessikuvaus on insinöörimäisen jämäkästi tehty numeroituna työlistana joka on raskasta luettavaa.
Toivon, että ohjeistus saataisiin sellaiseen muotoon, että nopealla silmäyksellä saataisiin kokonaiskuva siitä, mitä ollaan tekemässä ja sitten sen jälkeen tarvittaessa siirrytään lukemaan tekstiosuutta. Kateellisena katselen esim. arkkitehtien kykyä tehdä graafisia ”sarjakuvia” vaikeistakin asioista.
  • Tässä kehitetään TATE-lähtöisesti, ovatko muut (esim. ARK ja RAK) suunnittelualat   tunnistaneet samat ongelmakohdat kuin tässä esitetyt?

Alakattosuunnittelun osuus on alustavasti tarkastettu muutamien arkkitehtien toimesta ja kokonaispalaute on ollut hyvää. Toisaalta, palautetta tuli laidasta laitaan tyyliin: ”Kokemuksesta tiedän, että tämä kuvaus ei tule yleistymään” ja ” Kaikki mitä kirjoitat on täyttä asiaa. 2d-leikkauksella on lähdettävä.”

Kun ollaan muuttamassa nykyistä käytäntöä – tai tuomassa vanhaa tapaa takaisin – niin mielipiteet jakautuvat puolesta ja vastaan. Suurin osa kuitenkin oli sitä mieltä, että ohjeet ovat hyvät ja niitä voidaan noudattaa.
Rakennesuunnittelijoiden kanssa kävin myös reikäkuvaprosessin läpi (Finnmap, Rambol, A-Insinöörit). Ohje oli lähes sellaisenaan toimiva, olimme jo aikaisemmin eri kehityshankkeissa ja projekteissa rakennesuunnittelijoiden kanssa asiaa hioneet. Elementtisuunnittelun haasteet nousivat nyt konkreettisemmin esille ja ne jouduimme ohittamaan tässä hankkeessa.

Rakennesuunnittelijoilla on ymmärrettävä vaatimus – he haluavat kaiken reikävaraustiedon mallipohjaisena. Valitettavasti talotekniikan ohjelmistot eivät tähän vielä taivu ja ei voi olettaa, että talotekninen suunnittelija ottaisi normaalitapauksessa  käyttöön esim. Tekla Structures –ohjelmiston jolla tämä työ olisi mahdollista teknisesti suorittaa.
  • Pitäisikö kartoittaa myös toisten suunnittelualojen omat kipupisteet, jotka puolestaan           voisivat vaikuttaa koko rakentamisprosessiin?

Kyllä, se olisi erinomainen asia. Nyt on pintapuolisesti kyselty valmiin materiaalin kanssa arkkitehdeiltä ja rakennesuunnittelijoilta siitä, että soveltuuko tämä ohje heidän mielestä suunnitteluun. Ohjeessa on kuitenkin vaatimuksia kaikille osapuolille, eli jotta ohjeen vaatimukset voidaan toteuttaa, jokaisen osapuolen on sitä noudateltava.             
  • Prosessikuvaukset on tehty origon asettamisesta, alakattosuunnittelusta ja -mallinnuksesta   sekä TATE-reikävarausten tekemisestä. Miksi juuri nämä valittiin?

Nämä aiheet tulivat hankkeeseen perustetun työryhmän kautta. Valitsimme yhteisesti noin kymmenen eri aihetta, jotka ovat aiheuttaneet ylimääräistä, turhaa työtä hankkeissamme ja sieltä äänestettiin nämä kolme vaihtoehtoa ensimmäiseksi askeleeksi tässä prosessikehityshankkeessa.
  • Mitkä ovat oleellisimmat prosessinkulun muutokset TATE-suunnittelijan kannalta?

Oleellisin asia on yhteistyön korostaminen. TATE on riippuvainen muiden suunnittelualojen etenemisestä. Näillä prosessiohjeilla tuodaan takaisin myös töiden vaiheistus Jotta voidaan tehdä jokin asia, tulee ympäristö työn tekemiseksi olla jo suunniteltu riittävällä tasolla.

Lisäksi ohjeet toimivat muistilistana TATE-suunnittelijalle. Liian usein TATE ei tee jotain työosuutta, vaan odottaa ”täydellistä” ympäristöä tai lähtötietoa muilta suunnittleijoilta. Suunnittelu on iteratiivinen prosessi, kaikkien tulee tehdä iteraatioita oikeassa järjestyksessä ja vaiheessa.
  • Eikö origon asettamiselle ole ollut ohjeita aikaisemmin? Miten mallit voidaan yleensä           sovittaa yhteen ilman yhteistä origoa? 

Tämä on yksi surkuhupaisimmista asioista mitä tiedän. Origon sijoitus on ollut liian monessa projektissa hukassa jo 1990 luvulta lähtien. Yli kaksikymmentä vuotta sitten on keksitty, miten tämä asia tulee hoitaa, mutta jostain käsittämättömästä syystä edelleenkin lähes kuukausittain meille tulee projekteja, joissa origon asettamisessa ollaan epäonnistuttu.

Asian ratkaisu on erittäin yksinkertainen mutta vaatii toisen osapuolen mallintamisen ymmärrystä ja aivan normaalia keskustelua mallintajien kanssa. Ehkäpä tässä ollaan epäonnistuttu siksi, että ei tehdä suunnittelutiimin kanssa yhteistyötä riittävällä tasolla?
  • Alakattojen osalta yleissuunnitteluvaiheessa arkkitehti ja TATE-suunnittelija tekee 2D-leikkauksia valituista paikoista? Miksi ei tehdä heti mallintamalla, eikö 2D ole paluuta vanhaan suunnittelutapaan?

Tämä on yksi asia, jota yritän korostaa. Ensiksi suunnitellaan, sitten mallinnetaan.
TATE-puolella esim. käytäväleikkauksessa kulkee useiden eri suunnittelualojen verkostoja. Jotenkin nämä verkostot on koordinoitava siten, että ne pystytään mallintamaan 3-6 eri henkilön toimesta graafiseen tietomalliin. Tämän ajatustyön apuna on perinteinen 2D-leikkaus. Kun siinä on asia suunniteltu, niin voidaan siirtyä seuraavaan vaiheeseen, esim. saman asian mallintamiseen. Nämä eivät ole toisiansa poissulkevia työtehtäviä. Pitää hyväksyä se tosiasia, että ei ole olemassa tietomallipohjaista suunnittelua – on vain suunnittelua.
  • Reikävaraukset: Kuinka yleistä on, että esim. urakoitsija muuttaa rakennuksen runkoratkaisun

Ei se kokemukseni mukaan mikään normaali tilanne ole, mutta kun tuo tapahtuu, niin TATE-verkostojen graafinen mallinnus voidaan heittää roskikseen. Tai painaa deleteä tiedostoille.

Tätä asiaa ei mielestäni ymmärretä riittävästi, kun tehdään valinta euron halvemmasta runkoratkaisusta. Tuo tilanne on katastrofi TATE-suunnittelijalle ja yleensä rakennesuunnittelijallekin. Tilaajan pitäisi heti näin toimittaessa selvittä aikatauluvaikutus sekä kokonaiskustannusten nousuvaikutus.

Tosiasia on se, että jo valmiiksi mallinnettuja TATE-verkostoja ei tuosta vaan soviteta uuteen rakennusrunkoon, vaan yleensä fiksuinta on mallintaa verkostot uudelleen. Eli ei ole hyvää vaihtoehtoa tarjolla, kun runko muutetaan.
  • Miksi valittiin reikien kooksi tuo 150 mm, kun kuitenkin todetaan, että olisi                           kokonaistaloudellisempaa tehdä myös pienempien reikien mallinnukset suunnittelijan             toimesta?   

Tuossa on historian havinaa mukana. Joku koko pitää olla sanottuna, jotta voidaan tarjota järkevällä työmäärällä kiinteähintaisia suunnittelutarjouksia.

On monia asioita, joissa voitaisiin toteuttaa kokonaistaloudellisempaa suunnittelua, eli suunnittelija pystyisi tuottamaan lisätyöllä sellaista tietoa / materiaalia, joka helpottaa urakoitsijan työtä. Tätä ei kuitenkaan tehdä, koska tästä lisätyöstä ei olla valmiita maksamaan  - siis suunnittelijalle. Kokonaiskustannushan laskisi.
  • Prosessikuvauksessa erikseen mainitaan, että reikävaraussuunnittelun 2D-piirustusten           tekovelvollisuus on rakennesuunnittelijalla, onko tästä ollut epäselvyyttä?

On, sillä perinteisesti 2D-piirustukset on tehnyt TATE-suunnittelija. Tuo on puhdasta työtä, eli tuolle pitää olla varattuna suunnittelijan toimesta joku työmäärä, eli rahasumma. Rakennesuunnittelijalla on parempi ammattitaito ja tietämys siitä, mistä kohtaa rakennusta vedetään mittaviiva, mitä tietoja tarvitaan jne. 

Työmäärähän ei kokonaisuutta ajatellen kasva, vaan se siirtyy eri suunnittelualalta toiselle, joka osaa tehdä työn paremmin. Ja tämä siirtynyt työ tulee pystyä hinnoittelemaan tarjousvaiheessa.
  • Reikävarausten kohdalla on otettu esiin peruskorjauskohteet. Onko joku                           peruskorjauskohteiden työtapavaihtoehdoista (1-4) erityisen tyypillinen?

Oman näkemyksen mukaan tilanne 3 on tyypillisin, eli on käytössä arkkitehtimalli, mutta ei koko rakennuksen kattavaa rakennemallia. Mutta kaikkia vaihtoehtoja on olemassa ja se aiheuttaa haasteen peruskorjauskohteiden suunnittelussa.

Mielestäni vaihtoehto 1 olisi TATE:lle paras, eli rakennemalli mallinnettu vanhojen piirustusten mukaisesti ja sen lisäksi kaikilla osapuolilla ymmärrys siitä, että aivan varmasti matkan varrella tulee yllätyksiä niistä asioista, joita ei ole vanhoista piirustuksista löytynyt.

Kun toimitaan tämän mukaisesti, kannattaa pistokoemaisesti tarkistaa todellisen rakennuksen ja vanhojen rakennepiirustusten yhteensopivuus ennen mallinnuksen aloittamista.
  • Kuinka hyvin tietomallinnus yleisesti sopii mielestäsi peruskorjauskohteisiin?

Sopii aivan hyvin, kun ymmärretään se tosiasia, että täydellistä, virtuaalista mallia rakennuksesta on nykytekniikalla lähestulkoon mahdoton tehdä suunnittelijan käyttöön. Pitää hyväksyä todellisuuden ja virtuaalitodellisuuden rajat.

Nyt joku sanoo, että skannaamalla saadaan pistepilvet käyttöön ja siten parin millin tarkkuuteen. Heille sanoisin, että tervetuloa hommiin, kun käytetään pistepilviä TATE-mallinnuksen lähtökohtana koko rakennuksen alueella. Mallihuoneet tms. pikkualueet tai maanalaiset luolat ovat eri juttu pistepilvien suhteen.

Projektin valmistuminen
  • Aikataulu ja mistä löytää?

Vuoden 2013 lopulla pitäisi olla julkaistuna. Se mistä löytää, ei ole ihan vielä käsittääkseni sovittu, mutta ainakin nyt taustatietoa löytyy SKOL Ry:n sivuilta :
http://www.skolry.fi/tiedotteet/skol-kehitt%C3%A4%C3%A4-talotekniikkasuunnittelun-tietomalliprosesseja
  • Miten hankkeen tulokset saadaan eri suunnittelualoilla käyttöön (muillekin kuin SKOL:n       jäsentoimistoille)?
  • Viettekö ohjeet myös aktiivisesti tilaajien tietoon, vaikuttaa kuitenkin koko projektin             aikatauluun ja läpivientiin?

Toivon, että ohjeet ovat netistä vapaasti ladattavissa kaikkien käyttöön. Asiasta ei ole tehty tarkkaa suunnitelmaa, ainakaan minun toimesta. Tilaajille toivon tiedon kulkevan ensi alkuun lehdistön ja TATE-suunnittelutoimistojen kautta.

Lisäksi on ollut puhetta BuildingSMART Finlandin kanssa, että ohjeet voisivat tulla myös heidän kautta levitykseen.

Asian ratkaiseminen on vielä kesken, mutta tuskin nämä miksikään salaseuran sisäiseksi ohjeeksi jäävät – ne ovat tarkoitettu käyttöön jo silloin, kun annetaan suunnittelutarjousta kohteesta. Tilaaja voi viitata prosessikuvauksiin ja vaatia niiden noudattamista jos toteaa ne kohteeseensa sopiviksi. Näin kaikki tarjoajat ovat samalla viivalla ja tietävät, mitä heiltä odotetaan.
  • Prosessinkuvauksissa oli mainittu paljon tapaamisia eri suunnittelualojen suunnittelijoiden   kesken. Suunnittelijat sanovat, että erilaisia palavereja on nykyisin todella paljon. Jos           noudatetaan näitä ohjeita, onko vaikutusta suunnittelukokouksien määrään?

Sana ”Suunnittleukokous” tulisi määritellä tarkemmin. On liian paljon suunnittelukokouksia, joissa TATE-suunnittelija istuu kaksi tuntia ja pääsee kerran ääneen, kun kysytään suunnitteluasioita. Vastaus on yleensä, ”Ei kokousasioita”. Tuossa ei ole mitään järkeä – byrokratiaa tuntuu olevan liikaa.

Välillä on tuntunut, että suunnittelukokouksissa ei saa puhua suunnitteluasioista ja työmaakokouksissa ei saa puhua työmaan asioista.

Prosessikuvauksissa esitetyt kokoukset voivat olla myös etäpalavereja. Ajatus on kuitenkin se, että pidetään työpaja teknisistä asioista. Ei ole tarkoitus katsoa ”suurta kuvaa”, vaan keskitytään pienemmän mittakaavan asioihin, joiden me tiedämme aiheuttavan isoja ongelmia, jos niitä ei yhteistoiminnallisesti ratkaista. Esim. alakattosuunnittelua ei voi tehdä vain yksi osapuoli projektissa. Se vaatii usean ammattilaisen panostusta, jotta se voidaan suorittaa teknisesti toimivana

Yleisesti tietomallintamisesta
  • Jossain vaiheessa sanottiin, että Suomi on kärjessä tietomallintamisen käytössä. Mikä on       tilanne mielestäsi nyt?

Oma tuntuma on se, että meillä tietomallinnus on konkretisoitunut normaaliksi tavaksi tehdä suunnitelmia. Minun näkemyksen mukaan Norjalaiset ovat meitä edellä, siellä on paljon kehityshankkeita ja eteenpäin vievää voimaa. Englantilaiset ovat kuulemma edenneet todella nopeasti, kun hallitus määräsi mallinnuksen käyttöönotettavaksi. Kiinassa tapahtuu vaikka mitä, sitä aluetta en tunne mutta ilmiselvästi siellä on kuhinaa asian ympärillä. Lähellä Suomalaista tapaa tehdä asioita on ehkä Hollanti.

Mielestäni olemme kuitenkin edelleen kärkikolmikossa kun katsotaan kokonaiskuvaa. Olemme ohittaneet hype –vaiheen ja tilanne on normalisoitunut siinä määrin, että kaikki – sekä suunnittelijat, tilaajat ja urakoitsijat – ovat jo omat karikkonsa käyneet lävitse ja nyt osataan ottaa oppia vanhoista virheistä.
Me emme usko asioita, ennen kuin olemme tehneet ne pari kertaa väärin. Väittäisin, että muut eivät ole kaikkialla vielä samalla tasolla kokemuksen suhteen.
  • Onko ohjelmistokehitys pysynyt tietomalliprosessin kehittämishankkeiden mukana?

On pysynyt, välillä he ovat joillakin alueilla edellä ja jollakin toisella alueella jäljessä. Ohjelmistokehittäjäthän katsovat markkinatilannetta. Jos softaa myydään Kiinaan, niin tehdään sinne soveltuvia ominaisuuksia. Skandinavia on niin pieni markkina-alue jenkkien isoille firmoille, että lienee ihan sama, mitä me täällä huudamme. Esim. IFC ei ole heille ollenkaan tärkeä asia, kaikillahan voi olla saman softafirman tuotteet.

Onneksi meillä Suomessa tilanne on toinen – OpenBIM lyö itseään läpi ja tietomallisuunnittelussa toimivimmat ohjelmistot tehdään Suomessa.
  • Onko yhteensopivuus eri suunnittelualojen ohjelmistojen kesken parantunut (joskus               sanottiin, että oli ongelmia)?

Aina tilanne parantuu, kunnes tulee joku toinen asia mikä ei toimi. Omaa elämääni helpotti sen ymmärtäminen, että softa ei ole koskaan valmis. Se on aina puutteellinen käyttäjän mielestä.
Mikään softa ei ole täydellinen, koska käyttäjä kehittyy jatkuvasti vaativammaksi. Tietomallisoftia on pystyttävä käyttämään niiden äärirajoilla, jotta niistä saadaan kaikki teho irti. Tämä aiheuttaa sen, että käyttäjä asettaa koko ajan vaativampia ja vaativampia tavoitteita työnsä tekemiselle.

Tuolla on suora vaikutus softan toimintaan. Kun softafirma implementoi jonkun uuden ominaisuuden, voi olla, että sitä ei käytetä ensimmäiseen kahteen vuoteen, koska sen käyttö toisi uusia suunnitteluprosesseja. Mutta sitten kun uutta ominaisuutta käytetään, niin käyttäjä löytää siitä heti 10 ongelmaa – ja syynä on vain se, että softan tekijä ei ole suunnittelun ammattilainen. Palautteen merkitys on erittäin suuri.
  • Onko Tehtäväluettelo 2012 TATE-osuuden julkaisun viivästymisellä ollut vaikutusta esim     tietomallintamisen prosessien kehittämiseen? Ja toisinpäin, onko julkaistava TATE 12  edelleen ajan tasalla tietomallinnuksen suhteen?

Mielestäni viivästymisellä on ollut vaikutusta tietomallinnuksen kehittymiselle. Jotta me suunnittelijat voimme tehdä asioita mallipohjaisesti, niitä töitä pitää pystyä meiltä tilaamaan. Kun annamme kiinteähintaisia tarjoushintoja, niin tilaajan on pystyttävä kertomaan, mitä he haluavat.

Se onnistuu hyvin TATE12 tehtäväluettelolla ja se on mielestäni hyvin ajan tasalla nykyisyyden kanssa. TATE12 talotekniikan osaltahan oli lähes valmis, kun teimme YTV2012 vaatimuksia. Ehdimme lisäämään tehtäväluetteloon muutaman kohdan, jotka tarkensivat tietomallisuunnittelun tehtäviä.

Tietenkin, neuvottelumenettely on paras ratkaisu, jos todella halutaan laatua ja elinkaarikustannusten vähenemistä -  eikä vain investointikustannusten minimoimista.
  • Puhuit Plaanissa 2/12 uusista sopimusmalleista ja mainitsit IPD:n (Integrated Projec Delivery), jonka suuntaan toivoit mentävän. Nyt uusia malleja noussut, esim. Yliopisto-   kiinteistöjen ”yhteistyömallit”. Mitä mieltä nyt?

IPD tai Allianssi, se on yksi tapa tehdä asioita fiksummin. Nämä ovat sopimusteknisiä asioita, joissa pyritään sopimustekniikalla mahdollistamaan suunnittelijoiden, tilaajan ja urakoitsijan mahdollisimman järkevä yhteistyö. Normaalit, perinteiset sopimusmallit estävät järkevän yhteistyön, koska aina välillä joukossa on joku osapuoli, joka ei halua nähdä kokonaisuutta.

Se, että pitääkö näin pitkälle mennä, ei ole aina pakollista. Tilaaja voi aivan hyvin koota tiimin, jonka yhteistyön tietää toimivan ja jonka kanssa he osaavat toimia. Juridisia mahdollisuuksia on olemassa, neuvottelumenettelyt jne.


Kun Yhteistoimintamalliseen projektiin lisätään Lean Construction filosofia ja prosessina käytetään tietomallipohjaista etenemistä, niin uskon että homekouluilta vältytään ja tilaaja saa sitä, mitä on tilannut.

Viikon kuva:

lauantai 9. marraskuuta 2013

Allianssihanke "VIRMA" etenee

Kuten blogissani http://tietomalli.blogspot.fi/2013/06/virma-lahti-tosissaan-liikkeelle.html kirjoitin, Järvenpään kaupunki osoitti mallia ja laukaisi liikkeelle allianssiprojetkin uuden terveystalon rakentamisesta.

Suunnittelijatiimien tarjouskisan voitti "VALO" -ryhmä, jonka ydinryhmä on:
- Uki Arkkitehdit
- Tähti-Set
- A-Insinöörit rakennuttaminen
- A-Insinöörit suunnittelu
- Insinööritoimisto Erkki Leskinen
- Insinööritoimisto AX-LVI

Onnea voittaneille, hoitakaa homma kotiin. Tämä on tärkeä kohde suomalaiselle suunnittelulle ja rakennuttamiselle.

Itse olin mukana kilpailevassa tiimissä ja hävisimme insinöörimäiseen mokaan. Oikeastaan juttu kiteytyy Radiopuhelimien tekemän biisin sanoitukseen:
"Kun täytyy sanoa jotain, eivät runomitat kerro mitään"

Voisin kenties ottaa syyn jopa itselleni. Olin niin innostunut tästä asiasta, että hehkutin esittelytilaisuudessa allianssimallin erinomaisuutta ja kerroin, miten aiomme tehdä energialaskentoja, visualisointeja, olosuhdesimuloiteja jne. kerrankin siten, kun niitä pitää tehdä. Koska nyt siihen olisi tarjolla mahdollisuus myös sopimusteknisesti.

Eli aivan puhdasta insinööripornoa.

Kun valinta oli tehty, niin saamassani perustelumuistiossa ryhmämme kohdalla oli maininta:
"Talo itsessään tuntui olevan sivutuote ja uusi allianssikonsepti tärkeämpi".

On sydäntäraapaisevaa, koska tuo lause osui ja upposi. Olin täysin allianssin hurmiossa ja unohdin käyttäjän. Joka toisella sivulla tarjouspapereissa sanottiin "käyttäjälähtöinen suunnittelu".

Missasimme ryhmänä tämän jutun täydellisesti. Tämän asian ja kohteen merkityksen suomen rakennuttamiskulttuurissa olisivat voineet tajuta myös muutamat ryhmässämme olleet osapuolet.

Toivon tälle kohteelle erinomaisen paljon onnea ja menestystä.

http://julkinen.fi/virma/Etusivu







perjantai 8. marraskuuta 2013

Systems Engineering

Täytyy myöntää, että olen aika kovapäinen tyyppi.

Minun piti käydä pari seminaaria ja yksi baari-ilta asiaa tekevän henkilön kanssa ennen kuin tajusin, että on olemassa tekniikanhaara nimeltä Systems engineering.

Tajusin vasta kun pari kertaa toistettiin, että: "Tuo tietomallinnus vaikuttaa aika samanlaiselta hommalta kuin mitä minä teen.". Ehkä ympäristössä oli hieman liikaa melua, kun en heti tajunnut.

Jonkuntyyppisen googleselvittelyn jälkeen huomaan, että BIM onkin Systems engineeringiä.

Eli jos BIM on prosessi, niin prosessin toimiminen tarvitsee tavoitteita, vaatimuksia ja niiden todentamista.

Ja mitäpä sanotaan sivuilla http://www.finse.org/systemsengineering.php :
"Systems Engineeringillä tarkoitetaan järjestelmällistä toimintatapaa, jolla pyritään varmistumaan siitä, että järjestelmä tai yleisesti ottaen palvelu, jota ollaan tuottamassa vastaa sille asetettuja vaatimuksia. "

Keski-Euroopan reissujeni perusteella olen ymmärtänyt, että Alankomaissa tämä taiteenlaji on kohtalaisen normaalissa käytössä myös rakennuspuolella. Tai ainakin isommissa kohteissa, joita paikalliset firmat tekevät globaalisti.

Nyt tiedän, mitä aihealuetta selvittelen seuraavat pari vuotta jotta pääsen syvällisempään ymmärrykseen tietomallinnuksen mahdollisuuksista.

Näiden kavereiden termistössä ovat 'kaikki' oikeat sanat: "Integrated Teams, Life Cycle, Requirements, Coordination, Risk Management... jne."

Tästä se lähtee:
http://en.wikipedia.org/wiki/Systems_engineering

Viikon kuva:
Aika tutunnäköisiä ympyröitä






perjantai 1. marraskuuta 2013

Lean Construction seminaaria tarjolla

Lean Construction Instituutti (LCI Finland) tarjoaa seminaarin, jossa kerrotaan Lean Construction filosofiasta, yhteistoimintamalleista, allianssista / IPD:stä jne.

Eli täyttä asiaa kaikille tietomallintamiseen vihkiytyneille henkilöille ja yhteistöille.

http://www.lci.fi/fi/content/lcifin-%E2%80%93p%C3%A4iv%C3%A4-21112013

Ilmottautua voit täällä:
http://www.vison.fi/lcifin-paiva-21.11.2013

Ja ohjelma löytyy täältä:
http://files.kotisivukone.com/vison.fi.auttaa.fi/lcifin-paiva_ohjelma_21.11.2013.pdf

Muut speksit:
Torstai 21.11.2013 klo 9.00-16.00
Niemi Center / Hartwall Areena, Areenankuja 1, 00240 Helsinki


Suosittelen kaikille tämän blogin lukijoille. Jos olet eksynyt näille sivuille, sinun tulee osallistua tähän seminaariin ja laajentaa tajuntaasi...

Viikon kuva:
Oululaista hulluutta: