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

Onko rakennuksella Sielu?

Perinteisen vertauksen mukaisesti rakennuksen LVIS-tekniikka vastaa ihmiskehon verisuonia, keuhkoja, hermoja. Rakennusautomaation vastine on löytynyt aivoista, joskin nykytietämyksellä pari valvonta-alakeskusta taitaa löytyä viemäröintijärjestelmästäkin.

Missä on rakennuksen Sielu?

Onko se henkistä höpinää vai muodostuuko se pienten teknisten järjestelmien yhteistoiminnallisuudesta? Uskommeko, että rakennuksella on Sielu – kuolleella, elottomalla betoni- ja rautakasalla?

Onko rakennuksen Sielu sen käyttäjät ja heidän tuottama toiminta? Miten keho (rakennus) suhtautuu käyttäjien tekemiin valintoihin – tatuointeihin iholla, peseytymättömyyteen (grafitteihin, siivoukseen)?

Ilmanvaihtosuodattimien vaihtamattomuus, koneiden väärät käyntiajat, rasvasäiliön tyhjentämättömyys, taajuusmuuttajien manuaalisäädöt?

Jotkut meistä ovat narkkareita, alkoholisteja, tupakoitsijoita. Jotkut hyppivät silloilta (laskuvarjon kanssa ja ilman). Onko heidän VAK sekaisin? Onko heitä huollettu?

Alkaako rakennus reagoida - homehtua, rapistua, vuotaa jos sitä ei hoideta? Jokainen meistä käynee silloin tällöin kävelylenkillä tai hoitaa muuten oman kehon hyvinvointia. Näin saamme raikkaan olotilan ja pystymme jopa psyykkisesti olemaan tyytyväisiä itseemme – onnistuinpa juoksemaan 5km!

Voiko rakennus tehdä itse jotain oman hyvinvointinsa eteen? Tuskin, se on kuin ikuinen lapsi, joka vaatii ulkopuolista hoitoa. Rakennukset eivät pysty itseään korjaamaan, siihen vaaditaan ulkopuolista apua ja reagointia, joko ennakkoon tai jälkikäteen.

Ihmisen ajatukset päättävät, että nyt on tehtävä keholle jotain. Samalla logiikalla kiinteistöjen käyttäjien tulisi reagoida ympärillä rapistuvan rakennuksen ongelmiin. Kertoa siitä eteenpäin, vaatia toimintaa päättävän tahon puolelta.

Jos kiinteistön käyttäjät eivät reagoi, rakennuksen aivojen – rakennusautomaatio yhdistettynä ylläpito-ohjelmistoon – tulee puuttua asiaan. Limbinen järjestelmä ottaa ohjat. Tajuttomuus muuttuu ylläpitomoodiin, pitäen potilaan hengissä kunnes tulee lisäapua.

Asioihin tulee puuttua ennakoivasti, ei jälkikäteen. Rakennuksen olotila tulee pystyä ennustamaan vähintään viikon päähän käyttäen apuna esim. säätilaa sekä tulevaa käyttökuormaa. Rakennuksen pitää tietää, mikä olotila sillä oli vuosi sitten vastaavissa olosuhteissa. Rakennuksen tulee käydä silloin tällöin lääkärissä, jotta pystytään selvittämään missä mennään elinolosuhteiden kanssa. Mitä vanhempi rakennus, sitä tiheämpi lääkärivierailu.

Ihmiset ovat valloittaneet maapallon, koska olemme sopeutuvia. Emme valita ihan joka asiasta. Tai sitten 3% meistä valittaa kaikesta. Tämä on ongelma rakennuksia ylläpitäville organisaatioille. Koska palautetta rakennuksen toimivuudesta tulee kohtalaisen vähän ja se on epätasapainossa laadun suhteen, meillä pitää olla kyky analysoida rakennuksen teknistä toimivuutta sekä käyttäjien fiilistä teknisillä ratkaisuilla. Tässä auttaa sisätilapaikannus, erilaiset automaattiset mittaroinnit (ääni, hiilidioksidi, palkkapäivä, lämpötila, vuodenaika, mieliala, kasvojen ilmeet, liike, valoisuus, sijainti, työntekijöiden kalenterit…), tiedon keräys ja sen perusteella tehtävät analysoinnit. Analysointien lopputulokset ohjaavat kiinteistöä – ei huoltohenkilökunta.

Tästä kerätystä tiedosta rakennuksen tulee oppia käyttäytymään tarpeen mukaisesti. Onko perjantaisin vähemmän henkilöitä rakennuksessa kuin tiistaisin? Missä osassa rakennusta he ovat torstaina? Miten optimoin käyttäytymiseni parhaalla mahdollisella tavalla?

