Työelämässä jokaisen rohkeus ratkaisee

Suomalaiset toivovat vuodelta 2016 rohkeutta ja johtajuutta. Tämä oli yhteenveto Helsingin Sanomien vuoden vaihteessa teettämästä kansalaiskyselystä.

Olen harrastanut partiota ja se on harrastus, jossa johtaminen on läsnä kokoajan. Partio on hyvä harrastus myös siksi, että siinä oppii, että johtajuutta ja rohkeutta on hyvin monenlaista.

03 partiotaitokisat 2011
Kuva: Suomen Partiolaiset http://www.partio.fi

Esimerkki. Järjestimme metsäviikonlopun, jossa suunnistettiin. Yksi lapsiryhmä eksyi viimeisellä rastivälillä ja tuli jo pilkkopimeä. Eksynyt ryhmä pysyi tyynenä, rohkeana, minkä lisäksi joukosta löytyi johtajuutta siitä, miten nyt toimitaan. Suunnistuksen järjestävä ryhmä teki päätöksiä, miten etsintöjä tehdään ja päättää milloin tuli aika kutsua poliisi apuun.

Viranomaisten avustuksella lapset löytyivät muutaman tunnin kuluttua ja kaikki nukkuivat yönsä lämpimässä. Uudenlaista johtajuutta ja rohkeutta tarvittiin, kun ymmärrettiin, että vanhemmathan tässä eniten pelästyivät. Seuraavana päivänä järjestettiin tilaisuus vanhemmille, joka vedettiin kunniakkaasti läpi.

Akuutin tilanteen ratkettua tehtiin vielä päätöksiä siitä, millaisia muutoksia niin sanottuun perustoimintaan tehdään. Lähtökohdat olivat kuitenkin kunnossa. Lapset olivat selvinneet hienosti toiseksi viimeiselle rastille asti, ja herpaantuessaankin he selvisivät tilanteesta esimerkillisesti.

Kenellä tässä tilanteessa oli eniten rohkeutta tai parasta johtajuutta?  Lapsella, joka otti tilanteen haltuun pimeässä metsässä? Nuorella, joka teki päätöksen kutsua lisäapuja etsintään? Vai nuorella aikuisella, joka tyynesti otti vastaan lasten vanhemmat?

Vastaus toki on, että kaikkien rohkeutta ja johtajuutta tarvittiin. Jos yksikin olisi puuttunut, tilanne oli päättynyt hyvin eri tavalla.

Millaista on rohkeus työelämässä?

Asiantuntijaorganisaatiossa jokainen työntekijä johtaa ja jokainen on rohkea.

Jos partioesimerkistäni vetää yhtymäkohtia työelämään, voi kysyä samaan tapaan, kenellä työyhteisössä on eniten rohkeutta tai parasta johtajuutta?

RW_OlliSalo2
Kuva: Suomen Partiolaiset http://www.partio.fi

Asiantuntijalla, joka ratkoo haasteita ja keksii se olennaisen? Projektipäälliköllä, joka saa projektitiimin toimimaan saumatta? Esimiehellä, joka huolehtii ryhmänsä työkannasta? Yritysjohtajalla, joka tekee uuden yrityskaupan?

Jälleen vastaus on sama: kaikkien rohkeutta ja johtajuutta tarvitaan ja jos yksikin puuttuu, tilanne päättyy hyvin eri tavalla.

Idolista oppia

Kuinka siis löytää itse itsestään oikeanlaista sekä omanlaista johtajuutta ja rohkeutta?

Johtajuus ja rohkeus ovat vahvasti sidottuna oman persoonaan ja temperamenttiin, joten itsetutkiskelu on suotavaa. Koulutusta ja kirjoja on. Elämänkokemus on myös yksi hyvä. Harvemmin tulee kuitenkaan keskusteltua siitä, että kuka johtaja on itse kukin idoli, esikuva tai roolimalli. Näitä on hyvä olla. Kuka on siis sinun idolisi?

Koska itsensä johtaminen on tärkein osa-alue, on hyvä katsoa lähelle. Kenellä lähipiirissä tuntuu olevan homma hanskassa? Mitä häneltä voisi oppia?

Idoli, roolimalli tai esikuva löytyy todennäköisimmin jostain kauempaa. Ehkäpä täysin eri toimialalta, maailmalta tai historiasta. Jotta idolia voi kunnolla fanittaa, häntä ei voi tuntea hyvin, mutta hänen ominaisuuksiaan täytyy ihailla ja ammentaa niistä itselleen.

Nyt pahoittelut kaikille esimiehille. Idoli ei käytännössä koskaan ole oma esimies. Esimiestä pääsee liian lähelle ja hänet näkee kokonaisuutena.

