Rakennusalan toiminnanohjauksen valinta pienelle rakennusliikkeelle

Toiminnanohjausta ei hankita ominaisuuslistan vuoksi

Pienessä rakennusliikkeessä hallinto ei yleensä ole yhden ihmisen varsinainen päätyö. Yrittäjä laskee tarjoukset, sopii työmaat, vastaa asiakkaiden kysymyksiin, järjestää työntekijät oikeisiin kohteisiin ja selvittää samalla, ovatko kaikki tunnit, ostot ja lisätyöt muistettu laskuttaa. Päivällä tehdään töitä ja illalla yritetään saada yrityksen tilanne kasaan.

Jonkin aikaa kokonaisuus pysyy hallinnassa sähköpostilla, Excelillä, WhatsAppilla ja puhelimen kalenterilla. Raja tulee vastaan yleensä kolmannen samanaikaisen työmaan kohdalla. Silloin tietoa on enemmän kuin yhden ihmisen kannattaa pitää muistissa, vaikka hän kuinka pystyisi siihen.

Yhdessä viestiketjussa on asiakkaan hyväksyntä. Toisessa on kuva työmaalla löytyneestä vauriosta. Työntekijä ilmoittaa tunnit perjantaina viestillä. Tarjous on tallennettu kannettavalle, mutta laskutusta varten tarvittavat materiaalikuitit ovat vielä pakettiautossa. Työmaa voi olla täysin hallinnassa tekemisen näkökulmasta, mutta taloudellinen tilanne on silti epäselvä.

Rakennusalan toiminnanohjausjärjestelmän pitäisi ratkaista juuri tämä ongelma. Sen tehtävä ei ole tuoda pieneen rakennusliikkeeseen lisää hallintoa, uusia täytettäviä lomakkeita tai raskasta yrityskieltä. Hyvän järjestelmän pitäisi poistaa kohtia, joissa sama tieto kirjoitetaan useaan kertaan, jää yhden ihmisen puhelimeen tai löytyy vasta siinä vaiheessa, kun työmaa on jo valmis.

Siksi toiminnanohjausta ei kannata valita pelkän ominaisuuslistan perusteella. Olennaisempaa on selvittää, miten tieto kulkee tarjouspyynnöstä tarjoukseen, tarjouksesta työmaalle ja työmaalta laskutukseen sekä kustannusseurantaan. Mitä vähemmän tämän ketjun välissä tarvitaan muistamista ja käsin tehtävää tiedonsiirtoa, sitä enemmän järjestelmästä on käytännössä hyötyä.

Mitä rakennusalan toiminnanohjaus tarkoittaa käytännössä?

Toiminnanohjaus kuulostaa helposti paljon suuremmalta asialta kuin mitä se pienessä rakennusliikkeessä oikeasti on. Käytännössä kyse on siitä, että yritys tietää mahdollisimman ajantasaisesti, mitä on myyty, missä työt tehdään, kuka niitä tekee, mitä niiden tekeminen maksaa ja paljonko asiakkaalta voidaan laskuttaa.

Rakennusalan toiminnanohjausjärjestelmä eli ERP voi yhdistää asiakkaat, tarjouspyynnöt, tarjouslaskennan, projektit, työmaat, tehtävät, aikataulut, työaikakirjaukset, kuvat, dokumentit, ostot, alihankinnan, lisätyöt, laskutuksen ja kustannusseurannan.

Ominaisuuksien määrä ei kuitenkaan vielä tee ohjelmistosta toiminnanohjausta. Jos tarjous tehdään yhdessä järjestelmässä, tunnit kirjataan toisessa ja kustannuksia seurataan erillisessä taulukossa, yrityksellä on edelleen monta erillistä työkalua. Jokainen työkalu voi toimia omassa tehtävässään hyvin, mutta niiden välissä tieto liikkuu ihmisten muistin ja käsityön varassa.

Toiminnanohjauksen varsinainen arvo syntyy tietojen välisistä yhteyksistä. Asiakas luodaan kerran. Tarjouksella käytetyt asiakkaan ja työmaan tiedot siirtyvät hyväksynnän jälkeen projektille. Työmaalla kirjattu tunti kohdistuu oikealle projektille ja näkyy sen kustannuksissa. Hyväksytty lisätyö siirtyy laskutukseen. Projektille lisätty kuva löytyy myöhemmin samasta paikasta muiden työmaatietojen kanssa.

Yksi kirjaus voi silloin palvella montaa eri käyttötarkoitusta.

Milloin pieni rakennusliike tarvitsee toiminnanohjausta?

Toiminnanohjausjärjestelmän tarve ei synny tietystä työntekijämäärästä tai liikevaihdosta. Yhden hengen yrityksellä voi olla niin paljon samanaikaisia asiakkaita ja pieniä töitä, että tietojen hallinta vie kohtuuttomasti aikaa. Toisaalta viiden hengen yritys voi pärjätä pitkään kevyellä mallilla, jos työt ovat selkeitä ja projekteja on vain muutama vuodessa.

Tarvetta kannattaa arvioida arjen merkkien perusteella. Järjestelmän hankinta alkaa olla ajankohtainen, jos samoja asiakas- ja työmaatietoja kirjoitetaan useaan paikkaan, tarjousten versioita on vaikea löytää, tuntien tarkistaminen vie viikoittain paljon aikaa tai projektin todellinen kate selviää vasta työn valmistuttua.

Muita tavallisia merkkejä ovat puuttuvat materiaalikuitit, työntekijöiden puhelimiin jäävät työmaakuvat, laskuttamatta unohtuvat lisätyöt ja laskutuksen viivästyminen puuttuvien tietojen vuoksi. Viimeistään silloin kannattaa pysähtyä, kun yrittäjä toimii käytännössä yrityksen muistina ja jokainen kysymys kulkee hänen kauttaan.