Huoltohenkilökunnan tehtävä on varmistaa, että tekoäly ei tee idioottimaisuuksia, joita se voi hyvinkin tehdä. Emme pysty ylittämään ihmisaivojen kapasiteettiä ymmärtämisessä ja asioiden riippuvuuksien analysoinnissa. Asiansa osaavia huoltomiehiä tarvitaan aina, jotta pystymme muodostamaan inhimillisen kontaktin rakennuksiin ja sen käyttäjiin. Paras huoltomies on rakennuksessa, halvempi löytyy valvontakeskuksesta.

Pääsemme Toimivan Kiinteistön käyttöön, kun osaamme tehdä toimivan kiinteistön. Näitä kiinteistöjä on jo tehty useita. Ne eivät näy lehdissä, ne eivät kohoa tilastoissa. Ne toimivat, kuten ne on suunniteltukin toimivan. Tilaaja on panostanut siihen, että kokonaisuus on kunnossa.

Miten tähän päästään? Ei todellakaan antropologian kautta, vaan tekemällä normaali suunnittelutilaus, asettamalla selvät tavoitteet, valitsemalla suunnittelutiimi, joka ymmärtää tavoitteet ja osaa tehdä yhdessä töitä. Tilauksen tekijän tulee tietää, mitä hän haluaa. Sitä ei voi ammattitaitoinenkaan rakennuttajakonsultti kertoa – pitää olla tunne tekemisestä, jonka tietää oikeaksi.

Tiimi luo yhdessä tilaajan kanssa rakennuksen, joka täyttää tilaajan tavoitteet. Tiimi ymmärtää, että elämän tarkoitus ei ole valaa betoniseiniä, vaan saada niiden sisälle asiakas jota seinä palvelee. Asiakas tarvitsee elinkaariystävällisiä, omiin tarkoituksiinsa toimivia tiloja toiminnoillensa.

Tarvitsemme virtuaalisen kiinteistön, jonka avulla ohjataan todellista kiinteistöä. Haluamme tuottaa toimivia rakennuksia, jossa käyttäjä ja kiinteistö kommunikoivat keskenään.

Tarvitsemme rakennukseen sielun, joka ylläpitää fyysistä - todellista kokonaisuutta.

Kohti ajattelevaa, oppivaa rakennusta.

Viikon kuva:

Innovaatiostrategia 2021

Tiedon keruu - Visualisointi - Analysointi - Raportointi - Ennustaminen - Oppiminen - Ajatteleva kiinteistö -  Fyysisen kiinteistön ohjaaminen. Tekoäly.

Virtuaalinen kiinteistö, missä käyttäjä ja rakennus kommunikoivat keskenään

Osallistu TATE-tietomallikyselyyn

Johanna tekee YAMK opinnäytetyötä TATE tietomallien käytöstä - osallistu kyselyyn ja kehitä alaa eteenpäin!

---

Hei!

Teen Ylemmän Ammattikorkeakoulun opinnäytetyöhöni liittyen kyselyä TATE -tietomallien suunnittelumenetelmien kehittämisestä ja mallien käytöstä työmaalla.

Tietomallintaminen Suomessa pohjautuu pitkälti buildingSMART Finland:n julkaisemaan YTV2012 ohjeeseen, jonka mukaan useimmat tietomallikohteet suunnitellaan yleensä rakennusvaihetta tukevaksi malliksi. Tasapainoilu 2D–suunnitelmien laadinnan ja toimivan tietomallin rajamaastossa on osoittautunut välillä haastavaksi tässä käynnissä olevassa tekijämurroksessa. Itse LVI–suunnittelijana näen tätä tasapainoilua työssäni päivittäin miettien että siitä tietosisällöstä jota tuotamme, käyttöön päätyy vain murto-osa. Tähän toivon alalla muutosta.

Yleisesti vahvaksi mielipiteeksi työmaan suunnalta on noussut TATE-suunnitelmien puutteellisuus – miten mallia voi olettaa käytettävän jos yhteensovitus on puutteellista ja asioita jää ratkottavaksi työmaalle?

Kanna siis kortesi kekoon ja vastaa alla olevan linkin avulla kyselyyn - ja vaikuta tärkeän yhteistyön kehittämiseen!

https://fi.surveymonkey.com/r/582SJPK

Johanna Lankinen

johanna.lankinen@granlund.fi

Virtuaalinen rakennus

Kehitys menee välttämättä siihen suuntaan, että meillä tulee olemaan kaksi rakennusta.

Todellinen ja virtuaalinen

Tuleva todellinen rakennus toimii paremmin kuin nykyiset rakennukset, koska virtuaalinen rakennus ohjaa sen käyttöä.

Nykyinen todelinen rakennus ottaa vastaan huoltomiehen tekemiä manuaalisia säätöjä ilman, että joku asiaa ymmärtävä henkilö ottaa niihin kantaa.

