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:
---
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:
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
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:
Ei kommentteja:
Lähetä kommentti
Kerro mielipiteesi, palautteen kautta saadaan eri näkökulmia