Hyvä käytännön testi on kysyä, mitä yrityksessä tapahtuisi, jos yrittäjä olisi viikon tavoittamattomissa. Löytäisikö joku muu ajantasaiset tarjoukset, asiakkaiden kanssa sovitut asiat, työmaiden tehtävät, käytetyt tunnit ja laskuttamattomat työt? Jos vastaus on ei, tietoa on liikaa yhden ihmisen varassa.

Yksittäinen ongelma ei vielä välttämättä vaadi toiminnanohjausta. Jos ongelmia on useita ja ne liittyvät samaan tiedonketjuun, yhden yhteisen järjestelmän hankinta voi olla järkevämpää kuin uusien erillisten työkalujen lisääminen.

Aloita nykyisestä toimintatavasta

Ennen järjestelmien vertailua kannattaa kuvata yrityksen nykyinen toimintaketju mahdollisimman yksinkertaisesti. Tarkoitus ei ole laatia pitkää prosessikaaviota, vaan selvittää, missä tieto syntyy ja mitä sille tapahtuu seuraavaksi.

Tavallinen ketju voi mennä näin:

1. Tarjouspyyntö tulee sähköpostilla tai puhelimella.
2. Asiakkaan tiedot kirjataan muistiin.
3. Kuvat ja piirustukset tallennetaan omaan kansioon.
4. Tarjous lasketaan Excelillä.
5. Tarjous muodostetaan PDF-tiedostoksi ja lähetetään sähköpostilla.
6. Asiakas hyväksyy tarjouksen viestillä tai puhelimessa.
7. Työmaa lisätään kalenteriin.
8. Työntekijöille lähetetään tiedot WhatsAppilla.
9. Tunnit kerätään viikon lopussa.
10. Ostot ja kuitit kootaan eri lähteistä.
11. Lasku tehdään taloushallinnon järjestelmässä.
12. Projektin kannattavuus arvioidaan jälkikäteen.

Tässä mallissa ongelma ei välttämättä ole yksikään käytetty työkalu. Ongelma on siirtymien määrä. Jokaisessa siirtymässä tietoa voidaan joutua kopioimaan, tulkitsemaan tai etsimään uudelleen.

Toiminnanohjausjärjestelmän pitäisi vähentää juuri näitä siirtymiä. Siksi ohjelmistoesittelyssä kannattaa pyytää näyttämään yksi tavallinen työ alusta loppuun. Yksittäinen hieno näkymä ei vielä kerro, poistuuko käsityö yrityksen arjesta.

1. Tarjouslaskennan pitää muodostaa projektin lähtökohta

Rakennusliikkeen kannattavuus ratkaistaan usein jo tarjousvaiheessa. Jos laskelmasta puuttuu työvaihe, materiaalihukka, alihankinta tai riittävä kate, työmaa lähtee liikkeelle väärästä tilanteesta.

Siisti PDF-tarjous on lopputulos, ei laskennan tarkoitus. Tarjouslaskennan pitää erottaa toisistaan ainakin oman työn, materiaalien, alihankinnan ja muut kustannukset, jotta yritys näkee, millä perusteella asiakkaalle annettu hinta muodostuu.

Tarjouksessa kannattaa pystyä käsittelemään yrityksen toiminnan mukaan työvaiheita, määriä, yksikköhintoja, oman työn kustannusta ja myyntihintaa, materiaalihukkaa, alihankintaa, yleiskuluja, tavoiteltua katetta ja arvonlisäveroa. Tarjoukseen tarvitaan myös rajaukset, vaihtoehdot ja liitteet, jotta asiakas ymmärtää, mitä hinta sisältää.

Tärkeä kysymys tulee tarjouksen hyväksymisen jälkeen. Siirtyvätkö tarjous ja sen tiedot suoraan projektille vai pitääkö työmaa perustaa uudelleen? Säilyykö kustannusrakenne mukana, jotta toteumaa voidaan myöhemmin verrata siihen, mitä laskentavaiheessa suunniteltiin?

Jos tarjous jää pelkäksi asiakkaalle lähetetyksi PDF-tiedostoksi, suuri osa laskennassa tehdystä työstä katoaa projektin käynnistyessä.

Ohjelmistoa arvioitaessa kannattaa tarkistaa myös, miten aiempia tarjouksia voidaan hyödyntää. Pieni rakennusliike tekee usein keskenään samantyyppisiä töitä. Hyvin onnistunut tarjous pitäisi voida kopioida uuden laskennan pohjaksi ilman, että mukana siirtyvät vahingossa vanhan asiakkaan tiedot tai projektiin kuulumattomat liitteet.

Fisasin tarjouslaskennassa tarjous voidaan muodostaa työstä, materiaaleista, alihankinnasta ja muista kustannuksista. Vertailussa kannattaa silti arvioida tarjousnäkymän lisäksi koko jatkumo: mitä tapahtuu, kun asiakas hyväksyy tarjouksen ja työ pitäisi käynnistää?

2. Asiakkaan, työmaan ja projektin pitää liittyä toisiinsa

Pienessä yrityksessä asiakas ja työmaa voivat tuntua samalta asialta, mutta järjestelmän kannalta ne kannattaa erottaa. Yhdellä asiakkaalla voi olla useita työmaita. Sama isännöitsijä voi tilata töitä moneen kohteeseen. Rakennusliike voi tehdä yhdelle yritykselle useita projekteja eri osoitteissa ja eri yhteyshenkilöiden kanssa.