Virtuaalinen rakennus ei reagoi huonoihin ohjauskäskyihin. Se kertoo asiasta valvojalle tai analysoi tilanteen itse. Sen jälkeen tehdään säätötoimenpiteet - jotka tekoäly olisi tehnyt muutenkin.

Jollei joku rakennuspelastusaktiivi ole hakkeroinut järjestelmää ennen sitä.

Tekoäly muuttaa rakennusten ohjauksen. Rakennukset tulee tietämään itsestään enemmän kuin ihminen. Rakennukset ovat niin monimutkaisia kokonaisuuksia, että niitä ei yksinkertaisesti pysty ruohonleikkaaja ohjaamaan.

Rakennus ohjaa itseään optimaaliseen tilanteeseen, ottaen huomioon huomisen ihmismäärän, säätilan, auringon suuntauksen, ja henkilökunnan käyttäytymisen tiettynä viikonpäivänä. Rakennus muistaa, mitä sille kuului vuosi sitten samanlaisissa olosuhteissa. Se seuraa ihmisen liikettä rakennuksessa päivän aikana, tuottaen aina tavoitteen mukaiset olosuhteet tarvittavana kellonaikana - ennakoiden tulevat tapahtumat, säätäen olosuhteet ennustetun käytön mukaisesti.

Tekoäly tulee olemaan viisaampi kuin ihminen. Siihen menee ehkä muutama vuosikymmen, mutta näkymä tulevaisuuteen on selvä.

Me teimme sen.

Tietokoneet päihittävät ihmisen.

Viikon kuva:
Ruudunkaappaus netistä.

API pelastaa maailman

Töissä, minun tehtäväni on kehittää prosesseja.

Yksi näistä teknisistä asioista kulminoituu jälleen kerran kolmikirjaimiseen akronyymiin: API.
Application Programming Interface, https://fi.wikipedia.org/wiki/Ohjelmointirajapinta

Ja tuon jälkeen voisi käydä vilkaisemassa tätä. http://avoinrajapinta.fi/

En osaa koodata. En ymmärrä softien sielunelämää. Mutta saan (onneksi) käyttää niitä töissäni.

Edustamani organisaation sovelluskehityksessä tietojen linkitys ja siirto/kopiointi on ollut mielestäni selvää aina. Mutta vasta viimeisten kuukausien aikana olen nähnyt sellaista kehitystä, mitä olen olettanut meillä olleen jo 4v. sitten.

Vasta nyt olen nähnyt rajapinnan, johon voi toinen yritys/softa integroitua muutaman päivän työllä. Vasta nyt minun powerpointtini alkaa toimia. En ymmärrä, miksi asiaa piti harjoitella 4 vuotta. Miksi softakehitys tekee itselleen helppoja ratkaisuja? Siirtelee tietoja omien tietokantojensa sisällä siten, että kolmannella osapuolella (tai edes itsellään) ei ole mitään mahdollisuutta tajuta, mitä tapahtuu? Mikseivät he ajattele kokonaisuutta joka on ulkona heidän softastastansa.

Teemme yhteistyötä erään globaalin pelaajan kanssa, Tässä projektissa linkitys Granlund Designerin ja Revitin välillä on ehdoton vaatimus. Miten linkki tehdään -> tietenkin API:lla !