Jos olet esimies, jota kunnioitetaan, voit tuulettaa! Silloin on jo hyvin todennäköistä, että olet jonkun toisen osaston henkilöiden silmissä idoli.

GC_Miia_Anttila

Kirjoittaja on 1.6.2015 perustetun Granlund Consulting Oy:n toimitusjohtaja, jolle vuoden 2015 tärkeimpiä teemoja olivat rohkeus ja johtajuus. Kun tekee työelämään liittyviä isoja liikkeitä, asiasta tekee mittavan Due Diligencen. Kun kaikki riskit ja mahdollisuudet on kartoitettu, viimeiseksi kysymykseksi jää: löytyykö minusta tarpeeksi rohkeutta?

Kertaluontoisesta TDD-prosessista rullaavaan toimintaan

Kirjoittaja: Ville Reinikainen

Kiinteistökauppamarkkinoilla on ollut viime aikoina vauhdikasta. Muun muassa matala korkotaso ja rahoituksen saatavuus ovat vilkastuttaneet kiinteistökauppaa Suomessa. Saatavilla olevien tietojen perusteella sama meno jatkuu tänäkin vuonna ja kauppoja tullaan tekemään paljon.

En ole pätevä henkilö ennustamaan kiinteistökaupan kehitystä tämän laajemmin (ja tuossakin taisi olla jo vähän liikaa). Ajattelin kuitenkin tässä blogissa tarkastella vilkasta kiinteistökauppamarkkinaa teknisten due diligence -selvitysten (TDD) näkökulmasta. Tämä on itselleni huomattavasti tutumpi aihepiiri kuin kiinteistökauppamarkkinan kehittyminen.

Aihe on tuttu, koska vilkkaasta kiinteistökaupasta muodostuu loogisesti voimakasta kysyntää myös TDD-sektorille. Tähän kysyntään vastaamisen parissa olemme painiskelleet melkoisella urakalla viime kuukausina ja vuosina. Ja hyvä niin, että töitä riittää tehtäväksi.

Granlund Consulting Omaisuudenhallinta www

Mikä ihmeen TDD?

TDD-selvityksen tarkoituksena on nostaa esiin kaupan kohteena olevan kiinteistön merkittävimmät tekniset riskit ja niiden kustannusvaikutukset. Tekniset riskit liittyvät yleisimmin kiinteistön kuntoon ja käyttöön.

Keskeisiä TDD:n tuloksia ovat muun muassa arvio kiinteistön korjausvelan hallintaan sisältyvistä investointikustannuksista (Capex) esimerkiksi 10 vuodelle sekä kohteen operatiiviseen ylläpitotoiminnan vuositason kustannukset (Opex) nykykunnossa.

Tämän lisäksi TDD-selvityksessä kannattaa huomioida myös muita osa-alueita, kuten kohteen kaava-, rakennuslupa- ja rasiteasioihin liittyviä riskejä sekä arvioida kohteen energia- ja ympäristötehokkuutta elinkaarivaikutusten näkökulmasta.

Yhtä kaikki, selvityksen tulisi, kauppatilanteen sopimusneuvotteluja ja päätöksentekoa varten, antaa sovitussa laajuudessa mahdollisimman hyvät tiedot asiakkaalle kohteen teknisestä suorituskyvystä sekä siitä aiheutuvista kustannuksista kohteen ylläpidon aikana.

Millainen on ”tyypillinen” TDD-projekti

TDD-projekteille on tyypillistä, että niitä tehdään kireällä aikataululla suurille kiinteistöjoukoille kerrallaan ja vieläpä sesonkiluonteisesti niin, että pahimmat ruuhkat ajoittuvat juhannuksen ja vuodenvaihteen lähimaastoihin.

Kevyimmilläänkin tehtynä, laadukkaan ja luotettavan lopputuloksen saavuttamiseksi, TDD-projekti vaatii aina vähintään kolmen asiantuntijan (rakenne, LVI ja sähkö) fyysistä, matkoineen useamman tunnin kestävää, kohdekäyntiä. Työtunteja palaa siis lyhyessä ajassa paljon, jos kolmen viikon aikana pitää katselmoida esimerkiksi 30 kohdetta ympäri Suomea sekä raportoida englanniksi. Tämä aiheuttaa voimakasta painetta sopivien resurssien saatavuudelle, jonka vuoksi päteviä tekijöitä haalitaan joskus kasaan myös yhteistyössä useamman toteuttajan voimin.