Hyvä rakenne etenee asiakkaasta yhteyshenkilöön, työmaahan ja projektiin tai työmääräimeen. Projektiin liittyvät edelleen tehtävät, tunnit, ostot, kuvat, dokumentit ja laskut.

Järjestelmän pitäisi nostaa asiakkaan ja työmaan tiedot automaattisesti mukaan silloin, kun ne ovat jo tiedossa. Jos laskua lähdetään muodostamaan projektilta, asiakkaan nimeä, laskutusosoitetta ja työmaan tietoja ei pitäisi joutua valitsemaan uudelleen. Sama koskee tarjousta, työmääräintä ja dokumenttia.

Automaattisuus ei tarkoita sitä, ettei tietoja voisi korjata. Käyttäjän pitää nähdä, mistä asiakas ja työmaa ovat tulleet, ja pystyä vaihtamaan ne tarvittaessa. Tavallisessa tilanteessa oikeiden tietojen pitäisi kuitenkin siirtyä mukana ilman uutta työtä.

Fisasin projektinhallinta kokoaa projektiin liittyvät tiedot samaan kokonaisuuteen. Vertailussa kannattaa tarkistaa erityisesti, kuinka helposti käyttäjä pääsee asiakkaasta työmaalle ja työmaalta sen tarjouksiin, dokumentteihin, tunteihin, kustannuksiin ja laskuihin.

3. Mobiilikäyttö ratkaisee tiedon laadun

Rakennusalan ohjelmistoa ei voi arvioida pelkästään toimiston tietokoneella. Suuri osa tiedosta syntyy työmaalla, pakettiautossa tai asiakkaan luona. Jos kirjauksen tekeminen puhelimella on hankalaa, tieto kirjataan myöhemmin tai jätetään kokonaan kirjaamatta.

Tämä on yksi yleisimmistä syistä siihen, miksi sinänsä hyvä järjestelmä ei tuota odotettua hyötyä. Raportit voivat olla teknisesti tarkkoja, mutta niiden pohjana oleva tieto on puutteellista.

Työmaalla pitäisi voida aloittaa tai kirjata työaika, valita oikea projekti, ottaa kuva, tarkistaa tehtävät, ilmoittaa poikkeamasta, lisätä kuitti ja löytää tärkeät piirustukset. Tavallisten toimintojen pitää onnistua ilman pitkää valikkokierrosta.

Käytettävyyttä ei kannata arvioida sen perusteella, näyttääkö sovellus siistiltä. Parempi testi on antaa puhelin työntekijälle, joka ei tunne järjestelmää, ja pyytää häntä tekemään kolme tavallista asiaa ilman opastusta: kirjaamaan tunti, lisäämään kuva ja löytämään seuraava tehtävä.

Samalla kannattaa tarkistaa, miten järjestelmä toimii heikolla verkkoyhteydellä. Kaikkialla työmaalla ei ole vakaata yhteyttä. Ainakin tärkeimpien kenttäkirjausten pitäisi kestää hetkellinen yhteyden katkeaminen ilman, että jo syötetty tieto häviää.

Mobiilikäytössä pienetkin kitkat kertautuvat. Viisi työntekijää ja kolme kirjausta päivässä tekee 75 kirjausta viikossa, eli 75 kertaa se yksi ylimääräinen valinta, jota kukaan ei ehtinyt miettiä ohjelmistoa valittaessa.

4. Työajanseurannan pitää palvella palkkoja ja projektia

Monessa yrityksessä työaikaa tarkastellaan vain työntekijän päivän kokonaismääränä. Toiminnanohjauksen näkökulmasta tuntitiedolla on toinenkin tärkeä tehtävä: sen pitää kertoa, paljonko projekti ja sen työvaiheet ovat oikeasti kuluttaneet työtä.

Tuntikirjauksen pitäisi kohdistua vähintään oikealle projektille. Yrityksen tarpeen mukaan mukaan voidaan tarvita myös työvaihe, työmääräin tai lisätyö. Samasta kirjauksesta pitäisi muodostua projektin toteutunut työmäärä ja tarvittaessa asiakkaalta laskutettava tunti.

Järjestelmältä kannattaa selvittää, miten se käsittelee urakkatyön, tuntityön, laskutettavan lisätyön, ei-laskutettavan työn, alku- ja lopetusajan, tauon sekä projektikohdistuksen. Samalla pitää katsoa, miten työntekijän tekemä kirjaus tarkistetaan ja hyväksytään ennen kustannusseurantaa ja laskutusta.

Yksinkertainen kirjaus on kentällä etu, mutta tietojen pitää olla riittävän tarkkoja. Projektin, kohdistuksen ja työn tyypin valinnat ratkaisevat, mille työmaalle kustannus kertyy ja mikä työ siirtyy laskutuspohjalle.

Myös tavallinen hyväksyntätilanne kannattaa katsoa tarkasti. Näkeekö työnjohto kaikkien kirjaukset projekteittain reaaliajassa? Onnistuuko hyväksyntä ilman erillistä viikkoraporttia? Voidaanko tuntityölle ottaa tilaajan kuittaus jo työmaalla?

Fisasin työaikakirjauksissa tunnit kirjataan puhelimella suoraan projektille myös ilman verkkoyhteyttä. Halutessaan yritys voi kytkeä päälle sijainnin tallentumisen kirjaukselle. Esimies hyväksyy tunnit, ja hyväksytty tieto näkyy projektin kustannusseurannassa sekä laskutuspohjalla.

5. Kustannusseurannan pitää kertoa poikkeaman syy

