Avaa.io isännöintijärjestelmä saavutti tällä viikolla merkittävän virstanpylvään. Järjestelmästä generoitiin miljoonas (1 000 000) taloyhtiön myyntilasku (eli vastike-/vuokra-/mittari-/lainaosuuslasku).
Avaa:n tiimi kiittää miljoonasti luottamuksesta 🙏
Onko miljoona myyntilaskua sitten paljon vai vähän, ja mihin sitä vertaa? Meidän mielestämme se on merkittävän paljon, ottaen huomioon, että Avaa:n talousominaisuudet on ollut isännöintitoimistoilla aktiivisessa käytössä noin 3 vuotta. Kuukausitasollakin määrä on kohtuullisen vaikuttava ja asettaa järjestelmäinfrastruktuurin vaatimukset korkealle.
"Tavanomaisten yrityskirjanpitoon suunnattujen kirjanpitojärjestelmien myyntireskontra on toiminnoiltaan vajaavainen isännöintimaailmaan siirryttäessä ja isännöintialan vaatimuksia tarkasteltaessa."
Jos vertaa tavanomaiseen yrityskirjanpitoon ja siihen suunnattuihin järjestelmiin, niin miljoona myyntilaskua on itseasiassa todella paljon. Taloyhtiömaailman myyntireskontra on oma maailmansa verrattuna tavanomaiseen yrityksien myyntireskontraan, mikä myös luo isännöintijärjestelmille niiden uniikit vaatimukset. Tavanomaisten yrityskirjanpitoon suunnattujen kirjanpitojärjestelmien myyntireskontra on toiminnoiltaan vajaavainen isännöintimaailmaan siirryttäessä ja isännöintialan vaatimuksia tarkasteltaessa.".
Mistä tuo isännöintimaailman uniikkius sitten syntyy?
Isännöinnissä myyntilaskujen perusteena olevat pohjatiedot pitää pystyä hallinnoimaan poikkeuksellisen laaja-alaisesti, skaalautuvasti ja kaikki poikkeukset ja poikkeuksen poikkeukset huomioiden. Tietoja pitää pystyä yhdistelemään mitä mielikuvituksellisimmilla tavoilla, ja samaan aikaan pitää prosessi tiukasti kontrolloituna. Lisäksi erityisen hienon lisämausteen kuvioon luo se, että pohjatietojen muuttuminen on jatkuvaa mm. asuntojen myyntien ja ostojen, henkilöiden muuttamisen ja mittarilaskutuksen takia.
Mitä laajempi ja enemmän poikkeuksia sisältävä systeemi, sen kompleksisempi sitä on mallintaa ohjelmistokehitykseen. Tästä dilemmasta on hyvänä (tai huonona) esimerkkinä montakin julkisen sektorin tai sote-alan tietojärjestelmähanketta.
Taloyhtiön myyntireskontra voi vaikuttaa pienessä skaalassa triviaalilta ja helpolta, isossa skaalassa se on kaikkea muuta. Käytännössä taloyhtiön yhtiökokous voi päättää lähes minkälaiset vastikkeenkeruuperusteet, ja lähes minkälaiset tilakohtaiset poikkeukset tahansa, ja järjestelmän on taivuttava yhtiökokouksen päätöksiin. Tarvitaan merkittävä määrä joustavuutta järjestelmän toimintoihin ja prosessien täydellinen auki piirtäminen on tästä syystä hyvin haastavaa. Kirjoitin aikaisemmin jo isännöintijärjestelmän talousmoodien kehityksen haastavuudesta oman blogitekstin.
"Tietoja pitää pystyä yhdistelemään mitä mielikuvituksellisimmilla tavoilla, ja samaan aikaan pitää prosessi tiukasti kontrolloituna."
Ohjelmistojen suunnittelussa prosessien kuvauksilla ja auki piirtämisellä on merkittävä rooli. Kompleksiset ja poikkeuksia sisältävät prosessit on haastava mallintaa ja kirjoittaa koodiksi ja sitä myöten rakentaa tietojärjestelmäksi. Mitä laajempi ja enemmän poikkeuksia sisältävä systeemi, sen kompleksisempi sitä on mallintaa ohjelmistokehitykseen. Tästä dilemmasta on hyvänä (tai huonona) esimerkkinä montakin julkisen sektorin tai sote-alan tietojärjestelmähanketta. Alla yksi esimerkki lukuisista Adobe XD canvaksista, mitä käytimme suunnitteluun talousmoduulien kiihkeimmässä kehitysvaiheessa. Huomioon otettavia asioita on valtava määrä ja lopulta käyttöä palvelevat ominaisuudet syntyvät lukemattomien iterointikierroksien mukana.
"Jotta olemme päässeet miljoonaan luotuun myyntilaskuun, niin Avaa:n kehitystyössä on jouduttu tekemään tuhansia iterointikierroksia, kun uusia poikkeuksia ja poikkeuksen poikkeuksia on tullut kentältä esiin."
Avaa.io sisältää kiha-toimintojen lisäksi isännöintimaailmaan räätälöidyt myyntireskontra ja lainaosuuslaskenta-moduulit ja varsinainen yrityskirjanpito tehdään Fennoassa. Fennoa-kirjanpitojärjestelmäintegraation jälkeen järjestelmien käyttövoluumit ovat kasvaneet merkittävästi, kun rajapinnat tekevät tositteiden siirtotyön automaattisesti. Fennoan kanssa työnjako on selkeä, mikä mahdollistaa innovatiivisen jatkuvan kehitystyön, eikä pelkkää nykyominaisuuksien ylläpitoa. Avaa:lla pidämme huolen isännöintialan toimialaspesifeistä ominaisuuksista ja Fennoa pitää huolen kirjanpidon toimialaspesifeistä ominaisuuksista. Taloyhtiökenttä on hyvin haastava, sillä se vaatii ohjelmistolta sekä tavanomaiset yrityskirjanpitoon tarvittavat ominaisuudet, sekä spesifit taloyhtiömaailman ominaisuudet. Järjestelmien Iterointi ja kehitys tulee jatkumaan varmasti ikuisesti, ja on erinomaista, että voimme Avaa:lla keskittää resurssit kiinteistöalan spesifeihin tarpeisiin.
Tekoälyaiheista voisi kirjoittaa enemmänkin, mutta ne ansaitsevat kokonaan oman blogikirjoituksensa sopivassa välissä
Jatketaan taloyhtiön myyntireskontran perkaamista vielä aavistuksen. Olen kuullut taloyhtiön taloushallintoon liittyviä kommentteja vuosien varrella, esimerkiksi että ”No miksei sitten tehdä vaan excelissä myyntilaskuja jos joustavuutta tarvitaan?” Ehkä 3 vuodessa generoitu 1 000 000 myyntilaskua kertoo vastauksen, tarvittaisiin ihan kohtuuton armeija kirjanpitäjiä ja reskontranhoitajia pyörittämään tuo myyntilaskumäärä 3 vuodessa manuaalisesti excelissä. Kirjanpitojärjestelmien tavanomainen sopimuslaskutus-toimintokaan ei auta, sillä pohjatiedot (ja sitä myöten sopimukset) ovat jatkuvassa muutoksessa taloyhtiömaailmassa, ja käytännössä jokainen laskurivi (hoitovastikkeet, rahoitusvastikkeet, kulutusmaksut, saunamaksut jne. jne.) on oma sopimuksensa.
"En henkilökohtaisesti usko, että on oikotietä onneen. Jokaisen ohjelmiston alasta riippumatta pitää sama tie käydä läpi alkuinnostuksesta loputtomaan iterointiin."
Toinen mielenkiintoinen kommentti, mitä olen viime aikoina kuullut on, että miksei vaan syötetä yhtiökokouspäätöksiä ja taloyhtiön perustietoja ja asunto-osakeyhtiölakia tekoälylle ja tekoäly sitten pyöräyttää laskut. Tekoäly voisi ehkä tällä menetelmällä saada ”sinnepäin” vastauksen aikaiseksi, mutta voisiko luottaa miljoonaa myyntilaskua epävarman prosessin haltuun, jonka lopputuloksena on ”sinnepäin” tai ”melkein” hyviä vastauksia?
Taloyhtiöiden osakkaat ja hallitukset ovat tunnetusti kohtuullisen vaativa asiakaskunta ja aikamoinen tilanne voisi syntyä ”melkein” tarkoista vastikelaskuista, mitä kielimallit pystyisi mahdollisesti toteuttamaan. Tekoälyaiheista voisi kirjoittaa enemmänkin, mutta ne ansaitsevat kokonaan oman blogikirjoituksensa sopivassa välissä. Tekoäly tulee varmasti myös isännöintijärjestelmiin kiinteäksi osaksi, mutta jotta näistä toiminnoista saadaan laadukkaita ja työtä palvelevia, niin pohjatyö pitää olla kunnossa ja tarvittavat ensiaskelmat otettu, ettei kyseessä ole vain päälleliimattu AI:ksi kutsuttu chatbotti.
En henkilökohtaisesti usko, että on oikotietä onneen. Jokaisen ohjelmiston alasta riippumatta pitää sama tie käydä läpi alkuinnostuksesta loputtomaan iterointiin. Kehityspolku ei ole helppo ja oikea juoksu alkaa oikeastaan vasta siitä, kun uusi järjestelmä saadaan jonkinasteiseen tuotantokäyttöön, ja yllä mainittuja poikkeuksien hallinnointeja rupeaa tulemaan vastaan. Niihin on hyvin vaikea varautua etukäteen. Tuotannossa vasta todella testataan kehitystiimin kyvykkyys. Sama koskee sekä kokonaan uusien ohjelmistojen kehitystä, että myös vanhojen ohjelmistojen modernisointia.
Helppoa ei ohjelmistohommat missään muotoa ole, mutta sitäkin palkitsevampia, kun saadaan esimerkiksi näin mahtavia milestoneja, kuin miljoona myyntilaskua, täyteen! 😊
Iso kiitos Avaa:n tiimin puolesta isännöintikentälle luottamuksesta. Pyrimme jatkossakin kuuntelemaan tarkalla korvalla palautetta ja kehittämään toimintoja, jotka hyödyttävät alaa kokonaisvaltaisesti.
-Tomi
