perjantai 14. joulukuuta 2018

Digitaalinen omaisuus

Tajusin muutama kuukausi sitten erästä esitystä tehdessäni, että toimitilarakentamisen suunnittelukustannukset ovat ~8-10%.

Suunnittelu ei tuota mitään muuta kuin digitaalista aineistoa. Ihmisten aivoista valuu dataa erilaisiin tietoteknisiin järjestelmiin. Yksikään suunnittelija ei ole rakentanut fyysistä seinää tai asentanut kanavaa kattoon.

Tämän lisäksi urakointi ja varsinkin sen alihankinta- ja tavarantoimitusverkosto tuottaa tästä aineistosta omaa näkemystä myös digitaalisesti. Uudelleen ja uudelleen, käyttämättä suunnittelijan aineistoa hyödyksi. En osaa arvioida, kuinka paljon, mutta uskallan väittää, että se on rakentamiskustannuksista luokkaa 5-10%. Täysi mutu.

Kun rakennus on "valmis" (tai siis vastaanotettu), lähestulkoon kaikki tämä aineisto jää suunnittelijoiden, urakoitsijoiden ja tavarantoimittajien servereille.

Tämä tieto ei siirry kiinteistön käyttöön, sen ylläpitovaiheeseen. Tälle asialle ei ole kulttuurista tarvetta olemassa, sopimusmallit eivät tue digitaalisen omaisuuden siirtoa kiinteistön vastaanottovaiheessa. Tulostetaan paperia ja ollaan tyytyväisiä.

Suomessa ei arvosteta rakennetun ympäristön digitaalista omaisuutta.

Tämä digitaalinen omaisuus on siis euromääräisesti ~10% siitä summasta, mitä Suomessa rakennetaan vuosittain.