Projektin kokonaiskustannus on hyödyllinen tieto vasta silloin, kun sitä voidaan verrata johonkin. Siksi kustannusseurannan lähtökohdan pitäisi tulla tarjouslaskennasta tai erikseen määritetystä budjetista.

Pelkkä tieto siitä, että budjetista on käytetty 70 prosenttia, ei vielä kerro projektin tilanteesta. Jos työstä on valmis 80 prosenttia, tilanne voi olla hyvä. Jos työstä on valmis vasta puolet, poikkeama vaatii selvittämistä.

Hyvä kustannusseuranta erottaa toisistaan oman työn kustannukset, materiaalit, alihankinnan, muut kulut, laskutetun määrän, vielä laskuttamattoman työn ja hyväksytyt lisätyöt.

Poikkeaman pitää johtaa kysymykseen, johon voidaan vastata. Onko työvaihe vienyt arvioitua enemmän tunteja? Puuttuuko projektilta ostolaskuja? Onko materiaali kirjattu kahteen kertaan? Onko osa työstä tehty mutta jätetty laskuttamatta? Onko projektin sisältö kasvanut ilman hyväksyttyä lisätyötä?

Jos järjestelmä näyttää vain punaisen luvun, yrittäjä joutuu tekemään saman selvitystyön kuin ennenkin. Hyvä järjestelmä auttaa pääsemään luvusta sen taustalla oleviin tapahtumiin.

Kustannusseurannan ei tarvitse olla reaaliaikaista sekunnin tarkkuudella. Pienelle rakennusliikkeelle tärkeämpää on, että tiedot päivittyvät osana tavallista työtä. Kun tunnit kirjataan, ostot kohdistetaan ja lisätyöt hyväksytään, projektin tilanne tarkentuu ilman erillistä raportointipäivää.

6. Dokumentoinnin pitää säilyttää tieto yrityksellä

Rakennusliikkeessä otetaan paljon kuvia. Silti oikean kuvan löytäminen myöhemmin voi olla vaikeaa. Puhelimen kuvagalleriassa kuva ei yleensä kerro, mihin projektiin, huoneeseen, rakenteeseen tai työvaiheeseen se liittyy.

Hyvässä järjestelmässä kuva tai dokumentti liitetään oikeaan projektiin jo tallennushetkellä. Sen yhteyteen voidaan lisätä tarvittaessa otsikko, kuvaus, päivämäärä, luokka, sijainti ja vastuuhenkilö.

Dokumentoinnin pitäisi tukea työvaiheiden etenemistä, rakenteiden sisään jäävien asennusten kuvaamista, havaintojen kirjaamista, tarkastuslomakkeita, työmaapäiväkirjoja, turvallisuusasiakirjoja, vastaanottoa, luovutusta ja takuuajan selvityksiä.

Oleellista on löydettävyys. Jos asiakas kysyy vuoden päästä rakenteen sisään jääneestä asennuksesta, kuvan löytyminen ei saa riippua siitä, kuka työntekijä sen otti ja onko hänellä edelleen sama puhelin.

Fisasin dokumentoinnissa kuvat ja asiakirjat voidaan liittää suoraan projektiin. Järjestelmää valittaessa kannattaa selvittää myös, voiko yritys käyttää valmiita lomakkeita, muokata niitä omaan toimintaansa ja muodostaa täytetyistä tiedoista asiakkaalle tai tilaajalle toimitettavan PDF-dokumentin.

7. Lisä- ja muutostöille tarvitaan selkeä kulku

Rakennustyömaalla suunnitelmat muuttuvat. Purkuvaiheessa löytyy vaurio, asiakas haluaa vaihtaa materiaalin tai alkuperäiseen tilaukseen lisätään uusi työ. Muutos ei ole poikkeus, vaan tavallinen osa rakennusprojektia.

Ongelma syntyy silloin, kun työn sisältö, hinta ja hyväksyntä jäävät puhelun tai viestin varaan.

Toimivassa järjestelmässä lisätyö alkaa työmaalla tehdystä havainnosta tai asiakkaan pyynnöstä. Tilanne kirjataan projektille, mukaan lisätään kuvat ja työn vaikutus lasketaan. Asiakkaalle lähetetään ymmärrettävä tarjous, hyväksyntä tallennetaan ja työ lisätään projektin suunnitelmaan. Lopuksi toteutuneet tunnit ja kustannukset kohdistetaan projektille ja hyväksytty työ siirtyy laskutukseen.

Jos jokainen vaihe tehdään eri paikassa, lisätyö on vaarassa jäädä laskuttamatta. Erityisen tärkeää on, että hyväksytty lisätyö päivittää projektin taloudellisen tilanteen. Muuten kustannusseuranta näyttää ylitystä, vaikka projektin sisältö ja sovittu hinta ovat kasvaneet.

Järjestelmää vertaillessa kannattaa pyytää näyttämään oikea lisätyötilanne, ei vain lomaketta. Miten työ syntyy havainnosta? Mihin asiakkaan hyväksyntä tallentuu? Näkyykö laskuttamaton lisätyö yrittäjälle ilman, että hänen pitää muistaa etsiä sitä?

8. Laskutuksen pitää alkaa tehdystä työstä

Laskutuksen pitäisi olla toiminnanohjauksen ketjun loppupää, ei uusi erillinen työvaihe. Jos asiakkaan, työmaan, tarjouksen, tuntien ja lisätöiden tiedot ovat jo järjestelmässä, niitä ei pitäisi koota laskulle uudelleen.

Pienen rakennusliikkeen kannattaa arvioida, tukeeko järjestelmä kiinteähintaista urakkaa, tunti- ja materiaalilaskutusta, erä- ja osalaskutusta, maksuerätaulukkoa, lisätöiden laskutusta, koontilaskuja, laskun liitteitä ja yrityksen tarvitsemia arvonlisäverokäsittelyjä.