Softa-arkkitehtimme oli tehnyt jo aikaisemmin avoimen API rajapinnan (https://designer-demo.granlunddesigner.fi/api/index ). Täysin nonsense for me...

Mutta tällä tiedolla ulkopuolinen koodari otti yhteyden parin tunnin koodauksella ja parilla sähköpostilla järjestelmäämme, Luki tietoja sekä kirjoitti niitä takaisin systeemimme. Päivän yhteisen hackathonin jälkeen meillä oli proto softan toiminnallisuuksista valmiina.

API, joka voidaan julkaista ulos vapaasti on ehdoton edellytys tietojen linkittämiselle. Olemme itse sählänneet useita integraatioprojekteja koska olemme oikeisseet muutamia mutkia, alittaneet riman väärissä paikoissa. Kunnollinen softa-arkkitehtuuri avoimien rajapintojen aikaansaamiseksi tietää töitä, mutta voitto häämöttää horisontissa. Elämä (ja markkinointi) helpottuu, kun tietää ja ymmärtää olevansa pieni osa kokonaisuutta, johon voi kytkeytyä avoimen API:n kautta.

Nykyisessä maailmassa ei ole softaa, joka on keskiössä, hallitsee "kaikkea" tietoa. Softat on ulkoradalla ja linkittyvät toisiinsa API:en kautta. Näin ainakin tällä hetkellä, kunnes joku keksii "väylän" jolla pelastetaan koko maailma... jonka kautta tieto siiryy simpsalabim järjestelmästä toiseen (mahtaakohan tuokin toimia apien kautta...).

Tämä on hienoa minulle, powerpointeissa oleva laatikot ja niiden välissä olevat viivat alkavat muodostua ohjelmistoiksi.

Viikon kuva:
Thanks Steven;

Havainnollistamisen todellisuus v.2016

Tuomaisen Juha kirjoitti hienon blogin havainnollistamisen historiasta:

https://energistarakentamista.com/2016/10/05/virtuaalisesti-suunniteltu-on-puoliksi-tehty/

Itse luulin muutama vuosi sitten, että VR on menneen talven heiniä, se on jo nähty. Ajattelin, että AR on tällä ihan kohta.

Vaikuttaa siltä, että VR on täällä nyt ja AR on jossain tulevaisuudessa - otetaan siis virtuaalimaailmasta kaikki irti ja odotellaan tekniikan kehittymistä lisätyn todellisuuden puolella.

Viikon kuva:
Totta vai tarua:

BIM2FM ver. 2

Konsepti "tietomallit ylläpidossa" alkaa pikku hiljaa hahmottua.

Reunaehtoja löytyy ja tämän paletin kanssa pitää pystyä toimimaan:

Tässä teesini BIM2FM projektia miettivälle suunnittelijalle, softatoimittajalle ja asiakkaalle:

1. Tietosisältö on oltava standardisoitua

 Tieto on oltava koneluettavissa järjestelmästä toiseen

2. Tietosisältö on priorisoitava

Tietoa on liikaa, sen oikeellisuuden varmentaminen on työläs operaatio

On tehtävä valinta, mitä tietoa arvostetaan ja mihin käyttötarkoitukseen se on luotu

3. Tieto on oltava käytettävissä 24/7

Pilvipalvelujen tieto on käytettävissä jatkuvasti eri ohjelmistojen välillä

Pilvipalveluun pystyt luomaan käyttäjille erilaisia rooleja ja käyttöoikeuksia

4. Tietoa ei siirretä

Tieto linkitetään järjestelmien välillä

Loppukäyttäjä päättää, mitä tietolähdettä pitää tiedon ”kotina”

Yksi pilvipalvelu ei ratkaise kaikkia ongelmia.

Useisiin käyttötarkoituksiin tarvitaan useita eri pilvipalveluja.

Oikea tieto löytyy hakutulosten kautta, priorisoiden samat vastaukset ensimmäisiksi hakulistoilla.

5. Tietoa on päivitettävä

Kiinteistössä on ylläpidettävä sekä virtuaalista rakennusta, että todellista rakennusta

Jos virtuaalisen rakennuksen tietosisältö poikkeaa todellisesta rakennuksesta, sen tietosisältöön ei voi luottaa -> käyttö hiipuu vuosien saatossa

6. Normaali ylläpitoprosessi muuttuu erilaiseksi

”Tietomallit ylläpidossa” –käytettävyyttä ei voi verrata nykyisiin käyttötapauksiin

Tietomallien käyttö luo uusia toimintatapoja.

Kiinteistöorganisaation on oltava valmiita muutokseen.

"Tietomallit ylläpidossa" teema ei toimi nykyisissä prosesseissa. Nykyiset prosessit tulee haudata ja luoda uusia.

7. Tietomallit ylläpidossa ei ole 3D-dokumenttienhallintajärjestelmä.

8. Ymmärrettävä mikä on ero “Teknisellä ylläpidolla” (laitteet), “Tilahallinnalla” (neliöt) ja “Johtamisen työkalulla” (eurot)

9. Ymmärrettävä ero staattisella ja dynaamisella tiedolla

Staattinen tieto on IFC-malleissa. Dynaaminen tieto on antureissa.

10. Ymmärrettävä ero käyttäjällä ja kiinteistöhuollolla

Jätin tämän kympiksi; kaikista tärkein asia:
Kiinteistön omistajan asiakas on käyttäjä, ei huoltotoiminta. Asiakkaan etu on kaikista tärkein. Ihan sama, onko suodattimet vaihdettu jos lamppu on pimeänä.

11. Bonuspointti
Nykyään isommat kiinteistöt omistaa investori. Erilaiset Due Diligance -tsekkaukset nousevat arvoonsa. Pelkkä LEED ei aina riitä (toivottavasti)

Yllämainitun palikan päälle pitäisi alkaa rakennella softaa.

Helppo homma, tekemistä vaille valmis.

Puolen vuoden kuva:

½ vuoden kuva 2:

Valitettavasti olen myös tätä mieltä. Tieto on oltava hajautettuna
(c) http://lod-cloud.net/  / Trimble (Tekla).