Projektia ei kuitenkaan voi toteuttaa hajanaisilla resursseilla hätäisesti kasaan vedettynä. TDD-tuloksilla saattaa olla merkittäviä vaikutuksia kauppasopimukseen. Onpa joskus kaupat kokonaan peruuntuneetkin TDD –löydösten pohjalta.

TDD-projektiryhmältä vaaditaankin omien substanssialueiden vankan ymmärtämisen lisäksi ripaus poikkitieteellisyyttä, kykyä etsiä oleellinen tieto tehokkaasti ja konsultointitaitoa sekä yhdistää että välittää nämä oleelliset tiedot kiinteistökauppaprosessin hyödyksi.

Voisiko jotain tehdä toisin?

Ja vaikka tekijät ovat päteviä ja lyhyessä ajassa tehdään laajaan tietoon pohjautuen parhaat mahdolliset johtopäätökset TDD-raportille, herää silti muutamia kysymyksiä:

  • onko TDD pakko toteuttaa aina koko laajuudessaan ja niin järkyttävän lyhyessä ajassa?
  • löytyisikö keinoja varmistaa, että mahdollisimman laajat ja oikeat tiedot olisivat varmuudella käytettävissä TDD:n laatimisen hetkellä?
  • olisiko kohteen vuokralaistoiminnan vaikutukset investointeihin (esim. vuokrasopimuksen kesto ja toiminnan luonne) paremmin huomioitavissa TDD-prosessin aikana?
  • voitaisiinko TDD-raporttien laajaa tietomassaa hyödyntää tehokkaammin ylläpidon prosesseissa kauppatilanteen jälkeen?

Oikeastaan viimeinen kysymys käännettynä voisi hyvinkin vastata kolmeen ensimmäiseen kysymykseen: voitaisiinko ylläpidon prosesseja kehittää palvelemaan paremmin kauppatilanteen tarpeita ja TDD-raportointia?

Kysymys ei ole monimutkaisista asioista, mutta jonkin verran uutta ajattelua nykyisten ylläpitoprosessien osalta tarvitaan. Samalla voitaisiin kehittää normaalia ylläpidon tekemistä palvelemaan TDD:n lisäksi paremmin myös kiinteistöihin kohdistuvien investointien suunnittelua ja budjetointia sekä vuokralaisyhteistyötä.

Lisää rullaavuutta

Tällä hetkellä monessa organisaatiossa kiinteistöihin kohdistuvien investointien budjetointi tapahtuu kerran vuodessa kovalla tohinalla aiheuttaen tekijöilleen valtavia aikatauluhaasteita. Tilanne on hyvin vastaava kuin TDD-hankkeissa ja käsiteltävät asiatkin voittopuolisesti täysin vastaavat.

Ville_Reinikainen
Kirjoittaja Ville Reinikainen työskentelee toimialajohtajana Granlund Consultingissa.

Vaihtoehtoisesti investointien suunnittelun voisi hoitaa rullaavasti vuoden aikana kuntoon. Siis siten, että budjetoinnin käynnistyessä valtaosa askelmerkeistä olisi valmiina ja voitaisiin keskittyä hyvien lähtötietojen pohjalta hankkeiden aikatauluttamiseen ja priorisointiin.

Rullaava investointien suunnittelu antaisi myös hyvän mahdollisuuden edistää vuokralaisten kanssa tehtävää yhteistyötä ylläpitovastuiden hoitamisessa. Huonoimmalla tolalla vuokralaisyhteistyö taitaa olla triple net -kohteissa, joissa yhteistyö on tiivistä vuokrasopimusta laadittaessa, sen päättyessä ja ongelmatilanteissa, mutta muuten on melko rauhallista.

Jos yhteistyötä ylläpitovastuiden hoitamisessa ja investointien suunnittelussa tehtäisiin rullaavasti, voisi kuvitella, että reaktiivisen toiminnan sijaan päästäisiin proaktiivisuuteen. Tätä kautta saavutettaisiin paremman asiakastyytyväisyyden lisäksi kustannussäästöjä ja tarkoituksenmukaisempaa toimintaa. Lisäksi vuokrasopimuksen muutostilanteissa osapuolilla olisi hyvä käsitys sopimusvelvoitteiden hoitamisen tilasta.

Yhteistyötä, luotettavuutta ja parempaa kattavuutta

Kun edellä kuvatun rullaavan toiminnan pohjaksi otetaan omistajan kiinteistöstrategia ja vuokrasopimukset sisältöineen, voidaan toiminta suunnitella palvelemaan parhaalla mahdollisella tavalla niin kustannustehokasta korjausvelan hallintaa, vuokralaisyhteistyötä kuin TDD-prosessiakin.