Tärkeä käytännön kysymys on, mistä laskua lähdetään muodostamaan. Jos lasku luodaan projektilta, asiakkaan ja työmaan pitäisi tulla automaattisesti mukaan. Jos lasku luodaan asiakkaalta, asiakkaan tietojen pitäisi olla valmiina ja käyttäjän pitäisi voida liittää oikea työmaa tai projekti.

Järjestelmä ei saa tehdä hiljaisia oletuksia, joita käyttäjä ei näe. Ennen laskun lähettämistä pitää voida tarkistaa asiakas, työmaa, laskutusosoite, rivit, verokäsittely, eräpäivä ja liitteet.

Laskutusnopeus vaikuttaa suoraan yrityksen kassaan. Jos valmis työ odottaa viikon tai kaksi siksi, että tunteja ja kuitteja etsitään eri paikoista, kyse ei ole vain hallinnollisesta vaivasta. Yritys rahoittaa sillä välin asiakkaan projektia omasta kassastaan.

Fisasin laskutuksessa projektin tietoja voidaan hyödyntää laskun muodostamisessa. Kokonaisuutta arvioitaessa kannattaa tarkistaa myös, miten lasku siirtyy kirjanpitoon ja miten mahdolliset korjaukset käsitellään.

9. Tehtävien ja aikataulujen pitää olla riittävän kevyitä

Pienen rakennusliikkeen ei yleensä kannata ottaa käyttöön raskasta projektisuunnittelua, jos työmaat eivät sitä tarvitse. Toisaalta pelkkä kalenterimerkintä ei aina riitä kertomaan, mitä työmaalla pitäisi tapahtua ja kuka siitä vastaa.

Hyvä tehtävä kertoo, mitä pitää tehdä, missä kohteessa, kuka vastaa ja milloin työn pitäisi olla valmis. Siihen voidaan liittää tarvittavat kuvat, dokumentit ja keskustelut. Tilan pitää näkyä yksinkertaisesti: tekemättä, käynnissä tai valmis.

Aikataulutuksessa kannattaa arvioida yrityksen omaa työn tyyppiä. Lyhyitä huolto- ja korjaustöitä tekevä yritys tarvitsee erilaisen näkymän kuin useita kuukausia kestävää urakkaa johtava rakennusliike. Järjestelmän pitäisi tukea tavallista työtä ilman, että jokaiselle pienelle tehtävälle täytyy rakentaa monimutkainen projektisuunnitelma.

Myös muutosten tekemisen pitää olla helppoa. Rakennustyömaan aikataulu elää. Jos tehtävän siirtäminen toiselle päivälle tai toiselle työntekijälle vaatii paljon työtä, suunnitelma lakkaa nopeasti vastaamasta todellisuutta.

10. Viestinnän pitää liittyä projektiin

WhatsApp ja tekstiviestit ovat nopeita, eikä niitä tarvitse yrittää poistaa väkisin. Ongelma on se, että tavallisessa viestiketjussa työmaata koskeva päätös sekoittuu muuhun keskusteluun eikä välttämättä siirry yrityksen yhteiseen tietoon.

Toiminnanohjausjärjestelmän ei tarvitse korvata kaikkea keskustelua. Sen pitäisi kuitenkin tarjota paikka niille asioille, jotka pitää pystyä löytämään myöhemmin. Tällaisia ovat asiakkaan hyväksynnät, muutokset työn sisältöön, työmaalla havaitut ongelmat, tehtävien vastuut, aikataulumuutokset ja kuvat, joihin päätös liittyy.

Projektikohtainen viestintä vähentää henkilöriippuvuutta. Tieto ei jää vain sen ihmisen puhelimeen, joka sattui keskustelemaan asiakkaan kanssa.

11. Integraatio pitää avata käytännön tasolle

Ohjelmiston verkkosivuilla voi lukea, että järjestelmä integroituu taloushallintoon. Tämä ei vielä kerro, mitä tietoa oikeasti siirtyy ja mihin suuntaan.

Taloushallinnon integraatiosta kannattaa selvittää, miten myyntilaskut ja muut tuetut tiedot siirtyvät kirjanpitoon sekä miten virhetilanne näkyy käyttäjälle. Fisasissa laskutus ja taloushallinnon integraatiot kuuluvat samaan kokonaisuuteen, joten tuplatyötä voidaan vähentää projektin laskutuspohjalta kirjanpitoon asti.

Virhetilanteet ovat yhtä tärkeitä kuin onnistunut siirto. Käyttäjän pitää nähdä, jos lasku ei ole mennyt perille. Siirron pitää voida yrittää uudelleen ilman, että sama lasku tai tuntiaineisto syntyy kahteen kertaan.

Pieni yritys ei välttämättä tarvitse taloushallinnon integraatiota heti. Olennaista on tietää, tukeeko järjestelmä yrityksen käyttämää taloushallintoa ja sisältyykö tarvittava yhteys valittuun pakettiin.

Integraatio kannattaa testata yhdellä oikealla laskulla ennen täyttä käyttöönottoa. Tärkeintä on, ettei yhteydestä makseta vain nimen perusteella, vaan se vähentää juuri sitä käsin tehtävää työtä, jota yrityksessä syntyy nyt.

12. Tekoälyn pitää poistaa oikeaa työtä

Tekoäly on tullut nopeasti osaksi ohjelmistojen ominaisuuslistoja. Rakennusliikkeen kannalta kiinnostavaa ei ole se, käyttääkö ohjelmisto tekoälyä, vaan mitä työvaihetta se oikeasti helpottaa.

