"Isännöintijärjestelmän kriteerinä voitaneen pitää, että sen pitää pystyä tuottamaan isännöitsijäntodistus taloustietoineen."
Yritysohjelmistojen markkina
Tavanomaiseen yhtiö- ja yhdistyskirjanpitoon soveltuvia kirjanpitojärjestelmiä löytyy Suomen markkinoilta noin 20-30 kpl. Tilisanomien tutkimuksessa on mainittu nimeltä 23 järjestelmää: Linkki tilisanomien tutkimukseen. Edellä mainittu määrä lienee toimiva arvio kirjanpitojärjestelmien lukumäärästä.
PK-yrityksille tarjottavia ERP-järjestelmiä on kymmeniä, ellei jopa satoja. Tarkkaa määrää ei nopealla internetin selaamisella ja chatgpt:n tenttaamisella saatu. Joka tapauksessa PK-yrityssektorille ohjelmistopuolella on merkittävä määrä vaihtoehtoja tarjolla erilaisiin toiminnanohjauksen tarpeisiin.
Isännöintiliiton järjestelmäselvityksessä on mainittu nimeltä isännöintitoimistojen pääasiallisesti käyttämänä järjestelmänä 10 eri järjestelmää. Linkki isännöintiliiton järjestelmäselvitykseen.
Isännöintijärjestelmän kriteerinä voitaneen pitää, että sen pitää pystyä tuottamaan isännöitsijäntodistus taloustietoineen. Isännöitsijäntodistuksen luomisen ulkopuoliset ominaisuudet ja yksityiskohdat toki eroavat merkittävästi järjestelmien välillä, ja viime vuosina perustoimintojen rinnalle onkin tullut lisää ominaisuuksia helpottamaan ja automatisoimaan isännöintityötä.
Isännöintiliiton tutkimus osoittaa selkeästi, että taloustoiminnot ovat ylivoimaisesti tärkein työkalu, vaikka tiketöinti/tehtävänhallinta, kokousten hallinta, pts-suunnittelu ja vastaavat lisäominaisuudet nostavat päätään.
"Kun ottaa huomioon HTJ2:n vaatimukset isännöintijärjestelmille, sekä ohjelmistotalojen reagoinnit HTJ2-vaatimuksiin, näyttää vahvasti siltä että tulevaisuudessa ammattimaiseen isännöintiin soveltuvia järjestelmiä jää jäljelle 3 kpl."
Huoneistotietojärjestelmän nykyiset, ja erityisesti tulevat vaatimukset, on asettanut isännöintijärjestelmätoimittajat uuteen tilanteeseen, verrattuna esimerkiksi 5 vuoden takaiseen aikaan. Järjestelmien peruslogiikka siirtyy enemmän ja enemmän toiminnallisuuksiin, eikä vain tiedon säilyttämiseen. HTJ:ssa on tulevaisuudessa masterdata, ja isännöintijärjestelmät käsittelevät ja rikastavat tätä tietoa eri menetelmillä ja toiminnoilla.
Kun ottaa huomioon HTJ2:n vaatimukset isännöintijärjestelmille, sekä ohjelmistotalojen reagoinnit vaatimuksiin, näyttää vahvasti siltä että tulevaisuudessa ammattimaiseen isännöintiin soveltuvia järjestelmiä jää jäljelle 3 kpl. Mahdollista toki on, että markkinoille syntyy uusia toimijoita nopeasti. Nopeus isännöintijärjestelmissä tarkoittaa kuitenkin vuosien kehitystyötä aidosti tuotantokelpoisten talousominaisuuksien toimittamiseksi.
Nopeasti markkinoille tulo uutena isännöintijärjestelmätoimittajana ei ole mahdotonta, mutta äärettömän haastavaa, koska tarvitaan todella paljon laajoja ominaisuuksia ja toiminnallisuuksia. Uudelle toimijalle esimerkiksi 2-3 vuotta on tuskallisen pitkä aika kehitysprojektille, jotta päästäisiin edes kunnolla asiakastestausvaiheeseen.
"Tärkeä tekijä talouspuolen onnistumiselle on ollut, että järjestelmän suunnittelussa on varauduttu taloustoimintojen tuloon alusta asti."
Viimeisen viiden vuoden aikana markkinoille on ilmestynyt pienempiä apuohjelmia isännöinnin tehtävien avuksi, on kokoustyökalua, on viestintätyökalua, on PTS-suunnittelutyökalua. Myös Avaa.io oli aluksi aputyökalu isännöintijärjestelmän rinnalle. Tavoite on kuitenkin ollut alusta saakka rakentaa järjestelmä, joka kykenee toimimaan isännöintitoimiston kokonaisvalvaisena päätyökaluna. Kova työ on tuottanut lopulta halutun lopputuloksen. Tuloksena on isännöinnin päätyökaluksi soveltuva järjestelmä, jota jatkokehitetään yhteistyössä isännöintitoimistojen kanssa maailman tappiin saakka.
Avaa.io:ssa on isännöitsijäntodistuksen laadinta ollut mahdollista jo vuosia ja taloustoimintojen kehittyessä myös taloustiedot on pystytty tuomaan suoraan issarille automatisoidun prosessin kautta. Pari klikkausta ja taloustiedot sisältävä issaritilaus on allekirjoitettu ja dokumentit lähetetty tilaajalle.
Tärkeä tekijä talouspuolen onnistumiselle on ollut, että järjestelmän suunnittelussa on varauduttu taloustoimintojen tuloon alusta asti.
"Haasteena isossa ohjelmistokehitysprojektissa on ympyrän muotoinen palapeli, jossa moni laaja kompleksinen osatekijä tulee olla käyttövalmiina, valmiina palapelin palana, jotta ympyrän saa lopulta koottua kiinni, ja varsinainen kokonaisuuden käyttötestaus voi alkaa. Jokainen ympyrän pala on ohjelmisto jo itsessäänkin, mutta hyödytön ilman kokonaisuutta."
Talousmoduulit osaksi järjestelmää
Emme välttämättä osanneet alkuvaiheessa täysin valmistautua, kuinka suureen haasteeseen tartuimme, erityisesti talousmoduulien osalta. Vahva tiimikään ei aina helpota tilannetta, vaikka tiimistä löytyy ohjelmisto-osaamisen lisäksi kovaa kirjanpidon ja taloyhtiön taloushallinnon substanssiosaamista.
Isännöintijärjestelmän vastikereskontra eroaa merkittävästi kirjanpitojärjestelmän myyntireskontrasta. Jotta voidaan käsitellä massana tuhansien, jatkuvasti muuttuvien, asukkaiden ja osakkaiden maksutietoja rivitasolla, muodostaa laskuja, tiliöidä automaattisesti yhden viitenumeron sisältä useampi laskurivi eri kirjanpitotileillä, on mietittävä järjestelmän arkkitehtuuri pohjamutia myöten. Isännöinti- ja taloyhtiömaailmaan liittyy myös erittäin oleellisesti poikkeukset ja poikkeuksen poikkeukset. Hyvin moninaisiin skenaarioihin tulee pystyä varautumaan.
Lainaosuuslaskenta on oman pitkän luennon vaativa kokonaisuus koron täsmäyttämisineen, lainojen jyvityksineen, laina/hankeosuuksien maksuineen. Kyllähän excelissä pari pientä yhtiötä pyörittää, mutta sitten kun ruvetaan pyörittämään lainahallintaa kymmenien tai satojen taloyhtiöiden skaalalla, niin ollaankin ihan uusien kysymysten äärellä.
Avaa:n reskontra ja lainaosuuslaskenta on muotoutunut 5 vuoden aikana nykyiseen muotoonsa. Kompakti, kunnianhimoinen ja ketterä kehitystiimi, sekä muutama aktiivinen ja kehityshaluinen alkuvaiheen asiakas on ohjelmiston kehittämiseen paljon tehokkaampi kombo, kuin miljoonien budjetit ja korporaatioprosessit. Nostamme edelleen hattua ensimmäisille rohkeille talousmoduuleja hyödyntäneille kumppaneillemme. Ilman aktiivisia ja rohkeita ensimmäisen vaiheen kumppaneita, emme todennäköisesti olisi talous-ominaisuuksia saaneet riittävälle tasolle.
"Oikea kehitystyö alkaa vasta, kun asiakkaat ja kumppanit saadaan mukaan. Tosin polku siihen, että asiakkaille voidaan toimittaa jotain käyttökelpoista toimintoa testattavaksi, on tuskallisen pitkä. Asiakaspalautteen pohjalta järjestelmät vasta sitten oikeasti muotoutuvat. Kehitystyö ei onnistu vain kehittäjien kellareissa. "
Emme voida kiistää, etteikö miljoonien budjettia olisi välillä ollut ikävä kehitysprosessin aikana, mutta siltikään pelkkä budjetti ei näitä toimintoja olisi synnyttänyt. Haasteena isossa ohjelmistokehitysprojektissa on ympyrän muotoinen palapeli, jossa moni laaja kompleksinen osatekijä tulee olla käyttövalmiina, valmiina palapelin palana, jotta ympyrän saa lopulta koottua kiinni, ja varsinainen kokonaisuuden käyttötestaus voi alkaa. Jokainen ympyrän pala on ohjelmisto jo itsessäänkin, mutta hyödytön ilman kokonaisuutta. Mittarirekisterillä ei oikein ole virkaa, jos ei ole kyvykkyyksiä generoida laskuja mittarilukemista. Laskujen generoinnilla ei oikein ole virkaa, jos ei ole kyvykkyyksiä lähettää laskuja, ja niin edelleen. Laskujen lähettämisen kyvykkyys voi kuulostaa itsestäänselvyydeltä, mutta sitä se ei valitettavasti ole kehittäjän näkökulmasta.
"On kieltämättä aikamoinen kehittäjän dilemma, kun pitäisi olla todella paljon toimintoa valmiina, jotta voi edes aloittaa testaamisen oikeassa asiakasympäristössä. Ja toisaalta, toimintojen lopulliset kehitystarpeet ja vaatimukset paljastuu vasta oikeassa asiakasympäristössä. "
Alla on esimerkki yhdestä Avaa:n kehitysprosessin aikana luonnoksista ja muistiinpanoista muotoutuneesta adobe xd-canvaksesta. Alussa canvas oli tyhjä. Ensimmäinen tavoite oli saada siihen piirrettyä esimerkkejä käyttöliittymänäkymistä, miltä mystiset talousmoduulit voisivat näyttää. Seuraavassa vaiheessa lisättiin prosessikaavioita, miten toiminnot, data ja käyttöliittymät käyttäytyvät. Mallinnettiin UML-kaavioilla ja lopulta mietittiin teorian tasolla, että voisiko nämä ratkaisut toimia oikeassakin ympäristössä. Yhteisten palaverien ja kokousten jälkeen koodattiin, testattiin, iteroitiin urakalla. Pienen pienin askelin kohti valmiimpaa ja valmiimpaa ympyrää.
Tuhansien suunnittelu-, kehitys-, testauskierrosten jälkeen oltiin tilanteessa, jossa uskallettiin esittää tuotokset asiakkaalle. Oikea kehitystyö alkaa vasta, kun asiakkaat saadaan mukaan. Tosin polku siihen, että asiakkaalla voidaan toimittaa jotain käyttökelpoista toimintoa testattavaksi, on tuskallisen pitkä. Asiakaspalautteen pohjalta järjestelmät vasta oikeasti muotoutuvat. Kehitystyö ei onnistu vain kehittäjien kellareissa.
On kieltämättä aikamoinen kehittäjän dilemma, kun pitäisi olla todella paljon toimintoa valmiina, jotta voi edes aloittaa testaamisen oikeassa asiakasympäristössä. Ja toisaalta, toimintojen lopulliset kehitystarpeet ja vaatimukset paljastuu vasta oikeassa asiakasympäristössä.
"Kyllähän taloyhtiön myyntilaskut (eli vastikelaskut) normaalissa kirjanpitojärjestelmässäkin pystyy tekemään ja laskun rivit kirjoittamaan haluamanlaiseksi, mutta manuaalisten työvaiheiden määrä on merkittävä. Tehtävä on erityisen haastava, jos laskuja on tuhansia tai kymmeniä tuhansia. Yksityiskohtien määrä on valtava, kun puhutaan taloyhtiön taloustoimintojen vaatimusluettelosta. "
Jos yksityiskohtia tarkastelee, niin zoomataan yhteen käyttöliittymä-näkymään adobe xd-canvaksessa. Kyseessä on laskujen generointi-vaihe eli ns. ”tavoitteiden ajo”. Yksinkertaiselta kuulostavaan laskujen generointiin tarvitaan kuitenkin merkittävä pohjainfra ja pohjadata:
- Tarvitaan huoneistoluettelot ja huoneistojen yksityiskohdat (pinta-alat, osakemäärät jne). Dynaamisessa järjestelmässä huoneistot ovat tietysti hierarkiassa taloyhtiön perustietojen, tonttien ja rakennusten kanssa.
- Tarvitaan henkilöluettelot ja niiden ylläpitämiseen tarvittavat toiminnot.
- Tarvitaan sidokset tai vastaavat keinot liittää attributteja toisiinsa.
- Tarvitaan maksulajit, joissa taloudellinen informaatio yhdistetään huoneistojen kanssa ja luodaan sääntöjä ja määrityksiä maksuille.
- Nyt ruvetaan olemaan jo lähellä perustason tavoitteiden ajoa, mutta mitäs kun mukaan tulee kulutusperusteiset maksut ja niiden ennakoiden käsittely.
- Tarvitaan mittarirekisterit ja mittarilaskutus
- Mitäs jos mukaan tulee ylimääräinen hoitovastike tai 1.5 kertoimella oleva liikehuoneiston vastike, tai muuta poikkeavaa. Tarvitaan keinot hoitaa poikkeukset.
- Tarvitaan finvoice- ja pdf- generaattorit muodostamaan laskuaineisto.
- Tarvitaan e-laskun lähetyskanava ja postituspalvelu
- Tarvitaan reskontra missä voidaan seurata maksujen maksamista.
- Tarvitaan pankkiyhteys.
- Ja lisäksi kirjanpidon tavoitetositteet sekä maksutositteet pitää pyöriä koko ajan taustalla automaattisesti ja tiliöidä ennakkoon määritellyille kirjanpidon tileille oikeat eurot. (ja tilikartta tietysti tarvitaan myös).
Kyllähän taloyhtiön myyntilaskut (eli vastikelaskut) normaalissa kirjanpitojärjestelmässäkin pystyy tekemään ja laskun rivit kirjoittamaan haluamanlaiseksi, mutta manuaalisten työvaiheiden määrä on merkittävä. Tehtävä on erityisen haastava, jos laskuja on tuhansia tai kymmeniä tuhansia. Yksityiskohtien määrä on valtava, kun puhutaan taloyhtiön taloustoimintojen vaatimusluettelosta.
Ohjelmistotoiminnassa tehdyt lupaukset ovat kaksiteräinen miekka, aivan minimaalisen siivun voi luvata yli sen hetkisten kyvykkyyksien. Jos lupaukset ovat liian suuria, niin metsään mennään ja urakalla. Kukaan kehittäjä ei halua tilanteeseen, jossa on luvattu nopeasti asioita, joiden minimitoteuttamiseen menee parhaassakin tapauksessa 2-3 vuotta, jopa kauemman jos pohjainfra ei ole valmiudessa. Tästä hyvänä esimerkkinä taloyhtiön talousmoduulikokonaisuus.
"Vastikereskontran ja lainaosuuslaskennan tekeminen on lähtökohtaisesti kannattamatonta investointilaskelmien näkökulmasta, ja lisäksi riskit ovat kovat, kun niin ison projektin kustannuksia ei voi tietää varmuudella etukäteen."
Avaa.io täysiverinen isännöintijärjestelmä
Olen itse ollut mukana Avaa:n kehitysprosessissa tyhjästä ruutupaperista asti, ja vaikka olemme unelmoineet ja tavoitelleet alusta asti kokonaisvaltaisen isännöitijärjestelmän rakentamista, niin uskallan sen oikeasti luvata isännöintiammattilaisille vasta keväästä 2024 lähtien. Fennoa ja sen monipuoliset rajapinnat mahdollistivat Isännöintijärjestelmän ja kirjanpitojärjestelmän yhteistyön tasolla, mitä ei ole aikaisemmin alalla nähty.
Tänä päivänä voimme ylpeänä sanoa, että Avaa, yhdessä Fennoan kanssa, on tuhansien taloyhtiöiden tuotantokäytössä validoitu kokonaisvaltainen isännöintijärjestelmä. Tuotantokäytössä validoitu käyttö on erittäin merkityksellistä, kun isännöintiammattilaiset arvioivat järjestelmätarpeitaan kohti HTJ2-vaihetta tulevina vuosina, ja myös sen yli.
Tekstin alussa pohdin markkinoilla olevien järjestelmien lukumääriä. Oma hypoteesi sille, että isännöintijärjestelmiä on niin vähän vrt. kirjanpito- ja ERP:t- on, että taloyhtiön vastikereskontran ja lainaosuuslaskennan tekeminen on lähtökohtaisesti kannattamatonta investointilaskelmien näkökulmasta, ja lisäksi riskit ovat kovat, kun niin ison projektin kustannuksia ei voi tietää varmuudella etukäteen. Projekti on todella haastava ja resurssitarpeet merkittävät. Toisaalta startupille investointilaskelmat tarkoittaa aavistuksen eri asiaa kuin korporaatiolla.
Vaihtoehtona miljoonabudjetille on vaatimukset alunperin ehkä aavistusen aliarvioinut, mutta erittäin sitoutunut ja ennakkoluuloton porukka sopivilla substanssi-osaamisalueille, joka on valmiina hyppäämään muutamaksi vuodeksi syvään päähän.
Tiimimme on tehnyt menneinä vuosina upeaa työtä, ja se syvä pääty on opettanut meidät uimaan.
On mahtavaa saada palvella ja kehittäjää alaa yhdessä kumppani-isännöintitoimistojemme, sekä myös maanmittauslaitoksen kanssa pitkälle tulevaisuuteen.
Vaikka jonkunlainen välietappi on saavutettu, niin kehitystyöhän ei tule koskaan valmiiksi.
Asiakaspalautteen perusteella järjestelmän parantaminen jatkuu toivottavasti ikuisesti. Tavoitteena on, että pystymme yhdessä kumppaneiden ja asiakkaiden kanssa kehittämään alaa suotuisaan suuntaan, ja mahdollistamaan laadukkaat palvelut isännöintitoimistoille, ja heidän kauttaan taloyhtiöille, nyt ja tulevaisuudessa.