Tämä vaatii luonnollisesti yhteistyötä, hyvää organisointia ja halukkuutta muuttaa vakiintuneita toimintatapoja. Mutta uskallan väittää, että ajattelemalla asioita hiukan uudella tavalla ja yhdistämällä nämä kolme asiaa rullaavaksi toiminnaksi, saavutetaan merkittäviä kustannussäästöjä kiinteistön elinkaaren aikana, parempaa asiakastyytyväisyyttä, luotettavampia ja kattavampia TDD-raportteja sekä vähemmän kiirettä.

 

Tekeminen ei aina ole etenemistä

Maaret prosessiViime aikoina on pohdittu paljon tekemisen ja etenemisen suhdetta ja katsonkin nyt aihetta ohjelmistokehityksen silmin. Meistä jokaisella voi olla kädet täynnä töitä, mutta siitä huolimatta ei aina valmista synny. Kiireisyys ei aina tarkoita eteenpäin pääsemistä.

Kun asioita katsotaan leanin ja ketteryyden silmälasien läpi, keskusteluun nousee nopeasti asiakkaiden ja käyttäjien kokema arvo. Rakennamme asioita pienissä palasissa, arvokeskeisesti. Niinpä oleellista onkin pysähtyä miettimään ilmiötä, joka kulkee nimellä häiriökysyntä.

Palvelumuotoisen tekemisen osalta voidaan katsoa, karkeasti systeemiajattelun termein, että meillä on kahdenlaista kysyntää.

Ensimmäinen on arvokysyntää. Tämä on tekemistä, jossa tuotoksemme on hyvä, ja sitä tarvitaan enemmän: lisäarvoa tuotteeseen tai palveluun asiakkaan näkökulmasta. Tätä haluamme enemmän! Toimimme rajallisin voimavaroin epävarmuuden keskellä ja siksi teemme pienissä palasissa, jatkuvasti ja sujuvasti.

Toinen on häiriökysyntää.  Tämä on tekemistä, joka juontaa juurensa erilaisiin puutteisiin ja aiheuttaa lisätöitä, joita haluamme oppia välttämään toimimalla oikeaan aikaan paremmin. Häiriökysyntä on työtä, joka aiheutuu siitä, ettemme onnistu oikeaan aikaan täyttämään asiakkaan luomaa kysyntää, joko puuttuvien tuotteiden tai palveluiden tai laatupuutteiden vuoksi. Ja silloin  tehdään työtä, joka paikkaa puutteita.

Pyrimme aktiivisesti pohtimaan, milloin teemme töitä, jotka aiheutuvat siitä, että emme onnistuneet tekemään jotain oikein asiakkaan näkökulmasta.

Joskus teemme pyydettyjä ominaisuuksia, jotka eivät olleetkaan tarpeellisia – vielä. Joskus tekemämme ominaisuudet osoittautuvat pyynnön mukaisiksi, mutta pyyntö oli tulkittavissa väärin ja tarve ei täyty. Joskus teemme kiirehtien tai puutteellisella osaamisella, ja täydennämme myöhemmin.

Toimiessa monimutkaisten kokonaisuuksien ja inhimillisten rajoitteiden puitteissa, voimme aktiivisesti oppia lisää ja parantaa toimintaamme jatkuvasti. Kokonaisuuden häiriöt tuottavat työnkenttää muualla, ja haluamme oppia optimoimaan kokonaisuutta osien sijaan.

Ohjelmistokehittäminen, siinä missä suunnittelutoimintakin, on sosiaalinen systeemi. Jokaisella osalla on tarkoitus, kuten myös kokonaisuudella. Systeemin kannalta hyvät osat ovat sellaisia, jotka toimivat hyvin yhteen. Ohjelmistokehityksen tuotoksilla viedään eteenpäin suunnittelutoiminnan tehokkuutta.

Maaret Pyhajarvi_kasitelty
Maaret Pyhäjärvi kirjoittaa myös suosittua ”A Seasoned Tester’s Crystal Ball” -blogia.

Meidän mantramme ketteryydestä on hakea ”pieniä epäonnistumisia” sekä oppia nopeasti, miten onnistutaan. Mietimme mikä on arvokasta, millaisen asiakaskokemuksen haluamme luoda ja työstämme omaa rohkeuttamme yhdessä mennä oikeaan suuntaan.

Menemme eteenpäin ja luomme uutta, sen sijaan että pidämme itsemme kiireisenä, missä tahansa tekemisessä.

Niin, tekeminen ei ole aina etenemistä. Ja eteneminen on tärkeää.

Urakoitsija on ystävä

Ainoa2_Kuva8