Hyödyllisiä käyttötapoja voivat olla tarjouspyynnön tietojen tunnistaminen sähköpostista ja liitteistä, asiakkaan ja työmaan perustietojen ehdottaminen, pitkän dokumentin tiivistäminen, tarjousrungon valmistelu, kuvien luokittelu, työmaamerkinnän muodostaminen puheesta tai puuttuvien kirjausten nostaminen tarkistettavaksi.

Hyvän automaation pitää jättää käyttäjälle mahdollisuus tarkistaa tulos. Esimerkiksi tekoälyn avustama tarjouslaskenta tai projektin tulosanalyysi toimii parhaiten päätöksenteon tukena, kun yrittäjä näkee lähtötiedot ja hyväksyy lopputuloksen itse.

Järjestelmältä kannattaa kysyä myös, miten yrityksen tietoja käsitellään. Lähetetäänkö aineisto ulkopuoliselle palveluntarjoajalle? Tallennetaanko sitä mallien kouluttamiseen? Voiko tekoälytoiminnon ottaa pois käytöstä? Maksaako käyttö erikseen?

Tekoälystä kannattaa maksaa silloin, kun se lyhentää yrityksen omaa työketjua. Jos ominaisuus tuottaa vain tekstiä, jota kukaan ei tarvitse, siitä ei synny toiminnanohjauksen hyötyä.

13. Käyttöoikeudet ja tietoturva kuuluvat myös pienelle yritykselle

Pienessä yrityksessä voi tuntua helpolta antaa kaikille käyttäjille samat oikeudet. Käytännössä työntekijän ei yleensä tarvitse nähdä yrityksen kaikkia tarjouksia, asiakasrekisteriä, palkkatietoja tai kaikkien projektien kannattavuutta.

Järjestelmän pitäisi mahdollistaa käyttöoikeuksien rajaaminen ainakin roolin, projektin tai toiminnon perusteella. Työntekijä voi kirjata tunnit ja lisätä kuvia omille työmailleen. Työnjohto voi hallita tehtäviä ja tarkistaa kirjauksia. Yrittäjä tai pääkäyttäjä näkee talouden ja yrityksen asetukset.

Jokaisella käyttäjällä pitäisi olla oma tunnus. Yhteinen tunnus vaikeuttaa muutosten jäljittämistä ja aiheuttaa ongelmia heti, kun työntekijä vaihtuu.

Palveluntarjoajalta kannattaa selvittää, missä tietoja säilytetään, miten ne varmuuskopioidaan, miten käyttäjät tunnistetaan, jääkö muutoksista tapahtumaloki ja miten henkilötietoja käsitellään. Yrityksen pitää saada omat tietonsa ulos ymmärrettävässä muodossa myös silloin, kun sopimus päättyy.

Tietoturva ei tarkoita sitä, että yrittäjän pitäisi osata arvioida pilvipalvelun teknistä rakennetta. Palveluntarjoajan pitää pystyä vastaamaan tavallisiin kysymyksiin selkeästi ja kirjallisesti.

14. Hinta pitää laskea kokonaisuutena

Kuukausihinta on helppo vertailukohta, mutta harvoin koko kustannus. Toiminnanohjausjärjestelmän hintaan voivat vaikuttaa peruspaketti, käyttäjäkohtaiset maksut, käyttöönotto, koulutus, integraatiot, tallennustila, sähköiset allekirjoitukset, verkkolaskut, tekoälytoiminnot ja asiakastuki.

Kokonaiskustannus kannattaa laskea sillä käyttäjämäärällä ja niillä ominaisuuksilla, joita yritys oikeasti tarvitsee. Kahden järjestelmän perushinnat voivat näyttää samalta, mutta toisessa tarpeelliset ominaisuudet sisältyvät pakettiin ja toisessa ne veloitetaan erikseen.

Hinnan rinnalle pitää laskea säästyvä työ. Jos järjestelmä lyhentää viikoittaista tuntien tarkistamista, nopeuttaa laskutusta ja estää muutaman lisätyön unohtumisen, kuukausimaksu voi maksaa itsensä nopeasti takaisin.

Toisaalta kallis järjestelmä ei muutu hyväksi vain siksi, että siinä on paljon toimintoja. Käyttämättömät ominaisuudet eivät tuo hyötyä. Pienelle rakennusliikkeelle järkevä ratkaisu on usein sellainen, joka hoitaa tärkeimmät työketjut hyvin ja jota voidaan laajentaa myöhemmin.

Sopimuksesta kannattaa tarkistaa laskutusjakso, automaattinen uusiutuminen, irtisanomisaika, käyttäjämäärän muuttaminen, lisäkäyttäjien hinta ja se, miten palvelun olennaisista muutoksista ilmoitetaan.

Näin järjestelmä kannattaa testata

Valmista järjestelmää ei kannata arvioida vain myyjän esityksen perusteella. Esittelyssä kaikki etenee helposti, koska esittelijä tuntee tuotteen ja käyttää valmiiksi rakennettua esimerkkiaineistoa.

Paras testi on yksi oikea tai mahdollisimman todellinen työ. Luo asiakas ja työmaa, lisää tarjouspyynnön liitteet, laske tarjous ja lähetä se. Hyväksy tarjous, luo projekti, lisää työntekijä, kirjaa työaikaa puhelimella ja tallenna työmaakuva. Kirjaa hankinta, tee lisätyö, muodosta lasku ja tarkista projektin budjetti sekä toteuma.