Statistiikan mukaan (https://www.rakennusteollisuus.fi/globalassets/suhdanteet-ja-tilastot/suhdannekatsaukset/2018/syksy/suhdanne_syksy18_lopullinen.pdf)
rakentamisen arvo vuonna 2017 on ollut 33.6 mrd euroa.

Tuosta summasta 10% lienee lähellä 3,4 mrd euroa. Se on digitaalisen omaisuuden arvo, ilman rakennusurakoitsijan ja sen yhteistyöverkoston tuottamaa digitaalisen tiedon luomista.

Omistaja / rakennuttaja maksaa tämän kaiken.

Omistaja / rakennuttaja maksaa tämän kaiken..

Omistaja / rakennuttaja maksaa tämän kaiken...

Ja tämä omaisuus heitetään menemään, kun rakennus on valmis. Ollaan tyytyväisiä fyysisiin seiniin, kunnes halutaa tehdä peruskorjaus -> aloitetaan digitaalisen omaisuuden luonti uudelleen. Onneksi se on eri organisaation hommia, ei mene hankeporukan budjetista.

Kuvittelisi, että organisaatiot, jotka omistavat kiinteistöjä, ylläpitävät ja saneeraavat niitä olisi kiinnostuneita tästä asiasta.Eipä ole tullut montaa vastaan. Eri organisaatiot, eri budjetit, erilaiset tavoitteet ja strategiat - saman yrityksen sisällä.

Sanotaan, että investori ei ole kiinnostunut rakennuksen kunnosta. Tärkeintä on sijainti, sijainti ja sijainti. Väitän, että jos on samassa sijainnissa kaksi rakennusta, jossa toisessa on tiedossa mitä on tehty viimeisen 20v aikana + mitä korjaustoimenpiteitä tulee tehdä seuraavan 20v aikana, niin se on taloudellisesti arvokkaampi.
Technical Due Diligance on jo melkein tehty, kun taas toisessa juoksee konsultit kolme viikkoa tutkimassa kiinteistön kuntoa saamatta siitä kuitenkaan oikeasti mitään tolkkua.

Minulle rakennuksen Digital Twin on yhtä tärkeä kuin fyysinen rakennus. En pysty hahmottamaan, miten rakennusta pystytään nykyaikana ohjaamaan, jos se ei pyöri pilvessä analysoitavana. Rakennuksen fiilistä tulee pystyä näkemään usean eri asiantuntijan voimin läpi pilvipalveluiden. Sen toimintaa pitää pystyä ennustamaan, sen käyttäjiä tulee pystyä palvelemaan kaikin keinoin.

Tämä onnistuu vain käyttämällä digitaalisia työkaluja. Huoltomies, aulapalvelu, siivous ja hyvä kahvinkeitin ei enää riitä.

Tarvitaan digitaalisen omaisuuden hallintaa - sen johtamista ja strategiaa.


Vuoden kuva:
VR-lobbyssä valitset kiinteistöportfolion rakennuksen / kerroksen / järjestelmän, jota halutaan tarkastella


perjantai 24. elokuuta 2018

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/uutiset/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:










torstai 28. kesäkuuta 2018

Virtual Reality Models in Cleanroom Design


Tämä on kierrätys numero 2/2, kun ei ole mitään uutta kerrottavaa.

Kävin puhumassa puhdastilasuunnittelun seminaarissa "R3 Nordic Symposium" Virtuaalitodellisuuden käytöstä suunnittelussa.

Tässä abstract.

---




Virtual Reality Models in Cleanroom Design

Tero Järvinen
Granlund Oy, Finland
May 2018

Extended Abstract
The use of Virtual Reality (VR) possibilities has increased in recent years due to technology improvements. The driving force has been the gaming industry. The construction sector has been able to benefit from the technology leaps carried out by other industries.

Building Information Models (BIMs) have been in use by architects and structural and mechanical designers since the early 2000’s. In the Nordic countries, using BIMs is a normal way to design and the construction companies are able to utilize these models quite easily.

By combining BIM processes and current VR technologies we are in the situation that the use of VR glasses can be a common means with which the design in construction projects can be promoted.

When combining the VR glasses with models, the end users can obtain a better understanding of what architects and engineers are designing than based only on combined models on a computer screen. With VR glasses on, the users can walk inside the rooms and see objects in real scale.

When the construction process goes further and we have a real environment built up, we can start using Augmented Reality (AR) possibilities. With AR, you can add objects to the camera view of tablets, phones or smart glasses. AR models can utilize the same BIMs as VR is using. Unfortunately, technology in AR systems and software still needs improvements. VR models are easy to set up but AR models need a lot more preparation to work in real-life use cases.

Examples of possible use cases with VR models in the design and construction phases:
·         Checking process functionalities inside Clean Room, moving things in VR
·         Checking service/maintenance possibilities
·         Checking equipment/device locations in the design phase
·         End user approvals/rejections to design team
·         Visual inspection of different lighting environments
·         Multi-user meetings inside Clean Room (attendance from multiple locations)
·         Training of people (device maintenance or processes etc.)

Examples of possible use cases with AR models:
·         Seeing through walls/ceilings (using BIM)
·         Locating equipment/devices (with indoor location or tags attached to devices)
·         Serving additional information to end user for operating devices/to follow protocols (with preloaded material in the cloud)
·         Seeing additional information on top of gauges etc. (using object recognition)
·         Seeing and operating virtual user interfaces on top of QR code etc.
·         Using voice commands for operating AR software (if you need both hands)

Picture: Examples of functionalities in VR models


Processes
The construction process produces BIMs in multiple different formats. Efficient use of VR needs straightforward processes. Access to BIM information is available through an open BIM format called IFC (Industry Foundation Classes). All native BIM modeling software can export IFC-models and these models can be viewed through numerous other software.

Using IFC models as the basis of a VR environment is the most powerful way to create and update VR information during a construction project. With IFC, different disciplines can combine each other’s models and make their own VR models for other use cases from the same source and content.

If the whole design team is using the same native BIM software, IFC is not needed in the process. But in Finland, that’s not a normal case by any means.


Picture: VR/AR models are created from a single source


Devices
VR/AR devices are developing rapidly nowadays. Oculus Rift and HTC Vive have been the best VR glasses for a couple of years. Microsoft launched its “Windows Mixed Reality” platform at the end of 2017 and the cost of VR headsets decreased dramatically. Now there are multiple hardware manufacturers in the market.

Picture: Examples of Windows Mixed Reality Glasses



In the AR sector, there are many different approaches to utilize models.

The easiest way is to use your phone or tablet but in the Clean Room environment that’s not always possible. There needs to be a technology that brings the AR view to your visor or smart glasses.

One working and tested solution is using smart glasses.

Picture: Example of Smart Glasses, Vuzix M300 with Android operating system



In Granlund, we made prototype software using smart glasses with a virtual dashboard.
With that technology, the user can give a simple command using only hands to operate AR functionalities. Functionalities were made for Facility Management purposes, using cloud FM database information, but can also be made with any cloud information that has an interface to connecting data sources.

The software recognizes the hand of the user and draws a virtual dashboard on top of the hand. The user can push the buttons on the virtual dashboard and see more information about the selected topic. The user can change pages by swiping a hand in the air or give “accepted/rejected” commands with a thumb up/down. [1]

It is also possible to use voice recognition, but that was not tested in the Granlund prototype.

Picture: Screenshots from AR Smart Glasses


Information content
When using VR or AR models, the information inside BIMs is still very important. Therefore, access to BIM information is very important for use cases where the information of models is used. Using an open IFC format, information content is understandable to various software platforms.

With IFC, you can build a BIM environment where you can see multiple discipline models in a single, coordinated model. This kind of environment is ideal for VR purposes.

The downside of using the IFC format is that it contains static information. IFC is exported from designers’ native BIMs and is therefore always “old” information, because designers are making updates to native BIMs. In the design and construction phases this is not a big problem, because these phases are used to having iterative information flow in their processes. The designer is publishing a new IFC model, for example, every week to the construction site.

After the construction project – in the Facility Management phase – this kind of process is not possible. Updates to models must be done instantly when something has been changed. To achieve this, we need a Digital Twin of the building or clean room.

Digital Twin
Digital Twin is a representation of a real building, its components, systems, measurements and functionalities. Digital Twin can act as a user interface for AIM (Asset Information Model) [2].

With static asset information from BIMs and a dynamic IoT-sensor or system information from manufacturers’ environments we can build up a system that can be monitored and updated through cloud services. Information from multiple different systems can be seen and operated through a single interface.

With possibilities in cloud software, there is a possibility to update the information in the IFC model seamlessly, without the need of opening complex native BIM software. Native BIM software is needed only when there is a change in graphical objects – you need to move a wall etc.

Using REST API technology, there is a possibility to connect multiple different systems and gather dynamic information from them.


Picture: Example of Digital Twin user interface to monitor temperature, humidity and performance of spaces. This information is also available to a VR/AR environment through REST API.



Picture: Concept of Digital Twin during facility lifetime


With Digital Twin, there are more VR and AR use cases in the future. The digital model comes alive when the user can see dynamic information of clean room in the visor or smart glasses.

References
1.      Demo of using smart glasses with hand gestures
https://www.youtube.com/watch?v=EixdlYRRvAc&t=1s

2.      PAS 1192-3, AIM; “Asset Information Model”. Defined for guideline of using BIM models in operational phase of construction project by BSI, British Standards Institute. https://www.designingbuildings.co.uk/wiki/Asset_information_model_AIM




Virtual Property – Using BIM in Facility Management

Koska uusien ajatusten löytyminen on ollut viime aikoina hankalaa, ajattelin täyttää blogiani vanhoilla jutuilla. Tässä on kierrätys numero 1/2

Alla abstract, jonka jouduin tekemäään erääseen kansainväliseen seminaariin. (Sveitsi, SIA "BIM im Praxis-Check", www.sia.ch

---


Virtual Property – Using BIM in Facility Management
Tero Järvinen, Technology Director, Granlund Oy, Finland

In the Nordic countries, the first BIM models in real construction projects were in use circa 2000. Construction sites took designers’ models into use circa 2005. Subsequently, not many new breakthroughs have been made. The process has been evolving and new requirements on using BIM have been established. The contract methods nowadays support the collaboration between the client, design and general contractor (Alliance- and Integrated Project Delivery –projects).

BIM researcher and developers have also been pushing models to the Facility Management-phase. The work has been more or less “pushing with rope”. Building owner organisations have not been very interested in that topic. However, it seems like developers’ efforts are now succeeding and building owners have an interest in knowing how BIM can help their business.

Using BIM models in Facilities Management is the next logical step after their use for design and construction sites.



Now we are about to take BIM models in use at FM. The task is not so easy. Facilities Management means more than as-built models. Those in the construction business too often do not understand those in the FM business and vice versa. Construction sites are delivering as-built data and FM operators are asking why we need this and how to use it.

BIM from construction sites
Construction sites offer a huge amount of BIM information for different locations in Excel, Word, PDF, etc. Native Revit models or an Open IFC model does not mean that BIM models are in use at FM. These models need information enrichment to be suitable in technical operations. Information has to be available via cloud services and inside databases to make data updating easy. Information sharing within other software also has to be possible.


We also need to remember that 3D-models are nice to have, but the information content is more important. Revit/IFC-models do not have all the information connected to graphical objects. For example, the information on HVAC central units (Air Handling Units, Chillers…) is missing in 3D-models. This information is in Device Schedule and, unfortunately, the most common case is that the schedule is made with Excel without standardised content. FM operations also need MEP diagrams, Service Area Zones, etc. This information can be created during the design/construction phase, if it is ordered from the designer.

If information content is standardised, everything is much easier to Facility Management software. When IFC-models or information in cloud services are in machine readable format, importing the information is easy and the software business could also be more scalable. However, on the other hand, who believes in the global level standardisation of information in the construction industry?

Sharing information is the new Black
Information sharing with other software is the new black in the building sector. Building owners do not want to stick with one gigantic software solution. Earlier, software developers wanted all the data in their databases. To own information was important. Nowadays, sharing information is more important. Sharing data means you can create new information from data founded from multiple sources.

If you have a temperature of a room coming from the Building Automation system and a CO2 level from an IoT sensor, you can create an algorithm which shows you with good accuracy the number of people in the room and with a timeline. With this new information, you can create a new use case which is sellable to your client.




Digital Twin
Digital Twin is a representation of a real building along with its components, systems, measurements and functionalities. Digital Twin can act as a user interface for the AIM-model (Asset Information Model) [2].

With static asset information from BIM models and dynamic IoT-sensor or system information from manufacturers’ environments, we can build a system which can be monitored and updated through cloud services. Information from multiple different systems can be seen and operated through a single interface.

With the possibilities provided by cloud software, there is a possibility to update the information in the IFC model seamlessly, without the need for opening complex native BIM software. Native BIM software is needed only when there is a change in the graphical objects – you need to move a wall, etc.

Using REST API technology, there is a possibility to connect multiple different systems and gather dynamic information from them.





City Digital Twin
The next step after BIM in FM will be the city level adaptation of models. Many cities have already an open platform to connect CityGML models. In the City of Helsinki, all the buildings have unique identifiers allowing for a BIM model connected to the city level view. With one click, you can open your building from an intelligent city model.

Conclusion
The technology for answering these questions is ready. Now, we need software developers who have the courage to make software now for future clients. PowerPoint presentations do not thrill anyone – we need a running prototype of ideology on how BIM models are in use at facility management.
Thereafter, we will move towards FLM – Facility Life Cycle Management.




lauantai 28. huhtikuuta 2018

TATE-määrälistoja ei urakoitsija tule näkemään

Viime vuoden lopulla saatiin päätökseen KIRA-digihanke "Talotekniset määräluettelot urakkalaskentaan".

Toimin buildingSMART Finlandin TATE-työryhmän vetäjänä, joka oli tätä KIRA-digihanketta hakenut.

Loppuraportti on ladattavissa täältä:
http://www.kiradigi.fi/3-kokeiluhankkeet/kokeiluhankkeet/talotekniset-maaraluettelot-avuksi-urakkalaskentaan.html

Hanke oli kohtalainen tuskien taival. Onneksi se oli "kokeiluhanke", jossa yhtenä aspektina on aina epäonnistumisen mahdollisuus.

Epäonnistuimmeko tässä hankkeessa?

Jos katsoo projektisuunnitelmaa, niin vastaus on selkeästi "Kyllä".

Emme löytäneet todellisia urakkalaskentaprojekteja tähän hankkeeseen, jotta olisimme voineet testauttaa bSF:n laatimaa ohjeistusta määräluetteloiden käyttämiseksi:
https://buildingsmart.fi/wp-content/uploads/2016/11/YTV2012_Taydentava_liite_TATE_Prosessiohje.pdf
ja
http://tietomalli.blogspot.fi/2015/12/51-miljoonan-euron-saasto-vuodessa-sis.html

Jos asiaa katsoo jatkuvan parantamisen periaatteilla, niin vastaus on "Ei".

Voidaan todeta, että meillä on vielä paljon parannettavaa - koko rakennusalan laajuudessa. On mielestäni piristävää nostaa esiin fiksuja kehitysehdotuksia, jotka eivät kuitenkaan syystä tai toisesta tule käytäntöön.

Välillä tuntuu, että ratkaisut rakennusalan tai sen tuottavuuden kehittämiseen ovat liian yksinkertaisia. Ongelma on siinä, että usean ihmisen tai organisaation tulee tehdä samanaikaisesti tätä kehitystä. Tästä syystä allianssihankkeissa kehittäminen on mahdollista. Kaikilla osapuolilla on lupa toimia toisin / innovatiivisesti.

Toisin sanoen, "bottom-up" malli ei toimi rakennusalan kehittämisessä.

Tarvitsemme Kekkosen, joka sanoo miten toimitaan - ja sen jälkeen alkaa suorittavassa portaassa tapahtua.


Tässä copy/paste loppuraportista, eli analysointia siitä, miksei pilottikohteita löytynyt:
---
Miksi projekteja ei löytynyt? 
Suureksi pettymykseksi emme pystyneet vakuuttamaan todellisten hankkeiden vetäjiä siitä, että määrätietojen antaminen TATE-urakoitsijoiden käyttöön olisi kokonaisuuden kannalta hyvä ratkaisu.

Syitä projektien löytymättömyyteen ovat ainakin seuraavat aiheet:

BuildingSMART Finlandin sisäiset asiat:
- Ryhmässä olevat jäsenet kuuluvat pääsääntöisesti yritysten kehitysorganisaatioihin. Heillä ei ole henkilöinä suuriakaan mahdollisuuksia vaikuttaa yritysten liiketoiminnallisten projektien vetämiseen.
- BuildingSMART toimii ”harrastajapohjalta” ja jokaisella jäsenellä on selkeästi päätyö ensimmäisenä prioriteettina. Projekteja olisi voinut hankkia tarmokkaamminkin, mutta ajankäytöllisistä syistä siihen ei ollut mahdollisuuksia. Ydinjoukko hankkeen organisoinnissa oli kohtalaisen pieni, noin viisi henkeä.
- Jotta projekteja olisi löytynyt, olisi tullut panostaa enemmän yritysten johdon vakuuttamiseen asian kokonaistaloudellisesta tärkeydestä. Nyt keskustelimme projektinvetäjätasolla, jolloin helposti taloudellisessa vastuussa oleva projektipäällikkö ei halua ”ylimääräisiä” tehtäviä mukaan projektiinsa – varsinkin kun rakennusprojekti on alkuvaiheessa ja muita järjestettäviä asioita on paljon avoimena.

Ulkopuoliset asiat: 
- Projekteja ei löytynyt oletettavasti siitäkään syystä, että kenenkään hankkeiden käynnistämisessä mukana olevien henkilöiden intressissä ei ole luovuttaa määrätietoja urakoitsijoille. Ajatellaan ehkä vain käynnistettävää, yhtä hanketta, näkemättä kokonaiskuvaa Suomen mittakaavassa.
- Projektien löytymiseen vaikutti myös aikataulu, sillä tieto määräluetteloiden käyttämisestä hankkeessa olisi pitänyt saada mukaan jo suunnittelijoiden tarjouspyyntöihin. Tämä tarkoittaa sitä, että olisi tarvittu hankesuunnitteluvaiheessa oleva projekti, jossa tilaajan edustus olisi ollut avarakatseinen hankkeen päämääriä kohtaan.
- Koska rakennusalan kehitystä ei pystytä toteuttamaan ruohonjuuritasolta, tulisi yritysten johdon sekä rakennushankkeita tilaavien osapuolten nousta vaatimaan uusien, toimivaksi osoitettujen toimintatapojen käyttöönottoa

Eräänä syynä projektien löytymättömyyteen pidän henkilökohtaisesti sitä, että rakennusalalla puuttuu halu kehittää omaa osaamistaan. On helpompi tehdä kuten ennenkin, vaikka pystytään osoittamaan uusien prosessien hyödyllisyys hankkeelle.
Yleisesti rakennushankkeen eri osapuolten keskuudessa on todettu, että määrälistojen käyttö hankkeissa olisi ehdottomasti järkevää. Siitä hyötyisivät kaikki osapuolet, se toisi urakoitsijoiden tarjoushintoja lähemmäksi toisiaan jolloin voitaisiin tehdä vertailukelpoisia urakoitsijavalintoja.
Lisäksi suunnitelmien laatu nousisi pienen pykälän, sillä kun suunnittelijalla on tiedossa, että kohteesta otetaan määrälistat, aletaan kiinnittää enemmän huomiota tietomallien tietosisällön oikeellisuuteen.

---

Henkilökohtaisesti tämä oli minulle viimeinen taisto määrälistojen puolesta puhumisessa. Nyt pitää vaihtaa henkilöitä, sillä 20v olen tästä puhunut / yrittänyt ja tuloksia ei ole tullut. Vedän siis "omat johtopäätökset".


Viikon kuva:


lauantai 2. joulukuuta 2017

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





perjantai 3. marraskuuta 2017

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..."