Pohjoismaissa talotekniset urakoitsijat käyttävät suunnittelijan tekemää tietomallia rakentamiseen. Suunnittelijan mallinnus on riittävän tarkka kohteen toteuttamiseksi niiden perusteella.

Keski-Euroopassa ja Yhdysvalloissa talotekniikan urakoitsija tekee itse tarvitsemansa tietomallit. Tällöin suunnittelijan tekemät mallinnukset toimivat heillä pääosin skisseinä oman mallinnuksen aloittamiselle. Urakoitsijat eivät välttämättä silti mallinna koko rakennusta, vaan vain teknisesti haastavat kohteet – käyttötarkoitukseen parhaiten soveltuvimmalla ohjelmistolla.

Näiden mallien perusteella urakoitsijat voivat tehdä esivalmisteet, aikataulutuksen sekä kustannusseurannan. Yhdysvalloissa yksi suurimmista syistä mallintaa ilmanvaihtoverkostot on se, että he saavat mallista pellinlevitystiedot.

Yhdistämällä ja yhteistyöllä parhaat ominaisuudet sekä suunnittelijalle että urakoitsijalle

Sekä pohjoismaisessa toimintatavassa että Yhdysvaltalaisessa tavassa on omat hyvät ja huonot puolensa. Pohjoismaissa TATE-verkostoissa on matematiikka mukana, verkostot ovat tasapainotettuja ja mitoitettuja.

Yhdysvalloissa näin ei ole, sillä mallit on tehty vain asennuksen käyttötarpeisiin. Tästä syystä Yhdysvaltalaiset mallit ovat geometrian tarkkuudelta tarkempia ja käyttökelpoisempia kuin pohjoismaissa.

Pystyisimme Suomessa yhdistämään nämä kaksi asiaa toisiinsa – matemaattisesti toimivan järjestelmämallin, joka on esivalmistekelpoinen urakoitsijalle. Mallin, jonka tarkkuustaso ei ole pelkästään as-built ennen kuin on asennuksia edes aloitettu. Mallin, joka sisältää oikean tuotetiedon ollen näin käytettävissä ylläpidon lähtötietomallina.

Meillä on kaikki työkalut tällaisen mallin aikaansaamiseksi.

Yhteistoiminnallisissa sopimusmalleissa suunnittelijalle ja urakoitsijalle annetaan lupa tehdä yhteistyötä. Näiden sopimusten sisään on leivottu mahdollisuus miettiä itse, millä tavalla saavutetaan asetetut tavoitteet parhaiten ja kustannustehokkaimmin.

Avainsana tässäkin metodissa on siis yhteistyö. Urakoitsija ei ole järjestelmäsuunnittelun ammattilainen, eikä suunnittelijalla ole tietoutta kustannuksista tai asennusten haasteista. Yhdessä he kuitenkin hallitsevat kokonaisuuden, kun asenne ja toisen työn kunnioittaminen on kunnossa.

Tero_Jarvinen
Blogin kirjoittaja Tero Järvinen haluaa lisätä yhteistyötä tietomallipohjaisen suunnittelun edistämiseksi.

Resepti  asennuskelpoisen, matemaattisesti toimivan talotekniikan tietomallin tekemiseksi:

  1. Allianssi- tai partnerisopimus, jossa urakoitsijan ammattitaito on mukana jo hankevaiheessa
  2. Suunnittelija tekee järjestelmävalinnat ja mitoitukset yleissuunnittelutasolle käyttäen urakoitsijan kustannustietoutta apuna.
  3. Toteutussuunnitelu tehdään yhdessä urakoitsijan kanssa. Suunnittelija mallintaa, urakoitsija ohjaa asennusteknisiä ratkaisuja. Suunnitelma tehdään heti niillä tuotteilla, joita aiotaan kohteessa käyttää.

Väitän, että ylläkuvatulla toimintatavalla lopputuote on laadukkaampi, kustannustehokkaampi ja toimivampi kuin nykysysteemillä tuotetut ratkaisut. Lisäksi pääsemme eroon tappelemisesta – meidän pitää olla samassa veneessä kärsien tappiot ja voitot yhdessä.

Parasta tässä toimintamallissa on se, että saamme tehdä virheitä. Koska toiminta on läpinäkyvää, virheet löydetään ennen kuin aletaan rakentaa.

Kenenkään osapuolen intressissä ei ole peitellä löytämiään ongelmakohtia ajatellen, että muutaman kuukauden päästä asiaa korjattaessa voitaisiin lisälaskuttaa asiakasta.

Kahden eri osapuolen ammattitaito tulee huomioiduksi, jolloin  ratkaisut on pidemmälle mietittyjä ja toteuttamiskelpoisempia.