Testin aikana kannattaa merkitä ylös kohdat, joissa sama tieto joudutaan antamaan uudelleen. Juuri niistä näkee, kuinka yhtenäinen järjestelmä oikeasti on.

Testiin kannattaa ottaa mukaan ainakin yksi kentällä työskentelevä käyttäjä. Yrittäjä voi pitää raporttinäkymästä, mutta järjestelmä ei toimi, jos työntekijä ei saa kirjattua tuntia tai kuvaa riittävän helposti.

Myös ongelmatilanteita pitää kokeilla. Mitä tapahtuu, jos asiakas vaihtuu, tunti kirjataan väärälle työmaalle, tarjous pitää korjata hyväksymisen jälkeen tai laskulta puuttuu liite? Tavallinen arki sisältää korjauksia. Järjestelmän pitää kestää niitä ilman, että tiedot menevät sekaisin.

Käyttöönotto yhdellä tiedonketjulla

Pienen rakennusliikkeen ei yleensä kannata ottaa kaikkia ominaisuuksia käyttöön samana päivänä. Liian suuri muutos tekee järjestelmästä helposti uuden hallintoprojektin.

Parempi tapa on ottaa ensin käyttöön yksi läpi kulkeva prosessi. Kaikki uudet tarjoukset tehdään järjestelmässä, hyväksytystä tarjouksesta luodaan projekti, työntekijät kirjaavat tunnit projektille ja projektista muodostetaan lasku. Lopuksi toteutuneita tunteja verrataan tarjouksen suunnitelmaan.

Kun tämä ketju toimii yhdellä oikealla työmaalla, mukaan voidaan ottaa dokumentointi, hankinnat, aikataulutus, lisätyöt ja muut toiminnot.

Ennen käyttöönottoa yrityksen kannattaa sopia, kuka perustaa asiakkaat ja projektit, miten projektit nimetään, mille tasolle tunnit kohdistetaan, kuka tarkistaa puuttuvat kirjaukset ja miten kulut käsitellään. Samalla päätetään, missä asiakkaan hyväksynnät säilytetään ja kuka vastaa projektin loppulaskutuksesta.

Ohjelmisto ei yksin ratkaise epäselvää toimintatapaa. Sen pitäisi kuitenkin tehdä sovitun tavan noudattamisesta mahdollisimman helppoa.

Yleisimmät valintavirheet

Suurin järjestelmä valitaan varmuuden vuoksi

Laaja järjestelmä voi olla oikea ratkaisu, mutta ominaisuuksien määrä ei ole itseisarvo. Jos yritys tarvitsee kuukausien käyttöönottoprojektin ennen ensimmäistä tarjousta tai tuntikirjausta, kokonaisuus voi olla yrityksen kokoon nähden liian raskas.

Päätös tehdään vain kuukausihinnan perusteella

Halpa järjestelmä voi tulla kalliiksi, jos työntekijät eivät käytä sitä tai samoja tietoja joudutaan käsittelemään edelleen käsin. Hinnan rinnalla pitää arvioida ajansäästö, laskutusnopeus ja tiedon laatu.

Kentän käyttäjät unohdetaan

Työmaalla syntyvän tiedon laatu ratkaisee kustannusseurannan, dokumentoinnin ja laskutuksen luotettavuuden. Siksi työntekijän mobiilikokemus kuuluu valintapäätökseen.

Integraation oletetaan hoitavan kaikki

Integraation nimi ei kerro sen sisältöä. Tietojen suunnat, siirtyvät kentät ja virhetilanteet pitää selvittää erikseen.

Vanhoja toimintatapoja ei lopeteta

Jos uusi järjestelmä otetaan käyttöön, mutta samoja tietoja ylläpidetään edelleen myös Excelissä, viesteissä ja paperilla, hallintotyö kasvaa. Yrityksen pitää päättää, mikä järjestelmä on minkäkin tiedon ensisijainen paikka.

Kaikki otetaan käyttöön kerralla

Yksi toimiva prosessi tuottaa enemmän hyötyä kuin kymmenen puoliksi käyttöön otettua ominaisuutta.

Tiedon ulos saamista ei selvitetä

Järjestelmän vaihtaminen voi tulla joskus ajankohtaiseksi. Asiakas-, projekti-, tunti-, lasku- ja dokumenttitiedot pitää voida siirtää yrityksen käyttöön ymmärrettävässä muodossa.

Käytännön tarkistuslista valintaan

Ennen päätöstä varmista ainakin seuraavat asiat:

• Tarjouksessa laskettua kustannusrakennetta voi verrata toteumaan työmaan jälkeen.
• Asiakkaan ja työmaan tiedot siirtyvät työvaiheesta toiseen.
• Tavalliset kirjaukset onnistuvat puhelimella ilman pitkää opastusta.
• Tunnit kohdistuvat projektille ja näkyvät myös kustannuksissa.
• Kustannuspoikkeamasta pääsee sen taustalla oleviin tapahtumiin.
• Lisätyö kulkee havainnosta hyväksyntään ja laskulle.
• Kuvat ja dokumentit löytyvät myöhemmin projektin perusteella.
• Valmiista työstä saa laskun ulos hetkessä, ei viikkojen kuluttua.
• Integraation todellinen sisältö ja virhetilanteet on näytetty.
• Käyttöoikeudet voidaan rajata roolin ja tarpeen mukaan.
• Yrityksen tiedot saa tarvittaessa ulos palvelusta.
• Kokonaiskustannus on laskettu todellisella käyttäjämäärällä.
• Ensimmäinen oikea projekti voidaan ottaa käyttöön ilman raskasta hanketta.

Millainen ratkaisu sopii pienelle rakennusliikkeelle?

