Kiinteistödatan peruskorjaus – nopean takaisinmaksuajan PTS-hanke?
Oletko joskus ihmetellyt, miten eri ihmisillä tai tiimeillä voi kaikilla olla päivän käyttöasteesta eri näkemys ja numero? Oliko toiminnanohjausjärjestelmän käyttöönotto iso urakka? Törmäätkö arjessa virheelliseen tai puutteelliseen kiinteistödataan? Säilötäänkö teillä ylipäätään monipuolisesti dataa, kuten kiinteistöjen perustietoja?
Jos vastasit yhteenkin kysymykseen kyllä, on korjausvelkaa todennäköisesti päässyt kertymään – ei fyysisesti kiinteistöihin, vaan aineettomaan omaisuuteen.
Datan korjausvelka vaikuttaa yrityksen toimintaan samoin kuin fyysinen kiinteistöjenkin korjausvelka. Aineetonkin omaisuus kannattaisi siis huomioida huolto- ja PTS-suunnitelmissa.
Kiinteistödatan laatuun liittyvän korjausvelan kertyminen vaikuttaa yrityksen toimintaan hyvin samaan tapaan kuin fyysisen korjausvelan kertyminen kiinteistöihinkin. Esimerkiksi ylläpito- ja hallintokulut kasvavat ja tulevaisuuden investointitarpeet kasautuvat. Puhumattakaan siitä, että omaisuuden arvo laskee. Uusi tietosuojalainsäädäntö korostaa asian tärkeyttä entisestään. Jatkan tätä vertailua tarkemmin blogin lopussa (taulukko 1).
Kiinteistödatan korjausvelalla on suora vaikutus koko yrityksen riskitasoon ja sen hallintaan. Perinteisesti kiinteistöyhtiöt ovat hallinneet tietojärjestelmiin liittyviä riskejä muun muassa varmistamalla omistajuuden omaan dataansa. Lisäksi useimmiten on sopimuksellisesti huolehdittu, että oman datan saa järjestelmävaihdostilanteessa tietokannoista ulos ja, että toimittajilla on myötävaikutusvelvollisuus datasiirtojen toteuttamiseen. Näin pyritään välttämään mm. ”lock-in”-tilanteita.
Mitä enemmän korjausvelkaa datassa, sitä suurempi lock-in nykyisiin tietojärjestelmiin. Riskit on kuitenkin hallittavissa.
Nämä riskienhallintakeinot ovat edelleen hyvin tärkeitä, mutta käytännön tasolla herkästi kuitenkin merkityksettömiä, mikäli dataan pääsee kerääntymään korjausvelkaa. Mainittujen keinojen ohella yhtä tärkeää tulisi olla datan jatkuva laadunvarmistus. Tähän on kaksi lähestymistapaa, jotka molemmat tarvitaan, jotta tietoja voidaan tosiasiallisesti tarpeen tullen hyödyntää, oli kyse sitten järjestelmävaihdostilanteesta tai datan hyödyntämisestä esimerkiksi johdon raportointihankkeessa:
- Oikea vastuujako tietojärjestelmän ja ihmisten toiminnan välillä. Pandian näkemys on, että vastuu datan laadusta tulisi moderneissa tietojärjestelmissä olla melko vahvasti järjestelmän puolella, etenkin kun puhutaan kriittisestä ns. ”master datasta”. Tietojärjestelmissä tulisi olla riittävät validoinnit ja säännöt sen varmistamiseksi, että oikeisiin kenttiin on mahdollista syöttää vain niihin kuuluvaa tietoa ja oikeassa formaatissa. Todellisuus on usein erilainen. Jos vaikkapa puhelinnumero voidaan syöttää viiteen eri kenttään päivän fiiliksestä riippuen, ja on ihmisen muistista kiinni, tuliko numero syöttää kansainvälisessä (+35840…) vai kansallisessa (040…) muodossa, ja pitikö suuntanumero erottaa välilyönnillä, viivalla vai ei ollenkaan, niin jo luonnonlait määräävät, että data ei tule pysymään laadukkaana. Tämä ei ole ihmisten vika, vaan tietojärjestelmien. Tilanne ei välttämättä ole jokapäiväisessä toiminnassa ongelma (riippuu siitä, miten ja missä kyseistä dataa käytetään), mutta data ei ole välttämättä hyödynnettävissä silloin, kun sitä tarvitaan. Lisäksi ohjelmiston vaihdon yhteydessä voi olla edessä melkoinen jumppa (eli käytännössä lock-in-riski nykyisiin järjestelmiin on koholla).
- Systemaattinen ja kriittinen ote datan hallintaan yrityksissä. Vastuu ei voi olla lopulta täysin järjestelmän puolellakaan. Fiksusti toimivien tietojärjestelmien ohella tarvitaan myös fiksusti toimivia organisaatioita ja prosesseja. Mietittäessä esimerkiksi uuden tärkeän datan tallettamista ensimmäistä kertaa, tulisi miettiä aina kriittisesti mihin ja miten tätä tietoa olisi pitkässä juoksussa järkevää tallentaa. Tässä ajattelussa kannattaa etupäässä ajatella syitä tiedon tallentamiselle ja sen käyttötarkoitusta – tallenna data sinne, missä sitä tarvitaan ja tavalla, joka palvelee sen käyttötarkoitusta. Todennäköisesti osa tiedoista alkaa kaikesta huolimatta ennemmin tai myöhemmin ”mätänemään” ja mitä pitempään esimerkiksi toiminnanohjausjärjestelmän käyttöönotosta on kulunut, sitä suurempi on todennäköisyys, että korjausvelkaa on päässyt kertymään. Tämä on luonnonlaki siinä missä entropiakin. Olisikin tärkeää tehdä datalle jatkuvasti huoltotoimenpiteitä ja säännöllisesti peruskorjausoperaatioita. Kiinteistöissä osa normaalia riskienhallintaa on tarkistaa palosammuttimet, -varoittimet ja pelastussuunnitelma. Tietohallinnossa paras pelastussuunnitelma voi hyvin olla datan laadusta huolehtiminen ja säännölliset tarkastukset, jotta järjestelmien vaihtamisen kynnys pysyy matalana esimerkiksi kriisin tullessa eteen. Tietohallinnon varauloskäynti saattaa hyvin olla vaihtoehtoisen järjestelmän tietomalli.
Dataan liittyvät puutteet johtuvat usein tietojärjestelmien toiminnasta ja luonnonlaeista – ihmisten vika se ei ole. Riskit pienenevät, mikäli tietojärjestelmät toimivat fiksusti ja yritykset suhtautuvat dataan kuten fyysiseenkin omaisuuteensa (huolto ja peruskorjaukset!).
Kuten aiemmissa blogeissani olen jo tuonut esiin, toiminnanohjausjärjestelmän vaihtamisesessa suurin urakka on datasiirrot, jotka riippuvat suoraan siitä, miten paljon siirrettävää dataa on, kuinka laadukasta se on ja kuinka lähellä vanhan ja uuden järjestelmän tietomallit ovat toisiaan. Kennon osalta tietomalli poikkeaa jonkin verran totutusta, joka tarjoaa monia hyötyjä yrityksille. Lisäksi Kennosta on myös tietoisesti tehty datan validointien suhteen tarkka, jonka myötä laatuvaatimukset siirrettävälle datalle korostuvat. Näiden valintojen myötä kenellekään ei tule yllätyksenä, että tiedonsiirron kanssa on jonkin verran jumpattava, vaikka data olisi kohtuullisen laadukastakin.
Kennoon siirtymistä tällä hetkelle pohtiville on nyt otollinen hetki miettiä, mikä on datan tilannekuva ja miettiä millaisia toimenpiteitä olisi syytä toteuttaa tulevina kuukausina ja vuosina. Olisiko syytä tehdä ylläpitokorjauksia vai kenties isompi peruskorjaus? Pitäisikö rakentaa muutama varauloskäynti? Teemaan kannattaa panostaa, mutta laajuuden voi kukin päättä itse.
Oli edessä järjestelmähankkeita tai ei, kaikki toimenpiteet vievät asioita todennäköisesti eteenpäin vähentäen välittömästi yrityksen riskitasoa ja pienentäen hallintokuluja. Mikäli datalle jonain päivänä tulee uusia hyödyntämistarpeita, on huoltoon ja peruskorjauksiin käytetty työaika ja eurot todennäköisesti 1:1 pois myöhemmin vaaditusta ajan- ja rahankäytöstä. Hyödyntämistarve voi olla esimerkiksi johdon raportoinnin hanke, integraatioprojekti tai toiminnanohjausjärjestelmän vaihto.
Kaikki datan huolto ja korjaustoimet vähentävät välittömästi riskejä ja hallintokuluja. Käytetty työaika ja eurot ovat samalla 1:1 pois myöhemmin vaadittavasta ajan- ja rahankäytöstä esimerkiksi integraatioprojekteissa, johdon raportointihankkeissa tai Kennoon siirtymisessä.
Annamme mielellämme vinkkejä datan huolto- ja peruskorjaustoimenpiteisiin liittyen ja sparrailemme tarkemmin esimerkiksi Kennon tietomallista. Ole rohkeasti meihin yhteydessä, niin jutellaan lisää!
Taulukko 1: Kiinteistöjen vs Datan huolto ja peruskorjaus – hyödyt lyhyellä ja pitkällä tähtäimellä
| Kiinteistöt / fyysinen omaisuus | Data / aineeton omaisuus | |
| Lyhyt tähtäin | Hyvin huolletuissa kiinteistöistä kertyy vähemmän vikailmoituksia ja valituksia -> Pienemmät ylläpitokulut | Hyvin huolletun datan myötä ”oikeasta numerosta” kiistely vähenee, työaikaa ei mene virheiden korjaamiseen ja puutteellinen data ei johda puutteelliseen toimintaan –> Pienemmät hallintokulut |
| Keskipitkä tähtäin | Peruskorjatussa kiinteistössä vuokrattavuus on parempi ja vaihtuvuus pienempi –> Kiinteistö on omistajalleen arvokkaampi | Laadukkaan datan päälle voidaan rakentaa laadukasta raportointia ja johtamista –> Data on omistajalleen arvokkaampaa |
| Pitkä tähtäin | Kun korjataan suunnitelmallisesti, ei kasaudu valtavia kertapommeja maksettavaksi myöhemmin –> Toiminta on ennakoitavampaa ja riskit pienemmät | Yhtiö, jossa datan laatuun suhtaudutaan suunnitelmallisesti, on ketterämpi muutostilanteissa –> Esim. järjestelmän vaihto on pienempi ponnistus ja lock-in vähäisempi |