Pienelle rakennusliikkeelle sopiva järjestelmä on yleensä riittävän laaja yhdistämään tärkeimmät työvaiheet, mutta riittävän kevyt otettavaksi käyttöön ilman pitkää ERP-hanketta.

Hyvä ratkaisu ei edellytä, että yritys muuttaa itsensä suuren rakennuskonsernin kaltaiseksi. Sen pitäisi tukea yrityksen omaa tapaa toimia ja samalla poistaa turhaa käsityötä.

Käytännössä tärkeimpiä asioita ovat tarjous, josta voidaan jatkaa suoraan projektille, asiakkaan ja työmaan tietojen automaattinen siirtyminen, helppo mobiilikäyttö, projektille kohdistuvat tunnit ja kulut, dokumenttien säilyminen, lisätöiden hyväksyntä, laskutus ja ajantasainen näkymä projektin talouteen.

Fisas on suunniteltu erityisesti pienten rakennusyritysten toiminnanohjaukseen. Se yhdistää tarjoukset, asiakkaat, projektit, työaikakirjaukset, dokumentoinnin, kustannukset ja laskutuksen mobiilisti käytettävään kokonaisuuteen. Tarkoitus ei ole lisätä hallintoa, vaan rakentaa tarjouspyynnöstä laskutukseen asti kulkeva tiedonketju, jossa samaa tietoa ei tarvitse kirjoittaa jatkuvasti uudelleen.

Järjestelmän sopivuus kannattaa silti aina testata yrityksen omalla työllä. Paras ohjelmisto ei ole se, jossa on pisin ominaisuuslista. Paras on se, jota yrityksen ihmiset käyttävät ja jonka tiedoilla yrittäjä pystyy tekemään parempia päätöksiä.

Usein kysyttyä toiminnanohjauksen valinnasta

Mikä on rakennusalan toiminnanohjausjärjestelmä?

Rakennusalan toiminnanohjausjärjestelmä on ohjelmisto, joka yhdistää rakennusliikkeen asiakas-, tarjous-, projekti-, työaika-, kustannus-, dokumentti- ja laskutustietoja samaan kokonaisuuteen. Toimialakohtainen järjestelmä huomioi sen, että suuri osa tiedosta syntyy vaihtuvilla työmailla ja sitä pitää pystyä käsittelemään puhelimella.

Kuinka pienelle yritykselle toiminnanohjaus sopii?

Toiminnanohjaus voi olla hyödyllinen jo yhden tai muutaman henkilön rakennusliikkeelle, jos projekteja on useita, tietoa käsitellään monessa paikassa tai yrittäjän aikaa kuluu paljon tarjousten, tuntien, kuittien ja laskutuksen kokoamiseen. Tarve riippuu enemmän toiminnan monimutkaisuudesta kuin henkilöstömäärästä.

Mitä eroa on toiminnanohjauksella ja laskutusohjelmalla?

Laskutusohjelman päätehtävä on muodostaa ja käsitellä laskuja. Toiminnanohjaus yhdistää laskutuksen sitä edeltäviin vaiheisiin, kuten tarjouslaskentaan, työajanseurantaan, projektin kustannuksiin ja lisätöihin. Näin yritys näkee laskujen lisäksi, mitä työn tekeminen on maksanut ja onko projekti kannattava.

Pitääkö kaikki ominaisuudet ottaa käyttöön heti?

Ei tarvitse. Pienessä yrityksessä käyttöönotto kannattaa aloittaa yhdestä tärkeästä prosessista, kuten tarjouksen muuttamisesta projektiksi, tuntien kirjaamisesta ja laskun muodostamisesta. Muita ominaisuuksia voidaan lisätä, kun perusprosessi toimii.

Kannattaako valita rakennusalalle tehty vai yleinen järjestelmä?

Yleinen projektinhallinta- tai laskutusohjelmisto voi olla riittävä, jos yrityksen tarpeet ovat yksinkertaiset. Rakennusalalle tehty järjestelmä on yleensä vahvimmillaan silloin, kun tarvitaan työmaakohtaista tuntien ja kustannusten seurantaa, tarjouslaskentaa, dokumentointia, lisätöitä ja mobiilikäyttöä samassa kokonaisuudessa.

Miten toiminnanohjaus maksaa itsensä takaisin?

Hyöty voi syntyä nopeammasta laskutuksesta, tarkemmista tuntikirjauksista, laskuttamatta jäävien lisätöiden vähenemisestä, projektin kustannuspoikkeamien aikaisemmasta havaitsemisesta ja hallintoon kuluvan ajan säästymisestä. Takaisinmaksua kannattaa arvioida yrityksen oman ajankäytön ja nykyisten virheiden perusteella.

Yhteenveto

Rakennusalan toiminnanohjauksen valinta kannattaa aloittaa yrityksen omasta työstä. Missä tieto syntyy, mihin se siirretään ja missä kohdassa sitä joudutaan etsimään tai kirjoittamaan uudelleen?

Pienelle rakennusliikkeelle hyvä järjestelmä tekee tarjouspyynnöstä, tarjouksesta, projektista, työmaan kirjauksista, kustannuksista ja laskutuksesta yhden jatkuvan ketjun. Asiakas ja työmaa kulkevat mukana ilman turhaa uudelleenvalintaa. Työntekijä pystyy tekemään tavalliset kirjaukset puhelimella. Yrittäjä näkee projektin tilanteen ennen kuin työmaa on valmis.

Järjestelmän ei tarvitse tehdä kaikkea. Sen pitää tehdä yrityksen tärkeimmät asiat niin hyvin, että vanhoista rinnakkaisista tavoista voidaan oikeasti luopua.