question:Olen valinnut 5 lähdettä. Voisitko analysoida Ensimmäisen lähteen? OSTO- JA MYYNTILASKUJEN KIRJAUS- JA TARKISTUSPROSESSIEN TEHOSTAMINEN Tämän työn tavoitteena oli tehdä kehittämisehdotuksia logistiikka-alalla toimivan yrityksen ostoja myyntilaskujen kirjaus- ja tarkistusprosessien tehostamiseksi sekä kartoittaa niiden toimivuutta. Kehittämisehdotukset kohdistuivat lähinnä ERP-toiminnanohjausjärjestelmän kehittämiseen, mutta myös muihin järjestelmän ulkopuolisiin prosesseihin. Työ on ajankohtainen, sillä yritys on huomannut, että laskujen kirjaus- ja tarkistusprosessit ovat olleet tehottomia ja uusi toiminnanohjausjärjestelmä on tulossa lähitulevaisuudessa. Lopputulokseksi saatiin, että yrityksen nykyiset kirjaus- ja tarkistusprosessit ovat hyviä, mutta tällä hetkellä hiukan tehottomia. Tutkielman tekemiseen käytettiin omakohtaisia kokemuksia ja kollegoiden haastatteluja. Tutkielmassa annettiin tehottomille prosesseille konkreettisia parannusehdotuksia koskien uuden ERP-järjestelmän vaadittavia ominaisuuksia sekä käytännössä ilmeneviin ongelmiin, kuten yhtenäisiin käytäntöihin. Työ ei kuitenkaan sisällä seurantaa ehdotuksien onnistumiselle, koska yritys X ei ole vielä aloittanut projektia uuden ERPjärjestelmän hankkimiseen. Työstä on mahdollista tehdä jatkotutkielma, kun yritys on implementoinut uuden ERP-järjestelmän, haastattelemalla työntekijöitä ja kyselemällä heiltä heidän mielipiteitään uudesta ERP-järjestelmästä. ASIASANAT: ERP-järjestelmä, lasku, laskutusprosessi, tehokkuus BACHELOR´S THESIS | ABSTRACT TURKU UNIVERSITY OF APPLIED SCIENCES Business logistics Autumn 2019 | 38 pages, 1 page in appendices Eelis Lindvall ENCHANCING THE RECORD AND REVIEW PROCESSES IN INVOICING The objective of this thesis was to give development suggestions for a corporation operating in logistics regarding their entry and inspection processes in invoicing and to map out those processes’ operability. The development suggestions targeted mainly at developing a new ERP system but also at other processes outside of the ERP system. The subject of this work is currently topical as the corporation noticed that their entry and inspection processes have been ineffective and there is going to be soon an acquisition of a new ERP system. The outcome was that the entry and inspection processes in invoicing are good, but currently a little ineffective. Personal experience and interviews were used to make this thesis. This thesis gave concrete development suggestions regarding the new ERP system’s required attributes and to daily occurring problems such as integrated practices. However, this thesis did not include monitoring the success of the suggestions as the corporate has yet to start a project to acquire a new ERP system. It is possible to do a follow-up study of this thesis once the corporation has implemented the new ERP system by interviewing the employees and by asking their opinion regarding the new ERP-system. KEYWORDS: Effectivity, ERP system, invoice, invoicing processes SISÄLTÖ 1 JOHDANTO 6 1.1 Kohdeyritys 6 1.2 Työn tavoite, rajaus ja metodologia 7 2 KIRJANPITO 9 2.1 Kahdenkertainen kirjanpito 9 2.2 Tilit 10 2.3 Kirjanpitoaineisto 11 2.4 Liiketapahtumat ja tositteet 11 2.4.1 Lasku eli tulotosite 12 2.4.2 Menotosite 13 2.4.3 Tiliote tositteena 14 3 LASKUTUS 15 3.1 Asiakasrekisteri 15 3.2 Ostoreskontra 17 3.2.1 Ostolaskut ja niiden käsitteleminen 17 3.2.2 Avoimet ostolaskut 18 3.3 Myyntireskontra 18 4 SÄHKÖINEN TALOUSHALLINTO 20 5 YRITYKSEN OSTO- JA MYYNTILASKUT TANKKIKONTTIOSASTOLLA 21 5.1 Myyntilaskutusprosessi tankkikonttien tuonnissa 21 5.2 Tullausta vaativat keikat 22 5.3 Prosessi myyntilaskuun viennin puolella 22 5.4 Ostolaskujen kirjaaminen 23 5.5 Myyntilaskujen kirjaaminen 24 6 NYKYISTEN PROSESSIEN TILA 26 6.1 Ostolaskujen ongelmakohtia 26 6.1.1 Excel-tiedostot 27 6.1.2 Alustojen määrä ja kankeus 28 6.1.3 Toimittajien erilaiset käytännöt 30 6.2 Myyntilaskujen ongelmakohtia 31 6.2.1 Tarjoukset 31 6.2.2 Myyntilaskun järjestelmään kirjaamisen ongelmat 32 6.2.3 Lisäkulujen saaminen laskutukseen 33 7 KEHITYSEHDOTUKSET 35 8 YHTEENVETO 37 LÄHTEET 38 LIITTEET 39 KUVAT Kuva 1 Kirjanpidon erilaisia tilejä. 10 Kuva 2 Kuva laskusta. 13 Kuva 3 Prosessi tilauksesta kirjanpitoon. 16 Kuva 4 Kuva ostolaskun kirjauksesta. 29 Kuva 5 Kuva taulukosta, josta voi valita kuluja. 32 6 1 JOHDANTO Yrityksien perusasioihin kuuluvat olennaisesti osto- ja myyntilaskut, joiden perusteella rahaa joko saadaan tai kulutetaan. Koska laskutus perustuu osto- ja myyntitapahtumiin, on erittäin tärkeää, että osto- ja myyntilaskut ovat oikein, jotta säilytetään vastuullisuus sidosryhmien ja lain silmissä. Oikeellinen laskutus johtaa myös oikeaan määrään kassatuloja. Osto- ja myyntilaskut siirtyvät laskutusprosessien jälkeen lopulta arkistoon ja kirjanpitoon. Jos virheellinen lasku siirtyy kirjanpitoon, vaikuttaa se yrityksen taseeseen. Muita mahdollisia haittoja voivat olla esimerkiksi virheestä johtuvat liian pienet saatavat, jos myyntilaskuun on kirjattu esimerkiksi virheellisesti halvempi tuote tai liian suuri alennusprosentti. Myynti- ja ostolaskujen hoitamiseen kulutetaan väistämättä työtunteja, vaikka laskutus olisi sähköinen ja automatisoitu. Sähköiseen laskutukseen ei kannata luottaa sokeasti, vaan laskut olisi hyvä tarkistaa joka tapauksessa tai viimeistään kirjanpitäjän kehotuksen jälkeen. Työtunnit, jotka laskujen tarkistamiseen käytetään, ovat suoraan verrannollisia yrityksen laskutusprosesseihin ja oikeastaan niiden tehokkuuteen ja helppokäyttöisyyteen. Helpot ja tehokkaat prosessit nopeuttavat laskujen oikeellisuuden tarkistamista ja vähentävät virheiden määrää laskuissa. Virheettömät laskut puolestaan mahdollistavat sen, että tulevaisuudessa ei tarvitse palata laskuun virheiden takia ja käyttää virheen etsimiseen ja korjaamiseen lisää resursseja. 1.1 Kohdeyritys Tämän työn kohdeyritys on logistiikka-alan konserni, jossa työskentelen muun muassa asiakkuuksien ja laskutuksen parissa. Konserni on yksityinen logistiikka- ja investointiyritys, jonka päätoimipiste on Norjassa. Suomen toimipisteessä työskentelee kirjoittamisen hetkellä 12 henkilöä, ja toimipiste hoitaa tankkikonttien kuljetuksia, projektikuljetuksia ja trailerikuljetuksia. Konsernin Suomen toimipisteen liikevaihto on ollut 10 miljoonan euron luokkaa viime vuosina. 7 1.2 Työn tavoite, rajaus ja metodologia Työn tavoite on etsiä laskutusprosesseista kohtia, joita voisi muuttaa tehokkaammiksi. Nopeus ja helppokäyttöisyys laskutusprosesseissa on tässä työssä etusijalla, mutta laskujen oikeellisuudessa ei voida kuitenkaan joustaa yhtään. Yritys tarjoaa kuljetuspalveluita projektiluontoisesti sekä bulkkikuljetuksina tankkikontteja. Tämä työ tulee koskemaan vain tankkikonttien laskutusprosesseja. Tankkikontteja on sekä tuonnissa että viennissä. Yrityksillä on myös erilaiset tarpeet määrissä ja tuotteissa mitä kuljetetaan ja tämä luonnollisesti vaikuttaa laskutukseen ja sen prosesseihin. Aiheen valikoituminen perustuu työntekijöiden kokemiin ongelmiin. Laskutusprosessit ovat yleisesti katsoen hyvällä mallilla ja mahdollistavat lähes kokonaan virheettömät laskut, mutta virheettömyys voi välillä viedä aikaa enemmän kuin olisi tarpeen. Kuten Erätuuli, M; Leino, J. & Yli-luoma, P. (1994, 11) kirjassaan kuvaavat, ilmiö, jota tutkimus pyrkii selittämään, on helpoin tehdä selväksi, jos sen voi asettaa kysymyksen muotoon. Selitettävänä oleva ilmiö kysymyksenä antaa lukijalle helpommin käsityksen, että tutkimus on vain keino saada vastaus tiettyyn tai tiettyihin kysymyksiin. (Erätuuli ym. 1994, 11.) Tutkimuskysymykset tässä tutkimuksessa ovat seuraavanlaiset: Mikä tekee yrityksen kirjaus- ja tarkistusprosesseista tehottomia? Miten yrityksen kirjaus- ja tarkistusprosesseja saisi tehostettua? Tutkimuksen suorittamisen jälkeen tavoitteena olisi saada käsitys yrityksen kirjausprosesseista, niiden tehokkuudesta ja niiden mahdollisista parannuksista. Empiirisen yhteiskuntatutkimuksen alue on käytännössä dikotominen. Perusasenteiden erot ovat yleisesti selkeästi kaksijakoisia vastinpareja, kuten kvalitatiivinen – kvantitatiivinen tai objektiivinen – subjektiivinen. Aaltolan ja Vallin (2007, 18) mukaan tämän ymmärtäminen auttaa valitsemaan itselleen oikeanlaisen tutkimusmetodin. Asia ei ole tietenkään täysin mustavalkoinen, ja edellä mainittuihinkin tutkimuksellisiin asenteisiin löytyy yhteinen tekijä. Tämä tekijä on empiirisen tutkimuksen lähtökohta. (Aaltola & Valli 2007, 18–19; Heikkilä 2014, 27–28.) 8 Opinnäytteen tutkimusotteeksi valittiin konstruktiivinen case-tutkimusote, ja tutkielma on luonteeltaan kvalitatiivinen. Kvalitatiivinen tutkimus sopii hyvin suuremman tutkimuksen esitutkimukseksi, ja koska tämä tutkielma ei koske koko osto- tai myyntireskontraa, ei se ole kokonaisvaltainen tutkimus aiheesta. Kvalitatiivisessa, eli laadullisessa, tutkimuksessa on olennaista nostaa tutkimuksen kohteiden (toimijoiden) subjektiivisia näkökulmia esille. Tämä sopii hyvin tutkielman työhön, joka perustuu pitkälle kollegoiden omien näkemyksien varaan ja toivomuksiin, miten kirjausprosesseja voidaan tehostaa ja mitä epäkohtia prosesseista löytyy. Kvalitatiivinen tutkimus antaa vapauden subjektiivisuuteen, toisin kuin kvantitatiivinen, eli mittaavampi ja objektiivisempi tutkimusmetodi. Subjektiivisuus antaa vapaamman tavan hakea vastausta tutkimuskysymyksille. Vaikka kvalitatiivisessa tutkimuksessa on mukana subjektiivisuutta, hyvän tutkielman edellytyksiä ovat silti objektiivisuus, validiteetti ja reliabiliteetti. (Aaltola, & Valli, 2007, 18–19; Heikkilä, T. 2014, 27–28.) Tutkielman konstruktiivinen osuus tulee sisältämään ehdotuksia, jotka parantaisivat kirjaus- ja tarkistusprosesseja. Ehdotuksien toimivuuden mittaamista tässä opinnäytetyössä ei kuitenkaan ehditä tehdä, koska yritys on aloittamassa projektin uuden ERPjärjestelmän implementoimiseksi. Havainnot tuovat näkemyksiä ja ehdotuksia siihen, mitä uudessa järjestelmässä tulisi olla eri tavalla kuin vanhassa, jotta uuden järjestelmän kirjaus- ja tarkistusprosessit olisivat tehokkaampia verrattuna vanhaan järjestelmään. Jos uuden järjestelmän hankinta viivästyy, tutkielma tekee ehdotuksia myös väliaikaiseen prosessien parantamiseen. 9 2 KIRJANPITO Lähtökohtaisesti jokainen liike- tai ammattitoimintaa harjoittava on kirjanpitovelvollinen, eli hänen tulee pitää kirjaa toiminnastaan. Kirjanpito on olennainen osa verojen maksamisessa verovelvollisilla, mutta sen päätarkoitus on auttaa tuloksen selvittämisessä yritystoiminnassa. Tuloksen perusteella maksetaan veroja ja muita maksuja, jotka ovat laissa säädeltyjä. Myös yritystoiminnan voitto määräytyy kirjanpidon mukaan ja omistajat ovat tästä kiinnostuneita, koska voitosta saadaan jakokelpoiset osingot määrättyä. (Tomperi 2017, 11; Verohallinto 2107.) Kirjanpidon muodostuminen voi tulla pääkirjanpidosta sekä osakirjanpidosta. Osakirjanpidolla tarkoitetaan kirjanpidon eri osa-alueista, kuten laskutus, myynti- ja ostoreskontra, palkanlaskenta ja varasto. Jos kirjanpito muodostuu pääkirjanpidosta ja osakirjanpidosta, pitää niiden yhteys voida todentaa vaikeuksitta, ja sen vuoksi osakirjanpidon ja pääkirjanpidon yhteydet luetteloidaan siten, että yhteydet ilmenevät niistä selkeästi. Lisäksi tästä luettelosta tulee myös ilmetä, missä on yrityksen kirjanpitoaineiston säilytys. (Eklund & Hakonen 2018, 24.) 2.1 Kahdenkertainen kirjanpito Kirjanpito voi olla yhdenkertainen tai kahdenkertainen. Ainoastaan ammatinharjoittajalla voi olla yhdenkertainen kirjanpito, mutta liikkeenharjoittajalla se on kahdenkertainen. Kahdenkertaisella kirjanpidolla tarkoitetaan sitä, että jokainen merkintä tileille tehdään kahdenkertaisesti, eli merkitään kahdelle eri tilille. Toiseen tiliin merkitään debet tai kredit riippuen merkinnän laadusta ja vastatilille kirjataan vastakkainen kirjaus. Jos esimerkiksi yritys ostaa tietokoneohjelmiston käteiskauppana, merkitään kirjanpidossa pankkitilille kredit-puolelle ohjelmiston hinta ja tietokoneohjelmisto-tilille debet-puolelle sama ohjelmiston hinta. (Jormakka, Koivusalo, Lappalainen & Niskanen 2015, 51–52.) 10 2.2 Tilit Tili on kirjausyksikkö kirjanpidossa, johon merkitään esimerkiksi tulo- ja menolajin, pääoman tai velkatyypin vaihtelua eli nousut ja laskut. Jokaiselle liiketapahtumalle on oma tilinsä, jolle tehdään merkintä ja kahdenkertaisessa kirjanpidossa vastatili. (Jormakka ym. 2015, 50.) Kuva 1 esitetään esimerkki erilaisista tileistä ja niihin tehdyistä mahdollisista merkinnöistä. Tilit on kuvattu T-tiliristikossa, jonka vasemmalla puolella on debet ja oikealla kredit. Kuva 1. Kirjanpidon erilaisia tilejä (Yritysvinkit 2017). 11 2.3 Kirjanpitoaineisto Kun yritys aloittaa toimintansa, kaikki liiketapahtumista tulevat todenteet pitää kerätä ja pitää tallessa. Kirjanpitoaineistoa ovat kaikki asiakirjat ja tiedostot, jotka ovat osa yksityisasiakkaiden, pankkien, toisten yritysten tai viranomaisten kanssa asioidessa tarpeellisia. Tämä kirjanpitoaineisto on pidettävä liiketapahtumia todentavana aineistona ja talletettava liikekirjeenvaihtona. Kirjanpitoaineiston käsittely ja säilytys on tapahduttava niin, että niiden tarkastelu on helppoa ja ne ovat tulostettavissa pyynnöstä Suomessa sellaisessa muodossa, että niitä voi yleisesti pitää selväkielisenä. Aineistoa pitää säilyttää vähintään kuusi vuotta. Kuusi vuotta alkaa kulua vasta, kun sen tilikauden, jona aineisto on syntynyt, kalenterivuosi on loppunut. Jos esimerkiksi tilikausi on päättynyt 30.6.2010, kirjanpitoaineisto (tilikauden tositteet) tulee olla säilytettynä vähintään 31.12.2016 asti. Kirjanpito, tilinpäätös, tililuettelot ja muut kirjanpitokirjoihin kuuluvat aineistot pitää säilyttää vähintään 10 vuotta laskettuna tilikauden päätöksestä, eli se alkaa kulua ennen kuluvan kalenterivuoden loppumista. Vaikka liiketoiminta loppuisi, aineistoa on silti säilytettävä vaadittavan ajan. Säilytyksestä vastaa kirjanpitovelvollinen. (Eklund & Hakonen 2018, 18, 24.) 2.4 Liiketapahtumat ja tositteet Kuten on säädetty kirjanpitolaissa, kirjanpitovelvollisen on määrä kirjata kaikki liiketapahtumat kirjanpitoonsa. Liiketapahtumia ovat muun muassa menot ja tulot sekä rahoitustapahtumat. Rahoitustapahtumiin sisältyy myös niiden oikaisu- ja siirtoerät. Kirjauksien yksilöintitapaa ei ole laissa erikseen määrätty, mutta kirjauksen ja sen tositteen sekä liiketapahtuman yhteys on pakko olla helposti todistettavissa pyydettäessä. Tätä helpottava tapa on päivätä ja järjestelmällisesti numeroida jokainen tosite ja tehdä sitä vastaava kirjaus. Jos peruskirjanpidosta selviää vaikeuksitta liiketapahtuma, ei enää tänä päivänä tarvitse merkitä käytettyjä tilejä. (Eklund & Hakonen 2018, 18; Lindfors 2010, 21.) Tositteet on osoitettu kirjanpitovelvolliselle ja antajan pitää tehdä tosite omalla nimellään ja osoitteellaan luettavaan muotoon. Yrityksen tositteita ovat muun muassa myynti- ja ostolaskut, myyntiraportit kassasta, tavaran toimituksesta rahtikirja sekä lähetysluettelo, tiliotteet ja käteis- ja pankkikorttikuitit. Näissä tositteissa on pakko olla kirjanpitolaissa säädetyt tietosisältövaatimuksiin perustuvat tiedot. Verohallinto on tämän perusteella antanut ohjeet laskumerkintävaatimuksista. (Eklund & Hakonen 2018, 18.) 12 Verohallinnon antaman laskumerkintävaatimuksia koskevan ohjeen mukaan laskumerkintävaatimuksia kotimaankaupassa ovat seuraavanlaiset vaatimukset: • laskutuspäivä, eli päivä jona lasku on annettu • tositeen tunniste, joka on yleensä laskun numero • myyjän FI + Y-tunnus arvonlisäveroa varten • yhteisömyynnissä ja/tai käänteisen verovelvollisuuden omaavan ostajan arvonlisäverotunniste • tieto mitä tavaraa ja paljonko tai palvelun laajuus ja laji • molempien osapuolien nimet ja osoitteet • toimituspäivä, palvelun suorituspäivä tai ajanjakso tai ennakkomaksun suorituspäivä • veroton myyntihinta ja verokannan mukaan arvonlisävero erikseen • mahdolliset hyvitykset sekä alennukset • muutoslaskussa pitää viitata aikaisemman laskun tunnukseen • merkintä myynnin mahdollisesta verottomuudesta (Verohallinto 2017) Itselaskutus, käännetyt verovelvollisuudet tai vastaavanlaisilla laskutuksilla on näiden edellä mainittujen vaatimuksien lisäksi omia vaatimuksia. (Eklund & Hakonen 2018, 18, 60). 2.4.1 Lasku eli tulotosite Lasku on tosite tulosta. Tositteesta tulee löytyä vastaanottajan tiedot ja se, koska lasku on tehty (laskun päiväys). Myös luovutettu suorite (suorite on palvelu tai tuote, jota yritys myy) ja suoritteen luovutusajankohta tulee löytyä tositteesta. Luovutusajankohta on päivämäärä, jolloin asiakas on saanut tuotteet tai palvelut kokonaisuudessaan. Laskut luovat siis tulotositteen, mutta myyntitapahtuman ollessa käteismyynti on myyntipäivän kassapäätteen myyntiraportti tulotosite (käteismyyntitosite). Alkuperäiset kappaleet myyntilaskuista lähetetään aina ostajalle ja kirjanpitoon liitetään tulotositteeksi kopio laskusta. Jotkut toimialat ovat hyväksyneet käytännön, jossa ostaja tekee itse tositteen myyjän puolesta (esimerkiksi puualalla). Arvonlisäverolain mukaan tämä käytäntö on hyväksyttävää, jos asiasta on sovittu etukäteen ja myyjä hyväksyy tositteen sen saadessaan itselleen. (Eklund & Hakonen 2018, 19; Lindfors 2010, 22.) 13 Kuva 2. Kuva laskusta (Inv24 2019). Alla esimerkkinä kuva oikeaoppisesta laskusta. 2.4.2 Menotosite Menotosite on tosite menosta. Se on ostolasku tai vastaavanlainen tosite, jonka yritys vastaanottaa myyjältä. Sen on siis ensisijaisesti tultava yrityksen ulkopuolelta. Menotositteessa tulee olla kirjattuna lähettäjän (myyjän) ja vastaanottajan yhteystiedot sekä Y-tunnus. Lasku pitää olla päivätty. Myös hankitut palvelut ja tuotteet ja niiden vastaanottoaika pitää käydä ilmi menotositteessa. Vastaanottoaika on se päivä tai ajanjakso, jolloin tuotteet tai palvelut on toimitettu ostajalle tai palkat on maksettu. Jos nämä eivät käy ilmi selvästi, tulee menotositteen mukaan kirjanpitoon liittää lähetysluettelo tai muu 14 sitä vastaava tosite, joka on kuitenkin alkuperäinen eikä kopio. (Eklund & Hakonen 2018, 21.) 2.4.3 Tiliote tositteena Tiliotetta voi käyttää myös tositteena sekä maksun suorittamisesta että vastaanottamisesta. Tiliote pitää olla numeroitu ja sen on pidettävä sisällään riittävä selvitys maksutapahtumista. Sen pitää myös näyttää toteen maksujen kirjausketjun pankin omassa maksujenvälitysjärjestelmässä. Tiliotteesta pitää nähdä myös, mitä maksu koskee, jos sitä käytetään tulo- tai menotositteena. Tästä esimerkkinä on pankin palvelumaksut, jotka pankki on eritellyt tiliotteelle. (Lindfors 2010, 23.) 15 3 LASKUTUS Yrityksen myydessä kuluttajalle tavaroita tai palveluita käytetään yleensä käteiskauppaa, eli ostaja maksaa heti tavaransa ilman luottoa. Yritykset myyvät keskenään yleensä luotolla, eli toisin sanoen laskulla. Lasku on tällöin myyjälle myyntitulokseen kirjattava myyntisaaminen. Ostajalle tämä sama lasku on ostomenoa ja ostovelan lisäämistä. Lasku toimitetaan ostajalle myyjän toimesta perusoletuksena paperisena, mutta vastaanottajan suostumuksella lasku voidaan myös toimittaa sähköisesti, kuten verkkolaskuna, sähköpostilaskuna tai e-laskuna. (Tomperi 2017, 52–53; Verohallinto 2017.) Yrityksessä laskutuksen ja siihen liittyvät tehtävät hoitaa laskuttaja. Laskuttajan tulee huolehtia, että ennen laskutusta kaikki taustatiedot ovat kunnossa. Taustatietoja, joita tarvitsee laskutukseen, voivat olla muun muassa asiakastiedot, tuotetiedot, maksu- sekä toimitusehdot ja viivästyskoron määrä. Myös hinnanlisät kuuluvat laskutukseen. Hinnanlisiä voivat olla laskutusmuoto (paperinen lasku), laskutuslisä tai vaikka kuljetukseen liittyvät lisämaksut. Hinnanlisät ovat yleisesti ottaen aina etukäteen sovittuja lisiä, jotka löytyvät kauppasopimuksesta tai tarjouksesta. Myyntireskontraa voi hoitaa toinen henkilö, joka pitää huolen myyntilaskuista saatavista suorituksista ja yleensä hoitaa myös maksumuistutuksia ja viivästyskorkojen laskutusta. Monesti nämä kaksi tehtävää (laskutus ja myyntireskontran hoitaminen) tekee sama henkilö. (Eklund & Hakonen 2018, 56, 76.) 3.1 Asiakasrekisteri Asiakasrekisteri ja sen ylläpitäminen on tärkeä osa myyntitapahtumaa ja olennaista tilausten käsittelyn ja laskutuksen kannalta. Kun asiakastiedot ovat oikein, taataan se, että laskut, asiakirjat ja toimitukset menevät varmasti oikein. Yritys antaa myös hyvän kuvan sidosryhmille, jos asiakastiedot ovat oikein niin tiedollisesti kuin kieliopillisestikin. Tietoja, mitä tarvitaan asiakasrekisteriin, ovat muun muassa asiakkaan nimi, osoite ja yhteystiedot, Y-tunnus (tai henkilötunnus yksityisillä asiakkailla joissain tilanteissa), laskutustapa ja maksuehdot sekä sovitut alennukset. Asiakasrekisteriä pitäessä on velvollinen noudattamaan tietosuoja-asetusta (GDPR, General Data Protection Regulation) sekä muita ohjeita, joita on annettu henkilötietojen käsittelystä. Asiakkailla, jotka ovat rekisterissä, on oikeus saada tietoa henkilötietojen käsittelystä ja hänellä tulee olla vapaa pääsy omiin 16 tietoihinsa. Jos hän huomaa tiedoissa virheitä, hänellä on myös oikeus saada niihin oikaisu mahdollisimman nopeasti. Jos asiakas haluaa poistua rekisteristä, on yrityksen pakko noudattaa pyyntöä ja sen tulee poistaa kaikki tiedot rekisteristä. (Eklund & Hakonen 2018, 73–74.) Kuvassa kolme on esimerkki prosessista, jossa myyntitilaus etenee eri vaiheiden kautta kirjanpitoon asti. Kuva 3. Prosessi tilauksesta kirjanpitoon (Eklund & Hakonen 2018, 59). 1. Myyntitilaukset asiakkailta laitetaan järjestelmään. 2. Varasto antaa tiedon lähetetyistä tuotteista. 3. Lasku tulostetaan / lähetetään asiakkaalle. 4. Lähetetty myyntilasku kirjataan myyntireskontraan. 5. Saapunut maksusuoritus kohdistetaan myyntilaskulle myyntireskontrassa. 6. Tiedot siirretään kirjanpitoon myyntireskontrasta. Tiedot ovat lähetetyt laskut ja saadut suoritteet. Erilaisia raportteja on mahdollista tulostaa reskontrasta. Tarvittavia tietoja voivat olla esimerkiksi tietyn päivän erääntyneet myyntisaatavat. (Eklund & Hakonen 2018, 59.) Varastokirjanpito Myyntireskontra Kirjanpito Raportteja -Asiakastiedot -Saamiset -Erääntyneet saamiset -Maksumuistutukset -Viivästyskorkolaskut 1 Laskutus Lasku Saadut tilaukset 6 2 3 Saadut suoritukset 5 4 17 3.2 Ostoreskontra Ostoreskontra on osa osakirjanpitoa ja eroaa pääkirjanpidosta siten, että sillä seurataan tarkemmin ostoja. Osakirjanpidossa myyntireskontrassa puolestaan seurataan tarkemmin myyntisaamisia. Alla ovat esimerkit osto- ja myyntireskontraan kirjaamisesta: Kun yritys on ostanut velaksi tuotteita tai palveluita ja saanut siitä menotositteen (laskun). se tarkastetaan ja hyväksytään. Jos laskussa ilmenee virheitä, pyydetään myyjältä hyvityslasku. Hyvityslasku on lasku, jossa ei näy yleensä maksettavaa määrää, ja siinä pitää selkeästi huomata kyseessä olevan hyvityslasku. Arvonlisäverolain mukaan laskussa pitää ilmetä myös viittaus alkuperäiseen laskuun, jossa virhe on ollut. Hyväksymisen jälkeen ostolasku siirretään ostoreskontraan. Maksuaineisto liitetään yhteen ostoreskontrassa ja tiedot lähetetään pankkiin. Maksun jälkeen ostolasku kirjataan ostoreskontrassa suoritetuksi, jonka jälkeen kirjaukset merkitään kirjanpidon tileille. Liiketapahtumat maksuista ja kirjanpidon yhteenveto viedään pääkirjanpitoon vähintään kerran kuussa. Kalenterikuukauden päätteeksi on tarkistettava, että avoimena olevien ostolaskujen yhteyssumma on täysin sama summa kuin mikä on pääkirjanpidossa ostovelkatilin yhteissumma. (Lindfors 2010, 20; Eklund & Hakonen 2018, 79.) 3.2.1 Ostolaskut ja niiden käsitteleminen Lähtökohtaisesti jokainen ostolasku on tarkistettava, jotta oikeellisuus voidaan taata. Ostolaskujen tarkistaminen, eli numerotarkastus, tapahtuu vertailemalla ostotilausta ja/tai lähetysluetteloa, joka on tullut saapuvan kuorman tai palvelun yhteydessä. Periaatteena on tarkistaa kappalemäärät, hinnat ja tilausviite ja niiden oikeellisuus laskussa. Tarkastuksen voi tehdä tavaroiden vastaanottava henkilö tai esimerkiksi ostoreskontranhoitaja. Tarkistuksen jälkeen ostoreskontranhoitajan pitää tehtävänsä mukaisesti tarkistaa toimittajarekisteristä toimittajan tietojen oikeellisuus. Näitä tietoja ovat muun muassa Ytunnus, yhteystiedot ja esimerkiksi pankin tilinumero maksua varten. Joissain tapauksissa rekisteriin voi merkitä myös toimittajan kohdalle kulutilin kirjanpitoa varten tai sen voi tehdä manuaalisesti ostolaskua kirjatessa. Ostolaskun kirjauksen yhteydessä kulut siirtyvät suoraan toimittajan kulutilille. (Eklund & Hakonen 2018, 112–113.) 18 Kun ostolasku on tarkastettu, se esikirjataan ostoreskontraan, eli tiedot viedään ostoreskontraan hyväksymistä varten. Olennaista on kirjata lasku oikealle kuukaudelle sen mukaan, miten on käytäntö valittu. Käytäntöjä on yleisesti kaksi erilaista. Suoriteperusteessa lasku kirjataan päivälle, jona ostettu tavara on saapunut tai ostettu palvelu on toimitettu. Toinen käytäntö on laskuperuste, jolloin lasku kirjataan sille päivälle, jolle lasku on päivätty. Kun lasku on esikirjattu, lasku asiakirjatarkastetaan joko tilaajan tai hänen esimiehensä toimesta riippuen yrityksen käytännöistä. Asiakirjatarkastuksessa tarkistetaan sopimusehtojen täyttymiset, kuten alennukset, toimituskulut sekä maksuehdot. Tarkastuksen yhteydessä (numerotarkastus tai asiakirjatarkastus) lasku kohdistetaan oikealle kustannuspaikalle tai mahdolliselle projektille. Asiakirjatarkastuksen jälkeen lasku tarkastetaan kokonaisuudessaan, jotta se vastaa sovittuja käytäntöjä ja mahdollisesti ostoreskontranhoitaja voi vielä kerran tarkistaa ostolaskun kirjanpitomerkinnät. Tämän jälkeen ostolasku on maksukelpoinen. Käytännöt voivat vaihdella eri yrityksissä. Kun lasku kiertää yrityksen sisällä, henkilö, joka hoitaa ostoreskontraa, seuraa etenemistä ja muistuttelee ihmisiä laskusta, jos eteneminen kestää liian kauan ja laskun eräpäivä lähenee. Eräpäivään mennessä laskun pitäisi olla jo tarkistettu ja laitettu maksuun, jotta ei tulisi ylimääräisiä kuluja, kuten viivästyskorkoa. Yrityksen kannalta olisi myös hyvä hyödyntää mahdolliset käteismaksualennukset. (Eklund & Hakonen 2018, 117– 119.) 3.2.2 Avoimet ostolaskut Ostoreskontrasta on mahdollista saada avoimien ostolaskujen raportti, joka kertoo avoimena, eli maksamattomina, olevien ostolaskujen määrän sinä ajankohtana. Kun kuukausi loppuu, raportin loppusumma, eli maksamattomien laskujen yhteenlaskettu summa, tulisi olla täysin sama kuin kirjanpidon ostovelat-tilin loppusumma näyttää. Jos tilinpäätös osuu samalle ajankohdalle, pitää avoimien ostolaskujen raportti liittää tilinpäätöserittelyihin, jotta on nähtävissä, mistä ja miten ostovelka muodostuu yritykselle. (Eklund & Hakonen 2018, 131.) 3.3 Myyntireskontra Laskutusohjelmat siirtävät yleensä automaattisesti myyntilaskut lähetyksen jälkeen myyntireskontraan. Myyntireskontrassa ovat kaikki laskutus- ja suoritustiedot ja niiden 19 ylläpito ja seuraaminen tapahtuvat siellä. Laskun summa määräytyy sen mukaan, miten laskun kirjaaja on yleensä tuoterekisteristä valinnut tuotteita laskulle. Myyntireskontrassa avoimien laskujen yhteydessä voi ohjelmasta riippuen yleensä lähettää myös maksukehotuksia sekä viivästyskorkolaskuja asiakkaalle, jos asiakas ei ole suorittanut laskujaan eräpäivään mennessä. Suoritukset kirjataan myyntireskontraan tositteiden perusteella, joita ovat esimerkiksi tiliotteet tai pankkiohjelmasta saadut aineistot. Suorituksien kirjaaminen voi tapahtua sähköisesti tai käsin, jolloin myyntireskontraan kirjataan viitenumero, joka löytyy myyntilaskusta. Sähköisessä kirjauksessa suoritus tuodaan suoraan pankkiohjelmasta myyntireskontraan, ja tämä on nopein ja helpoin tapa, kunhan maksun suorittaja kirjoittaa viitetiedot viitekenttään viestikentän sijaan. Jos maksaja käyttää viestikenttää, suoritus pitää tuoda käsin pankkiohjelmasta reskontraan ja kohdistaa oikealle myyntilaskulle. Kuun lopuksi, tai ainakin vähintään kerran kalenterikuussa, tiedot laskutuksista ja suorituksista siirretään pääkirjanpitoon osakirjanpidosta (myyntireskontrasta). Tällöin maksamattomien myyntilaskujen yhteissumma tulisi olla täysin sama kuin mitä kirjanpidon myyntisaamiset-tilin loppusumma on. (Eklund & Hakonen 2018, 79, 86–87.) 20 4 SÄHKÖINEN TALOUSHALLINTO Tehokas taloushallinto on ennen kaikkea kustannustehokas, ja kustannuksia pitää pystyä optimoimaan tehokkaasti. Taloushallinto on liiketoiminnan tukifunktio eli toimintaa tukeva toiminto, ja sen takia sen pitää olla kustannustehokas taloudellisesta näkökulmasta katsottuna. Tähän päästään automatisoimalla prosesseja, toimintaa ja työtehtäviä sekä yleisesti virtaviivaistamalla kaikkia prosesseja. Taloushallinto tukiessaan liiketoimintaa on erityisen tärkeää, että raportointi on virheetöntä. Virheellinen raportointi vääristää sekä tuloksentekokyvyn mittaamista että itse tulosta. Virheiden määrää pystyy vähentämään esimerkiksi automatisoimalla ostolaskujen kiertoa. Tiedon liikkuminen järjestelmien välillä ja automaatio, joka mahdollistetaan järjestelmän säännöillä, ovat suoraan verrannollisia taloushallinnon tehokkuuteen. Jos esimerkiksi tilitoimisto käyttää samaa ohjelmaa yrittäjän kanssa, tiedot siirtyvät automaattisesti ja nopeasti eteenpäin ja tämä vähentää työtunteja ja sitä kautta alentaa kuluja. Tietoja, joita tilitoimisto voi haluta sähköisesti voi olla esimerkiksi kuitit, tositteet ja laskut. Tehokkaan taloushallinnon yksi pääpiirre on myös jatkuva tarkkailu talousjärjestelmien ja talousautomaation kehityksessä. Myös työntekijöiden jatkuva kehittäminen, sitouttaminen ja individuaalinen eli yksittäisten henkilöiden osaaminen on olennainen osa tehokkaita taloushallinnon prosesseja ja mahdollistaa parempien toimintatapojen kehittämisen. (Suni 2017, 74–75; Finago 2019.) Tehokkaan taloushallinnon tuoma etu ei katso yrityksen kokoa ja jopa mikro- ja pienyritykset saavat huomattavaa etua käyttäessään tehokasta sähköistä taloushallintoa. Pienyrityksen taloushallintoon käyttämä aika voi olla jopa kolmannes, jos yritys käyttää sähköistä ja automatisoitua taloushallintoa perinteisen taloushallinnon sijaan. (Accounter Finago Oy 2019) 21 5 YRITYKSEN OSTO- JA MYYNTILASKUT TANKKIKONTTIOSASTOLLA Tankkikontteja yritys on kuljettanut keskiarvollisesti kuluvan vuoden aikana hieman yli kolmesataa jokaisena kuukautena. Tuonnin puolella kuljetuksia on huomattavasti enemmän, kuin viennin puolella. Jokainen kuljetus laskutetaan erikseen, joten myynti-ja ostolaskuja tulee satoja kuukaudessa tankkikonttien tuonnin ja viennin osalta ja eri henkilöt luovat laskuja sen mukaan, että kuka hoitaa keikkaa. Keikkaa hoitaa Account Manager yleensä alusta loppuun, mutta tuonnin puolella kuljetusta voi hoitaa toinen henkilö, kun kontti on saapumassa Suomeen ja laskun tekijä määräytyy sen mukaan. Ostolaskut ovat jaettu ostojen mukaan eri henkilöille ja nämä henkilöt tarkistavat ostolaskujen oikeellisuuden. Jos tarkistamattomia ostolaskuja kuitenkin kasaantuu ostoreskontraan tietylle henkilölle, voivat muut myös tarkistaa kasaantuneita laskuja. Yrityksen yhteistyökumppani mahdollistaa yrityksen kaikki tankkikontit vuokraamalla. Yrityksellä itsellään ei ole omia tankkikontteja omistuksessa ollenkaan, joten kaikki kontit ovat yhteistyökumppanilta. 5.1 Myyntilaskutusprosessi tankkikonttien tuonnissa Ensimmäinen vaihe myyntilaskuun on asiakkaan yhteydenotto keikkaa varten. Asiakkaat lähestyvät pääasiassa sähköpostilla yritystä kertoen omasta tarpeestaan kuljetukselle ja tuotteelle. Tämän jälkeen luodaan keikka ERP-järjestelmään nimeltä Sentera, johon kirjataan kaikki olennainen tieto, kuten lastauspäivä ja paikka, toimituspäivä ja paikka, kuljetettava tuote ja reititys. Tässä vaiheessa sekä keikka itsessään, että ”yksikkö”, eli kontti Senterassa, saavat molemmat omat viitenumeronsa, johon voidaan kohdistaa kuluja ja tuloja. Keikan tiedot lähetetään tämän jälkeen yhteistyökumppanille, joka on maailmanlaajuinen logistiikka-alan yritys, ja yhteistyökumppani valitsee konttiseurannastaan oikeanlaisen kontin ja kuljettajan keikalle ja tarvittaessa varaa lastausajan. Kontin lastauksen jälkeen se kuljetetaan valittuun satamaan ja sieltä kontti kulkeutuu Suomeen, jossa yrityksen valitsema kuljettaja hakee kontin ja toimittaa sen asiakkaalle sovittuna päivänä. 22 Kuljettaja kertoo joko ajojärjestelijälle tai Account Managerille purkuajan, jonka perusteella kuljettaja laskuttaa yritykseltä lisäkuluja tarpeen mukaan. Lopuksi kuljettaja vie kontin joko pesuun tai satamaan. Kun kontti on toimitettu ja sijoitettu pyydettyyn paikkaan, pesukulut saatuna ostolaskulla ja lastauksesta mahdolliset lisäkulut on ilmoitettu, voi keikasta tehdä myyntilaskun asiakkaalle. Ideana on kerätä tilauksesta asti kaikki tiedot keikoille, jotta laskun tekijä saa tietää mahdolliset lisäkulut ja ongelmat sekä katsoa oikean perushinnan rahdille reitityksen perusteella. Kaikki tärkeät liitteet, kuten laivayhtiön saapumisilmoitukset ja vastaavat laitetaan pilvipalveluun, johon jokaisella on pääsy. Pilvipalvelussa on myös hinnastot, joita käytetään laskujen kirjaamiseen. Ongelmana on, että liikenteenhoitaja voi unohtaa kirjata tai voi kirjata virheellisesti keikalle olennaisia tietoja. Esimerkiksi kontin lämmityksen alkamispäivä tai esimerkiksi toimituspäivä voi olla väärin. Tällöin laskun tekijän pitää tarkistaa ajojärjestelijän ohjelmasta päivän, koska kontti on toimitettu tai tarkistaa keikan ”yksikkö” välilehdeltä päivä, joka on kirjattu konttiseurantaan. Kytkentäpäivän puute voidaan huomata viimeistään siinä vaiheessa, kun satamalta tulee lasku kytkennästä ja sen oikeellisuus pitää tarkistaa. 5.2 Tullausta vaativat keikat Jotkut kontit tulevat maista, mitkä eivät kuulu vapaan liikkumisen alueelle ja ne pitää lain mukaan tullata. Yritys ei itse hoida tullauksia, koska tullausta vaativien konttien määrä, joiden liikennettä yritys hoitaa, on todella vähäistä. Muutamat asiakkaat silti haluavat tuoda Suomeen tullattavia kontteja ja tällöin yritys ulkoistaa tullauksen huolintayritykselle, joka on erikoistunut tullaukseen. Yritys välittää kaikki mahdolliset paperit, jotka tullaukseen vaaditaan huolintayritykselle, joka hoitaa lopulta tullauksen ja lähettää tullauspäätöksen, tulliverolaskun ja oman huolintalaskunsa. Kun kontti on tullattu ja päätökset on saatu, kontti toimitetaan normaalisti asiakkaalle sovittuna päivänä ja laskuun kirjataan normaalin kuljetuksen lisäksi huolintakulut. 5.3 Prosessi myyntilaskuun viennin puolella Viennin puolella tilauksen eteneminen menee aluksi vastakkaisesti verrattuna tuontiin. Joko suomalainen asiakas haluaa toimittaa ulkomaiselle asiakkaalle tuotetta tai ulkomainen asiakas haluaa lastata Suomessa tavaraa ja saada se itselleen ulkomaille. Tilauksen 23 tullessa luodaan keikka ja sovitaan lastauspäivästä Suomessa ja tarkistetaan mitä reittiä käytetään. Yritys valitsee kuljettajan ja konttiseurannasta tankkikontin keikalle. Kontin valinta tehdään tuotteen perusteella. Tuote voi vaatia lämmitystä, se voi olla tietynlaista ominaisuuksiltaan, jolloin kaikkien konttien fyysiset ominaisuudet eivät ole oikeanlaisia esimerkiksi purkuun ja myös tuotteen määrä mitä pyydetään määrää kontin koon. Esimerkiksi 35000 kg vetävään konttiin ei voi lastata 25000 kg tavaraa ilman baffleja (väliverkkoja), koska tankki on liian tyhjä ja tuote hölskyy kuljetuksen aikana mikä aiheuttaa riskitilanteita. Lastauksen jälkeen kuljettaja vie tankkikontin satamaan laivausta varten ja kontti kuljetetaan asiakkaalle. Merimatkan jälkeen yhteistyökumppani hoitaa kuljetuksen perille asiakkaalle pyydettynä päivänä. Matkan varrelta kaikki tiedot, ongelmat ja lisäkustannukset kirjataan keikalle, jotta laskun tekijällä on kaikki tarvittavat tiedot laskun oikeellisuuden takaamiseksi. 5.4 Ostolaskujen kirjaaminen Yritykselle tulee monelta eri toimittajalta ostolaskuja kaikista kuljetuksen eri vaiheista. Ostolaskut tulevat sähköisesti palvelimelle, johon pääsee käsiksi internetin kautta sekä ERP-järjestelmään. Ostolasku avataan ERP-järjestelmässä ostoreskontran avoimien ostolaskujen selauksesta ja järjestelmä antaa ostolaskun numeron, jonka perusteella palvelimelta löytyy kuvana ostolasku. Ostolaskun kirjauksessa jokainen kulu kohdistetaan keikan tai yksikön viitteelle. Yksikön viitettä käyttäen on mahdollisuus väärinkirjaukselle pienempi, koska joskus kulut eivät kuulu keikalle, jonka viite laskusta löytyy vaan enemminkin yksikölle. Kulut kirjataan yksitellen ERP-ohjelmaan ja samalla tarkistetaan hinnastoista (yleensä Excel-tiedostona) oikea hinta kululle ja se kirjataan järjestelmään. Jos hinta on eri kuin mikä hinnastossa on, kulu kirjataan joka tapauksessa järjestelmään ja pyydetään hyvityslaskua toimittajalta. Rivejä syöttäessä pitää myös huomioida arvonlisäverotus. Esimerkiksi satamamaksut ovat veroluonteisia maksuja ja ne eivät kuulu arvonlisäverotuksen piiriin. Myöskin joidenkin ulkomaalaisten asiakkaiden kanssa pitää huomioida käänteinen verovelvollisuus ja silloin ei myöskään lisätä riville arvonlisäveroa. Näistä ei ole erillistä ohjetta ja laskun kirjaajan pitää itse tietää, koska arvonlisävero kuuluu kirjata ja koska ei. Kun kaikki kulut ovat kirjattu, ERP-järjestelmän kohdassa ”laskua jäljellä” tulisi lukea 0,00 €. Jos loppusumma on 0,00 € järjestelmä hyväksyy ostolaskun kirjauksen ja ostolasku 24 siirtyy seuraavaan vaiheeseen ostolaskun kierrossa. Seuraava vaihe kierrossa on esimiehen ostolaskun tarkistaminen. Esimies tarkistaa jo hyväksytyn ostolaskun, jonka jälkeen ostolasku siirtyy Tallinnassa sijaitsevalle kirjanpitäjälle. Laskun tila muuttuu hyväksynnän aikana järjestelmässä ”Waiting Cost Split”-> ”Waiting approval”. Ennen Tallinnaan siirtymistä laskun kulut tiliöidään oikeille kirjanpidon tileille ja kirjanpitäjä tarkistaa tämän. Kirjanpitäjä lähettää esimiehelle tasaisin väliajoin koosteen maksettavista laskuista ja esimies päättää jätetäänkö jokin lasku tässä vaiheessa pois ja siirretään myöhemmäksi. Kooste perustuu kirjanpitäjän tietoihin hyväksytyistä laskuista. Kun on päätetty mitkä laskut siirtyvät maksuun, on seuraava vaihe laskun maksaminen ja arkistointi. 5.5 Myyntilaskujen kirjaaminen Jokaisen tankkikontin kuljetuksen jälkeen tehdään lasku sille kuljetukselle. Yrityksessä ei tehdä yhtä laskua monelle samanlaiselle kuljetukselle kirjausvaiheessa, mutta tiettyjen asiakkaiden kuljetukset nidotaan lopuksi yhteen ERP-järjestelmässä koontilaskuksi, jolloin moni saman asiakkaan kuljetus löytyy samalta laskulta. Kirjauksen perusteena on yleensä ERP-järjestelmästä löytyvä tarjous, joka on asiakkaalle annettu. Tarjous löytyy ERP-järjestelmästä kuljetustarjouksista, joissa tarjous on merkitty asiakasrekisteristä löytyvän yrityksen nimelle. Tarjouksessa voi olla monta eri vaihtoehtoa reititykseen ja muut lisäkulut, jotka voivat ilmaantua kuljetuksen aikana tai ennalta sovitusti. Muutamilla asiakkailla on omat hinnastot, joissa on rahtihintoja sekä lisäkuluja. Olennaista on katsoa ERP-järjestelmästä keikan tiedot ja liikenteenhoitajan merkinnät ja verrata niitä hinnastoihin ja tarjouksiin ja sen mukaan kirjata myyntirivejä. Kuten ostolaskuissa, myös myyntilaskuissa pitää tarkistaa kuuluuko myyntiriviin arvonlisävero tai onko asiakkaalla käänteinen verovelvollisuus. Kun lasku on kirjattu kokonaisuudessaan, se tulostetaan yleensä PDF-tiedostoksi (harvat asiakkaat haluavat paperisen version) ja se lähetetään asiakkaan valitsemaan sähköpostiosoitteeseen. Laskun tulostuksen yhteydessä järjestelmä luo sille laskunumeron ja viitteen. Lasku tiliöidään automaattisesti ja lähetetään kirjanpitäjälle, joka raportoi viikoittain maksamattomista, mutta eräpäivän jo ohittaneista laskuista, joista lähetetään muistutuksia. Laskun oikeellisuus on tärkeää, koska laskua ei saateta maksaa ennen kuin virheet on selvitetty laskun tekijän ja asiakkaan välillä. Tähän joidenkin asiakkaiden kanssa on tehty 25 ratkaisu, että rahdit kirjataan eri laskulle, koska ne ovat aina samat ja perustuvat kirjallisiin tarjouksiin. Lisäkustannukset kirjataan eri laskulle, koska näistä käydään yleensä eniten keskustelua oikeellisuudesta ja näitä pitää todistaa joskus kirjallisesti. 26 6 NYKYISTEN PROSESSIEN TILA Haastattelujen perusteella yrityksessä ollaan tyytyväisiä laskujen kirjaamisen ja tarkistamisen oikeellisuuteen. Nykyiset prosessit mahdollistavat täysin tai lähes täysin oikeellisen laskutuksen. Ongelmana on kuitenkin havaittu tehottomuus, joka näkyy ajankäyttönä laskutuksen kaikilla osa-alueilla, mutta etenkin ostolaskujen kierrättämisen kanssa. Tehottomuutta aiheuttavat monet eri tekijät, jotka ovat muutettavissa yrityksen toimesta, mutta esimerkiksi toiminnanohjausjärjestelmän kankeus on erittäin kallista ja aikaa vievää päivittää ja sitä ei todennäköisesti edes kannata päivittää, kun uuden ERP:n implementointi on joka tapauksessa yrityksellä edessä. Ongelmia ilmenee myös yhtenäistämisessä. Monella laskujen kanssa tekemisissä olevalla on omia erilaisia tapoja ja käytäntöjä ja näistä ei ole annettu selkeitä ohjeita, miten kaikkien tulisi toimia. Jotkin tavat ovat hitaampia kuin toiset ja tietyt tavat voivat olla epäselviä toisille. Uusi työntekijä saa ohjeita monelta henkilöltä ja jotkin ohjeet voivat olla ristiriidassa toistensa kanssa. Ilman ohjeita yhtenäistämiseen tätä on hankala korjata. 6.1 Ostolaskujen ongelmakohtia Ostolaskujen selkeimpiä ongelmakohtia olivat monien eri alustojen käyttö tarkistustilanteessa. Myöskin toimittajien suuri määrä ja heidän omat tapansa laskuttaa loivat ongelmia laskujen tarkistamiselle. Toimittajien tapoihin tehdä laskuja on hankalampi puuttua. Toimittajat eivät helposti muuta omia käytäntöjään yhden yrityksen pyynnön perusteella, koska se tuo heille pelkästään kustannuksia. Yrityksen ostolaskut eivät pääsääntöisesti mene maksuun ennen eräpäivää. Keskimääräinen aika ostolaskujen laittamiseen maksuun on noin yhdestä kahteen viikkoa eräpäivän jälkeen. Syynä ei ole prosessien tehottomuus vaan enemmänkin taloudelliset ja rahoitukselliset syyt. Projektikuljetuksissa isot projektit pitää rahoittaa ennen kuin projektin tilaaja maksaa laskunsa. Projektien tilaajilla on yleensä 60 päivän maksuaika myyntilaskuissa ja yrityksen ostolaskuissa on yleisesti 30 päivän maksuaika. Ostolaskujen maksuja priorisoidaan ja maksusuunnitelmia kehitetään sekä seurataan koko ajan. Tehostamalla ostolaskujen tarkistusprosessia ja nopeuttamalla ostolaskujen kiertoa voidaan kehittää tarkempia maksusuunnitelmia, jotka ennaltaehkäisevät tilanteita, jolloin tulee kiire 27 maksaa jokin tietty lasku. Jos jonkin ison ostolaskun maksaminen ei ole mahdollista eräpäivän jälkeen ja maksusuunnitelman mukaan maksaminen venyisi liian pitkälle, voi yritys lainata rahaa konsernin sisäisesti maksamista varten. 6.1.1 Excel-tiedostot Laskua kirjatessa pitää olla aina keikka auki ERP-järjestelmän TC-osastosta (Tank Container) ja ostolaskut-osio samasta järjestelmästä sekä laskujen pilvipalvelun ikkuna, jossa näkyy itse lasku. Myös Excel-tiedostot ja sähköposti ovat pakollisia oikeellisuuden varmistamiseksi. Tämän takia laskuttaja joutuu vaihtelemaan monen eri ohjelman ikkunan välillä. Työntekijöillä on mahdollista saada kaksi näyttöpäätettä työpöydälleen, mutta se ei tunnu riittävän monelle ohjelmaikkunalle. Pahimmillaan voi olla 5–7 eri Exceliä auki, jotta laskun jokaisen rivin voi tarkistaa. Exceleitä on muun muassa satamakustannuksista, yhteistyökumppanin vetohinnoista, laivayhtiöiden hinnoista ja esimerkiksi pesukustannusten hinnoista. Excelit perustuvat eri toimijoiden hinnastoihin ja sen vuoksi niitä ei ole yhdistetty. Myös samalta toimittajalta voi tulla eri tiedostoja eri kustannuslajeille, mutta niitä ei ole yhdistetty, koska päivitetty versio on helppo laittaa käyttöön sen sijasta, että tiedosto yhdistettäisiin saman toimittajan muihin tiedostoihin. Exceleitä on useita, koska toimittajia on erittäin paljon. Jokaiselle toimittajalle on oma hinnasto, jonka yritys joko saa toimittajalta tai luo uuden heitä varten. Suuri toimittajien määrä on välttämätöntä yritykselle, koska yrityksen ideana on tarjota joustavaa kuljetuspalvelua. Toimittajia karsimalla ja siten hinnastoja siistimällä menetetään joustavuus, joten se ei ole yritykselle vaihtoehto. Excelin käyttöön riittää perusosaaminen Excelin kanssa. Suurin osa Excelin käytöstä on vain suodattamista ja rivien selailua ja esimerkiksi laivayhtiön polttoainekustannusten prosentin vaihtamista soluun. Koska monimutkaisia funktioita ei ole, olisi mahdollista työstää kaikki hinnastot yhteen isoon Exceliin kopioimalla tiedot. Vaikeata tässä on suuren datan yhteen kasaaminen ja käytön jaotteleminen niin, että se pysyy käyttäjäystävällisenä ja selkeänä. Koska tietoa on niin paljon ja monet niistä eivät ole olennaista osalle käyttäjistä pitäisi Excel saada muotoon, jota käyttäjä voi itse muovata itselleen sopivaksi helposti joka kerta Excelin avatessa. Jos käyttäjä tallentaa oman version Excelistä työpöydälleen on riskinä, ettei sitä päivitetä, joka tällöin johtaa virheellisiin laskuihin. Jos taas sen tallentaa pilvipalveluun, seuraava käyttäjä joutuu muokkaamaan sitä vielä enemmän, jotta saa itse tarvitsemansa tiedot näkyviin. 28 Eri Excel-tiedostojen ylläpitäminen on työlästä ja joistakin tiedostoista on vielä pilvipalvelussa eri revisioita, jotka eivät enää pidä paikkaansa, mutta joista voi seurata esimerkiksi hinnan kehitystä. Joissakin hinnastoissa näkyy edelleen esimerkiksi viimevuotinen hinta ja se on monelle käyttäjälle epäolennainen tieto. Asian selkeyttämiseksi pitäisi poistaa vanhat tiedot uudesta hinnastosta, koska vanhat versiot ovat edelleen saatavilla pilvipalvelusta. Uusi toiminnanohjausjärjestelmä, joka on määrä ottaa käyttöön tulevaisuudessa, pitäisi olla sellainen, että ostolaskun avatessa näkyisi myös ennalta määrätyt hinnat juuri rivin kuljetukselle tai korkeintaan yhden lisäikkunan kautta näkisi kuljetukselle kaikki mahdolliset hinnat reittien perusteella sekä lisähinnat. 6.1.2 Alustojen määrä ja kankeus Ostolaskut avataan ERP:stä, jolloin saadaan laskun numero. Laskun numerolla saadaan pilvipalvelusta, joka on keskittynyt vain laskuihin, näkyviin lasku. ERP:stä ei siis ole mahdollista nähdä ostolaskun rivejä. Tämän takia joutuu vaihtelemaan ikkunoita jatkuvasti tai vaihtoehtoisesti tulostamaan lasku paperille, jotta rivien selailu olisi helpompaa. ERP:stä näkee vain jo hyväksytyt rivit ja keikan viitteet. Tämän lisäksi esimerkiksi ylimääräiset kulut pitää tarkistaa TC-osaston keikalta, joka on erillinen ikkuna ostolaskujen ja pilvipalvelun lisäksi. Jos esimerkiksi lisäkulu on sovittu ja löytyy laskulta, pitää se vielä tarkistaa Excel-tiedostosta, jotta määrä on oikein. Tehottomuus on erittäin näkyvää, kun joutuu vaihtelemaan monen eri alustan välillä ja klikkauksia tulee tehtyä erittäin paljon enemmän, kuin mikä olisi tarpeen. 29 Kuva 4. Kuva ostolaskun kirjauksesta. Nykyinen ERP on vanha ja sitä ei kannata enää päivittää helppokäyttöisemmäksi ja joustavammaksi. Uuden ERP:n pitäisi mahdollistaa tarkistuksen alla olevien ostolaskujen näkymisen riveineen käyttäjälle samalla kun niitä tarkistetaan ja tällöin ei tarvitsisi erillistä pilvipalvelua näyttämään kuvaa laskusta. Pilvipalvelu käytöstä on päätetty konsernitasolla, joten siitä luopuminen voi olla hankalaa. Vaihtoehtona olisi pitää sitä käytössä uuden ERP:n ohessa arkistona, joissa on nähtävillä tarvittaessa ostolaskuja, mutta varsinaisen ostolaskun tarkistaminen tapahtuisi pelkästään ERP:ssä. Rivien näkyminen tarkistuksen yhteydessä mahdollistaisi automatiikan implementaation ostolaskujen tarkistamiseen. Jos ostolaskun rivi täsmää ennalta asetettuun hintaan tarjouksen pohjalta, ERP hyväksyisi automaattisesti rivin, ilman että sitä tarvitsee kirjata erikseen käsin. Hinnat, jotka eivät täsmäisi antaisivat hälytyksen tai muun huomion, jolloin laskun tarkastaja voi tarkistaa itse oikean hinnan ja korjata sen käsin. Pääyhteistyökumppanin ostolaskut voivat olla kymmeniä sivuja ja satoja rivejä pitkiä. Rivit, jotka ovat saman suuruiset kuin yrityksen hinnastosta löytyvät, tulisi automaattisesti tulla hyväksytyiksi, jolloin voisi säästää useita tunteja jo yhden ison laskun kanssa. Haastattelujen pohjalta on pääteltävissä, että tarkistusprosessissa on liian monta välivaihetta, jotta voi tarkistaa esimerkiksi jo kirjatun kulurivin keikalta. Tällöin pitää mennä TCpuolelle keikalle ja katsoa Arviot-osiosta kulurivin esikirjausnumero. Esikirjausnumero syötetään Ostolaskut-osioon, josta saadaan laskun numero, jonka avulla pilvipalvelusta saa laskun auki. Tarkistamista nopeuttaisi, jos keikan kuluriveistä saisi suoraan laskun auki käyttäjän tarkistamiseksi tai edes laskun numeron, jolla käyttäjä voi hakea laskun pilvipalvelusta. 30 6.1.3 Toimittajien erilaiset käytännöt Toimittajien suuresta määrästä johtuen myös erilaisia laskutuskäytäntöjä on monia. Yritys ei ole erikseen pyytänyt tietynlaisia laskuja toimittajilta tai alihankkijoilta muuten kuin viitteiden osalta. Laskussa on oltava aina keikkaviite vähintään, jotta kuluja voidaan kohdentaa oikein kirjanpitoa varten. Joskus laskuissa näkyy vain kontin numero, jolloin pitää tarkistaa päivämäärien avulla oikea keikkanumero ERP-järjestelmästä. Kun laskua tarkistetaan, on tärkeää pitää ERP:ssä keikan ikkunaa auki merkintöjen vuoksi ja jos toimittajan laskussa ei ole keikkaviitettä millään rivillä ja vain ainoastaan kontin rekisterinumero, hidastuu laskun tarkistaminen erittäin paljon, koska kontin rekisterinumeron perusteella pitää oikean rajanylityspäivämäärän perusteella hakea keikkaviite. Eri toimittajilla on myös eri maksuaikoja myönnettynä yritykselle ja ostoreskontran avoimista ostolaskuista pitää selailla lähestyviä tai menneitä eräpäiviä. Joskus laskun ilmestyessä avoimiin ostolaskuihin on eräpäivä voinut jo mennä. Tällöin lasku pitäisi heti tarkistaa, mutta tarkistamisen hitaus voi siirtää laskun tarkistamista, koska tarkistajalla voi olla jokin muu työtehtävä, joka vaatii sillä hetkellä huomiota. Laskun tarkistamisen jälkeen ostolaskun kierto vie oman aikansa. Olisi tärkeää saada toimittajilta lasku ajoissa, oikeilla viitteillä ja oikeilla riveillä, jotta ostolaskun kierrättäminen olisi mahdollisimman nopeaa. Jotkin kuljetusliikkeet tiedottavat purkuajoista huonommin kuin toiset. Jokainen kuljetusliike tiedottaa purkuajat, mutta siinä voi kestää tai ei anneta tarkkoja kellonaikoja ja vain kulunut aika tiedotetaan. Myöskin vaihteluita on muun muassa siinä millä alustalla kuljettaja tai kuljetusliike tiedottaa ajoista. Jotkut kuljettajat soittavat suoraan joko Account Managerille tai ajojärjestelijälle ja jotkut laittavat rahtikirjan sähköpostiin ja rahtikirjaan on merkitty purkamisen alkamisen ja loppumisen ajankohta sekä joskus tuotteen lämpö purkauksen aikana. Nämä sähköpostit tulevat yleensä sille henkilölle, joka on pyytänyt kuljetusta. Koska tietoja voi olla sähköpostissa, puhelimessa tekstiviestinä tai jonkun työntekijän pöydällä kirjattuna puhelimesta saadun tiedon perusteella, on erittäin aikaa vievää tarkistaa purkuaika, jos sitä ei ole merkitty keikalle. Jos kuljettajia ja kuljetusliikkeitä ohjeistettaisiin yhtenäistämään ilmoitustapansa esimerkiksi lähettämällä tiettyyn sähköpostiosoitteeseen rahtikirjan purku- tai lastausajoilla ja nimeämällä sähköpostin kontin rekisterinumerolla ja keikkaviitteellä, saisi tiedot helpommin tarkistettua osto- tai myynti- 31 laskun kirjaamisen aikana. Joillakin yksittäisillä kuljettajilla ei ole omaa sähköpostiosoitetta tai älypuhelinta, jolla voisi laittaa kuvan rahtikirjasta purkuaikoineen ja tämän vuoksi uutta ohjeistusta ei ole vielä tehty, vaikka hyöty olisi selvä. 6.2 Myyntilaskujen ongelmakohtia Ostolaskuihin verrattuna myyntilaskut ovat suoraviivaisempia, koska ne perustuvat yrityksen itse laskemiin ja antamiin tarjouksiin. Vaikka yrityksen ERP:hen on mahdollista lisätä kaikki myyntitarjoukset, pitää silti joitakin tarjouksia ja hinnastoja pitää Excel-tiedostoissa. ERP:n kankeus myyntilaskua luodessa on myös erittäin näkyvä ja automaation puuttuminen laskutuksessa on huomattava. Myyntilaskuissa saatavien saaminen yrityksen tilille on keskimäärin 30 päivää laskun lähettämisestä. Tankkikonttien nopeampi matka tilauksesta laskuun rahoittaa hitaampien ja rahallisesti suurempien projektikuljetusten ostolaskuja, joten on erittäin tärkeää, että kuljetukset laskutetaan mahdollisimman nopeasti ja kerralla oikein, jolloin asiakas maksaa laskun saatavat mahdollisimman nopeasti ja saatavat saadaan kiertoon. 6.2.1 Tarjoukset Tarjouksia löytyy ERP:stä ja Excel-tiedostoista riippuen asiakkaan tarpeista. Joillakin asiakkailla voi olla monta eri lastaus- ja/tai purkupaikkaa ja jokaiselle reititykselle on oma tarjouksensa, koska myös kulut ovat eri suuruisia eri reitityksille. Excel-tiedostoja käyttäviä asiakkaita on kuitenkin erittäin pieni osuus asiakkaiden kokonaismäärästä, mutta se voi hidastaa myyntilaskun kirjaamista, jos laskuttaja joutuu erikseen etsimään ja avaaman tietyn tiedoston yhtä laskua varten. Excel-tiedostojen käyttämisen voisi lopettaa, jos ERP-järjestelmästä saisi ulos helposti luettavan koosteen kaikista asiakkaiden tarjouksista. Kooste voi olla Excel-tiedosto tai ERP:n oma kooste, jonka voi lähettää asiakkaalle hyväksyttäväksi. Tarjouksia on erilaisia sen mukaan, miten ne on neuvoteltu asiakkaan kanssa. Esimerkiksi lisäkulut vaihtelevat asiakkaiden mukaan ja niiden laskuttamiseen pitää avata tarjous toiseen ikkunaan, kun asiakasta laskuttaa. Esimerkiksi päivien lukumäärän, joina tankkikontti odottaa satamassa ennen toimitusta, laskuttaminen vaihtelee tavaran vaarallisuuden mukaan ja myös asiakkaiden mukaan. Näiden yhtenäistäminen jokaiselle 32 asiakkaalle helpottaisi laskuttajaa tietämään ulkomuistista koska lisäkuluja asiakkaalle syntyy. Tarjouksissa lukee myös, että vapaata lastaus- ja purkuaikaa on asiakkaalle kaksi tuntia (ellei erikseen muuta ole sovittu) ja X€ per alkava tunti. Käytännössä kukaan ei kuitenkaan laskuta, jos purku- tai lastausaika ylittyy muutamalla minuutilla yli kahden tunnin, mutta tähän ei ole sovittuna selkeää ohjeistusta mikä määrä minuutteja on rajana ennen lisäkulujen laskuttamista. Jos tarjouksia ei noudateta kirjaimellisesti, olisi hyvä ohjeistaa kaikille samanlainen tapa katsoa lisäkulujen laskutusta. 6.2.2 Myyntilaskun järjestelmään kirjaamisen ongelmat Myyntilaskut kirjataan Invoice-osiossa ERP-järjestelmässä. Myyntilaskun kirjaamiseen tarvitaan myös erillinen ikkuna keikalle, jotta voi tarkastaa päivämääriä ja huomautuksia. Kun laskua alkaa kirjaamaan, antaa järjestelmä huomautuksen, jos keikalle ”laskutus”- osioon on kirjoitettu huomautuksia, mutta jos se on laitettu eri osioon tai vajailla tiedoilla, pitää laskuttajan tarkistaa se keikalta. Laskuttajalla ei myöskään ole mitään ohjetta mitä kuluja pitäisi laskuttaa keikalta ja tämä pitäisi itse tietää seuraamalla keikalta merkintöjä tankkikontin liikkeistä ja mitä kuluja se on kerännyt. Tämä luo riskin, ettei kaikkia kuluja muisteta veloittaa. Myöskin poikkeuksia on paljon eri kuluissa riippuen tankkikontin liikkumisista. Esimerkiksi tietyt laivayhtiöt maksavat itse tavaramaksun ja se sisältyy heidän rahtiinsa ja joissakin tapauksissa se pitää itse veloittaa asiakkaalta erikseen. Kun keikkaviite on syötetty voi valita huolintatarjouksen, joka antaa vaihtoehdoksi valita rahtikulun ja lisäkuluja. Tässä ei kuitenkaan näy mikä on rahdin hinta ja vaihtoehtoja voi olla useampi. Kuvassa viisi esitetään kuva tarjousperusteisesta taulukosta. Kuva 5. Kuva taulukosta, josta voi valita kuluja. Valitsemalla lisäkulun järjestelmä syöttää myös automaattisesti arvonlisäveron ja hintayksikön kululle. Hintayksikkö on väärä esimerkiksi polttoainekustannuksille, jolloin järjestelmä tarjoaa prosenttia, jota voisi käyttää, jos laskee polttoainekulua laivarahdin hinnan päälle. Virheitä tulee, jos ei huomaa rivin loppusummaa, joka voi olla 100€ sijasta 33 vain 1€, jos määräksi on valittu yksi. Myös arvonlisäveron automaattinen syöttö ei toimi ulkomaisille asiakkaille, koska järjestelmä ei tunnista ulkomaille sijoittuvaa asiakasta ja siten käänteistä verovelvollisuutta. Jos laskua hyväksyessään laskuttaja ei huomaa arvonlisäveroa riveiltä, asiakas joutuu pyytämään hyvityslaskua arvonlisäveron verran ja tähän joudutaan käyttämään työtunteja. Nykyisestä ERP-järjestelmästä siirryttäessä uuteen, tulisi uuden järjestelmän olla käytännöllisempi tietojen automaattisen syöttämisen kanssa esimerkiksi havaitsemalla onko asiakas ulkomailla. Myös mahdollinen muokkaaminen käyttäjän mieleiseksi olisi hyvä ominaisuus, jotta halutessaan voi käyttää polttoainekustannuksista prosenttiyksikköä tai kappalemäärää. Kun laskua syötetään riveittäin järjestelmään, ei järjestelmän ikkunasta näe juurikaan mitään tietoa keikalta. Olennaisia tietoja mitä laskuttajan pitäisi nähdä joka kerta olisi muun muassa tankkikontin koko, saapumis- ja toimituspäivä, mahdollinen laivaus pois, mahdollinen pesu ja esimerkiksi kytkentäpäivät. Tällä hetkellä kaiken näkee eri paikoista ja päivät joutuu laskemaan itse kalenteria katsomalla. Kaikki tämä altistaa sille, että kaikkia kuluja ei muisteta veloittaa tai veloitetaan väärin ja väärin veloittaminen johtaa myöhäisempään saatavien saamiseen. Pieni epäkäytännöllisyys, joka nostettiin esille myyntilaskujen kirjaamisessa, on kun myyntilasku on kirjattu ja lasku hyväksytään, sitä ei voi tulostaa suoraan, koska muuten lasku ei saa numeroa. Laskun tulostus pitää aloittaa ja keskeyttää, jotta lasku saa numeron ja sen jälkeen esikatselun kautta tulostaa uudelleen pdf-tiedostoksi niin että laskun numero on tullut laskulle. 6.2.3 Lisäkulujen saaminen laskutukseen Lisäkuluja syntyy monelle kuljetukselle väistämättä ja niiden laskutus on erittäin tärkeää, koska kulut koituvat muuten yritykselle, jos niitä ei laskuteta eteenpäin. Jotkin toimittajat ovat hitaampia kuin toiset lähettämään ostolaskuja esimerkiksi koontilaskutuksen vuoksi ja sen vuoksi myyntilaskun kirjaamista voi joutua odottamaan, jos asiakas haluaa kuljetuksen koko laskutuksen kerralla itselleen. Lisäkuluja syntyy muun muassa pesukuluista, jos pesuasemalla kontin pesemiseen on mennyt enemmän aikaa, kuin tarjouksessa on sovittu tai jos esimerkiksi pesuainetta on jouduttu käyttämään enemmän. Riippuen tarjouksessa olevasta hyväksyttyjen pesukulujen määrästä, joissakin kuljetuksissa voi olla 34 useastikin ylimääräisiä pesukuluja ja olisi ensisijaisen tärkeää saada ostolasku pesukuluista ennen laskuttamista. Jotkin pesuasemat kuitenkin lähettävät koontilaskun esimerkiksi kahden viikoin välein ja todellisia kuluja ei voi tietää sitä ennen. Yhteistyökumppani ei kerro tuontikonttien lastausaikaa oma-aloitteisesti. Kysyttäessä he lähettävät lastausajan tai sitten kun kontti on purettu ja purku sekä mahdollinen pesu on merkitty konttiseurantaan he lähettävät ”compliance advice”-tiedoston, jossa näkyy sekä lastausaika että purkuaika. Tämä voi tulla joskus sen jälkeen, kun laskutuksen voisi jo muuten tehdä. 35 7 KEHITYSEHDOTUKSET Tutkielman tavoitteena oli tehdä kehittämisehdotuksia logistiikka-alan yrityksen osto- ja myyntilaskujen kirjaus- ja tarkistusprosessien tehostamiseksi. Yrityksen nykyinen ERPjärjestelmä on tarkoitus vaihtaa lähitulevaisuudessa, joten kehittämisehdotukset suunnattiin uuden ERP-järjestelmän hankkimiseen. Tutkielman tarkoitus on siis olla tukena uuden toiminnanohjausjärjestelmän valitsemiselle ja kustomoinnille. Nykyisessä ERPjärjestelmässä on selkeitä puutteita osto- ja myyntilaskujen näkökulmasta ja yrityksen omat käytännöt ovat osin tehottomia sen vuoksi. Työn onnistumista on vaikea arvioida lyhyellä tähtäimellä. Kun uuden ERP-järjestelmän hankinta tulee yritykselle enemmän ajankohtaiseksi, voidaan arvioida tämän tutkielman onnistumista. Ehdotukset prosessien tehostamiseksi ovat kuitenkin konkreettisia ja pohjautuivat haastatteluihin sekä omiin kokemuksiin ja tämän myötä voidaan olettaa, että tutkimus on onnistunut havainnoimaan ongelmia ja ehdottanut niihin sopivia korjauksia. Mikä tekee yrityksen kirjaus- ja tarkistusprosesseista tehottomia? Yrityksen kirjaus- ja tarkistusprosessien tehottomuus johtuu selkeästi vanhan ja kankean ERP-järjestelmän tehottomuudesta osto- ja myyntilaskujen kirjauksissa ja tarkistamisissa. Koska ERP on vanha eikä sitä enää päivitetä, on jämähdetty vanhoihin tapoihin ja automaatio on erittäin alhaisella tasolla. ERP-järjestelmän kankeuden takia on käytössä useita muita alustoja, joiden tarkoitus on tukea ERP-järjestelmää, kuten Excel-hinnastot ja pilvipalvelu. Useiden alustojen ja ikkunoiden avaaminen laskuja varten on aikaa vievää ja niiden välillä selailu vie tehokkuutta prosesseista tarpeettoman paljon. Työntekijöiden eri tavat ja käytännöt eivät ole kaikilta osin yhtenäisiä, vaikka lopputulos on sama ja työntekijä löytää oman tapansa muiden ohjeiden ja oman kokemuksen perusteella sen sijaan, että olisi selkeä ohjenuora mitä noudattaa. Tämä itseoppiminen aiheuttaa tarpeetonta tehottomuutta. Miten yrityksen kirjaus- ja tarkistusprosesseja saisi tehostettua? Yrityksen kirjaus- ja tarkistusprosesseja saisi tehostettua selvästi poistamalla ylimääräisiä askeleita osto- ja myyntilaskujen ympäriltä. Päivittämällä uuteen ERP-järjestelmään voitaisiin luopua mahdollisesti kokonaan muista alustoista kuin ERP. Yhtenäistämällä alihankkijoiden käytäntöjä, yrityksen sisäisiä ohjeita ja käytäntöjä sekä sopimalla uusista käytännöistä yhteistyökumppanin kanssa saisi prosesseista tehokkaampia uuden ERP- 36 järjestelmän ohella. Prosessien virtaviivaistaminen, automatisointi ja useiden alustojen poistaminen ovat tärkeimpiä asioita uuden järjestelmän hankinnassa laskutuksen kannalta. Projekti uuden ERP-järjestelmän käyttöönottoon ei ole vielä alkanut ja sen takia on vielä mahdollista ja myöskin tärkeää tutkia mitä uudelta järjestelmältä vaaditaan verrattuna vanhaan järjestelmään. Jos ei ole mitään mitä uudelta järjestelmältä vaatisi, olisi vaihtaminen täysin turhaa rahan ja ajan kulutusta. Koska uuden järjestelmän implementointi vie aikaa ja käyttöönoton valmistuminen ei ole näkyvissä vielä lähitulevaisuudessa, on tärkeää, että nykyisiä prosesseja tehostettaisiin niin paljon kuin ilman ERP-järjestelmän muuttamista voi tai nykyinen ERP-järjestelmä antaa myöden ilman sen päivittämistä. Kuljettajien ja kuljetusliikkeiden kanssa yhteistyön yhtenäistäminen esimerkiksi purku- ja lastausaikojen ilmoittamisessa ja kuljettajien tuominen nykyaikaan älypuhelinten ja sähköpostien osalta olisi jo huomattava lisä tehokkuuteen, koska tällöin rahtikirjat ja purkuajat löytyisivät heti sähköpostista. Tutkielman liitteestä löytyy havainnollistava Excel-tiedosto hinnastosta, jota voisi tulevaisuudessa käyttää laskujen tarkistamisessa. Yhtenäisen Excel-tiedoston luominen ja ylläpitäminen vie kuitenkin työaikaa runsaasti, eikä sen täydelliseen yhteenkokoamiseen ja tarkistamiseen riitä aika yrityksessä tutkielman kirjoittamisen hetkellä. Kun yrityksessä löytyy parempi aika, on havainnollistava tiedosto jo valmiina, jotta on jokin mistä aloittaa tiedostojen yhtenäistäminen. Jos uuden ERP:n käyttöönotto kuitenkin sijoittuu lähitulevaisuuteen, ei yhtenäistä Excel-tiedostoa tarvita. Tällä hetkellä erityisesti myyntilaskun kirjaamisessa luotetaan todella paljon kirjaajan omaan muistiin, että kaikki mahdolliset veloitukset tulevat tehtyä. Edellistä keikkaa katsomalla saa osviittaa veloituksista, mutta ne voivat vaihdella eikä niihin voi sokeasti luottaa. Yleisimmille keikoille tarvitsisi pohjan, jossa olisi kaikki mahdolliset veloitusrivit ja näistä riveistä karsitaan pois ne, jotka eivät kuulu laskutettavalle keikalle. Nykyisellään kirjaaja kuluttaa paljon aikaa varmisteluun ja mahdollisten kulujen muistamiseen ja tämä kaikki ylimääräinen aika on mahdollista karsia pois, jos rivejä kirjattaessa näkyisi olennaiset tiedot keikalta ja olisi jokin pohja mistä keikkaa lähtisi veloittamaan. 37 8 YHTEENVETO Tutkimusmenetelmät olivat sopivat tähän tutkielmaan. Kvalitatiivinen luonne oli tarpeellinen, koska muita työntekijöitä haastattelemalla tuli paljon kokemuksien ja mielipiteiden kautta kipukohtia esille prosesseissa. Myös omat kokemukset uutena työntekijänä olivat tärkeitä, koska pidempiaikaisilla työntekijöillä ei välttämättä ole enää kunnollista käsitystä epäkohdista, koska niihin on totuttu. Konstruktiivinen tutkimusote oli sopiva tutkielmaan, koska tutkielmassa pyrittiin huomaamaan reaalimaailman ongelmia ja ratkaisemaan niitä niin, että siitä olisi yritykselle hyötyä. Tutkielmassa tuli selkeästi esille prosessien tehottomuuden syitä ja parannusehdotuksia uutta ERP-toiminnanohjausjärjestelmää varten sekä mahdollisia parannuksia, jos ERP:n hankinta viivästyy. Osa kehitysehdotuksista sopii myös uuden ERP:n rinnalle. Yleistettävyyttä on vaikea arvioida tälle tutkielmalle. Tutkielma keskittyi nimenomaan yhden yrityksen toimintaan ja sen prosesseihin, joten jotta tutkielma olisi käytettävissä toiseen yritykseen, tulisi kohdeyrityksen organisaatiorakenteen, toimintamallin ja tavan olla lähellä tämän tutkielman kohdeyritystä. Havainnot mitä laskutusprosesseista tehtiin voivat kuitenkin esiintyä muidenkin yrityksien laskutusprosesseissa ja tutkielmaa voi käyttää tukena silloin toisen yrityksen laskutusprosessien tutkimiseen ja parantamiseen.

question:Analysoitko tekstin? OSTO- JA MYYNTILASKUJEN KIRJAUS- JA TARKISTUSPROSESSIEN TEHOSTAMINEN Tämän työn tavoitteena oli tehdä kehittämisehdotuksia logistiikka-alalla toimivan yrityksen ostoja myyntilaskujen kirjaus- ja tarkistusprosessien tehostamiseksi sekä kartoittaa niiden toimivuutta. Kehittämisehdotukset kohdistuivat lähinnä ERP-toiminnanohjausjärjestelmän kehittämiseen, mutta myös muihin järjestelmän ulkopuolisiin prosesseihin. Työ on ajankohtainen, sillä yritys on huomannut, että laskujen kirjaus- ja tarkistusprosessit ovat olleet tehottomia ja uusi toiminnanohjausjärjestelmä on tulossa lähitulevaisuudessa. Lopputulokseksi saatiin, että yrityksen nykyiset kirjaus- ja tarkistusprosessit ovat hyviä, mutta tällä hetkellä hiukan tehottomia. Tutkielman tekemiseen käytettiin omakohtaisia kokemuksia ja kollegoiden haastatteluja. Tutkielmassa annettiin tehottomille prosesseille konkreettisia parannusehdotuksia koskien uuden ERP-järjestelmän vaadittavia ominaisuuksia sekä käytännössä ilmeneviin ongelmiin, kuten yhtenäisiin käytäntöihin. Työ ei kuitenkaan sisällä seurantaa ehdotuksien onnistumiselle, koska yritys X ei ole vielä aloittanut projektia uuden ERPjärjestelmän hankkimiseen. Työstä on mahdollista tehdä jatkotutkielma, kun yritys on implementoinut uuden ERP-järjestelmän, haastattelemalla työntekijöitä ja kyselemällä heiltä heidän mielipiteitään uudesta ERP-järjestelmästä. ASIASANAT: ERP-järjestelmä, lasku, laskutusprosessi, tehokkuus BACHELOR´S THESIS | ABSTRACT TURKU UNIVERSITY OF APPLIED SCIENCES Business logistics Autumn 2019 | 38 pages, 1 page in appendices Eelis Lindvall ENCHANCING THE RECORD AND REVIEW PROCESSES IN INVOICING The objective of this thesis was to give development suggestions for a corporation operating in logistics regarding their entry and inspection processes in invoicing and to map out those processes’ operability. The development suggestions targeted mainly at developing a new ERP system but also at other processes outside of the ERP system. The subject of this work is currently topical as the corporation noticed that their entry and inspection processes have been ineffective and there is going to be soon an acquisition of a new ERP system. The outcome was that the entry and inspection processes in invoicing are good, but currently a little ineffective. Personal experience and interviews were used to make this thesis. This thesis gave concrete development suggestions regarding the new ERP system’s required attributes and to daily occurring problems such as integrated practices. However, this thesis did not include monitoring the success of the suggestions as the corporate has yet to start a project to acquire a new ERP system. It is possible to do a follow-up study of this thesis once the corporation has implemented the new ERP system by interviewing the employees and by asking their opinion regarding the new ERP-system. KEYWORDS: Effectivity, ERP system, invoice, invoicing processes SISÄLTÖ 1 JOHDANTO 6 1.1 Kohdeyritys 6 1.2 Työn tavoite, rajaus ja metodologia 7 2 KIRJANPITO 9 2.1 Kahdenkertainen kirjanpito 9 2.2 Tilit 10 2.3 Kirjanpitoaineisto 11 2.4 Liiketapahtumat ja tositteet 11 2.4.1 Lasku eli tulotosite 12 2.4.2 Menotosite 13 2.4.3 Tiliote tositteena 14 3 LASKUTUS 15 3.1 Asiakasrekisteri 15 3.2 Ostoreskontra 17 3.2.1 Ostolaskut ja niiden käsitteleminen 17 3.2.2 Avoimet ostolaskut 18 3.3 Myyntireskontra 18 4 SÄHKÖINEN TALOUSHALLINTO 20 5 YRITYKSEN OSTO- JA MYYNTILASKUT TANKKIKONTTIOSASTOLLA 21 5.1 Myyntilaskutusprosessi tankkikonttien tuonnissa 21 5.2 Tullausta vaativat keikat 22 5.3 Prosessi myyntilaskuun viennin puolella 22 5.4 Ostolaskujen kirjaaminen 23 5.5 Myyntilaskujen kirjaaminen 24 6 NYKYISTEN PROSESSIEN TILA 26 6.1 Ostolaskujen ongelmakohtia 26 6.1.1 Excel-tiedostot 27 6.1.2 Alustojen määrä ja kankeus 28 6.1.3 Toimittajien erilaiset käytännöt 30 6.2 Myyntilaskujen ongelmakohtia 31 6.2.1 Tarjoukset 31 6.2.2 Myyntilaskun järjestelmään kirjaamisen ongelmat 32 6.2.3 Lisäkulujen saaminen laskutukseen 33 7 KEHITYSEHDOTUKSET 35 8 YHTEENVETO 37 LÄHTEET 38 LIITTEET 39 KUVAT Kuva 1 Kirjanpidon erilaisia tilejä. 10 Kuva 2 Kuva laskusta. 13 Kuva 3 Prosessi tilauksesta kirjanpitoon. 16 Kuva 4 Kuva ostolaskun kirjauksesta. 29 Kuva 5 Kuva taulukosta, josta voi valita kuluja. 32 6 1 JOHDANTO Yrityksien perusasioihin kuuluvat olennaisesti osto- ja myyntilaskut, joiden perusteella rahaa joko saadaan tai kulutetaan. Koska laskutus perustuu osto- ja myyntitapahtumiin, on erittäin tärkeää, että osto- ja myyntilaskut ovat oikein, jotta säilytetään vastuullisuus sidosryhmien ja lain silmissä. Oikeellinen laskutus johtaa myös oikeaan määrään kassatuloja. Osto- ja myyntilaskut siirtyvät laskutusprosessien jälkeen lopulta arkistoon ja kirjanpitoon. Jos virheellinen lasku siirtyy kirjanpitoon, vaikuttaa se yrityksen taseeseen. Muita mahdollisia haittoja voivat olla esimerkiksi virheestä johtuvat liian pienet saatavat, jos myyntilaskuun on kirjattu esimerkiksi virheellisesti halvempi tuote tai liian suuri alennusprosentti. Myynti- ja ostolaskujen hoitamiseen kulutetaan väistämättä työtunteja, vaikka laskutus olisi sähköinen ja automatisoitu. Sähköiseen laskutukseen ei kannata luottaa sokeasti, vaan laskut olisi hyvä tarkistaa joka tapauksessa tai viimeistään kirjanpitäjän kehotuksen jälkeen. Työtunnit, jotka laskujen tarkistamiseen käytetään, ovat suoraan verrannollisia yrityksen laskutusprosesseihin ja oikeastaan niiden tehokkuuteen ja helppokäyttöisyyteen. Helpot ja tehokkaat prosessit nopeuttavat laskujen oikeellisuuden tarkistamista ja vähentävät virheiden määrää laskuissa. Virheettömät laskut puolestaan mahdollistavat sen, että tulevaisuudessa ei tarvitse palata laskuun virheiden takia ja käyttää virheen etsimiseen ja korjaamiseen lisää resursseja. 1.1 Kohdeyritys Tämän työn kohdeyritys on logistiikka-alan konserni, jossa työskentelen muun muassa asiakkuuksien ja laskutuksen parissa. Konserni on yksityinen logistiikka- ja investointiyritys, jonka päätoimipiste on Norjassa. Suomen toimipisteessä työskentelee kirjoittamisen hetkellä 12 henkilöä, ja toimipiste hoitaa tankkikonttien kuljetuksia, projektikuljetuksia ja trailerikuljetuksia. Konsernin Suomen toimipisteen liikevaihto on ollut 10 miljoonan euron luokkaa viime vuosina. 7 1.2 Työn tavoite, rajaus ja metodologia Työn tavoite on etsiä laskutusprosesseista kohtia, joita voisi muuttaa tehokkaammiksi. Nopeus ja helppokäyttöisyys laskutusprosesseissa on tässä työssä etusijalla, mutta laskujen oikeellisuudessa ei voida kuitenkaan joustaa yhtään. Yritys tarjoaa kuljetuspalveluita projektiluontoisesti sekä bulkkikuljetuksina tankkikontteja. Tämä työ tulee koskemaan vain tankkikonttien laskutusprosesseja. Tankkikontteja on sekä tuonnissa että viennissä. Yrityksillä on myös erilaiset tarpeet määrissä ja tuotteissa mitä kuljetetaan ja tämä luonnollisesti vaikuttaa laskutukseen ja sen prosesseihin. Aiheen valikoituminen perustuu työntekijöiden kokemiin ongelmiin. Laskutusprosessit ovat yleisesti katsoen hyvällä mallilla ja mahdollistavat lähes kokonaan virheettömät laskut, mutta virheettömyys voi välillä viedä aikaa enemmän kuin olisi tarpeen. Kuten Erätuuli, M; Leino, J. & Yli-luoma, P. (1994, 11) kirjassaan kuvaavat, ilmiö, jota tutkimus pyrkii selittämään, on helpoin tehdä selväksi, jos sen voi asettaa kysymyksen muotoon. Selitettävänä oleva ilmiö kysymyksenä antaa lukijalle helpommin käsityksen, että tutkimus on vain keino saada vastaus tiettyyn tai tiettyihin kysymyksiin. (Erätuuli ym. 1994, 11.) Tutkimuskysymykset tässä tutkimuksessa ovat seuraavanlaiset: Mikä tekee yrityksen kirjaus- ja tarkistusprosesseista tehottomia? Miten yrityksen kirjaus- ja tarkistusprosesseja saisi tehostettua? Tutkimuksen suorittamisen jälkeen tavoitteena olisi saada käsitys yrityksen kirjausprosesseista, niiden tehokkuudesta ja niiden mahdollisista parannuksista. Empiirisen yhteiskuntatutkimuksen alue on käytännössä dikotominen. Perusasenteiden erot ovat yleisesti selkeästi kaksijakoisia vastinpareja, kuten kvalitatiivinen – kvantitatiivinen tai objektiivinen – subjektiivinen. Aaltolan ja Vallin (2007, 18) mukaan tämän ymmärtäminen auttaa valitsemaan itselleen oikeanlaisen tutkimusmetodin. Asia ei ole tietenkään täysin mustavalkoinen, ja edellä mainittuihinkin tutkimuksellisiin asenteisiin löytyy yhteinen tekijä. Tämä tekijä on empiirisen tutkimuksen lähtökohta. (Aaltola & Valli 2007, 18–19; Heikkilä 2014, 27–28.) 8 Opinnäytteen tutkimusotteeksi valittiin konstruktiivinen case-tutkimusote, ja tutkielma on luonteeltaan kvalitatiivinen. Kvalitatiivinen tutkimus sopii hyvin suuremman tutkimuksen esitutkimukseksi, ja koska tämä tutkielma ei koske koko osto- tai myyntireskontraa, ei se ole kokonaisvaltainen tutkimus aiheesta. Kvalitatiivisessa, eli laadullisessa, tutkimuksessa on olennaista nostaa tutkimuksen kohteiden (toimijoiden) subjektiivisia näkökulmia esille. Tämä sopii hyvin tutkielman työhön, joka perustuu pitkälle kollegoiden omien näkemyksien varaan ja toivomuksiin, miten kirjausprosesseja voidaan tehostaa ja mitä epäkohtia prosesseista löytyy. Kvalitatiivinen tutkimus antaa vapauden subjektiivisuuteen, toisin kuin kvantitatiivinen, eli mittaavampi ja objektiivisempi tutkimusmetodi. Subjektiivisuus antaa vapaamman tavan hakea vastausta tutkimuskysymyksille. Vaikka kvalitatiivisessa tutkimuksessa on mukana subjektiivisuutta, hyvän tutkielman edellytyksiä ovat silti objektiivisuus, validiteetti ja reliabiliteetti. (Aaltola, & Valli, 2007, 18–19; Heikkilä, T. 2014, 27–28.) Tutkielman konstruktiivinen osuus tulee sisältämään ehdotuksia, jotka parantaisivat kirjaus- ja tarkistusprosesseja. Ehdotuksien toimivuuden mittaamista tässä opinnäytetyössä ei kuitenkaan ehditä tehdä, koska yritys on aloittamassa projektin uuden ERPjärjestelmän implementoimiseksi. Havainnot tuovat näkemyksiä ja ehdotuksia siihen, mitä uudessa järjestelmässä tulisi olla eri tavalla kuin vanhassa, jotta uuden järjestelmän kirjaus- ja tarkistusprosessit olisivat tehokkaampia verrattuna vanhaan järjestelmään. Jos uuden järjestelmän hankinta viivästyy, tutkielma tekee ehdotuksia myös väliaikaiseen prosessien parantamiseen. 9 2 KIRJANPITO Lähtökohtaisesti jokainen liike- tai ammattitoimintaa harjoittava on kirjanpitovelvollinen, eli hänen tulee pitää kirjaa toiminnastaan. Kirjanpito on olennainen osa verojen maksamisessa verovelvollisilla, mutta sen päätarkoitus on auttaa tuloksen selvittämisessä yritystoiminnassa. Tuloksen perusteella maksetaan veroja ja muita maksuja, jotka ovat laissa säädeltyjä. Myös yritystoiminnan voitto määräytyy kirjanpidon mukaan ja omistajat ovat tästä kiinnostuneita, koska voitosta saadaan jakokelpoiset osingot määrättyä. (Tomperi 2017, 11; Verohallinto 2107.) Kirjanpidon muodostuminen voi tulla pääkirjanpidosta sekä osakirjanpidosta. Osakirjanpidolla tarkoitetaan kirjanpidon eri osa-alueista, kuten laskutus, myynti- ja ostoreskontra, palkanlaskenta ja varasto. Jos kirjanpito muodostuu pääkirjanpidosta ja osakirjanpidosta, pitää niiden yhteys voida todentaa vaikeuksitta, ja sen vuoksi osakirjanpidon ja pääkirjanpidon yhteydet luetteloidaan siten, että yhteydet ilmenevät niistä selkeästi. Lisäksi tästä luettelosta tulee myös ilmetä, missä on yrityksen kirjanpitoaineiston säilytys. (Eklund & Hakonen 2018, 24.) 2.1 Kahdenkertainen kirjanpito Kirjanpito voi olla yhdenkertainen tai kahdenkertainen. Ainoastaan ammatinharjoittajalla voi olla yhdenkertainen kirjanpito, mutta liikkeenharjoittajalla se on kahdenkertainen. Kahdenkertaisella kirjanpidolla tarkoitetaan sitä, että jokainen merkintä tileille tehdään kahdenkertaisesti, eli merkitään kahdelle eri tilille. Toiseen tiliin merkitään debet tai kredit riippuen merkinnän laadusta ja vastatilille kirjataan vastakkainen kirjaus. Jos esimerkiksi yritys ostaa tietokoneohjelmiston käteiskauppana, merkitään kirjanpidossa pankkitilille kredit-puolelle ohjelmiston hinta ja tietokoneohjelmisto-tilille debet-puolelle sama ohjelmiston hinta. (Jormakka, Koivusalo, Lappalainen & Niskanen 2015, 51–52.) 10 2.2 Tilit Tili on kirjausyksikkö kirjanpidossa, johon merkitään esimerkiksi tulo- ja menolajin, pääoman tai velkatyypin vaihtelua eli nousut ja laskut. Jokaiselle liiketapahtumalle on oma tilinsä, jolle tehdään merkintä ja kahdenkertaisessa kirjanpidossa vastatili. (Jormakka ym. 2015, 50.) Kuva 1 esitetään esimerkki erilaisista tileistä ja niihin tehdyistä mahdollisista merkinnöistä. Tilit on kuvattu T-tiliristikossa, jonka vasemmalla puolella on debet ja oikealla kredit. Kuva 1. Kirjanpidon erilaisia tilejä (Yritysvinkit 2017). 11 2.3 Kirjanpitoaineisto Kun yritys aloittaa toimintansa, kaikki liiketapahtumista tulevat todenteet pitää kerätä ja pitää tallessa. Kirjanpitoaineistoa ovat kaikki asiakirjat ja tiedostot, jotka ovat osa yksityisasiakkaiden, pankkien, toisten yritysten tai viranomaisten kanssa asioidessa tarpeellisia. Tämä kirjanpitoaineisto on pidettävä liiketapahtumia todentavana aineistona ja talletettava liikekirjeenvaihtona. Kirjanpitoaineiston käsittely ja säilytys on tapahduttava niin, että niiden tarkastelu on helppoa ja ne ovat tulostettavissa pyynnöstä Suomessa sellaisessa muodossa, että niitä voi yleisesti pitää selväkielisenä. Aineistoa pitää säilyttää vähintään kuusi vuotta. Kuusi vuotta alkaa kulua vasta, kun sen tilikauden, jona aineisto on syntynyt, kalenterivuosi on loppunut. Jos esimerkiksi tilikausi on päättynyt 30.6.2010, kirjanpitoaineisto (tilikauden tositteet) tulee olla säilytettynä vähintään 31.12.2016 asti. Kirjanpito, tilinpäätös, tililuettelot ja muut kirjanpitokirjoihin kuuluvat aineistot pitää säilyttää vähintään 10 vuotta laskettuna tilikauden päätöksestä, eli se alkaa kulua ennen kuluvan kalenterivuoden loppumista. Vaikka liiketoiminta loppuisi, aineistoa on silti säilytettävä vaadittavan ajan. Säilytyksestä vastaa kirjanpitovelvollinen. (Eklund & Hakonen 2018, 18, 24.) 2.4 Liiketapahtumat ja tositteet Kuten on säädetty kirjanpitolaissa, kirjanpitovelvollisen on määrä kirjata kaikki liiketapahtumat kirjanpitoonsa. Liiketapahtumia ovat muun muassa menot ja tulot sekä rahoitustapahtumat. Rahoitustapahtumiin sisältyy myös niiden oikaisu- ja siirtoerät. Kirjauksien yksilöintitapaa ei ole laissa erikseen määrätty, mutta kirjauksen ja sen tositteen sekä liiketapahtuman yhteys on pakko olla helposti todistettavissa pyydettäessä. Tätä helpottava tapa on päivätä ja järjestelmällisesti numeroida jokainen tosite ja tehdä sitä vastaava kirjaus. Jos peruskirjanpidosta selviää vaikeuksitta liiketapahtuma, ei enää tänä päivänä tarvitse merkitä käytettyjä tilejä. (Eklund & Hakonen 2018, 18; Lindfors 2010, 21.) Tositteet on osoitettu kirjanpitovelvolliselle ja antajan pitää tehdä tosite omalla nimellään ja osoitteellaan luettavaan muotoon. Yrityksen tositteita ovat muun muassa myynti- ja ostolaskut, myyntiraportit kassasta, tavaran toimituksesta rahtikirja sekä lähetysluettelo, tiliotteet ja käteis- ja pankkikorttikuitit. Näissä tositteissa on pakko olla kirjanpitolaissa säädetyt tietosisältövaatimuksiin perustuvat tiedot. Verohallinto on tämän perusteella antanut ohjeet laskumerkintävaatimuksista. (Eklund & Hakonen 2018, 18.) 12 Verohallinnon antaman laskumerkintävaatimuksia koskevan ohjeen mukaan laskumerkintävaatimuksia kotimaankaupassa ovat seuraavanlaiset vaatimukset: • laskutuspäivä, eli päivä jona lasku on annettu • tositeen tunniste, joka on yleensä laskun numero • myyjän FI + Y-tunnus arvonlisäveroa varten • yhteisömyynnissä ja/tai käänteisen verovelvollisuuden omaavan ostajan arvonlisäverotunniste • tieto mitä tavaraa ja paljonko tai palvelun laajuus ja laji • molempien osapuolien nimet ja osoitteet • toimituspäivä, palvelun suorituspäivä tai ajanjakso tai ennakkomaksun suorituspäivä • veroton myyntihinta ja verokannan mukaan arvonlisävero erikseen • mahdolliset hyvitykset sekä alennukset • muutoslaskussa pitää viitata aikaisemman laskun tunnukseen • merkintä myynnin mahdollisesta verottomuudesta (Verohallinto 2017) Itselaskutus, käännetyt verovelvollisuudet tai vastaavanlaisilla laskutuksilla on näiden edellä mainittujen vaatimuksien lisäksi omia vaatimuksia. (Eklund & Hakonen 2018, 18, 60). 2.4.1 Lasku eli tulotosite Lasku on tosite tulosta. Tositteesta tulee löytyä vastaanottajan tiedot ja se, koska lasku on tehty (laskun päiväys). Myös luovutettu suorite (suorite on palvelu tai tuote, jota yritys myy) ja suoritteen luovutusajankohta tulee löytyä tositteesta. Luovutusajankohta on päivämäärä, jolloin asiakas on saanut tuotteet tai palvelut kokonaisuudessaan. Laskut luovat siis tulotositteen, mutta myyntitapahtuman ollessa käteismyynti on myyntipäivän kassapäätteen myyntiraportti tulotosite (käteismyyntitosite). Alkuperäiset kappaleet myyntilaskuista lähetetään aina ostajalle ja kirjanpitoon liitetään tulotositteeksi kopio laskusta. Jotkut toimialat ovat hyväksyneet käytännön, jossa ostaja tekee itse tositteen myyjän puolesta (esimerkiksi puualalla). Arvonlisäverolain mukaan tämä käytäntö on hyväksyttävää, jos asiasta on sovittu etukäteen ja myyjä hyväksyy tositteen sen saadessaan itselleen. (Eklund & Hakonen 2018, 19; Lindfors 2010, 22.) 13 Kuva 2. Kuva laskusta (Inv24 2019). Alla esimerkkinä kuva oikeaoppisesta laskusta. 2.4.2 Menotosite Menotosite on tosite menosta. Se on ostolasku tai vastaavanlainen tosite, jonka yritys vastaanottaa myyjältä. Sen on siis ensisijaisesti tultava yrityksen ulkopuolelta. Menotositteessa tulee olla kirjattuna lähettäjän (myyjän) ja vastaanottajan yhteystiedot sekä Y-tunnus. Lasku pitää olla päivätty. Myös hankitut palvelut ja tuotteet ja niiden vastaanottoaika pitää käydä ilmi menotositteessa. Vastaanottoaika on se päivä tai ajanjakso, jolloin tuotteet tai palvelut on toimitettu ostajalle tai palkat on maksettu. Jos nämä eivät käy ilmi selvästi, tulee menotositteen mukaan kirjanpitoon liittää lähetysluettelo tai muu 14 sitä vastaava tosite, joka on kuitenkin alkuperäinen eikä kopio. (Eklund & Hakonen 2018, 21.) 2.4.3 Tiliote tositteena Tiliotetta voi käyttää myös tositteena sekä maksun suorittamisesta että vastaanottamisesta. Tiliote pitää olla numeroitu ja sen on pidettävä sisällään riittävä selvitys maksutapahtumista. Sen pitää myös näyttää toteen maksujen kirjausketjun pankin omassa maksujenvälitysjärjestelmässä. Tiliotteesta pitää nähdä myös, mitä maksu koskee, jos sitä käytetään tulo- tai menotositteena. Tästä esimerkkinä on pankin palvelumaksut, jotka pankki on eritellyt tiliotteelle. (Lindfors 2010, 23.) 15 3 LASKUTUS Yrityksen myydessä kuluttajalle tavaroita tai palveluita käytetään yleensä käteiskauppaa, eli ostaja maksaa heti tavaransa ilman luottoa. Yritykset myyvät keskenään yleensä luotolla, eli toisin sanoen laskulla. Lasku on tällöin myyjälle myyntitulokseen kirjattava myyntisaaminen. Ostajalle tämä sama lasku on ostomenoa ja ostovelan lisäämistä. Lasku toimitetaan ostajalle myyjän toimesta perusoletuksena paperisena, mutta vastaanottajan suostumuksella lasku voidaan myös toimittaa sähköisesti, kuten verkkolaskuna, sähköpostilaskuna tai e-laskuna. (Tomperi 2017, 52–53; Verohallinto 2017.) Yrityksessä laskutuksen ja siihen liittyvät tehtävät hoitaa laskuttaja. Laskuttajan tulee huolehtia, että ennen laskutusta kaikki taustatiedot ovat kunnossa. Taustatietoja, joita tarvitsee laskutukseen, voivat olla muun muassa asiakastiedot, tuotetiedot, maksu- sekä toimitusehdot ja viivästyskoron määrä. Myös hinnanlisät kuuluvat laskutukseen. Hinnanlisiä voivat olla laskutusmuoto (paperinen lasku), laskutuslisä tai vaikka kuljetukseen liittyvät lisämaksut. Hinnanlisät ovat yleisesti ottaen aina etukäteen sovittuja lisiä, jotka löytyvät kauppasopimuksesta tai tarjouksesta. Myyntireskontraa voi hoitaa toinen henkilö, joka pitää huolen myyntilaskuista saatavista suorituksista ja yleensä hoitaa myös maksumuistutuksia ja viivästyskorkojen laskutusta. Monesti nämä kaksi tehtävää (laskutus ja myyntireskontran hoitaminen) tekee sama henkilö. (Eklund & Hakonen 2018, 56, 76.) 3.1 Asiakasrekisteri Asiakasrekisteri ja sen ylläpitäminen on tärkeä osa myyntitapahtumaa ja olennaista tilausten käsittelyn ja laskutuksen kannalta. Kun asiakastiedot ovat oikein, taataan se, että laskut, asiakirjat ja toimitukset menevät varmasti oikein. Yritys antaa myös hyvän kuvan sidosryhmille, jos asiakastiedot ovat oikein niin tiedollisesti kuin kieliopillisestikin. Tietoja, mitä tarvitaan asiakasrekisteriin, ovat muun muassa asiakkaan nimi, osoite ja yhteystiedot, Y-tunnus (tai henkilötunnus yksityisillä asiakkailla joissain tilanteissa), laskutustapa ja maksuehdot sekä sovitut alennukset. Asiakasrekisteriä pitäessä on velvollinen noudattamaan tietosuoja-asetusta (GDPR, General Data Protection Regulation) sekä muita ohjeita, joita on annettu henkilötietojen käsittelystä. Asiakkailla, jotka ovat rekisterissä, on oikeus saada tietoa henkilötietojen käsittelystä ja hänellä tulee olla vapaa pääsy omiin 16 tietoihinsa. Jos hän huomaa tiedoissa virheitä, hänellä on myös oikeus saada niihin oikaisu mahdollisimman nopeasti. Jos asiakas haluaa poistua rekisteristä, on yrityksen pakko noudattaa pyyntöä ja sen tulee poistaa kaikki tiedot rekisteristä. (Eklund & Hakonen 2018, 73–74.) Kuvassa kolme on esimerkki prosessista, jossa myyntitilaus etenee eri vaiheiden kautta kirjanpitoon asti. Kuva 3. Prosessi tilauksesta kirjanpitoon (Eklund & Hakonen 2018, 59). 1. Myyntitilaukset asiakkailta laitetaan järjestelmään. 2. Varasto antaa tiedon lähetetyistä tuotteista. 3. Lasku tulostetaan / lähetetään asiakkaalle. 4. Lähetetty myyntilasku kirjataan myyntireskontraan. 5. Saapunut maksusuoritus kohdistetaan myyntilaskulle myyntireskontrassa. 6. Tiedot siirretään kirjanpitoon myyntireskontrasta. Tiedot ovat lähetetyt laskut ja saadut suoritteet. Erilaisia raportteja on mahdollista tulostaa reskontrasta. Tarvittavia tietoja voivat olla esimerkiksi tietyn päivän erääntyneet myyntisaatavat. (Eklund & Hakonen 2018, 59.) Varastokirjanpito Myyntireskontra Kirjanpito Raportteja -Asiakastiedot -Saamiset -Erääntyneet saamiset -Maksumuistutukset -Viivästyskorkolaskut 1 Laskutus Lasku Saadut tilaukset 6 2 3 Saadut suoritukset 5 4 17 3.2 Ostoreskontra Ostoreskontra on osa osakirjanpitoa ja eroaa pääkirjanpidosta siten, että sillä seurataan tarkemmin ostoja. Osakirjanpidossa myyntireskontrassa puolestaan seurataan tarkemmin myyntisaamisia. Alla ovat esimerkit osto- ja myyntireskontraan kirjaamisesta: Kun yritys on ostanut velaksi tuotteita tai palveluita ja saanut siitä menotositteen (laskun). se tarkastetaan ja hyväksytään. Jos laskussa ilmenee virheitä, pyydetään myyjältä hyvityslasku. Hyvityslasku on lasku, jossa ei näy yleensä maksettavaa määrää, ja siinä pitää selkeästi huomata kyseessä olevan hyvityslasku. Arvonlisäverolain mukaan laskussa pitää ilmetä myös viittaus alkuperäiseen laskuun, jossa virhe on ollut. Hyväksymisen jälkeen ostolasku siirretään ostoreskontraan. Maksuaineisto liitetään yhteen ostoreskontrassa ja tiedot lähetetään pankkiin. Maksun jälkeen ostolasku kirjataan ostoreskontrassa suoritetuksi, jonka jälkeen kirjaukset merkitään kirjanpidon tileille. Liiketapahtumat maksuista ja kirjanpidon yhteenveto viedään pääkirjanpitoon vähintään kerran kuussa. Kalenterikuukauden päätteeksi on tarkistettava, että avoimena olevien ostolaskujen yhteyssumma on täysin sama summa kuin mikä on pääkirjanpidossa ostovelkatilin yhteissumma. (Lindfors 2010, 20; Eklund & Hakonen 2018, 79.) 3.2.1 Ostolaskut ja niiden käsitteleminen Lähtökohtaisesti jokainen ostolasku on tarkistettava, jotta oikeellisuus voidaan taata. Ostolaskujen tarkistaminen, eli numerotarkastus, tapahtuu vertailemalla ostotilausta ja/tai lähetysluetteloa, joka on tullut saapuvan kuorman tai palvelun yhteydessä. Periaatteena on tarkistaa kappalemäärät, hinnat ja tilausviite ja niiden oikeellisuus laskussa. Tarkastuksen voi tehdä tavaroiden vastaanottava henkilö tai esimerkiksi ostoreskontranhoitaja. Tarkistuksen jälkeen ostoreskontranhoitajan pitää tehtävänsä mukaisesti tarkistaa toimittajarekisteristä toimittajan tietojen oikeellisuus. Näitä tietoja ovat muun muassa Ytunnus, yhteystiedot ja esimerkiksi pankin tilinumero maksua varten. Joissain tapauksissa rekisteriin voi merkitä myös toimittajan kohdalle kulutilin kirjanpitoa varten tai sen voi tehdä manuaalisesti ostolaskua kirjatessa. Ostolaskun kirjauksen yhteydessä kulut siirtyvät suoraan toimittajan kulutilille. (Eklund & Hakonen 2018, 112–113.) 18 Kun ostolasku on tarkastettu, se esikirjataan ostoreskontraan, eli tiedot viedään ostoreskontraan hyväksymistä varten. Olennaista on kirjata lasku oikealle kuukaudelle sen mukaan, miten on käytäntö valittu. Käytäntöjä on yleisesti kaksi erilaista. Suoriteperusteessa lasku kirjataan päivälle, jona ostettu tavara on saapunut tai ostettu palvelu on toimitettu. Toinen käytäntö on laskuperuste, jolloin lasku kirjataan sille päivälle, jolle lasku on päivätty. Kun lasku on esikirjattu, lasku asiakirjatarkastetaan joko tilaajan tai hänen esimiehensä toimesta riippuen yrityksen käytännöistä. Asiakirjatarkastuksessa tarkistetaan sopimusehtojen täyttymiset, kuten alennukset, toimituskulut sekä maksuehdot. Tarkastuksen yhteydessä (numerotarkastus tai asiakirjatarkastus) lasku kohdistetaan oikealle kustannuspaikalle tai mahdolliselle projektille. Asiakirjatarkastuksen jälkeen lasku tarkastetaan kokonaisuudessaan, jotta se vastaa sovittuja käytäntöjä ja mahdollisesti ostoreskontranhoitaja voi vielä kerran tarkistaa ostolaskun kirjanpitomerkinnät. Tämän jälkeen ostolasku on maksukelpoinen. Käytännöt voivat vaihdella eri yrityksissä. Kun lasku kiertää yrityksen sisällä, henkilö, joka hoitaa ostoreskontraa, seuraa etenemistä ja muistuttelee ihmisiä laskusta, jos eteneminen kestää liian kauan ja laskun eräpäivä lähenee. Eräpäivään mennessä laskun pitäisi olla jo tarkistettu ja laitettu maksuun, jotta ei tulisi ylimääräisiä kuluja, kuten viivästyskorkoa. Yrityksen kannalta olisi myös hyvä hyödyntää mahdolliset käteismaksualennukset. (Eklund & Hakonen 2018, 117– 119.) 3.2.2 Avoimet ostolaskut Ostoreskontrasta on mahdollista saada avoimien ostolaskujen raportti, joka kertoo avoimena, eli maksamattomina, olevien ostolaskujen määrän sinä ajankohtana. Kun kuukausi loppuu, raportin loppusumma, eli maksamattomien laskujen yhteenlaskettu summa, tulisi olla täysin sama kuin kirjanpidon ostovelat-tilin loppusumma näyttää. Jos tilinpäätös osuu samalle ajankohdalle, pitää avoimien ostolaskujen raportti liittää tilinpäätöserittelyihin, jotta on nähtävissä, mistä ja miten ostovelka muodostuu yritykselle. (Eklund & Hakonen 2018, 131.) 3.3 Myyntireskontra Laskutusohjelmat siirtävät yleensä automaattisesti myyntilaskut lähetyksen jälkeen myyntireskontraan. Myyntireskontrassa ovat kaikki laskutus- ja suoritustiedot ja niiden 19 ylläpito ja seuraaminen tapahtuvat siellä. Laskun summa määräytyy sen mukaan, miten laskun kirjaaja on yleensä tuoterekisteristä valinnut tuotteita laskulle. Myyntireskontrassa avoimien laskujen yhteydessä voi ohjelmasta riippuen yleensä lähettää myös maksukehotuksia sekä viivästyskorkolaskuja asiakkaalle, jos asiakas ei ole suorittanut laskujaan eräpäivään mennessä. Suoritukset kirjataan myyntireskontraan tositteiden perusteella, joita ovat esimerkiksi tiliotteet tai pankkiohjelmasta saadut aineistot. Suorituksien kirjaaminen voi tapahtua sähköisesti tai käsin, jolloin myyntireskontraan kirjataan viitenumero, joka löytyy myyntilaskusta. Sähköisessä kirjauksessa suoritus tuodaan suoraan pankkiohjelmasta myyntireskontraan, ja tämä on nopein ja helpoin tapa, kunhan maksun suorittaja kirjoittaa viitetiedot viitekenttään viestikentän sijaan. Jos maksaja käyttää viestikenttää, suoritus pitää tuoda käsin pankkiohjelmasta reskontraan ja kohdistaa oikealle myyntilaskulle. Kuun lopuksi, tai ainakin vähintään kerran kalenterikuussa, tiedot laskutuksista ja suorituksista siirretään pääkirjanpitoon osakirjanpidosta (myyntireskontrasta). Tällöin maksamattomien myyntilaskujen yhteissumma tulisi olla täysin sama kuin mitä kirjanpidon myyntisaamiset-tilin loppusumma on. (Eklund & Hakonen 2018, 79, 86–87.) 20 4 SÄHKÖINEN TALOUSHALLINTO Tehokas taloushallinto on ennen kaikkea kustannustehokas, ja kustannuksia pitää pystyä optimoimaan tehokkaasti. Taloushallinto on liiketoiminnan tukifunktio eli toimintaa tukeva toiminto, ja sen takia sen pitää olla kustannustehokas taloudellisesta näkökulmasta katsottuna. Tähän päästään automatisoimalla prosesseja, toimintaa ja työtehtäviä sekä yleisesti virtaviivaistamalla kaikkia prosesseja. Taloushallinto tukiessaan liiketoimintaa on erityisen tärkeää, että raportointi on virheetöntä. Virheellinen raportointi vääristää sekä tuloksentekokyvyn mittaamista että itse tulosta. Virheiden määrää pystyy vähentämään esimerkiksi automatisoimalla ostolaskujen kiertoa. Tiedon liikkuminen järjestelmien välillä ja automaatio, joka mahdollistetaan järjestelmän säännöillä, ovat suoraan verrannollisia taloushallinnon tehokkuuteen. Jos esimerkiksi tilitoimisto käyttää samaa ohjelmaa yrittäjän kanssa, tiedot siirtyvät automaattisesti ja nopeasti eteenpäin ja tämä vähentää työtunteja ja sitä kautta alentaa kuluja. Tietoja, joita tilitoimisto voi haluta sähköisesti voi olla esimerkiksi kuitit, tositteet ja laskut. Tehokkaan taloushallinnon yksi pääpiirre on myös jatkuva tarkkailu talousjärjestelmien ja talousautomaation kehityksessä. Myös työntekijöiden jatkuva kehittäminen, sitouttaminen ja individuaalinen eli yksittäisten henkilöiden osaaminen on olennainen osa tehokkaita taloushallinnon prosesseja ja mahdollistaa parempien toimintatapojen kehittämisen. (Suni 2017, 74–75; Finago 2019.) Tehokkaan taloushallinnon tuoma etu ei katso yrityksen kokoa ja jopa mikro- ja pienyritykset saavat huomattavaa etua käyttäessään tehokasta sähköistä taloushallintoa. Pienyrityksen taloushallintoon käyttämä aika voi olla jopa kolmannes, jos yritys käyttää sähköistä ja automatisoitua taloushallintoa perinteisen taloushallinnon sijaan. (Accounter Finago Oy 2019) 21 5 YRITYKSEN OSTO- JA MYYNTILASKUT TANKKIKONTTIOSASTOLLA Tankkikontteja yritys on kuljettanut keskiarvollisesti kuluvan vuoden aikana hieman yli kolmesataa jokaisena kuukautena. Tuonnin puolella kuljetuksia on huomattavasti enemmän, kuin viennin puolella. Jokainen kuljetus laskutetaan erikseen, joten myynti-ja ostolaskuja tulee satoja kuukaudessa tankkikonttien tuonnin ja viennin osalta ja eri henkilöt luovat laskuja sen mukaan, että kuka hoitaa keikkaa. Keikkaa hoitaa Account Manager yleensä alusta loppuun, mutta tuonnin puolella kuljetusta voi hoitaa toinen henkilö, kun kontti on saapumassa Suomeen ja laskun tekijä määräytyy sen mukaan. Ostolaskut ovat jaettu ostojen mukaan eri henkilöille ja nämä henkilöt tarkistavat ostolaskujen oikeellisuuden. Jos tarkistamattomia ostolaskuja kuitenkin kasaantuu ostoreskontraan tietylle henkilölle, voivat muut myös tarkistaa kasaantuneita laskuja. Yrityksen yhteistyökumppani mahdollistaa yrityksen kaikki tankkikontit vuokraamalla. Yrityksellä itsellään ei ole omia tankkikontteja omistuksessa ollenkaan, joten kaikki kontit ovat yhteistyökumppanilta. 5.1 Myyntilaskutusprosessi tankkikonttien tuonnissa Ensimmäinen vaihe myyntilaskuun on asiakkaan yhteydenotto keikkaa varten. Asiakkaat lähestyvät pääasiassa sähköpostilla yritystä kertoen omasta tarpeestaan kuljetukselle ja tuotteelle. Tämän jälkeen luodaan keikka ERP-järjestelmään nimeltä Sentera, johon kirjataan kaikki olennainen tieto, kuten lastauspäivä ja paikka, toimituspäivä ja paikka, kuljetettava tuote ja reititys. Tässä vaiheessa sekä keikka itsessään, että ”yksikkö”, eli kontti Senterassa, saavat molemmat omat viitenumeronsa, johon voidaan kohdistaa kuluja ja tuloja. Keikan tiedot lähetetään tämän jälkeen yhteistyökumppanille, joka on maailmanlaajuinen logistiikka-alan yritys, ja yhteistyökumppani valitsee konttiseurannastaan oikeanlaisen kontin ja kuljettajan keikalle ja tarvittaessa varaa lastausajan. Kontin lastauksen jälkeen se kuljetetaan valittuun satamaan ja sieltä kontti kulkeutuu Suomeen, jossa yrityksen valitsema kuljettaja hakee kontin ja toimittaa sen asiakkaalle sovittuna päivänä. 22 Kuljettaja kertoo joko ajojärjestelijälle tai Account Managerille purkuajan, jonka perusteella kuljettaja laskuttaa yritykseltä lisäkuluja tarpeen mukaan. Lopuksi kuljettaja vie kontin joko pesuun tai satamaan. Kun kontti on toimitettu ja sijoitettu pyydettyyn paikkaan, pesukulut saatuna ostolaskulla ja lastauksesta mahdolliset lisäkulut on ilmoitettu, voi keikasta tehdä myyntilaskun asiakkaalle. Ideana on kerätä tilauksesta asti kaikki tiedot keikoille, jotta laskun tekijä saa tietää mahdolliset lisäkulut ja ongelmat sekä katsoa oikean perushinnan rahdille reitityksen perusteella. Kaikki tärkeät liitteet, kuten laivayhtiön saapumisilmoitukset ja vastaavat laitetaan pilvipalveluun, johon jokaisella on pääsy. Pilvipalvelussa on myös hinnastot, joita käytetään laskujen kirjaamiseen. Ongelmana on, että liikenteenhoitaja voi unohtaa kirjata tai voi kirjata virheellisesti keikalle olennaisia tietoja. Esimerkiksi kontin lämmityksen alkamispäivä tai esimerkiksi toimituspäivä voi olla väärin. Tällöin laskun tekijän pitää tarkistaa ajojärjestelijän ohjelmasta päivän, koska kontti on toimitettu tai tarkistaa keikan ”yksikkö” välilehdeltä päivä, joka on kirjattu konttiseurantaan. Kytkentäpäivän puute voidaan huomata viimeistään siinä vaiheessa, kun satamalta tulee lasku kytkennästä ja sen oikeellisuus pitää tarkistaa. 5.2 Tullausta vaativat keikat Jotkut kontit tulevat maista, mitkä eivät kuulu vapaan liikkumisen alueelle ja ne pitää lain mukaan tullata. Yritys ei itse hoida tullauksia, koska tullausta vaativien konttien määrä, joiden liikennettä yritys hoitaa, on todella vähäistä. Muutamat asiakkaat silti haluavat tuoda Suomeen tullattavia kontteja ja tällöin yritys ulkoistaa tullauksen huolintayritykselle, joka on erikoistunut tullaukseen. Yritys välittää kaikki mahdolliset paperit, jotka tullaukseen vaaditaan huolintayritykselle, joka hoitaa lopulta tullauksen ja lähettää tullauspäätöksen, tulliverolaskun ja oman huolintalaskunsa. Kun kontti on tullattu ja päätökset on saatu, kontti toimitetaan normaalisti asiakkaalle sovittuna päivänä ja laskuun kirjataan normaalin kuljetuksen lisäksi huolintakulut. 5.3 Prosessi myyntilaskuun viennin puolella Viennin puolella tilauksen eteneminen menee aluksi vastakkaisesti verrattuna tuontiin. Joko suomalainen asiakas haluaa toimittaa ulkomaiselle asiakkaalle tuotetta tai ulkomainen asiakas haluaa lastata Suomessa tavaraa ja saada se itselleen ulkomaille. Tilauksen 23 tullessa luodaan keikka ja sovitaan lastauspäivästä Suomessa ja tarkistetaan mitä reittiä käytetään. Yritys valitsee kuljettajan ja konttiseurannasta tankkikontin keikalle. Kontin valinta tehdään tuotteen perusteella. Tuote voi vaatia lämmitystä, se voi olla tietynlaista ominaisuuksiltaan, jolloin kaikkien konttien fyysiset ominaisuudet eivät ole oikeanlaisia esimerkiksi purkuun ja myös tuotteen määrä mitä pyydetään määrää kontin koon. Esimerkiksi 35000 kg vetävään konttiin ei voi lastata 25000 kg tavaraa ilman baffleja (väliverkkoja), koska tankki on liian tyhjä ja tuote hölskyy kuljetuksen aikana mikä aiheuttaa riskitilanteita. Lastauksen jälkeen kuljettaja vie tankkikontin satamaan laivausta varten ja kontti kuljetetaan asiakkaalle. Merimatkan jälkeen yhteistyökumppani hoitaa kuljetuksen perille asiakkaalle pyydettynä päivänä. Matkan varrelta kaikki tiedot, ongelmat ja lisäkustannukset kirjataan keikalle, jotta laskun tekijällä on kaikki tarvittavat tiedot laskun oikeellisuuden takaamiseksi. 5.4 Ostolaskujen kirjaaminen Yritykselle tulee monelta eri toimittajalta ostolaskuja kaikista kuljetuksen eri vaiheista. Ostolaskut tulevat sähköisesti palvelimelle, johon pääsee käsiksi internetin kautta sekä ERP-järjestelmään. Ostolasku avataan ERP-järjestelmässä ostoreskontran avoimien ostolaskujen selauksesta ja järjestelmä antaa ostolaskun numeron, jonka perusteella palvelimelta löytyy kuvana ostolasku. Ostolaskun kirjauksessa jokainen kulu kohdistetaan keikan tai yksikön viitteelle. Yksikön viitettä käyttäen on mahdollisuus väärinkirjaukselle pienempi, koska joskus kulut eivät kuulu keikalle, jonka viite laskusta löytyy vaan enemminkin yksikölle. Kulut kirjataan yksitellen ERP-ohjelmaan ja samalla tarkistetaan hinnastoista (yleensä Excel-tiedostona) oikea hinta kululle ja se kirjataan järjestelmään. Jos hinta on eri kuin mikä hinnastossa on, kulu kirjataan joka tapauksessa järjestelmään ja pyydetään hyvityslaskua toimittajalta. Rivejä syöttäessä pitää myös huomioida arvonlisäverotus. Esimerkiksi satamamaksut ovat veroluonteisia maksuja ja ne eivät kuulu arvonlisäverotuksen piiriin. Myöskin joidenkin ulkomaalaisten asiakkaiden kanssa pitää huomioida käänteinen verovelvollisuus ja silloin ei myöskään lisätä riville arvonlisäveroa. Näistä ei ole erillistä ohjetta ja laskun kirjaajan pitää itse tietää, koska arvonlisävero kuuluu kirjata ja koska ei. Kun kaikki kulut ovat kirjattu, ERP-järjestelmän kohdassa ”laskua jäljellä” tulisi lukea 0,00 €. Jos loppusumma on 0,00 € järjestelmä hyväksyy ostolaskun kirjauksen ja ostolasku 24 siirtyy seuraavaan vaiheeseen ostolaskun kierrossa. Seuraava vaihe kierrossa on esimiehen ostolaskun tarkistaminen. Esimies tarkistaa jo hyväksytyn ostolaskun, jonka jälkeen ostolasku siirtyy Tallinnassa sijaitsevalle kirjanpitäjälle. Laskun tila muuttuu hyväksynnän aikana järjestelmässä ”Waiting Cost Split”-> ”Waiting approval”. Ennen Tallinnaan siirtymistä laskun kulut tiliöidään oikeille kirjanpidon tileille ja kirjanpitäjä tarkistaa tämän. Kirjanpitäjä lähettää esimiehelle tasaisin väliajoin koosteen maksettavista laskuista ja esimies päättää jätetäänkö jokin lasku tässä vaiheessa pois ja siirretään myöhemmäksi. Kooste perustuu kirjanpitäjän tietoihin hyväksytyistä laskuista. Kun on päätetty mitkä laskut siirtyvät maksuun, on seuraava vaihe laskun maksaminen ja arkistointi. 5.5 Myyntilaskujen kirjaaminen Jokaisen tankkikontin kuljetuksen jälkeen tehdään lasku sille kuljetukselle. Yrityksessä ei tehdä yhtä laskua monelle samanlaiselle kuljetukselle kirjausvaiheessa, mutta tiettyjen asiakkaiden kuljetukset nidotaan lopuksi yhteen ERP-järjestelmässä koontilaskuksi, jolloin moni saman asiakkaan kuljetus löytyy samalta laskulta. Kirjauksen perusteena on yleensä ERP-järjestelmästä löytyvä tarjous, joka on asiakkaalle annettu. Tarjous löytyy ERP-järjestelmästä kuljetustarjouksista, joissa tarjous on merkitty asiakasrekisteristä löytyvän yrityksen nimelle. Tarjouksessa voi olla monta eri vaihtoehtoa reititykseen ja muut lisäkulut, jotka voivat ilmaantua kuljetuksen aikana tai ennalta sovitusti. Muutamilla asiakkailla on omat hinnastot, joissa on rahtihintoja sekä lisäkuluja. Olennaista on katsoa ERP-järjestelmästä keikan tiedot ja liikenteenhoitajan merkinnät ja verrata niitä hinnastoihin ja tarjouksiin ja sen mukaan kirjata myyntirivejä. Kuten ostolaskuissa, myös myyntilaskuissa pitää tarkistaa kuuluuko myyntiriviin arvonlisävero tai onko asiakkaalla käänteinen verovelvollisuus. Kun lasku on kirjattu kokonaisuudessaan, se tulostetaan yleensä PDF-tiedostoksi (harvat asiakkaat haluavat paperisen version) ja se lähetetään asiakkaan valitsemaan sähköpostiosoitteeseen. Laskun tulostuksen yhteydessä järjestelmä luo sille laskunumeron ja viitteen. Lasku tiliöidään automaattisesti ja lähetetään kirjanpitäjälle, joka raportoi viikoittain maksamattomista, mutta eräpäivän jo ohittaneista laskuista, joista lähetetään muistutuksia. Laskun oikeellisuus on tärkeää, koska laskua ei saateta maksaa ennen kuin virheet on selvitetty laskun tekijän ja asiakkaan välillä. Tähän joidenkin asiakkaiden kanssa on tehty 25 ratkaisu, että rahdit kirjataan eri laskulle, koska ne ovat aina samat ja perustuvat kirjallisiin tarjouksiin. Lisäkustannukset kirjataan eri laskulle, koska näistä käydään yleensä eniten keskustelua oikeellisuudesta ja näitä pitää todistaa joskus kirjallisesti. 26 6 NYKYISTEN PROSESSIEN TILA Haastattelujen perusteella yrityksessä ollaan tyytyväisiä laskujen kirjaamisen ja tarkistamisen oikeellisuuteen. Nykyiset prosessit mahdollistavat täysin tai lähes täysin oikeellisen laskutuksen. Ongelmana on kuitenkin havaittu tehottomuus, joka näkyy ajankäyttönä laskutuksen kaikilla osa-alueilla, mutta etenkin ostolaskujen kierrättämisen kanssa. Tehottomuutta aiheuttavat monet eri tekijät, jotka ovat muutettavissa yrityksen toimesta, mutta esimerkiksi toiminnanohjausjärjestelmän kankeus on erittäin kallista ja aikaa vievää päivittää ja sitä ei todennäköisesti edes kannata päivittää, kun uuden ERP:n implementointi on joka tapauksessa yrityksellä edessä. Ongelmia ilmenee myös yhtenäistämisessä. Monella laskujen kanssa tekemisissä olevalla on omia erilaisia tapoja ja käytäntöjä ja näistä ei ole annettu selkeitä ohjeita, miten kaikkien tulisi toimia. Jotkin tavat ovat hitaampia kuin toiset ja tietyt tavat voivat olla epäselviä toisille. Uusi työntekijä saa ohjeita monelta henkilöltä ja jotkin ohjeet voivat olla ristiriidassa toistensa kanssa. Ilman ohjeita yhtenäistämiseen tätä on hankala korjata. 6.1 Ostolaskujen ongelmakohtia Ostolaskujen selkeimpiä ongelmakohtia olivat monien eri alustojen käyttö tarkistustilanteessa. Myöskin toimittajien suuri määrä ja heidän omat tapansa laskuttaa loivat ongelmia laskujen tarkistamiselle. Toimittajien tapoihin tehdä laskuja on hankalampi puuttua. Toimittajat eivät helposti muuta omia käytäntöjään yhden yrityksen pyynnön perusteella, koska se tuo heille pelkästään kustannuksia. Yrityksen ostolaskut eivät pääsääntöisesti mene maksuun ennen eräpäivää. Keskimääräinen aika ostolaskujen laittamiseen maksuun on noin yhdestä kahteen viikkoa eräpäivän jälkeen. Syynä ei ole prosessien tehottomuus vaan enemmänkin taloudelliset ja rahoitukselliset syyt. Projektikuljetuksissa isot projektit pitää rahoittaa ennen kuin projektin tilaaja maksaa laskunsa. Projektien tilaajilla on yleensä 60 päivän maksuaika myyntilaskuissa ja yrityksen ostolaskuissa on yleisesti 30 päivän maksuaika. Ostolaskujen maksuja priorisoidaan ja maksusuunnitelmia kehitetään sekä seurataan koko ajan. Tehostamalla ostolaskujen tarkistusprosessia ja nopeuttamalla ostolaskujen kiertoa voidaan kehittää tarkempia maksusuunnitelmia, jotka ennaltaehkäisevät tilanteita, jolloin tulee kiire 27 maksaa jokin tietty lasku. Jos jonkin ison ostolaskun maksaminen ei ole mahdollista eräpäivän jälkeen ja maksusuunnitelman mukaan maksaminen venyisi liian pitkälle, voi yritys lainata rahaa konsernin sisäisesti maksamista varten. 6.1.1 Excel-tiedostot Laskua kirjatessa pitää olla aina keikka auki ERP-järjestelmän TC-osastosta (Tank Container) ja ostolaskut-osio samasta järjestelmästä sekä laskujen pilvipalvelun ikkuna, jossa näkyy itse lasku. Myös Excel-tiedostot ja sähköposti ovat pakollisia oikeellisuuden varmistamiseksi. Tämän takia laskuttaja joutuu vaihtelemaan monen eri ohjelman ikkunan välillä. Työntekijöillä on mahdollista saada kaksi näyttöpäätettä työpöydälleen, mutta se ei tunnu riittävän monelle ohjelmaikkunalle. Pahimmillaan voi olla 5–7 eri Exceliä auki, jotta laskun jokaisen rivin voi tarkistaa. Exceleitä on muun muassa satamakustannuksista, yhteistyökumppanin vetohinnoista, laivayhtiöiden hinnoista ja esimerkiksi pesukustannusten hinnoista. Excelit perustuvat eri toimijoiden hinnastoihin ja sen vuoksi niitä ei ole yhdistetty. Myös samalta toimittajalta voi tulla eri tiedostoja eri kustannuslajeille, mutta niitä ei ole yhdistetty, koska päivitetty versio on helppo laittaa käyttöön sen sijasta, että tiedosto yhdistettäisiin saman toimittajan muihin tiedostoihin. Exceleitä on useita, koska toimittajia on erittäin paljon. Jokaiselle toimittajalle on oma hinnasto, jonka yritys joko saa toimittajalta tai luo uuden heitä varten. Suuri toimittajien määrä on välttämätöntä yritykselle, koska yrityksen ideana on tarjota joustavaa kuljetuspalvelua. Toimittajia karsimalla ja siten hinnastoja siistimällä menetetään joustavuus, joten se ei ole yritykselle vaihtoehto. Excelin käyttöön riittää perusosaaminen Excelin kanssa. Suurin osa Excelin käytöstä on vain suodattamista ja rivien selailua ja esimerkiksi laivayhtiön polttoainekustannusten prosentin vaihtamista soluun. Koska monimutkaisia funktioita ei ole, olisi mahdollista työstää kaikki hinnastot yhteen isoon Exceliin kopioimalla tiedot. Vaikeata tässä on suuren datan yhteen kasaaminen ja käytön jaotteleminen niin, että se pysyy käyttäjäystävällisenä ja selkeänä. Koska tietoa on niin paljon ja monet niistä eivät ole olennaista osalle käyttäjistä pitäisi Excel saada muotoon, jota käyttäjä voi itse muovata itselleen sopivaksi helposti joka kerta Excelin avatessa. Jos käyttäjä tallentaa oman version Excelistä työpöydälleen on riskinä, ettei sitä päivitetä, joka tällöin johtaa virheellisiin laskuihin. Jos taas sen tallentaa pilvipalveluun, seuraava käyttäjä joutuu muokkaamaan sitä vielä enemmän, jotta saa itse tarvitsemansa tiedot näkyviin. 28 Eri Excel-tiedostojen ylläpitäminen on työlästä ja joistakin tiedostoista on vielä pilvipalvelussa eri revisioita, jotka eivät enää pidä paikkaansa, mutta joista voi seurata esimerkiksi hinnan kehitystä. Joissakin hinnastoissa näkyy edelleen esimerkiksi viimevuotinen hinta ja se on monelle käyttäjälle epäolennainen tieto. Asian selkeyttämiseksi pitäisi poistaa vanhat tiedot uudesta hinnastosta, koska vanhat versiot ovat edelleen saatavilla pilvipalvelusta. Uusi toiminnanohjausjärjestelmä, joka on määrä ottaa käyttöön tulevaisuudessa, pitäisi olla sellainen, että ostolaskun avatessa näkyisi myös ennalta määrätyt hinnat juuri rivin kuljetukselle tai korkeintaan yhden lisäikkunan kautta näkisi kuljetukselle kaikki mahdolliset hinnat reittien perusteella sekä lisähinnat. 6.1.2 Alustojen määrä ja kankeus Ostolaskut avataan ERP:stä, jolloin saadaan laskun numero. Laskun numerolla saadaan pilvipalvelusta, joka on keskittynyt vain laskuihin, näkyviin lasku. ERP:stä ei siis ole mahdollista nähdä ostolaskun rivejä. Tämän takia joutuu vaihtelemaan ikkunoita jatkuvasti tai vaihtoehtoisesti tulostamaan lasku paperille, jotta rivien selailu olisi helpompaa. ERP:stä näkee vain jo hyväksytyt rivit ja keikan viitteet. Tämän lisäksi esimerkiksi ylimääräiset kulut pitää tarkistaa TC-osaston keikalta, joka on erillinen ikkuna ostolaskujen ja pilvipalvelun lisäksi. Jos esimerkiksi lisäkulu on sovittu ja löytyy laskulta, pitää se vielä tarkistaa Excel-tiedostosta, jotta määrä on oikein. Tehottomuus on erittäin näkyvää, kun joutuu vaihtelemaan monen eri alustan välillä ja klikkauksia tulee tehtyä erittäin paljon enemmän, kuin mikä olisi tarpeen. 29 Kuva 4. Kuva ostolaskun kirjauksesta. Nykyinen ERP on vanha ja sitä ei kannata enää päivittää helppokäyttöisemmäksi ja joustavammaksi. Uuden ERP:n pitäisi mahdollistaa tarkistuksen alla olevien ostolaskujen näkymisen riveineen käyttäjälle samalla kun niitä tarkistetaan ja tällöin ei tarvitsisi erillistä pilvipalvelua näyttämään kuvaa laskusta. Pilvipalvelu käytöstä on päätetty konsernitasolla, joten siitä luopuminen voi olla hankalaa. Vaihtoehtona olisi pitää sitä käytössä uuden ERP:n ohessa arkistona, joissa on nähtävillä tarvittaessa ostolaskuja, mutta varsinaisen ostolaskun tarkistaminen tapahtuisi pelkästään ERP:ssä. Rivien näkyminen tarkistuksen yhteydessä mahdollistaisi automatiikan implementaation ostolaskujen tarkistamiseen. Jos ostolaskun rivi täsmää ennalta asetettuun hintaan tarjouksen pohjalta, ERP hyväksyisi automaattisesti rivin, ilman että sitä tarvitsee kirjata erikseen käsin. Hinnat, jotka eivät täsmäisi antaisivat hälytyksen tai muun huomion, jolloin laskun tarkastaja voi tarkistaa itse oikean hinnan ja korjata sen käsin. Pääyhteistyökumppanin ostolaskut voivat olla kymmeniä sivuja ja satoja rivejä pitkiä. Rivit, jotka ovat saman suuruiset kuin yrityksen hinnastosta löytyvät, tulisi automaattisesti tulla hyväksytyiksi, jolloin voisi säästää useita tunteja jo yhden ison laskun kanssa. Haastattelujen pohjalta on pääteltävissä, että tarkistusprosessissa on liian monta välivaihetta, jotta voi tarkistaa esimerkiksi jo kirjatun kulurivin keikalta. Tällöin pitää mennä TCpuolelle keikalle ja katsoa Arviot-osiosta kulurivin esikirjausnumero. Esikirjausnumero syötetään Ostolaskut-osioon, josta saadaan laskun numero, jonka avulla pilvipalvelusta saa laskun auki. Tarkistamista nopeuttaisi, jos keikan kuluriveistä saisi suoraan laskun auki käyttäjän tarkistamiseksi tai edes laskun numeron, jolla käyttäjä voi hakea laskun pilvipalvelusta. 30 6.1.3 Toimittajien erilaiset käytännöt Toimittajien suuresta määrästä johtuen myös erilaisia laskutuskäytäntöjä on monia. Yritys ei ole erikseen pyytänyt tietynlaisia laskuja toimittajilta tai alihankkijoilta muuten kuin viitteiden osalta. Laskussa on oltava aina keikkaviite vähintään, jotta kuluja voidaan kohdentaa oikein kirjanpitoa varten. Joskus laskuissa näkyy vain kontin numero, jolloin pitää tarkistaa päivämäärien avulla oikea keikkanumero ERP-järjestelmästä. Kun laskua tarkistetaan, on tärkeää pitää ERP:ssä keikan ikkunaa auki merkintöjen vuoksi ja jos toimittajan laskussa ei ole keikkaviitettä millään rivillä ja vain ainoastaan kontin rekisterinumero, hidastuu laskun tarkistaminen erittäin paljon, koska kontin rekisterinumeron perusteella pitää oikean rajanylityspäivämäärän perusteella hakea keikkaviite. Eri toimittajilla on myös eri maksuaikoja myönnettynä yritykselle ja ostoreskontran avoimista ostolaskuista pitää selailla lähestyviä tai menneitä eräpäiviä. Joskus laskun ilmestyessä avoimiin ostolaskuihin on eräpäivä voinut jo mennä. Tällöin lasku pitäisi heti tarkistaa, mutta tarkistamisen hitaus voi siirtää laskun tarkistamista, koska tarkistajalla voi olla jokin muu työtehtävä, joka vaatii sillä hetkellä huomiota. Laskun tarkistamisen jälkeen ostolaskun kierto vie oman aikansa. Olisi tärkeää saada toimittajilta lasku ajoissa, oikeilla viitteillä ja oikeilla riveillä, jotta ostolaskun kierrättäminen olisi mahdollisimman nopeaa. Jotkin kuljetusliikkeet tiedottavat purkuajoista huonommin kuin toiset. Jokainen kuljetusliike tiedottaa purkuajat, mutta siinä voi kestää tai ei anneta tarkkoja kellonaikoja ja vain kulunut aika tiedotetaan. Myöskin vaihteluita on muun muassa siinä millä alustalla kuljettaja tai kuljetusliike tiedottaa ajoista. Jotkut kuljettajat soittavat suoraan joko Account Managerille tai ajojärjestelijälle ja jotkut laittavat rahtikirjan sähköpostiin ja rahtikirjaan on merkitty purkamisen alkamisen ja loppumisen ajankohta sekä joskus tuotteen lämpö purkauksen aikana. Nämä sähköpostit tulevat yleensä sille henkilölle, joka on pyytänyt kuljetusta. Koska tietoja voi olla sähköpostissa, puhelimessa tekstiviestinä tai jonkun työntekijän pöydällä kirjattuna puhelimesta saadun tiedon perusteella, on erittäin aikaa vievää tarkistaa purkuaika, jos sitä ei ole merkitty keikalle. Jos kuljettajia ja kuljetusliikkeitä ohjeistettaisiin yhtenäistämään ilmoitustapansa esimerkiksi lähettämällä tiettyyn sähköpostiosoitteeseen rahtikirjan purku- tai lastausajoilla ja nimeämällä sähköpostin kontin rekisterinumerolla ja keikkaviitteellä, saisi tiedot helpommin tarkistettua osto- tai myynti- 31 laskun kirjaamisen aikana. Joillakin yksittäisillä kuljettajilla ei ole omaa sähköpostiosoitetta tai älypuhelinta, jolla voisi laittaa kuvan rahtikirjasta purkuaikoineen ja tämän vuoksi uutta ohjeistusta ei ole vielä tehty, vaikka hyöty olisi selvä. 6.2 Myyntilaskujen ongelmakohtia Ostolaskuihin verrattuna myyntilaskut ovat suoraviivaisempia, koska ne perustuvat yrityksen itse laskemiin ja antamiin tarjouksiin. Vaikka yrityksen ERP:hen on mahdollista lisätä kaikki myyntitarjoukset, pitää silti joitakin tarjouksia ja hinnastoja pitää Excel-tiedostoissa. ERP:n kankeus myyntilaskua luodessa on myös erittäin näkyvä ja automaation puuttuminen laskutuksessa on huomattava. Myyntilaskuissa saatavien saaminen yrityksen tilille on keskimäärin 30 päivää laskun lähettämisestä. Tankkikonttien nopeampi matka tilauksesta laskuun rahoittaa hitaampien ja rahallisesti suurempien projektikuljetusten ostolaskuja, joten on erittäin tärkeää, että kuljetukset laskutetaan mahdollisimman nopeasti ja kerralla oikein, jolloin asiakas maksaa laskun saatavat mahdollisimman nopeasti ja saatavat saadaan kiertoon. 6.2.1 Tarjoukset Tarjouksia löytyy ERP:stä ja Excel-tiedostoista riippuen asiakkaan tarpeista. Joillakin asiakkailla voi olla monta eri lastaus- ja/tai purkupaikkaa ja jokaiselle reititykselle on oma tarjouksensa, koska myös kulut ovat eri suuruisia eri reitityksille. Excel-tiedostoja käyttäviä asiakkaita on kuitenkin erittäin pieni osuus asiakkaiden kokonaismäärästä, mutta se voi hidastaa myyntilaskun kirjaamista, jos laskuttaja joutuu erikseen etsimään ja avaaman tietyn tiedoston yhtä laskua varten. Excel-tiedostojen käyttämisen voisi lopettaa, jos ERP-järjestelmästä saisi ulos helposti luettavan koosteen kaikista asiakkaiden tarjouksista. Kooste voi olla Excel-tiedosto tai ERP:n oma kooste, jonka voi lähettää asiakkaalle hyväksyttäväksi. Tarjouksia on erilaisia sen mukaan, miten ne on neuvoteltu asiakkaan kanssa. Esimerkiksi lisäkulut vaihtelevat asiakkaiden mukaan ja niiden laskuttamiseen pitää avata tarjous toiseen ikkunaan, kun asiakasta laskuttaa. Esimerkiksi päivien lukumäärän, joina tankkikontti odottaa satamassa ennen toimitusta, laskuttaminen vaihtelee tavaran vaarallisuuden mukaan ja myös asiakkaiden mukaan. Näiden yhtenäistäminen jokaiselle 32 asiakkaalle helpottaisi laskuttajaa tietämään ulkomuistista koska lisäkuluja asiakkaalle syntyy. Tarjouksissa lukee myös, että vapaata lastaus- ja purkuaikaa on asiakkaalle kaksi tuntia (ellei erikseen muuta ole sovittu) ja X€ per alkava tunti. Käytännössä kukaan ei kuitenkaan laskuta, jos purku- tai lastausaika ylittyy muutamalla minuutilla yli kahden tunnin, mutta tähän ei ole sovittuna selkeää ohjeistusta mikä määrä minuutteja on rajana ennen lisäkulujen laskuttamista. Jos tarjouksia ei noudateta kirjaimellisesti, olisi hyvä ohjeistaa kaikille samanlainen tapa katsoa lisäkulujen laskutusta. 6.2.2 Myyntilaskun järjestelmään kirjaamisen ongelmat Myyntilaskut kirjataan Invoice-osiossa ERP-järjestelmässä. Myyntilaskun kirjaamiseen tarvitaan myös erillinen ikkuna keikalle, jotta voi tarkastaa päivämääriä ja huomautuksia. Kun laskua alkaa kirjaamaan, antaa järjestelmä huomautuksen, jos keikalle ”laskutus”- osioon on kirjoitettu huomautuksia, mutta jos se on laitettu eri osioon tai vajailla tiedoilla, pitää laskuttajan tarkistaa se keikalta. Laskuttajalla ei myöskään ole mitään ohjetta mitä kuluja pitäisi laskuttaa keikalta ja tämä pitäisi itse tietää seuraamalla keikalta merkintöjä tankkikontin liikkeistä ja mitä kuluja se on kerännyt. Tämä luo riskin, ettei kaikkia kuluja muisteta veloittaa. Myöskin poikkeuksia on paljon eri kuluissa riippuen tankkikontin liikkumisista. Esimerkiksi tietyt laivayhtiöt maksavat itse tavaramaksun ja se sisältyy heidän rahtiinsa ja joissakin tapauksissa se pitää itse veloittaa asiakkaalta erikseen. Kun keikkaviite on syötetty voi valita huolintatarjouksen, joka antaa vaihtoehdoksi valita rahtikulun ja lisäkuluja. Tässä ei kuitenkaan näy mikä on rahdin hinta ja vaihtoehtoja voi olla useampi. Kuvassa viisi esitetään kuva tarjousperusteisesta taulukosta. Kuva 5. Kuva taulukosta, josta voi valita kuluja. Valitsemalla lisäkulun järjestelmä syöttää myös automaattisesti arvonlisäveron ja hintayksikön kululle. Hintayksikkö on väärä esimerkiksi polttoainekustannuksille, jolloin järjestelmä tarjoaa prosenttia, jota voisi käyttää, jos laskee polttoainekulua laivarahdin hinnan päälle. Virheitä tulee, jos ei huomaa rivin loppusummaa, joka voi olla 100€ sijasta 33 vain 1€, jos määräksi on valittu yksi. Myös arvonlisäveron automaattinen syöttö ei toimi ulkomaisille asiakkaille, koska järjestelmä ei tunnista ulkomaille sijoittuvaa asiakasta ja siten käänteistä verovelvollisuutta. Jos laskua hyväksyessään laskuttaja ei huomaa arvonlisäveroa riveiltä, asiakas joutuu pyytämään hyvityslaskua arvonlisäveron verran ja tähän joudutaan käyttämään työtunteja. Nykyisestä ERP-järjestelmästä siirryttäessä uuteen, tulisi uuden järjestelmän olla käytännöllisempi tietojen automaattisen syöttämisen kanssa esimerkiksi havaitsemalla onko asiakas ulkomailla. Myös mahdollinen muokkaaminen käyttäjän mieleiseksi olisi hyvä ominaisuus, jotta halutessaan voi käyttää polttoainekustannuksista prosenttiyksikköä tai kappalemäärää. Kun laskua syötetään riveittäin järjestelmään, ei järjestelmän ikkunasta näe juurikaan mitään tietoa keikalta. Olennaisia tietoja mitä laskuttajan pitäisi nähdä joka kerta olisi muun muassa tankkikontin koko, saapumis- ja toimituspäivä, mahdollinen laivaus pois, mahdollinen pesu ja esimerkiksi kytkentäpäivät. Tällä hetkellä kaiken näkee eri paikoista ja päivät joutuu laskemaan itse kalenteria katsomalla. Kaikki tämä altistaa sille, että kaikkia kuluja ei muisteta veloittaa tai veloitetaan väärin ja väärin veloittaminen johtaa myöhäisempään saatavien saamiseen. Pieni epäkäytännöllisyys, joka nostettiin esille myyntilaskujen kirjaamisessa, on kun myyntilasku on kirjattu ja lasku hyväksytään, sitä ei voi tulostaa suoraan, koska muuten lasku ei saa numeroa. Laskun tulostus pitää aloittaa ja keskeyttää, jotta lasku saa numeron ja sen jälkeen esikatselun kautta tulostaa uudelleen pdf-tiedostoksi niin että laskun numero on tullut laskulle. 6.2.3 Lisäkulujen saaminen laskutukseen Lisäkuluja syntyy monelle kuljetukselle väistämättä ja niiden laskutus on erittäin tärkeää, koska kulut koituvat muuten yritykselle, jos niitä ei laskuteta eteenpäin. Jotkin toimittajat ovat hitaampia kuin toiset lähettämään ostolaskuja esimerkiksi koontilaskutuksen vuoksi ja sen vuoksi myyntilaskun kirjaamista voi joutua odottamaan, jos asiakas haluaa kuljetuksen koko laskutuksen kerralla itselleen. Lisäkuluja syntyy muun muassa pesukuluista, jos pesuasemalla kontin pesemiseen on mennyt enemmän aikaa, kuin tarjouksessa on sovittu tai jos esimerkiksi pesuainetta on jouduttu käyttämään enemmän. Riippuen tarjouksessa olevasta hyväksyttyjen pesukulujen määrästä, joissakin kuljetuksissa voi olla 34 useastikin ylimääräisiä pesukuluja ja olisi ensisijaisen tärkeää saada ostolasku pesukuluista ennen laskuttamista. Jotkin pesuasemat kuitenkin lähettävät koontilaskun esimerkiksi kahden viikoin välein ja todellisia kuluja ei voi tietää sitä ennen. Yhteistyökumppani ei kerro tuontikonttien lastausaikaa oma-aloitteisesti. Kysyttäessä he lähettävät lastausajan tai sitten kun kontti on purettu ja purku sekä mahdollinen pesu on merkitty konttiseurantaan he lähettävät ”compliance advice”-tiedoston, jossa näkyy sekä lastausaika että purkuaika. Tämä voi tulla joskus sen jälkeen, kun laskutuksen voisi jo muuten tehdä. 35 7 KEHITYSEHDOTUKSET Tutkielman tavoitteena oli tehdä kehittämisehdotuksia logistiikka-alan yrityksen osto- ja myyntilaskujen kirjaus- ja tarkistusprosessien tehostamiseksi. Yrityksen nykyinen ERPjärjestelmä on tarkoitus vaihtaa lähitulevaisuudessa, joten kehittämisehdotukset suunnattiin uuden ERP-järjestelmän hankkimiseen. Tutkielman tarkoitus on siis olla tukena uuden toiminnanohjausjärjestelmän valitsemiselle ja kustomoinnille. Nykyisessä ERPjärjestelmässä on selkeitä puutteita osto- ja myyntilaskujen näkökulmasta ja yrityksen omat käytännöt ovat osin tehottomia sen vuoksi. Työn onnistumista on vaikea arvioida lyhyellä tähtäimellä. Kun uuden ERP-järjestelmän hankinta tulee yritykselle enemmän ajankohtaiseksi, voidaan arvioida tämän tutkielman onnistumista. Ehdotukset prosessien tehostamiseksi ovat kuitenkin konkreettisia ja pohjautuivat haastatteluihin sekä omiin kokemuksiin ja tämän myötä voidaan olettaa, että tutkimus on onnistunut havainnoimaan ongelmia ja ehdottanut niihin sopivia korjauksia. Mikä tekee yrityksen kirjaus- ja tarkistusprosesseista tehottomia? Yrityksen kirjaus- ja tarkistusprosessien tehottomuus johtuu selkeästi vanhan ja kankean ERP-järjestelmän tehottomuudesta osto- ja myyntilaskujen kirjauksissa ja tarkistamisissa. Koska ERP on vanha eikä sitä enää päivitetä, on jämähdetty vanhoihin tapoihin ja automaatio on erittäin alhaisella tasolla. ERP-järjestelmän kankeuden takia on käytössä useita muita alustoja, joiden tarkoitus on tukea ERP-järjestelmää, kuten Excel-hinnastot ja pilvipalvelu. Useiden alustojen ja ikkunoiden avaaminen laskuja varten on aikaa vievää ja niiden välillä selailu vie tehokkuutta prosesseista tarpeettoman paljon. Työntekijöiden eri tavat ja käytännöt eivät ole kaikilta osin yhtenäisiä, vaikka lopputulos on sama ja työntekijä löytää oman tapansa muiden ohjeiden ja oman kokemuksen perusteella sen sijaan, että olisi selkeä ohjenuora mitä noudattaa. Tämä itseoppiminen aiheuttaa tarpeetonta tehottomuutta. Miten yrityksen kirjaus- ja tarkistusprosesseja saisi tehostettua? Yrityksen kirjaus- ja tarkistusprosesseja saisi tehostettua selvästi poistamalla ylimääräisiä askeleita osto- ja myyntilaskujen ympäriltä. Päivittämällä uuteen ERP-järjestelmään voitaisiin luopua mahdollisesti kokonaan muista alustoista kuin ERP. Yhtenäistämällä alihankkijoiden käytäntöjä, yrityksen sisäisiä ohjeita ja käytäntöjä sekä sopimalla uusista käytännöistä yhteistyökumppanin kanssa saisi prosesseista tehokkaampia uuden ERP- 36 järjestelmän ohella. Prosessien virtaviivaistaminen, automatisointi ja useiden alustojen poistaminen ovat tärkeimpiä asioita uuden järjestelmän hankinnassa laskutuksen kannalta. Projekti uuden ERP-järjestelmän käyttöönottoon ei ole vielä alkanut ja sen takia on vielä mahdollista ja myöskin tärkeää tutkia mitä uudelta järjestelmältä vaaditaan verrattuna vanhaan järjestelmään. Jos ei ole mitään mitä uudelta järjestelmältä vaatisi, olisi vaihtaminen täysin turhaa rahan ja ajan kulutusta. Koska uuden järjestelmän implementointi vie aikaa ja käyttöönoton valmistuminen ei ole näkyvissä vielä lähitulevaisuudessa, on tärkeää, että nykyisiä prosesseja tehostettaisiin niin paljon kuin ilman ERP-järjestelmän muuttamista voi tai nykyinen ERP-järjestelmä antaa myöden ilman sen päivittämistä. Kuljettajien ja kuljetusliikkeiden kanssa yhteistyön yhtenäistäminen esimerkiksi purku- ja lastausaikojen ilmoittamisessa ja kuljettajien tuominen nykyaikaan älypuhelinten ja sähköpostien osalta olisi jo huomattava lisä tehokkuuteen, koska tällöin rahtikirjat ja purkuajat löytyisivät heti sähköpostista. Tutkielman liitteestä löytyy havainnollistava Excel-tiedosto hinnastosta, jota voisi tulevaisuudessa käyttää laskujen tarkistamisessa. Yhtenäisen Excel-tiedoston luominen ja ylläpitäminen vie kuitenkin työaikaa runsaasti, eikä sen täydelliseen yhteenkokoamiseen ja tarkistamiseen riitä aika yrityksessä tutkielman kirjoittamisen hetkellä. Kun yrityksessä löytyy parempi aika, on havainnollistava tiedosto jo valmiina, jotta on jokin mistä aloittaa tiedostojen yhtenäistäminen. Jos uuden ERP:n käyttöönotto kuitenkin sijoittuu lähitulevaisuuteen, ei yhtenäistä Excel-tiedostoa tarvita. Tällä hetkellä erityisesti myyntilaskun kirjaamisessa luotetaan todella paljon kirjaajan omaan muistiin, että kaikki mahdolliset veloitukset tulevat tehtyä. Edellistä keikkaa katsomalla saa osviittaa veloituksista, mutta ne voivat vaihdella eikä niihin voi sokeasti luottaa. Yleisimmille keikoille tarvitsisi pohjan, jossa olisi kaikki mahdolliset veloitusrivit ja näistä riveistä karsitaan pois ne, jotka eivät kuulu laskutettavalle keikalle. Nykyisellään kirjaaja kuluttaa paljon aikaa varmisteluun ja mahdollisten kulujen muistamiseen ja tämä kaikki ylimääräinen aika on mahdollista karsia pois, jos rivejä kirjattaessa näkyisi olennaiset tiedot keikalta ja olisi jokin pohja mistä keikkaa lähtisi veloittamaan. 37 8 YHTEENVETO Tutkimusmenetelmät olivat sopivat tähän tutkielmaan. Kvalitatiivinen luonne oli tarpeellinen, koska muita työntekijöitä haastattelemalla tuli paljon kokemuksien ja mielipiteiden kautta kipukohtia esille prosesseissa. Myös omat kokemukset uutena työntekijänä olivat tärkeitä, koska pidempiaikaisilla työntekijöillä ei välttämättä ole enää kunnollista käsitystä epäkohdista, koska niihin on totuttu. Konstruktiivinen tutkimusote oli sopiva tutkielmaan, koska tutkielmassa pyrittiin huomaamaan reaalimaailman ongelmia ja ratkaisemaan niitä niin, että siitä olisi yritykselle hyötyä. Tutkielmassa tuli selkeästi esille prosessien tehottomuuden syitä ja parannusehdotuksia uutta ERP-toiminnanohjausjärjestelmää varten sekä mahdollisia parannuksia, jos ERP:n hankinta viivästyy. Osa kehitysehdotuksista sopii myös uuden ERP:n rinnalle. Yleistettävyyttä on vaikea arvioida tälle tutkielmalle. Tutkielma keskittyi nimenomaan yhden yrityksen toimintaan ja sen prosesseihin, joten jotta tutkielma olisi käytettävissä toiseen yritykseen, tulisi kohdeyrityksen organisaatiorakenteen, toimintamallin ja tavan olla lähellä tämän tutkielman kohdeyritystä. Havainnot mitä laskutusprosesseista tehtiin voivat kuitenkin esiintyä muidenkin yrityksien laskutusprosesseissa ja tutkielmaa voi käyttää tukena silloin toisen yrityksen laskutusprosessien tutkimiseen ja parantamiseen.

question:Analysoitko tekstin? Laurea University of Applied Sciences Abstract Degree Programme in Business Information Technology Bachelor of Business Administration Aleksi Mutanen Integrations Development in ERP Projects Year 2021 Pages 42 The goal of this Bachelor’s thesis was to track and documentate the job and improvement of a beginner employee in Microsoft Dynamics 365 ERP projects. The purpose of the thesis was to improve the knowledge and know-how of the author in information technology business. The employer of this thesis was eCraft Ltd. The aim of this thesis was to find out the level of expertise and improvement of a recently graduated intern from eCraft’s training degree to improve their future trainings. The thesis was made as a diary model and it tells the crucial environments, technologies and working conventions of the job. Knowledge base to do this is from Microsoft’s, Atlassian’s and other system’s required technologies’ documentation. In eCraft’s software projects there are defined technologies and working conventions and they are strictly followed during the thesis. The result of the thesis is a documentation of the tracking period from beginner Software Developer’s improvement and how the developer has improved in using the crucial technologies required to do the job. The employer can read the thesis and get ideas on how to improve the company’s workflow. Also in the company’s future training programs the students can read the thesis to find out what to expect in software projects. Keywords: Azure, integrations, Dynamics 365 Sisällys 1 Johdanto................................................................................................ 6 2 Integraatiokehityksen keskeiset ympäristöt ja teknologiat ..................................... 6 2.1 Käsitteet....................................................................................... 6 2.2 Integraatiokehityksen erilaiset tehtävät................................................ 10 2.2.1 Integraatioputken suunnittelu .................................................... 10 2.2.2 Autentikoituminen eri järjestelmiin ............................................. 10 3 Nykytilanne........................................................................................... 10 3.1 Nykyinen työ ja osaaminen ............................................................... 11 3.2 Sidosryhmät................................................................................. 12 3.3 Vuorovaikutustaidot ....................................................................... 13 3.4 Kehittäminen ............................................................................... 13 3.5 Opinnäytetyön tavoitteet ................................................................. 13 4 Päiväkirjavaihe ...................................................................................... 14 4.1 Viikko 1 ...................................................................................... 14 4.2 Viikko 2 ...................................................................................... 16 4.3 Viikko 3 ...................................................................................... 20 4.4 Viikko 4 ...................................................................................... 23 4.5 Viikko 5 ...................................................................................... 26 4.6 Viikko 6 ...................................................................................... 28 4.7 Viikko 7 ...................................................................................... 30 4.8 Viikko 8 ...................................................................................... 32 4.9 Viikko 9 ...................................................................................... 34 4.10 Viikko 10..................................................................................... 36 5 Yhteenveto ........................................................................................... 37 5.1 Oman työn analysointi..................................................................... 38 5.2 Tulokset ja kehittämisehdotukset yritykselle .......................................... 38 Lähteet..................................................................................................... 39 Kuviot ...................................................................................................... 42 6 1 Johdanto Tämän päiväkirjamuotoisen opinnäytetyön tarkoituksena on seurata aloittelevan integraatiokehittäjän työskentelyä 10 viikon mittaisella aikajaksolla. Seuranta alkaa kolmen kuukauden työharjoitteluajan jälkeen, joista kaksi ensimmäistä oli työnantajan koulutusohjelmassa kouluttautumista. Harjoittelujakso jatkuu vielä koko seurannan ajan. Seurannan aikana viikon tulevat tapahtumat suunnitellaan ja asetetaan tavoitteet omaan kehittymiseen integraatiokehittäjänä sekä kartoitetaan tarvittava tietämys viikon aikana tuleviin tehtäviin. Päivittäin tehtävissä merkinnöissä kerrotaan työpäivän aikana tehdyistä tehtävistä ja niihin liittyvien ongelmien ratkaisuista sekä tarkastellaan oman osaamisen kehittymistä. Työn toimeksiantajana toimii eCraft Oy Ab, jonka työntekijänä suoritan kehitystyötä useammassa eri asiakasprojektissa. eCraft kuuluu kansainväliseen Fellowmind-konserniin. Yrityksen ydintoimintaan kuuluu mm. Microsoftin Dynamics 365–tuoteperhe. Yritys on jaettu eri liiketoimintalinjoihin ja Modern Work & Cloud Infrastructure -linjan alaisuudessa toimii Integrations & API -liiketoimintayksikkö, johon kuulun itse yhdeksän muun työntekijän lisäksi. 2 Integraatiokehityksen keskeiset ympäristöt ja teknologiat Työni menestyksekäs hoitaminen edellyttää integraatiokehitykseen liittyvien teknologioiden ja ympäristöjen tuntemista. Toimintaympäristöissä toimiminen vaatii työssä käytettävien käyttäjätilien pääsyn ympäristöjen resursseihin ja käytettäviin komponentteihin. Tietoturvasyistä jokaiselle käyttäjätilille ei anneta pääsyä järjestelmiin, vaan yksittäisille käyttäjätileille annetaan lupa tarpeen vaatiessa. Uuteen asiakasympäristöön saapuessa usein pyydetään projektin vanhemmalta työntekijältä pääsy esimerkiksi Azure-tilaukseen, jotta kyseisen projektin sisällä oleviin komponentteihin pääsee käsiksi. 2.1 Käsitteet Azure Azure on Microsoftin luoma pilvipalveluympäristö, jossa on saatavilla monia työssäni käytettäviä komponentteja ja ympäristöjä. Sen tuotevalikoimiin kuuluu esimerkiksi virtuaalipalvelimet, kehitysalustat ja tietokannat (Microsoft 2019a). Azure-portaalin ja sen sisällä olevien toiminnallisuuksien tunteminen ja osaaminen on tärkeä osa työtä. 7 Azuren sisällä on oma hierarkinen mallinsa käyttäjien ja resurssien hallintaan. Yrityksellä voi olla useampi tilaus, jonka sisällä on lisenssejä, joita annetaan käyttäjille, jotka ovat Active Directoryn sisällä olevassa haltijassa (Microsoft 2020a). Azure Logic App Azuren Logic Appit ovat keskeinen integraatiokomponentti integraatioiden toteutuksessa. Logic App on pilvessä oleva palvelusovellus, jolla voidaan luoda erilaisia työnkulkuja integraation aikana (Microsoft 2021d). Esimerkiksi Logic App voi ottaa vastaan HTTP-kutsun ja tehdä sen jälkeen erilaisia tehtäviä ja palauttaa HTTP-vastauksessa tehtävien tuloksen. Yleinen käyttötarkoitus Logic Appille on myös se, että se mahdollistaa integraatioiden suorituksien tarkistuksen. Azure Function App Azure Function App on Azuressa pyörivä pilvipalvelu, johon voidaan julkaista ohjelmistoja ajattelematta taustalla pyörivää palvelinpuolta ja näitä ohjelmistoja tai funktioita voidaan kutsua monella eri tavalla (Microsoft 2020c). eCraftilla yleisimmät käyttötapaukset ovat integraatioiden tekeminen järjestelmien välille ja API-rajapintojen luominen data-analytiikkaa varten. Azure Service Bus Azure Service Bus on Azureen tehtävä viestinvälitys komponentti, jolla voidaan vastaanottaa viestejä erilaisista järjestelmistä (Microsoft 2021e). Viestit syntyvät Service Busin alle luotavaan jonoon, josta muut applikaatiot voivat ottaa viestejä vastaan. Yleinen käyttökohde Service Busille on luoda lähdejärjestelmään tapahtuma, joka lähettää Service Busiin viestin tapahtumasta ja Logic App myöhemmin ottaa viestin vastaan ja tekee viestin sisällöstä riippuen erilaisia toimintoja. Visual Studio Visual Studio on Microsoftin kehitysympäristö ohjelmistokehitykseen ja toimii ohjelmakoodien tekstieditorina ja projektin- sekä ja versionhallinnan ohjelmana. Visual Studion uusin versio on 2019-malli, jossa on sisäänrakennettuja toiminnallisuuksia auttamaan kehitystyötä. Sen sisällä on toiminnallisuutta esimerkiksi versionhallintaan ja Azuren integraatiokomponenteille julkaisemiseen (Microsoft 2019c). Jälkimmäistä ei käytetä paljoa, koska monimutkaisien ympäristöjen julkaiseminen on huomattavasti helpompaa ja nopeampaa ARM-mallien avulla. Integraatioiden logiikassa käytettyyn ODataan on myös sisäänrakennettua konfiguraatiotoiminnallisuutta, mutta eCraft on luonut oman NuGet-paketin OData clientille, jonka implementoiminen ja käyttäminen projektissa on tehty erittäin helpoksi. 8 Visual Studiossa työskentelyyn liittyy aina projektihierarkia. Ylimpänä tasona on Visual Studioratkaisu, jonka alla on projektit yksittäisempää laajempaa kokonaisuutta varten (Microsoft 2020b). Esimerkiksi Azure-funktioiden projektiin ei sekoiteta SQL-tietokantaan liittyvää EntityFramework-kokonaisuutta vaan se luodaan omaan projektiin. CRM CRM eli customer relationship management on asiakkuudenhallintaan tehty järjestelmä, jossa luodaan esimerkiksi uusia käyttäjiä asiakkaille ja heille liittyviä tietoja (Microsoft 2019d). CRM:n sisällä on myös laajennuksia muuhun tarkoitukseen esimerkiksi Field Service. Järjestelmästä käytetään hyvin montaa eri nimeä työelämässä, mutta tässä työssä järjestelmästä käytetään nimeä Dynamics 365 CRM, jolla tarkoitetaan pilvessä olevaa järjestelmää. ERP ERP eli enterprise resource planning on toiminnanohjausjärjestelmä, joka on laaja järjestelmäkokonaisuus, jossa käsitellään yrityksen laskutusta, kirjanpitoa, tuotantoa, jakelua ja varastonhallintaa muuta vastaavaa yrityksen toimintaan liittyvää logiikkaa. Yksi Microsoftin tarjoamista ERP:stä kulkee nimellä Dynamics 365 Finance & Operations (Encore 2021.) Microsoft Dynamics AX on laajemmin tunnettu nimi, joka oli järjestelmän vanha nimi. Tässä työssä järjestelmästä käytetään nimeä Dynamics 365 ERP, jolla tarkoitetaan pilvessä olevaa järjestelmää. Dynamics 365 ERP:n ja integraatioiden ohjelmointikielet C# on Microsoftin kehittämä ohjelmointikieli, joka julkaistiin vuonna 2000. C# on olio-ohjelmointiin sopiva kieli ja se on laajamittaisessa käytössä integraatio-ohjelmista videopeleihin. Sen juuret tulevat C, C++ ja Javan syntakseista. (Microsoft 2021a.) X++ on Dynamics 365 ERP:ssä käytettävä ohjelmointikieli ja sen taustalla toimii MorphX-ohjelmointiympäristö. Kieltä käytetään aktiivisesti Dynamics 365 ERP:n Application Object Tree - hierarkian kanssa, josta löytyy järjestelmän kaikki käytettävät tietotyypit, taulujen kentät, taulut, järjestelmän entiteetit, lomakkeet ja muut vastaavat järjestelmän komponentit. (Microsoft 2015a.) X++-kielellä on paljon samanlaisia ominaisuuksia C#:n kanssa, mutta niiden käyttö kehitysympäristöissä on kuitenkin erilaista. Ohjelmistokehityksen ympäristöt Järjestelmäkokonaisuuksien kehitystyössä jatkuva testaaminen kehittäjien ja käyttäjien näkökulmasta on elintärkeää, mutta käyttäjiä ei kuitenkaan pitäisi päästää testaamaan vielä vaiheessa olevia ominaisuuksia (Codebots 2017). Siksi ohjelmistokehityksessä käytetään useita ympäristöjä kehityksen eri vaiheissa. Nämä ympäristöt tunnetaan eCraftilla usein nimillä DEV 9 eli development, UAT eli user acceptance testing ja PROD eli production. DEV-ympäristöä käytetään uusien ominaisuuksien kehittämiseen ja testaamiseen. UAT-ympäristössä asiakkaalle annetaan pääsy järjestelmään, jolloin loppukäyttäjät voivat testata ominaisuuksia. PROD-ympäristössä on valmis versio tuotteesta, joka on jo asiakkaan liiketoimintakäytössä. HTTP HTTP tai Hypertext Transfer Protocol on ohjelmakerros, joka on tarkoitettu dokumenttien ja tiedon välittämiseen verkkoselainten ja verkkopalvelinten välillä (Mozilla 2021). HTTP-kutsuihin liittyy monia eri osia riippuen käyttötapauksesta, mutta tärkeimmät ovat URI-merkkijono ja HTTP-metodi. Esimerkiksi verkkopalvelimien rajapintoihin voidaan käyttää mm. GET- ja POST-metodeja, joilla haetaan tai lisätään tietoa rajapinnan alla olevaan tietokantaan. OData OData tai Open Data Protocol on rajapintastandardi, jolla voidaan luoda REST-pohjaisia rajapintapalveluita (OData 2021). Vaikka OData luo HTTP-kutsuja, eCraft on luonut NuGet-paketin, jolla voidaan C#-ohjelmakoodin sisällä luoda rajapintakutsuja LINQ-kirjaston kanssa. Yleinen käyttökohde ODatalle on ottaa yhteys CRM- tai ERP-järjestelmän tietokantaan ja tehdä sillä kyselyitä tiedon hakemiseen, lisäämiseen tai muokkaamiseen. DevOps DevOps tai development and operations on toimintamalli ohjelmistokehityksessä, joka mahdollistaa monien kehitysprosessin automatisoinnin. DevOpsin kautta voidaan automatisoida ohjelmiston testaamisprosessi, käännösprosessi ja julkaisuprosessi. (Microsoft 2021b.) Käytännössä tämä tarkoittaa esimerkiksi sitä, että kun DevOpsiin konfiguroituun versionhallinnan repositorion haaraan tulee muutos, DevOps suorittaa ohjelman testauksen, käännöksen ja julkaisun kohdeympäristöön. Confluence Confluence on Atlassianin luoma yhteistyötila, jota voidaan käyttää esimerkiksi työyhteisön toimintamallien luontiin ja projektikohtaiseen- sekä graafiseen järjestelmädokumentaatioon (Atlassian 2020). eCraft käyttää Confluencea projektien ohjelmistojen suunnittelun dokumentointiin, joita asiakkaat ja muut projektin osalliset voivat tarkistella. Dokumentointi sisältää mm. kaavioita ohjelmiston toiminnasta tai ohjelmaluokkien kenttäkartoituksia. 10 2.2 Integraatiokehityksen erilaiset tehtävät Integraatiokehityksen aikana on myös tarve tietää kaikki erilaiset tehtävät ja mitä niiden suorittamiseen vaaditaan. Erilaisten ympäristöjen kanssa toimimiseen tarvitaan paljon pientä nuanssitietoa, esimerkiksi App Registeration, jolla voidaan käyttää vaikkapa CRM:n OData- rajapintaa Azure-funktioilla. 2.2.1 Integraatioputken suunnittelu Joissain projekteissa toimitaan vain Microsoftin tuotteiden parissa, jolloin eri järjestelmien tietorajapintojen kanssa toimiminen on tehty suhteellisen helpoksi. Kuitenkin hyvin usein integraatioissa toimitaan jonkun Microsoftin järjestelmän kanssa, joka integroidaan asiakkaan kolmannen osapuolen järjestelmän kanssa. Näissä tapauksissa on useita eri vaihtoehtoja, millä integraatio kehitetään, mutta myös joissain tapauksissa voi joutua käyttämään jotain tiettyä komponenttiputkea kolmannen osapuolen rajapinnan teknisen toteutuksen vuoksi. Esimerkiksi jos kolmannen osapuolen API on toteutettu SOAP:lla, niin joskus Logic App voi olla kykenemätön muuttamaan sen metadataa oikeaan muotoon. Logic App ei pysty tehdä XML pyyntöjä, joten SOAP-rajapinnat täytyy kääntää Custom Connectionilla sellaiseen muotoon, että niitä voi kutsua JSON-malleilla Logic Appin kautta. 2.2.2 Autentikoituminen eri järjestelmiin Tietoturvasyistä jokaiseen integroitavaan järjestelmään täytyy autentikoitua luvitetulla käyttäjällä, jottei projektikuplan ulkopuoliset pääse tietoihin käsiksi. Lisäksi integraatioputken komponentit ovat salattu joko Azuren autentikoinnin taakse tai funktioiden headerit vaativat autentikaation. Koko integraation sisällä olevien järjestelmien ja komponenttien yhteen liittäminen vaatii paljon työtä ja tietämystä niiden toiminnasta. Esimerkiksi Azure-funktion kautta Dynamics 365 ERP:n OData-rajapintaan autentikoituminen vaatii Azure-tilauksen alla olevasta Active Directory-haltijasta sen uniikin tunnisteen, Active Directory ohjelmarekisteröinnin ja sen salaisuuden, Dynamics 365 ERP:n pohja URL-osoitteen sekä sen API-kutsuja varten olevan aliosoitteen. 3 Nykytilanne Jokaisessa uudessa työssä on paljon opittavaa ja vähän aikaa oppia vaadittavat taidot. Tavoitteena on kasvaa mahdollisimman nopeasti työpaikan tuottavaksi jäseneksi, mutta täysin uutena ihmisenä IT-alalla tämä ei kuitenkaan ole mahdollista. Vertaistyöntekijöiden joukossa on ihmisiä, jotka ovat jo olleet IT-alalla töissä. Tästä huolimatta jokaisella on mennyt kauan 11 työhön vaadittavien taitojen omaksumisessa. Pelkkien työtapojen ja työn tekemiseen liittyvien järjestelmien opetteluun menee suuri määrä aikaa. Uutena työntekijänä uudella alalla suorittamisen paineet ovat kovat ja uusien haastavien tehtävien myötä virheitä sattuu joka päivä. Virheiden kautta oma osaaminen ja kokemus kuitenkin kehittyy joka päivä. 3.1 Nykyinen työ ja osaaminen Työtehtävät ja osaaminen Pääasiallinen työtehtäväni on toimia ohjelmistokehittäjänä asiakasprojekteissa ja tarkemmin sanottuna integraatioliittymien kehittäjänä. Konkreettisella tasolla työtehtävinäni projekteissa on Azure–pilvipalvelun integraatiokomponenttien luominen, konfiguroiminen ja muokkaaminen tiettyä tarkoitusta varten. Projektin oman osa-alueen vastuu on aina itsellä, mutta projektikokonaisuuden toiminnallisuudesta vastaa aina projektin vanhempi työntekijä. Työssä tarvitaan olio-ohjelmoinnin lisäksi tietämystä järjestelmien ja rajapintojen toiminnasta. Kuten missä tahansa ohjelmointityössä, jossa käsiteltävä ohjelma tai järjestelmä ei ole tuttu tai suoritettava työ ei ole rutiininomainen, vaaditaan pitkäjänteisyyttä ja kärsivällisyyttä toimintojen opettelussa. Työn opettelu on ollut haastavaa omalta osaltani, mutta onnistumisien kautta myös palkitsevaa. Oman osaamisen arviointi Näissä tehtävissä olen aloitteleva toimija. Työssä käytettävistä teknologioista ainoa tuttu suuri kokonaisuus on C#-kieli ja silläkään en ollut tehnyt mitään soveltavaa harjoittelua ennen työssä aloittamista. Koulutusjaksolla olevien harjoittelutehtävien aikana piti kysyä apua jokaisen komponentin tekemisen ohella. eCraftissa on kuitenkin yhteisöllinen kulttuuri, joten apua saa aina tarvittaessa. Pienempien projektien osa-alueiden korjauksia ja muunnoksia olen saanut suoritettua myös yksin. Kehittyminen Olen vielä lähtökuopissa, mutta kehittymisen merkkejä näkyy kuitenkin jo. Integraatiokomponenttien luominen ja niiden toiminnan ymmärtäminen on jo paremmalla tasolla, kuin työssä aloituksen aikana. Niiden luomisessa voi kuitenkin käyttää useampaa eri tapaa ja jokainen pitäisi osata. Jatkossa työn alla on ohjelmointitaidon parantaminen ja projektitöissä käytettävien järjestelmien osa-alueiden toiminnan kertausta. 12 3.2 Sidosryhmät eCraftilla työntekijällä on monia sidosryhmiä ja riippuen työntekijän asemasta niiden tärkeys vaihtelee (Kuvio 1). Kuvio 1 Sidosryhmät Työharjoittelijana suurimmat vaikuttavat sisäiset sidosryhmät ovat oman liiketoimintayksikön ja -linjan esimiehet, eCraftin muut työntekijät ja projekteissa olevat tiimit. Integraatiokehittäjän pitää olla tarvittaessa yhteistyössä integroitavien järjestelmien arkkitehtien tai vastaavien henkilöiden kanssa. Ilman selkeää kommunikaatiota pienienkin asioiden tekeminen voi muuttua työlääksi. eCraftin ja Fellowmindin johtoryhmät eivät vaikuta tällä hetkellä niin paljoa, koska työharjoittelijana keskityn enemmän oppimiseen ja koulutuksiin, kuin yrityksen johtoryhmän tekemisiin. Tulevaisuudessa tämä varmasti muuttuu, kun alkaa ajattelemaan korkeamman päätäntävallan tekemisiä enemmän. Ulkoisien sidosryhmien joukosta ainoa, joka ei ole työharjoittelijalle tärkeä on projektien mukana olevat yritykset. Tähän mennessä en ole ollut vielä tekemisissä muiden yrityksien kanssa, jotka ovat mukana samassa projektissa. Tämäkin varmasti muuttuu tulevaisuudessa, kun omien töiden vastuullisuus ja kokemus kasvaa. 13 3.3 Vuorovaikutustaidot Miltei poikkeuksetta työpäivän aikana saa olla kokouksessa projektiin liittyvän henkilöstön kanssa. Kokouksia voidaan pitää paikan päällä, mutta koronatilanteen vuoksi lähes kaikki kokoukset tähän mennessä on pidetty etänä. Kokouksissa käsitellään työn etenemiseen, käytettäviin järjestelmiin ja toimintatapoihin liittyviä asioita ja sen aikana kukin kertoo omasta näkökulmasta asioiden edistyminen tai käsitellään vaikeudet miksi asiat eivät edisty. Koska oma roolini työn alla olevissa projekteissa ei vielä vakiintunut ja tehtävät eivät ole rutiininomaisia, huomaan, että joskus on vaikea osallistua keskusteluun. Tilanteita on myös tullut eteen, jossa on täytynyt kyseenalaistaa vanhemman työntekijän teknistä suunnitelmaa. Työharjoittelijana kynnys tähän on kuitenkin korkea. 3.4 Kehittäminen Toistaiseksi en ole kehittänyt työtehtäviäni eteenpäin, koska jotta jotain voisi kehittää, täytyy ensin osata asia. Joidenkin toimintaprosessien kehittämisestä on ollut esimiehen kanssa puhetta. Esimerkiksi integraatiokomponenttien julkaisuprosessissa käytetty ARM-mallin osaalueiden luonnissa tarvittavia JSON-pätkiä voisi luoda johonkin käytettävään liittymään. 3.5 Opinnäytetyön tavoitteet Työn tavoitteena on kehittyä integraatiokehittäjänä ja saada syvempää ymmärrystä usein käytettyjen järjestelmien toiminnasta, esimerkiksi CRM ja ERP. Integraatioita voi tehdä myös tietämättä järjestelmien toimintaa, mutta se hidastaa ja vaikeuttaa kehittämistä huomattavasti, koska oikean tiedon hakeminen tai oikean avun saaminen voi kestää hyvinkin kauan. Opinnäytetyön seurantajakson aikana on tarkoitus toimia asiakasprojekteissa ja niiden sisältö vaihtelee Dynamics 365 ERP:n tehtävistä laajennoksista kolmannen osapuolen rajapintaintegraatioihin. Miltei jokaisessa projektissa on vanhempi työntekijä mukana ja opastamassa, mutta sellaisen puuttuessa apua on mahdollista saada myös projektitiimin ulkopuolelta. eCraftin tavoitteena on validoida omaa projektityöskentelyn muotoa ja tiimityöskentelyä. Aloittelevien kehittäjien tehokas ja onnistunut koulutus on elintärkeää uusia ja tulevia koulutusohjelmia ajatellen. Päiväkirjamuotoisella opinnäytetyöllä voidaan tarkastella projektityössä eteen tulevia ongelmia niin teknisistä kuin suunnitelmallisista näkökulmista ja täten saada tietoa ja ymmärrystä koulutusohjelmien kehittämiseen. 14 4 Päiväkirjavaihe 4.1 Viikko 1 Ensimmäisen viikon tavoitteena on saada Visual Studio -ratkaisu rakennettua tulevaa ulkoista palkkajärjestelmän integraatiota varten, ratkaista DevOps-putken ongelma ja saada käyttäjätili luvitettua asiakkaan Azure-tilaukseen toisen projektin osalta. Muissa projekteissa ongelmien sattuessa suoritetaan testejä ja tarvittaessa korjataan vikoja. Visual Studio -ratkaisun pystyyn saaminen on tärkeä alku projektissa, sillä se pitäisi saada luotua ja siirrettyä versionhallintaan, jotta muut projektin kehittäjät pääsevät siihen käsiksi ja itse kehittäminen voi alkaa. Maanantai 25.1 Päivän aikana on tavoitteena saada Visual Studio -ratkaisu tehtyä ensi viikolla alkavaa ulkoisen palkkajärjestelmän ja Dynamics 365 ERP:n välistä integraatiota varten ja siirtää se versionhallintaan. eCraftilla on valmis Visual Studio -ratkaisumalli, jossa on valmiina koottuna monia Integrations & API -liiketoimintayksikön luomia työkaluja erilaisia API-kutsuja ja virheenhallintaa varten sekä valmiita ARM-mallien kokonaisuuksia julkaisua varten. Tiistai 26.1 Päivän keskeisimpänä aiheena on saada kokeiltua joulukuussa aloitettua ulkoiseen tuntikirjausjärjestelmän rajapintaan tehtävää integraatiota. Integraation päätavoitteena on saada Dynamics 365 ERP:n projektinhallinnassa olevista projekteista luotua projektihierarkia tuntikirjausjärjestelmään (Kuvio 2). Kuvio 2: Dynamics 365 ERP - ja tuntikirjausjärjestelmien välinen integraatioputki 15 Dynamics 365 ERP:stä lähtee tieto tapahtumalla, joka laukaistaan aina, kun uusi projekti luodaan tai olemassa olevaa projektia muokataan ja projektin status on aloitettu tai valmis. Tapahtuma lähettää viestin viestijonoon ja viestin sisällä on projektille annettu tunniste, sekä yrityskohtainen tunniste. Logic App -suorituksen aikana viestin sisällöstä etsitään projektitunniste ja yritystunniste ja ne lähetetään Azure-funktiolle. Funktion sisällä validoidaan projektin olemassaolo ja sen jälkeen kutsutaan tuntikirjausjärjestelmän rajapintaa luodun projektiluokan sisällöllä. Keskiviikko 27.1 Päivän ongelmana on ollut etsiä vikaa YAML-ohjelmointikielellä kirjoitetusta DevOps-käännösputkesta. Samaa putkea käytetään projektin muissa osissa, joissa siitä ei tule vikaa, mutta jostain syystä tuntikirjausjärjestelmän integraation Visual Studio -projektin käännösputki ei mene läpi. Virhelokissa olevista viesteistä päätellen ongelma on käyttäjän autentikoinnissa. Tämän ongelman ratkaisuun tarvitaan kokeneempaa työntekijää, mutta kiireisen aikataulun vuoksi tämän ongelman ratkaisu siirtyy myöhempään ajankohtaan. Torstai 28.1 Päivän aiheena on testata Dynamics 365 ERP - ja tuntikirjausjärjestelmän välisen integraatioputken koko toimintaa. Koska DevOps-käännösputken kanssa on ollut ongelmia, myöskään julkaisuputkea ei ole vielä voitu käyttää. Tämä tarkoittaa sitä, että Azure-funktio täytyy luoda manuaalisesti ja julkaista funktion sisältö manuaalisesti Visual Studio -projektin sisäänrakennetulla työkalulla. Service Bus -viestijono ja siihen liittyvät yhteydet sekä Logic App luodaan manuaalisesti asiakkaan Azure-ympäristössä. Testaus meni hyvin integraatioputken toiminnan suhteen, mutta uusia kysymyksiä heräsi liittyen integraation suunnitteluun. Tuntikirjausjärjestelmässä projektien hierarkian luonti onnistuu, mutta projektin alla olevat tehtävät eivät siirry projektien lapsiksi. Suunnitelman mukaisesti tekemällä hierarkian luonti ei siis onnistu, joten täytyy kysyä projektin johdolta lupaa ja mahdollisesti myös ohjeita tarvittavien muutoksien tekemiseen, sillä siitä syntyy hyväksymättömiä lisätöitä. Perjantai 29.1 Päivän aiheena on jatkaa tuntikirjausjärjestelmän integraation testausta. Suurempien projektihierarkioiden luonnissa huomattiin, että Logic App-Service Bus välisessä laukaisimessa on suuri rajoittava pullonkaula. Nykyisellään Logic App tarkistaa annetun aikavälein viestijonosta saapuneita viestejä ja tässä tapauksessa aikaväli on kolmen minuuttia. Ongelma syntyy siinä, kun Dynamics 365 ERP -testiympäristössä luodaan kolme projektia yhden minuutin aikana, integraatioputkella menee mahdollisesti jopa yhdeksän minuuttia suorittaa näiden muutoksien 16 tekeminen tuntikirjausjärjestelmän rajapintaan. Tämä ratkaistiin muuttamalla Logic App laukaisin yhden viestin tarkistusmuodosta viestierän tarkistukseen. Viikko 1 yhteenveto Yksi viikon aikana tehtävistä töistä oli Visual Studio -ratkaisun perustaminen, mutta sen tekeminen siirrettiin lopulta vanhemmalle työntekijälle. Visual Studio -ratkaisujen rakenne on kuitenkin tärkeä tieto, joten sen tutkiminen on hyödyllistä kertausta. Projektien alkupuolella tehdyt integraatiosuunnitelmat ovat joskus suuntaa antavia ja yleensä vasta testausvaiheessa selviää ongelmia, jotka johtuvat suunnitelman puutteista tai virheistä. Näissä tapauksissa herää oma ongelma siitä, että ehdottaako suoraan toimivaa muutosta suunnitelmaan vai antaako vastuun tarvittavasta muutoksesta suoraan vastuuta kantavalle taholle. Asia täytyy kuitenkin ainakin jollain tavalla nostaa projektijohdon tietoisuuteen, että ongelmaa voidaan alkaa selvittää joko tiimin voimin tai saada ulkopuolista apua. Hyvin suunniteltu ohjelmisto on jo puoliksi tehty ja tällä tavoin säästetään työtunteja. Tarkistamalla huolellisesti kaikki ohjelmistossa käytettävien rajapintojen palauttamat sanomat tulevilta ongelmanratkaisuilta todennäköisesti säästytään. Puutteellisella suunnittelulla tiimi käyttää resursseja ongelmien ratkaisuun ja tarkistamalla kohdejärjestelmän rajoitteita suunnittelun aikana virhe olisi huomattu jo ennen työn aloittamista (Hyperext 2017.) Ohjelmistoprojektien suunnitteluun kuuluu monta eri osaa, joita yleensä hoitaa projektipäällikkö ja arkkitehdit. Ylimpänä on projektin ”scope” eli mitä kaikkea projektissa tarvitsee saada tehtyä. Scopen määrittely on erittäin tärkeää ohjelmistoa toimittavan yrityksen kannalta, koska sopimus tehdään sovituista töistä ja työmääristä, jolloin sopimuksen ulkopuoliset työt määritellään muutoksina eikä korjauksina. Tästä lisää myöhemmillä viikoilla. Scopen alla on työmäärä- ja muut kustannusarviot sekä kehitykseen tarvittava aikataulu (javatpoint 2021.) Projektien tai sen osa-alueiden suunnittelu ei kuulu työharjoittelijalle, mutta tulevaisuutta ajatellen on kuitenkin tärkeää kyetä arvioimaan jonkin työn resurssivaatimuksia. Integraatioiden osa-alueilla on oma työmääräarvio tehtäväkohtaisesti. Työmääräarviot ovat vain arvioita, mutta sovitun budjetin ylittyessä lisäbudjettia on paljon vaikeampi saada. 4.2 Viikko 2 Viikon aikana on tarkoitus aloittaa ulkoisen palkkajärjestelmän ja Dynamics 365 ERP:n välisen integraation tekeminen. Tavoitteena on saada liittymää aloitettua sekä saada ymmärrystä kirjanpidon logiikasta yleisesti ja Dynamics 365 ERP:n General Ledgerin toiminnasta. 17 Maanantai 1.2 Integraation toisena osapuolena on palkkajärjestelmä, jota käytetään laajasti palkanlaskentaan, henkilöstöhallintoon ja raportointiin. Tässä projektissa on tarve integroida palkkajärjestelmästä tulevien kulutiedostojen sisältö Dynamics 365 ERP:n General Ledger -kirjanpitotietokantaan (Kuvio 3). Kuvio 3: Dynamics 365 ERP - ja palkkajärjestelmien välinen integraatioputki Palkkajärjestelmästä tiedostot liikkuvat asiakkaan tiedostoserverille SFTP-yhteyden kautta ja integraatioputki ottaa yhteyden paikalliseen tietokäytävään palveluliitännällä. Tästä seuraava osa on Logic App, joka toimii ajastetusti joka yö. Logic App saa palveluliitännällä yhteyden käsiteltävään tiedostoon ja antaa sen sisällön HTTP-kutsun rungossa Azure-funktiolle. Azurefunktion sisällä tiedoston sisältö puretaan ja käännetään oikeaan muotoon, josta se lopulta lähetetään Dynamics 365 ERP:n General Ledger -rajapintaan. Integraatiossa oleva palkkajärjestelmä on laajasti käytetty järjestelmä, joten osaamisesta siihen integroitumiseen on suurta hyötyä. Tällä hetkellä olen osallisena kolmessa projektissa, jossa tehdään samanlainen integraatio. 18 Tiistai 2.2 Päivän tavoitteena on saada viimeiset muutokset palkkajärjestelmän integraatioon ennen UAT-julkaisua. Tähän sisältyy Business Event -tapahtumien luonti Dynamics 365 ERP UAT -ympäristöön ja niihin tarvittavat Service Bus -päätepisteet. Asiakkaan Azure-tilauksen UAT-resurssiryhmään luodaan uusi Service Bus, jotta eri ympäristöjen viestit eivät mene sekaisin. Tietoturvaoikeudet ovat kriittisiä isommissa ohjelmistoprojekteissa ja tuntikirjausjärjestelmän integraatiota tehdessä olen saanut parempaa ymmärrystä Azuren käytöstä ja erilaisten pääsyoikeuksien luonnissa. Muissa projekteissa tarvitaan täysin samanlaista tietämystä, joten Dynamics 365 ERP:n Business Eventien teosta on suuri hyöty. Keskiviikko 3.2 Päivän aikana tuli aikaisemman projektin jo toteutetun integraatioliittymän suunnitelmaan muutos. Integraation alkupää on Dynamics 365 CRM-järjestelmä, joka on tässä tapauksessa laajennettu XRM:ksi, koska järjestelmässä on käyttäjätileissä asiakkaiden lisäksi myös toimittajien ja muiden yhteyshenkilöiden tietoja. Integraation pää on Dynamics 365 ERP –järjestelmä. Dynamics 365 CRM:n puolella tapahtuvasta muutoksesta käyttäjätietojen taulun tietueeseen laukaistaan tapahtumaketju, jonka tavoitteena on kopioida tapahtuman juuri tehty muutos Dynamics 365 ERP:n puolella oleviin tauluihin tai vaihtoehtoisesti luoda uusia tietueita tauluihin (Kuvio 4). Kuvio 4: Dynamics 365 CRM - ja Dynamics 365 ERP -järjestelmien välinen integraatioputki Kesken projektin tehtävät muutokset eivät ole mitenkään harvinaisia. Tässä tapauksessa asiakas huomasi, että kutakin osoitetyyppiä voidaan tarvita useampi per asiakas. Dynamics 365 ERP:n entiteetit eivät tue tätä toimintoa, joten tässä tilanteessa muutos oli tarpeellinen. 19 Torstai 4.2 Päivän aiheena oli jatkaa käyttäjätili-integraation muutosta. Miltei poikkeuksetta projektin vastaavat järjestelmäarkkitehdit ovat tehneet valmiin Confluence-dokumentaation muutoksen suunnitelmasta, mikä auttaa kehittäjän työtä suuresti. Tästä huolimatta täytyi kysyä pari kertaa Dynamics 365 CRM-arkkitehdilta tunnisteisiin liittyviä kysymyksiä Dynamics 365 ERP:n automaattisen tunnisteluomisen vuoksi. Ilman dokumentaatiota työ olisi edistynyt huomattavasti hitaammin. Palaan tähän aiheeseen myöhemmin seurantajakson aikana. Perjantai 5.2 Päivän tavoitteena oli saada palkkajärjestelmän integraatioliittymä hyvään vaiheeseen, minkä jälkeen alkoi tilannekatsaus vanhemman projektijäsenen kanssa. Liittymän yksikkötestit menivät läpi sekä General Ledger-rajapintakartoitus tuotti viestit oikeassa muodossa. Visual Studio-projektin kansioista piti vain siirtää ja poistaa tarpeetonta tai sinne kuulumatonta sisältöä. Seuraava askel on tehdä koodikatselmointipyyntö, jotta ohjelmakoodi voidaan tarkistaa ja viedä projektin integraatiokokonaisuuden versionhallintaan. eCraftin versionhallintakäytäntöjen mukaan kaikki tehty ohjelmakoodi täytyy katselmoittaa ennen versionhallintaan siirtämistä. Joskus työpäivän aikana voi ilmetä pieniä töitä, joita esimies tai projektin vanhempi työntekijä antaa nuoremmalle työntekijälle. Tänään sain iltapäivällä tehtäväksi luoda uuden Logic Appin samaan projektiin, jossa olen tehnyt Dynamics 365 CRM-Dynamics 365 ERP käyttäjäintegraatiota. Tapauksessa on tarve saada haettua General Ledger-rajapinnasta tämän kuun ja viime kuun kirjaukset. Logic App palauttaa HTTP-vastauksen rungossa rajapinnan palauttamat datat. Viimeisestely täytyy jättää ensi viikolle, koska en saanut tehtävän antajalta vielä tietoa, että missä muodossa data täytyy palauttaa. Viikko 2 yhteenveto Viikon aikana on ollut työskentelyä kolmessa eri projektissa ja näin toivoisin asioiden olevan myös jatkossa. Erilaisissa projekteissa mukana olemisella kertyy aina uutta osaamista ja kokemusta erilaisista tarpeista. Ongelmia on syntynyt pienistä puutteista yhden integraation suunnitelmassa, mutta yhtä lailla myös omasta toiminnasta. Ottamalla ongelmat heti käsittelyyn joko omassa työssä tai projektiryhmän työhön liittyvissä ongelmissa niistä selvitään jollain ratkaisulla. Koodikatselmointi joskus tuntuu prosessia hidastavalta toimenpiteeltä, mutta se on kuitenkin erittäin tärkeä oman oppimisen ja projektin toiminnan suhteen. Työtä tehdessä virheitä tulee tehtyä huomaamattaan, mutta katselmoinnissa virheet tai vaihtoehtoiset tavat tehdä asioita tulevat ilmi ja niistä oppii. Gitflow-mallinen versionhallinta on ollut hyvä tapa toimia ainakin 20 tähän mennessä, mutta sen rajoitteena on ylimääräinen työ ja ajan käyttö (Gadzinowski 2021). Tästä lisää myöhemmin. Koodikatselmointien tekeminen on tärkeää, koska hyvin usein omassa katselmointipyynnössä on sisältöä, jonka ei pitäisi olla siellä. Joskus Visual Studio -projektihierarkiassa on kymmeniä tiedostoja ja niiden muutoshistoriaa on melkein mahdotonta muistaa itse. Katselmoinnilla annat työsi tuloksen muille tarkistettavaksi, jotta työn laatu on parempi ja että potentiaalisilta virheiltä vältytään (Larsen 2018). Lisäksi muiden ehdotuksilla on helppo oppia uusia tapoja ja tekniikoita tehdä asioita. Katselmointien tekeminen on hidasta, mutta varmasti muodostumassa jokapäiväiseen työhön. En ole vielä oppinut tarkistamaan muiden tekemiä katselmointeja, mutta todennäköisesti niitäkin pääsee tekemään lähitulevaisuudessa. Olisi hyvä, jos jossain vaiheessa ehtisi käyttää aikaa työharjoittelijatovereiden kanssa muiden tekemien ratkaisujen tarkistukseen. Tällä tavalla olisi hyvä jakaa osaamista ja mahdollisia yleisiä kompastuskiviä tiettyjen liittymien toteutuksessa. 4.3 Viikko 3 Viikon tavoitteena on saada viime perjantaina aloitettu Logic App viimeisteltyä, jatkaa palkkajärjestelmän integraatiota ja mahdollisesti saada myös käyttäjäintegraatio valmiiksi. Palkkajärjestelmä- ja käyttäjäintegraatioissa tarvitsen tietoa ohjelman suunnittelijalta yksityiskohdista. Palkkajärjestelmän integraatiota on testattu yksikkötesteillä, muttei vielä oikealla General Ledger -rajapinnalla. Käyttäjäintegraatiota on kokeiltu omassa ympäristössä ja todettu sen toimivan, mutta yleensä pieniä virheitä ei huomaa tässä vaiheessa työtä. Maanantai 8.2 Päivä alkoi viime perjantaisen General Ledger -rajapinnan Logic App -haun palautusmuodon luomisella. Aluksi olin luonut palautusmuodon, jossa oli eriteltynä listoissa tämän kuun ja viime kuun merkinnät. Tarkoitus oli kuitenkin saada molempien kuiden merkinnät samaan listaan ja palauttaa lista sellaisenaan. Päivän aikana sain tehtyä integraatiopuolen koodikatselmoinnin tuntikirjausjärjestelmän integraatioon. Vanhemman kehittäjän pieniä muutosehdotuksia lukuun ottamatta Visual Studio -projektit olivat hyvällä tasolla. Aloitin myös koodikatselmoinnin palkkajärjestelmän integraatiossa. Suurimpana työnä oli tänään virheen selvitys käyttäjäintegraatiossa. Mielestäni integraatiossa kulkevat viestit olivat oikein, eikä virhettä olisi pitänyt sattua. Sain esimieheltä hyviä ohjeita virheiden selvittämiseen, jotka eivät aluksi toimineet. Sain myöhemmin lisätietoa sellaisista 21 Visual Studion virheenjäljittäjän toiminnoista, joiden olemassaolosta en tiennyt. Ongelman syy ei ole vielä selvinnyt. Tiistai 9.2 Päivän tavoitteena on saada palkka- ja tuntikirjausjärjestelmien integraatioiden koodikatselmoinnit läpi sekä jatkaa käyttäjäintegraation testausta. Tuntikirjausjärjestelmän integraatio on menossa tauolle ja on tärkeää saada ohjelmakoodit versionhallintaan, jotta ne ovat muiden käytettävissä tarpeen vaatiessa. Palkkajärjestelmän integraatiossa koodikatselmoinnin jälkeen on tarkoitus siirtyä testaamaan General Ledger -rajapintakutsua, mutta tämä voi vaatia vielä muun projektitiimin työn edistymistä. Päivä alkoi jatkamalla kahden viikon takaista DevOps-käännösputken ongelmanratkaisua. Kokeneemman työntekijän kanssa saimme muutettua käännösputken logiikkaa, mutta oikea ongelman syy ei selvinnyt. Koska tuntikirjausjärjestelmän integraatio on menossa tauolle, kyseisen ongelman selvitys jää myöhemmälle ajalle. Tuntikirjausjärjestelmän integraation koodikatselmointi meni myös läpi, joten tässä vaiheessa on hyvä siirtää se tauolle. Suurin osa päivästä meni käyttäjäintegraation ongelmanselvitykseen. Perusteellisen selvityksen jälkeenkin ongelma oli suuri mysteeri myös kokeneille työntekijöille. Ongelma ratkesi sillä, että entiteetti luodaan aina uudestaan vakioarvojen asetuksen yhteydessä ja korvataan vanha uudella. Keskiviikko 10.2 Sain kolme viikkoa sitten tehtävän olla kahden tuotantoon menneen integraation valvojana, koska integraation kehittäjä lähti kahden viikon lomalle. Viime yönä sain viestin Azure-tilauksesta, että integraatiossa on tapahtunut virhe, joten tehtävänä on tarkistaa virhe ja yrittää selvittää mitä on tapahtunut ja miksi. Koska itselläni ei ole pääsyä asiakkaan Azure-tilaukseen, ehdotin projektitiimin jäsenelle Logic Appin manuaalista uudelleenajamista Azuren puolelta. Uudelleenajamisella voidaan tarkistaa, onko ongelma toistuva. Palkkajärjestelmän integraation koodikatselmointi meni läpi, mutta käyttäjäintegraation ongelmanratkaisuun meni koko päivä. Eilen saatu ratkaisu ongelmaan ei ollutkaan niin hyvä. Ongelmaa voidaan kiertää luomalla aina uusi entiteetti samoilla tiedoilla, joilla vanha entiteetti on jo olemassa tietokannassa. Tämä ei ole oikeanlainen ratkaisu ongelmaan, mutta muita ratkaisuja ei ole tiedossa. Torstai 11.2 Eilen tarkistin tuotantoon menneen integraation virhettä ja ehdotin Logic Appin manuaalisesti uudelleenajamista. Koska integraatio on asetettu ajettavaksi automaattisesti joka yö, jos 22 jokin virhe on toistuva sen pitäisi toistua joka yö, mutta koska viime yönä ei ole sattunut virheitä todennäköisesti oikeaa ongelmaa ei ole ollutkaan. Tehtävän päivystysvuoro päättyy tällä viikolla. Sain päivällä myös uuden tehtävän. Tehtävänä oli selvittää Azuren UAT-ympäristössä epäonnistuneita suorituksia. Ongelma ei ratkennut iltapäivän aikana ja jatkan sen parissa huomenna. Perjantai 12.2 Päivän tavoitteena on jatkaa tuoteintegraation ongelman selvitystä ja saada tietoa käyttäjäintegraation osoitemuutoksen jatkokehityssuunnasta. Muutos toimii testien mukaan tällä hetkellä halutulla tavalla, mutta ratkaisu ei ole ideaali duplikaattien takia. Nykyinen versio on kahdella vanhemmalla työntekijällä tarkistettavana ja testattavana. Tein käyttäjäintegraation osoitemuutoksesta koodikatselmoinnin ja se hyväksyttiin. Siitä tehdään julkaisu UAT-ympäristöön jonkin ajan päästä ja laajemmassa testauksessa selviää, löytyykö jotain rajoituksia nykyisestä toteutuksesta. Tuntikirjausjärjestelmän integraatiossa tehtiin viimeiset julkaisut UAT-ympäristöön ennen projektin keskeyttämistä, jotta integraation toimivuutta voidaan testata tarvittaessa. Viikko 3 yhteenveto Viikon aikana tuli vastaan käyttäjäintegraatiossa pieniä ongelmia, jotka eivät lopuksi olleet niin pieniä. Pienienkin ongelmien ratkaisussa voi mennä hyvinkin pitkä aika ja joskus oikeaa ratkaisua ei löydy ikinä. Tällaisissa tapauksissa nuorella työntekijällä tulee mieleen oman työn tehokkuus ja sen suhtauttaminen tehtävän arvioituun työmäärään. Arvioituihin työmääriin olisi tarkoitus aina päästä, mutta tosielämässä uusien ongelmien vastaan tullessa nämä usein eivät kuitenkaan toteudu. Koodikatselmointiprosessit tuntuvat joskus aikaa vieviltä, mutta nuorempana työntekijänä niiden tuottama uusi tieto on kuitenkin korvaamatonta. Usein katselmoinneissa kiinnitetään huomiota myös koodin ulkoasuun eikä vain sen sisältöön. Ominaisuuksien kommentointi ja yhteneväinen tyyli ovat yksiä huomioitavia asioita, vaikkei ”oikeaa” tyyliä ole olemassa. Vanhemman työntekijän kokemuksella kuitenkin on arvoa ja juuri aloittanutta työntekijää ohjataan tähän suuntaan. Katselmoinneissa saat palautetta tekemästä työstä ja usein se ei ole pelkkää kehua. Aloittelijana täytyy osata ottaa kritiikki vastaan. Kritiikkiä tulee siksi, että virheistä opitaan (Coutermarsh 2015.) eCraftin koodikäytännöt pyörivät yleisien käytäntöjen ja Microsoftin käytäntöjen ympärillä. Erityisen tärkeänä asiana pidetään ohjelmiston refaktorointia eli ohjelmiston toiminnallisuuden eriyttämistä eri osiin, jotta sitä on helpompi muokata ja ymmärtää (Microsoft 2018). 23 Ohjelmakoodin kommentointi on yksi yksinkertaisimmista ja samalla tärkeimmistä tehtävistä asioista. Se on pääasiallisesti tarkoitettu muita ihmisiä varten, jotka lukevat tehtyä ohjelmakoodia. Se on myös tärkeää kehittäjän kannalta tapauksissa, jossa kehittäjä käyttää vuosia sitten tehtyä ratkaisua muussa projektissa, jossa tarvitaan samanlaista ratkaisua. Monimutkaisempia asioita ovat esimerkiksi toimiva ja kattava virheenhallinta ja palautusmuodot httpkutsuihin liittyvissä luokissa. Yksinkertaisempia asioita on muuttujien, metodien ja luokkien oikeanlainen nimeäminen ja ohjelmakooditiedoston rakenne (Microsoft 2015b.) Koodikäytäntöjen perusasiat ovat minulla hyvin hallussa, mutta siitä huolimatta luokkien ja metodien kunnollinen dokumentointi ja kommentointi jäävät usein tekemättä. Syynä on yleensä joko kehittämiseen ja testaamiseen keskittyminen tai budjetin puute. Edellä mainitut asiat ovat erittäin tärkeitä tilanteessa, jossa projekti menee tuotantoon ja esimerkiksi vuoden päästä löytyy jokin ongelma. Sen ratkaisu voidaan antaa jollekin muulle tehtäväksi ja kyseisen henkilön täytyy lukea ohjelmakoodia ymmärtääkseen liittymän toimintaa. Luokkien ja metodien dokumentointi ja kommentointi tekevät tämän henkilön työstä huomattavasti tehokkaampaa. 4.4 Viikko 4 Viikon alussa tulevien töiden määrä ja muoto ei ole vielä tiedossa, koska monet työt ovat testauksessa tai odottavat muiden työntekijöiden työn edistymistä. Pienempiä töitä löytyy usein nopeasti, mutta ne eivät yleensä kestä kovinkaan pitkään. Maanantai 15.2 Maanantaina on tarkoitus tehdä osa päivästä Azure Developer Associate -sertifikaattia ja loppupäivä uusia integraatioita uuden projektin parissa. Integraatio vaikuttaa hieman monimutkaisemmalta, kuin aikaisemmat tekemäni integraatiot sekä tarkoitus ja kohde ovat täysin uusia (Kuvio 5). 24 Kuvio 5: Dynamics 365 FS - ja asiakkaan työtilausjärjestelmien välinen integraatioputki Uudessa projektissa on tarve saada työtilaukset integroitua asiakkaan järjestelmästä Dynamics 365 CRM:n sisällä olevaan Field Serviceen. Tapauksesta tekee monimutkaisen se, että työtilauksien status voi muuttua kummassa tahansa järjestelmässä, joten nämä muutokset täytyy myös integroida, jotta molemmissa järjestelmissä on ajantasainen tieto tilauksesta. Tiistai 16.2 Päivän aikana jatkoin eilen aloitettua työtilausintegraatiota. Ainoa kompastuskivi oli se, että työtilausjärjestelmästä tulevan tiedoston sisältöä ei voi kääntää suoraan C#-kielen luokaksi, vaan tiedostosta täytyy kartoittaa jokainen kenttä yksitellen. Keskiviikko 17.2 Päivän aikana pidimme ensimmäisen kokouksen työtilausintegraatiossa olevan tiimin kanssa. Sain hieman paremmin tietoa tehtävän integraation kokonaisuudesta integraatioarkkitehdilta ja projektin CRM-arkkitehdilta kartoitustaulukon Field Servicen työtilausta ja sen relaatioita varten. Confluenceen tehtyjen kartoitustaulukoiden avulla työtilauksien luominen OData-rajapinnalla on huomattavasti helpompaa. Oikeat kentät voi toki päätellä itsekin, mutta 25 integraation ollessa vasta alussa ei ole järkevää lähteä arvailemaan oikeita kenttiä. Testauksessa yleensä löytyy ongelmat, jos niitä on. Torstai 18.2 Tärkeimpänä aiheena tänään oli kehityskeskustelu esimiehen kanssa. Kävimme läpi nykyistä osaamistilannetta viime joulukuun jälkeisestä hetkestä. Hyvää kehitystä on tapahtunut, mutta opittavaa on kuitenkin vielä paljon. Tarkistimme myös työn teknisen osaamisen ulkopuolella olevia asioita, esimerkiksi työskentelymotivaatiota, työn merkityksellisyyttä ja tiimityöskentelyä. Kehityskeskustelun parhaana antina oli tulevaisuutta varten olevat keinot kehitystä varten. Esimiehen mielestä nykyinen osaaminen on jo sellaisella tasolla, ettei tarvitse lähteä kertaamaan mitään työtehtäviä erikseen. Työssä vastaan tulevat tehtävät riittävät tällä hetkellä oppimiseen. Koulusta valmistumisen jälkeen olisi tavoitteena saada vuoden aikana suoritettua Azure Developer Associate -sertifikaatti sekä pitää työmääristä päiväkirjaa jonain ajanjaksona. Päiväkirjamerkinnät ovat tärkeä oppimisen osa-alue työarvioiden ja suunnitelmien tekemiseen. Perjantai 19.2 Päivän aikana pidettiin kaksi tärkeää kokousta työtilausintegraation osalta. Ensimmäisessä esimies kertoi työprosessin, joka tarvitaan Dynamics 365 CRM:n Business Eventien tekoon. Olin jo tehnyt aikaisemmin vastaavia Dynamics 365 ERP:ssä, mutta niissä prosessi oli hyvin erilainen ja huomattavasti vaikeampi. Seuraavassa kokouksessa kävimme projektin integraatio- ja CRM-arkkitehtien kanssa tehtävää integraatiota läpi ja tarvittavia toimenpiteitä Field Servicen päässä. Saimme päätöksiä tehtyä esimerkiksi tietyistä vakioarvoista työtilauksen entiteetillä Field Servicessä ja sain lisätietoa tietyistä kartoituksista. Viikko 4 yhteenveto Viikolla pääsin aloittamaan jälleen uudessa projektissa työskentelyn ja pääsen samalla työskentelemään uusien ihmisten kanssa. Kaiken lisäksi tehtävä integraatio on uusi tapaus itselle ja hyvinkin kiinnostava. Kehityskeskustelussa sain hyvää tietoa ja palautetta omasta kehittymisestä niin esimieheltä kuin projektien tiimien jäseniltä. Palautteissa annettiin kehuja kehittymisestä, mutta yhtä paljon kehotettiin luottamaan enemmän omaan osaamiseen. Tämä oli jo tiedossa ja pyrin jatkossa luottamaan enemmän omaan tekemiseen. Projektitöiden aloituksen aikana oma 26 luottamus tekemiseen oli erittäin heikkoa hyvästä syystä, mutta varsinkin parina viime viikkona on tuntunut, että itseluottamusta tekemiseen on jo kertynyt. eCraftin integraatiotiimissä on pidetty parin viikon välein välikeskusteluja töiden muodosta, niiden riittävyydestä ja taitojen kehittymisestä. Välikeskusteluilla saadaan pidettyä pidempiaikaista kuvaa kehittymisestä ja kehityskeskusteluissa tarkistetaan uudelleen kehittymisen tasoa, mutta enemmän tulevaisuutta ajatellen. Kehityskeskusteluja pidetään, jotta esimiehellä ja työntekijällä on selkeä kuva työntekijän kuvitellusta taitotasosta ja esimiehen näkemästä oikeasta taitotasosta. Uusien tavoitteiden pariin kannustetaan jatkuvasti, että työntekijä ja esimies eivät tyydy pelkkään perusosaamiseen vaan pyrkivät aina kohti uusia saavutuksia (Murphy 2018.) Kaiken lisäksi esimies saa palautetta työntekijältä omasta toiminnastaan. Laajempaa osaamista muita töistä tarvitaan jatkuvasti IT-alalla. Aloitteleville työntekijöille on tärkeää pitää kehityskeskusteluja monista eri syistä. Joillain aloittelijoilla voi olla liian suuret odotukset itsestään tai kuvittelevat olevansa jo hyvinkin korkealla tasolla heti aloittamisen jälkeen. Kehityskeskustelussa on hyvä pitää aloittavan työntekijän jalat maassa sekä madaltaa liian epärealistisia tavoitteita. Kukaan ei ole ammattilainen heti aloittaessaan ja pitää ymmärtää, että kehittymiseen menee aikaa. Yleensä aloittelevat työntekijät palkataan potentiaalin takia ja sen kulminoituminen ammattilaiseksi voi viedä vuosia (HR Morning 2021.) 4.5 Viikko 5 Viikon ainoana aikataulutettuna tehtävänä on jatkaa työtilausintegraatiota. Tavoitteena on saada integraatio valmiiksi suunnitellussa työmäärässä ja siirtää toimiva putki testaukseen. Tämän saavuttamiseksi täytyy vielä luoda jokaiselle integraation vaiheelle putki ja testata niiden toimivuutta. Tähän mennessä olen vain keskittynyt Azure-funktion ja Field Servicen väliseen kommunikointiin. Muitakin töitä voi tulla vastaan, kuten aikaisempina viikkoina on huomattu. Maanantai 22.2 Päivän aikana oli tavoitteena saada työtilausintegraation putket tehtyä. Viime viikolla sain tehtyä Field Servicen päähän toimivat Business Eventit sekä sain asiakkaalta pääsyn SFTP-palvelimelle. Näiden pohjalta on mahdollista luoda kommunikaatio molempiin suuntiin työtilausjärjestelmän ja Field Servicen välillä. Tiistai 23.2 Sain päivän aikana luotua koko putken työtilausjärjestelmästä Field Servicen suuntaan ja testattua sitä. Tähän mennessä tehtyjen testien perusteella työtilausten luonti ja päivitys sekä niiden onnistumisesta ja epäonnistumisesta luotavat viestit toimivat oikein. Nykyisellä 27 aikataululla työtilausjärjestelmän ja Field Servicen välinen kommunikointi työtilausten luonnin suhteen pitäisi olla valmiina tällä viikolla. Keskiviikko 24.2 Päivä alkoi lyhyellä kokouksella työtilausintegraation integraatioarkkitehdin kanssa, jossa opetin integraation toimintaa Azuresta testejä varten. eCraftin projektihallintaa tehdään Jira-järjestelmässä ja arkkitehti tarvitsee tietoa integraation toiminnasta, jotta hän voi luoda Xray-testejä järjestelmään. Jirassa projektit pilkotaan tehtäviksi ja Xray-testeillä voidaan tehdä end-to-end testausta koko tehtävän toiminnasta. Torstai 25.2 Päivän aikana oli uusi tilannekatsaus CRM-arkkitehdin kanssa. Tarkoitus oli saada lisätietoa työtilausten päivittämisen tapahtumista Field Servicen päässä. Tapahtumia pitäisi laukaista työtilauksen päivittämisestä, mutta koska sanoman sisältö takaisin työtilausjärjestelmän suuntaan vaihtelee riippuen päivityksen muodosta, päivitystä ei voi laukaista mistä tahansa muutoksesta. Työtilausten uudelleenajoituksen tapahtumaa varten luodaan uusi nappula Field Servicen käyttöliittymään, josta työntekijä voi sitten laukaista uudelleenajoituksen uusien päivämäärien asettamisen jälkeen. Keskeytyksessä, perumisessa ja päivittämisessä täytyy käyttää monimutkaisempaa logiikkaa oikean tapahtuman tunnistamiseksi. Perjantai 26.2 Päivän aikana oli tavoitteena saada työtilausintegraation Visual Studio -projektin ohjelmakoodiluokat muutettua uuteen ja tehokkaampaan muotoon. Integraatiota on tähän mennessä tehty mahdollisimman nopeasti, jotta saadaan ensimmäinen versio testattavaksi ensi maanantaita varten. Tästä syystä Azure-funktiota varten olevat luokat ovat hieman itseään toistavia, koska monissa vaiheissa tarvitaan koodikielen käännös tiedostosta tai kartoitus sanomaa varten. Viikko 5 yhteenveto Viikon aikana tein lähes pelkästään työtilausintegraatiota. Viikon tavoitteena oli saada ensimmäisen vaiheen prototyyppi ensi viikon alussa olevaa asiakastestausta varten. Tämäntyyppisissä integraatioissa on tyypillistä, että aluksi luodaan niin sanottu MVP eli Minimum Viable Product. Tarkkaan työn jälkeen ei vielä kiinnitetä niin paljoa huomiota, vaan luodaan toimiva ensimmäinen versio niin nopeasti kuin mahdollista. Minimum Viable Product ohjelmistokehityksessä tarkoittaa kokonaisuutta, jossa on vain kaikkein tärkeimmät ominaisuudet. Ohjelmakoodin tai Visual Studio -projektin muotoiluun ei kiinnitetä vielä tässä vaiheessa niin tarkkaa huomiota. MVP:n tarkoitus on demonstroida tuotteen 28 ominaisuuksia ja esittely- ja testausvaiheen jälkeen tuote voi muuttaa muotoaan jopa radikaalisti. MVP:ssä tärkeintä on loppukäyttäjän ja kehittäjätiimin välinen kommunikaatio tarvittavista muutoksista, jotta kehittäjätiimillä on koko ajan selkeä suunta kehityksessä (Techopedia 2020.) Aloittelevana ohjelmistokehittäjänä on tärkeää osata luoda mahdollisimman nopeasti ja pienellä vaivalla ensimmäinen versio toteutettavasta tuotteesta, jotta se saadaan heti testaukseen. Integraatioliittymissä se on hieman vaikeampaa, koska putkeen liittyy monta eri osaa, jotta viesti kulkee alusta loppuun. Pelikehityksessä MVP-konsepti on hieman toimivampi, koska ominaisuuksia ja grafiikoita voi karsia pois niin helposti. Jos MVP:tä lähdetään kehittämään olisi hyvä tietää alkuun, että mitä kaikkea siihen kuuluu. Tarvitseeko integraatiossa olla kokonainen toimiva putki vai riittääkö kehittäjän oman tietokoneen ympäristössä toimiva versio, jota voi demonstroida asiakkaalle? Jos MVP:lle ei ole määritelty kokonaiskuvaa se voi paisua liian valmiiksi tuotteeksi, jota ei ole lähtökohtaisesti myyty asiakkaalle ja budjetti voi ylittyä turhaan. Laajuus olisi hyvä määrittää asiakkaan kanssa ennen kehittämisen aloitusta. 4.6 Viikko 6 Viikon aikana on tavoitteena saada työtilausintegraatiota edistettyä siihen pisteeseen, että myös peruminen, uudelleenajoittaminen ja päivittäminen toimii halutulla tavalla. Maanantaina on ensimmäinen testaus asiakkaan kanssa. Maanantai 1.3 Päivän aikana aloitin Field Servicen päästä lähtevän päivityssanoman kartoitusta. Työtilauksen entiteetillä on paljon relaatiotauluja Dynamics 365 CRM:ssä ja monia näistä tarvitaan sanoman kentissä. Yhdeksi ongelmaksi on muodostunut päivämäärä- ja enum-tyyppiset kentät. XML-käännöksessä ei näy kenttiä, vaikka ne on kartoitettu. Tiistai 2.3 Sain päivän aikana selvitettyä ongelmat XML-käännökseen liittyen. Huomiseksi on tarkoitus saada nykyinen työtilausintegraation versio käyttöön UAT -ympäristöön. Tässä tapauksessa luodaan uusi App Registeration Azuren Active Directoryssä, uusi käyttäjä Dynamics 365 CRM:ssä integraatioita varten ja Logic Appien sekä Azure-funktioiden julkaiseminen. Uuden integraatiokäyttäjän luominen vaatii henkilöä, jolla on hallintaoikeudet Microsoft 365 Admin Centeriin. Keskiviikko 3.3 Aamulla sain työtilausintegraatioon integraatiokäyttäjän UAT-ympäristöön, joten nyt voin julkaista loput komponentit Azureen, jotta koko integraatioputki toimii Field Servicen suuntaan. 29 Päivän aikana sain myös päivitys- ja uudelleenajoitussanomia hyvään vaiheeseen. Ne on julkaistu DEV-ympäristöön ja integraatioarkkitehti saa tehtyä testejä nykyisellä versiolla. Torstai 4.3 Päivän aikana oli tarkoitus saada työtilausintegraation pieniä puutteita korjattua nykyisessä kartoituslogiikassa. Koska Field Serviceen on nyt saatu käyttöliittymään nappula uudelleenajoitusta varten, on tarve tehdä Dynamics 365 CRM -järjestelmään uudet Business Eventit työtilauksen uudelleenajoitusta varten DEV- ja UAT-ympäristöihin. Tapahtumat luotiin Plugin Registration Tool -työkalulla. Perjantai 5.3 Päivän aikana oli ensimmäiset asiakastestaukset työtilausintegraatiossa. Kaikki toimi muuten hyvin paitsi, että olin jättänyt työtilauksen lisäysosan versioon oman päivityslogiikan. Päivityslogiikka oli siellä siksi, että voin säästää aikaa omassa kehitystyössä. Jos päivityslogiikkaa ei ole jokaisella testikerralla, täytyy luoda uusi työtilausnumero ja siihen kuluu paljon aikaa. Viikko 6 yhteenveto Viikon aikana tein vain yhtä integraatiota, jossa on monia erilaisia osa-alueita. Lisäksi kaikkiin osa-alueisiin liittyy tietynlainen toiminnallisuus ja logiikka. Jos olisin aloittanut työn ilman mitään dokumentaatiota, olisin joutunut kysymään apua tai lisäohjeita arkkitehdilta useasti päivässä. Integraatio oli kuitenkin dokumentoitu hyvin Confluenceen, josta on kehittäjänä huomattavasti helpompi katsoa yleisellä tasolla tehtävän osan logiikkaa. Integraatioiden hyvissä dokumentaatioissa on eriteltynä mm. tehtävä asia, käytettävät ympäristöt ja niihin autentikointiin liittyvät asiat, mahdolliset tarvittavat kartoitukset ja käytettävät entiteetit. Dokumentaation pohjalta kehittäjän työ on huomattavasti helpompaa, koska se poistaa arvailuun pohjautuvan kehityksen (AltexSoft Inc 2018). Dokumentaatio voi olla myös sopimuksessa eritelty asia, joten sen toimittaminen on yhtä tärkeää, kuin itse ohjelmiston. Dokumentointia tehdään ohjelmistoprojekteissa monista eri syistä. Tärkein syy on se, että asiakkaalla ja toimittavalla yrityksellä on yhteinen kuva sovitusta kokonaisuudesta. Tämä on erityisen tärkeää muutoksen hallinnassa, koska sovittuun kokonaisuuteen ei tehdä muutoksia ilman erillistä prosessia (Fox 2021.) eCraftin ohjelmistoprojekteissa dokumentaatiolla on myös muita syitä, esimerkiksi olemassa olevien liittymien dokumentointi oman liiketoimintalinjan käyttöön. Tämä tulee ilmi tilanteessa, jossa vanhemmalla asiakkaalla on jokin toimitettu liittymä ja hiljattain on kehitetty sama liittymä uudestaan toisessa projektissa. Jos uudemmassa projektissa on tehty parannuksia liittymään, niin vanhemmalle asiakkaalle voi tarjota päivityspalvelua. 30 Omassa työssäni ei ole ollut vielä tarvetta tehdä dokumentaatioita itse, koska olen vielä työharjoittelija. Dokumentaatiot tehdään seniori- tai arkkitehtitasoisen henkilön toimesta ja toteutan liittymän sen mukaisesti. Tulevaisuutta varten on toki tärkeä osata myös tehdä itse dokumentaatioita, jotta ne on helpompi selittää asiakkaalle ja mahdollisille tuleville työharjoittelijoille. 4.7 Viikko 7 Viikon aikana jatketaan työtilausintegraatiota. Nykyisellä aikataululla päivitys- ja uudelleenajoittamislogiikat pitäisi saada hyvään vaiheeseen, jotta ne voidaan siirtää UAT-ympäristöön asiakkaan testattavaksi. Maanantai 8.3 Aloitin tänään uuden integraation samassa projektissa, jossa teen työtilausintegraatiota. Tavoitteena on saada valmistuneen työtilauksen toimitettujen tuotteiden tiedot Dynamics 365 ERP:n sisällä olevien projektien myydyiksi tuotteiksi (Kuvio 6). Kuvio 6: Dynamics 365 FS - ja Dynamics 365 ERP -järjestelmien välinen integraatioputki Yksi tärkeimmistä osista integraatiossa on transaktion onnistuminen Dynamics 365 ERP:ssä. Joko kaikkien rivien täytyy onnistua tai ei yhdenkään. Transaktion onnistuessa Dynamics 365 ERP:n rajapinta palauttaa transaktion tunnisteen, joka tallennetaan takaisin Field Servicen toimitetuille tuotteille. 31 Tiistai 9.3 Jatkoin päivän aikana eilen aloitettua toimitettujen tuotteiden integraatiota. Päivän aikana oli tarkoitus jatkokehittää ja testata eilen saatua ensimmäistä versiota. Ongelmiksi muodostui se, että Dynamics 365 CRM:ään ei ole vielä tehty puuttuvaa relaatiota työtilauksen ja projektin välille, sekä se, että Dynamics 365 ERP:n päähän ei ole vielä tehty tarvittavaa entiteettilaajennosta. Työ jatkuu muun projektitiimin työn edistyttyä. Keskiviikko 10.3 Päivän aikana jatkoin työtilausintegraation kehittämistä. Viimeisimmän refaktoroinnin jäljiltä integraatioon oli jäänyt ongelma liittyen Azure-funktion palautusarvoon. Kartoitusfunktion sisällä kutsutaan toista luokkaa, joka kartoittaa oikeanlaisia sanomia riippuen käyttäjän antamasta arvosta. Ongelmaksi oli muodostunut se, että funktion sisällä olevat luokat eivät palauttaneet virhettä sellaisen sattuessa vaan omanlaisen palautusobjektin. Poistamalla palautusobjektin käytön virheen sattuessa korjasi ongelman. Torstai 11.3 Päivällä pidettiin kahdesti viikossa pidettävä integraatiotiimin kokous. Kokouksesta teki mielenkiintoisen se, että katsoimme yhdessä Microsoft Ignite -tapahtuman yhtä esitystä, jossa kerrottiin uudesta teknologiasta liittyen ARM-mallien luontiin. Koska työtilausintegraatiossa yksi seuraavaksi tehtävistä töistä on ARM-mallien luonti DevOpsia varten, saan hyvän tilaisuuden kokeilla uutta teknologiaa ja raportoida kokemuksia muille tiimin jäsenille. Perjantai 12.3 Päivän aikana työtilausintegraation CRM-arkkitehti piti testaustilaisuuden asiakkaan kanssa nykyisen työtilausintegraation toiminnasta. Kaikki tuntui toimivan lähellä haluttua tapaa, mutta muutamia korjausehdotuksia tuli. Vastaustiedostot tulivat väärällä enkoodauksella ja muutamia elementtejä piti asettaa vaihtoehtoisiksi työtilausten viennissä Field Serviceen. Viikko 7 yhteenveto Viikon aikana tein useampia eri asioita eri projekteissa, jotka vaativat erilaisia toimenpiteitä versionhallinnassa. Kehitystuloksien vieminen versionhallintaan ja niiden julkaiseminen tuotantoympäristöön vaativat omanlaisensa prosessin. eCraftin projekteissa käytetään usein GitFlow-mallista versionhallintaa. Versionhallinnassa käytetään useita haaroja eri tarkoituksia varten. Integraatioiden kehityksessä käytetään ominaisuus tai feature-haaroja, joissa itse kehitystä tehdään. Kun ominaisuutta saadaan kehitettyä, muutoksia siirretään koodikatselmoinneilla kehitys tai develop-haaraan. Develop- 32 haarassa säilytetään sen hetkistä kehitysversiota, joka julkaistaan DEV-ympäristöön, jossa kehittäjät voivat testata versiota. Develop-haarasta julkaistaan myös UAT-ympäristöön siinä vaiheessa, kun versio on saatu tarpeeksi hyvään vaiheeseen testausta varten. Feature-haaroista voidaan viedä myös katselmoinnilla tuotanto tai master-haaraan (Atlassian 2021.) Tuotannossa havaituista puutteista tai huoltotoimenpiteistä luodaan korjaus tai hotfix-haara, joka pohjautuu tuotannossa olevaan master-haaraan. Hotfix-haarassa tehdään tarvittava korjaus, jonka jälkeen haara yhdistetään koodikatselmoinnilla master- ja develop-haaroihin (Atlassian 2021.) Tämän jälkeen haluttavat muutokset viedään tuotantoon DevOpsin julkaisuputkella. Työssäni versionhallintaa käytetään koko ajan, mutta silti osaaminen on vielä hieman vajanaista. Kokemuksella pienemmät tietämättömyyden osat selviävät, mutta syvempää osaamista olisi hyvä saada. Sain koulutuksen alussa harjoittelumateriaalia Gitin käyttöön, mutta en ole vielä ehtinyt opetella sitä. Harjoittelumateriaalissa on osia Gitin sisällä tapahtuvasta toiminnasta, joten siitä olisi hyvä lähteä liikkeelle. 4.8 Viikko 8 Viikon aikana on tavoitteena saada työtilausintegraation vaiheet valmiiksi, mutta tämän onnistuminen on myös riippuvainen asiakkaan aktiivisesta testauksesta. Kehittäjätiimin näkökulmasta on joskus vaikea nähdä kaikkia asiakkaan tarpeita ja nämä tarpeet huomataan parhaiten asiakkaan testauksella. Maanantai 15.3 Aloitin päivän aikana yksikkötestien tekemisen työtilausintegraatioon. Yksikkötesteissä tarvitsee kattaa työtilausjärjestelmästä tulevien tiedostojen käsittelyyn, työtilausjärjestelmään menevien vastaustiedostojen kartoitukseen sekä Field Service -yhteyden luomiseen tarvittavat toiminnallisuudet. Yksikkötesteillä varmistetaan DevOpsin käännösputkessa ohjelmiston oikeanlainen toiminta. Tiistai 16.3 Päivän aikana sain lisää kommentteja työtilausintegraatiossa tehdyistä testeistä asiakkaan toimesta. Asiakas testasi Field Servicen päästä lähettää päivitysviestejä työtilausjärjestelmään muuttamalla UAT-ympäristössä työtilauksen status valmiiksi. Miltei kaikki tuntui olevan asiakkaan näkökulmasta olevan oikein muutamia pieniä yksityiskohtia lukuun ottamatta. Työtilausjärjestelmään menevissä tiedostoissa lähdejärjestelmäksi pitää asettaa asiakkaan vanha järjestelmä, vaikka lähde on oikeasti Field Service. Lisäksi päivämäärien kentissä pitää käyttää muotoa, jolla kohdejärjestelmä tunnistaa ne UTC-ajaksi. 33 Keskiviikko 17.3 Päivän aiheena oli tehdä Dynamics 365 ERP -kehittämistä samassa projektissa, jossa olen tehnyt käyttäjäintegraatiota. Kehittämiseen sisältyi uusien taulu- ja entiteettilaajennoksien tekeminen sekä olemassa olevien käyttöliittymän lomakkeiden ja valikon valintojen muokkaaminen. Integraatiotiimin vanhempi kehittäjä oli kouluttamassa minua ja toista tiimin nuorempaa työntekijää aiheesta. Viimeisimmästä ERP-kehittämisestä on jo useita kuukausia, joten päivä oli erittäin opettavainen uusien asioiden oppimisesta ja vanhojen asioiden kertaamisesta. Torstai 18.3 Päivän aiheena oli jatkaa työtilausintegraation yksikkötestien tekoa ja samalla käydä keskustelua CRM- ja integraatioarkkitehtien kanssa asiakkaan toiveista liittyen sanomien muodostukseen työtilausjärjestelmästä ja -järjestelmään. Perjantai 19.3 Päivän aikana jatkoin toimitettujen tuotteiden integraatiota. Yhdeksi päivän ongelmaksi muodostui Dynamics 365 ERP -järjestelmän tuotteiden konfiguraation puute. Järjestelmä luo sen sisällä olevien projektien tuotteista automaattisesti laskuja ja laskuilla olevilla tuotteilla täytyy olla tyyppikategoria, esim. palvelu tai tuote. Järjestelmän tuotteiden kategorian asetuksen jälkeen integraatio toimi halutulla tavalla. Viikko 8 yhteenveto Tein viikon aikana monia erilaisia yksikkötestejä työtilausintegraation Visual Studio -ratkaisussa. Tähän mennessä olen käyttänyt xUnit- ja Moq-kirjastoja testien tekemiseen. Monia muitakin vaihtoehtoja on, mutta en ole vielä kokeillut näitä. Yksikkötestejä tehdään siksi, että niillä voidaan tarkistaa tuotantoputken eri vaiheissa Visual Studio -projektihierarkiassa olevien liittymien toimintaa. Lisäksi yksikkötestit auttavat sellaisessa tilanteessa, jossa kesken ohjelmiston kehitystä projektiin otetaan uusia kehittäjiä. Testit auttavat uutta kehittäjää ymmärtämään nykyisen version toimintaa. Testeille määritellään oletusarvoinen toiminta, jolla Visual Studio -projektissa olevien liittymien tulisi toimia. Yksikkötestit ovat projektikokonaisuuden alimman tason testejä. Aikaisemmin olen maininnut Xraytesteistä, joita tehdään Jiraan. Xray testit ovat integraatiotason testejä eli niillä testataan koko putkea yhdestä järjestelmästä toiseen (Guru99 2021a). eCraftilla yksikkötestejä käytetään toiminnallisuuden tarkistamiseen kehittäjän omassa ympäristössä ja myöhemmin DevOpsin käännösputkessa. Jos yksikkötestit eivät mene läpi, käännös epäonnistuu ja julkaisu ympäristöön perutaan. DevOpsista ja sinne julkaisusta lisää myöhemmin. Lisäksi yksikkötestit toimivat oleellisesti muutoksenhallinnassa. Yksikkötestit tarkistavat 34 liittymän toiminnan muutoksen jälkeen ja varmistavat, ettei liittymä hajoa ennen asennusta (Software Testing Fundamentals 2020.) Yksikkötestien tekemisestä pidettiin minulle ja muille aloitteleville työharjoittelijoille koulutusta viime syksynä, mutta omakohtainen harjoittelu on jäänyt aika vähälle. Yksikkötestien kehittämien on mielestäni vaikeampaa kuin itse liittymän kehittäminen. Tämä johtuu siitä, että osaamiseni xUnit- ja Moq-kirjastojen kanssa on vielä suhteellisen heikkoa. Monimutkaisen sovelluslogiikan testaaminen on vielä itselle vaikeaa ja tarvitsen vielä lisää opettelua aiheen parissa. Erityisesti callback-logiikka olisi tärkeä osata, jotta voi luoda testitapauksia funktioille, joissa käytetään silmukoita. 4.9 Viikko 9 Viikon aikana on tavoitteena saada työtilausintegraation ARM-mallit tehtyä jatkuvaa julkaisuputkea varten sekä saada toimitettujen tuotteiden integraatio valmiiksi ja asiakkaan testattavaksi. Maanantai 22.3 Päivän aikana sain tehtyä yksikkötestit toimitettujen tuotteiden integraatioon sekä korjattua muutamia ongelmakohtia rivien kirjoittamisessa Dynamics 365 ERP:hen. Yksi integraation tärkeimmistä teknisistä ominaisuuksista on se, että joko kaikkien rivien kirjoittaminen onnistuu tai ei yhdenkään. Huomasin testauksessa ongelman, jossa yksi rivien kirjoittamisesta epäonnistui, kun yritti kirjoittaa riviä, jolla on väärä määräyksikkö. Tapahtuma epäonnistuu, mutta kaksi kolmesta rivistä kirjoittui kuitenkin järjestelmään, mikä ei ole haluttu toiminnallisuus. Muuttamalla tallennuslogiikkaa hieman ongelma ratkesi. Tiistai 23.3 Sain päivän aikana tehtyä ARM-mallit työtilausintegraatioon käyttäen Microsoftin uutta Bicepohjelmointikieltä. Suurempia ongelmia ei vielä löytynyt, mutta ongelmat yleensä selviävät siinä vaiheessa, kun malleja yritetään käyttää DevOpsin julkaisuputkessa. Keskiviikko 24.3 Päivän aikana sain uuden tehtävän, jossa jo kehitetyn integraation toimintalogiikkaa tarvitsee muuttaa. Integraatiossa kirjoitetaan Dynamics 365 ERP:n General Ledger -rajapintaan kirjanpitotapahtumia perustuen kortistotiedostosta tuleviin riveihin. Muutoksessa nykyinen liittymä muutetaan käyttämää XML-tiedostoja. Muutoksesta ei ole vielä dokumentaatiota, joten tässä vaiheessa voin vain kehittää alustavan toteutuksen. 35 Torstai 25.3 Päivän aikana oli tarkoitus saada toimitettujen tuotteiden integraatio hyvään vaiheeseen huomista asiakastestiä varten. Yksi tärkeimmistä asioista oli testata nykyistä ratkaisua ja saada yleisimmät ongelmakohdat ratkaistua. Yksi ongelmista oli saada tietoon kaikki Dynamics 365 ERP:n projektientiteetin ominaisuudet, jotka estävät rivien kirjoituksen. Kaikki yleisimmät ongelmat löytyivät. Perjantai 26.3 Aamun aikana oli vielä joitain ongelmia toimitettujen tuotteiden integraatiossa rajapintakutsujen suhteen, mutta ne saatiin ratkottua ennen testauksen alkua. Testaus sujui integraation osilta hyvin, koska oikeita virheitä suorituksien aikana ei sattunut. Viikko 9 yhteenveto Viikon aikana sain monia muutostöitä ja valvomiseen liittyviä töitä ja siksi en saanut ARM-malleja valmiiksi. Niiden tekeminen siirtyy ensi viikolle. eCraftilla ja monissa muissa ohjelmistoyrityksissä isoissa projekteissa tehdään laaja suunnitelma tarvittavista kokonaisuuksista ennen työn aloitusta. Suunnitelmassa dokumentoidaan esimerkiksi integraatioliittymän kenttien kartoitus ja toimintalogiikka. Kuitenkin kehityksen aikana tai tuotannossa asiakas voi huomata omasta näkökulmastaan puutteen liittymän toiminnassa ja täten haluaisi muutoksen olemassa olevaan ratkaisuun. Tällaisissa tapauksissa tehdään muutospyyntö tai Change Request. Muutospyynnöissä asiakas kuvailee nykyisessä ratkaisussa olevan puutteen ja halutun uuden toiminnallisuuden, jonka jälkeen se päätyy käsiteltäväksi ohjelmiston toimittajayritykselle. Muutospyyntöjen kuuluminen projektityöhön riippuu usein asiakkaan kanssa tehdystä sopimuksesta, joten joskus muutospyyntöjä ei käsitellä muutoksina vaan korjaustöinä. Jos muutos on projektin kokonaisuuden ulkopuolella, tällöin kyse on muutoksesta. Useimmiten muutostöissä kyse on vain ylimääräisistä kenttäkartoituksista tai joidenkin kartoituksien muuttamisesta, jolloin pyyntö hyväksytään sovitulla työmäärällä ja toteutetaan sovitulla aikataululla. Jos muutos liittyy CRM:n sisäiseen toiminnallisuuteen, niin silloin projektin vastaava CRM-arkkitehti huolehtii muutoksen toteuttamisesta. Itse muutoksen lisäksi täytyy päivittää olemassa olevat dokumentaatiot vastaamaan muutosta (Tallyfy 2021.) Jos muutospyyntöön liittyvä toteutus on jo tuotannossa, silloin käytetään aiemmin mainittua hotfix-periaatetta. Muuten kehitys tehdään normaalisti feature-haaran kautta dev-haaraan. Tehtyjen muutoksien jälkeen kyseessä oleva liittymä menee uudestaan testaukseen ja se hyväksytään asiakkaan puolesta (Guru 99 2021b.) 36 Oma osaamiseni muutoksien teossa on hyvällä mallilla, mutta itse muutospyynnön prosessia en ole vielä oppinut. Olen kyllä ollut asiakkaan kanssa yhteydessä tarvittavista muutoksista, mutta vain käytännön ratkaisujen puolella. Projektinhallinnan osalta tämä on vielä hieman mysteeri. Tulevaisuudessa tulen olemaan enemmän vastuussa omista työmääräarvioista, jolloin muutospyyntöjen prosessi tulee varmasti silloin enemmän tutuksi. 4.10 Viikko 10 Viikon aikana on tavoitteena saada ARM-mallit tehtyä työtilausintegraatioon ja DevOps-putket tehtyä jatkuvaa julkaisua varten. Maanantai 29.3 Päivän aikana etsin ongelmaa Bicep-malleistani ja omaksi harmikseni se paljastui olevan vain yhden kirjaimen puuttuminen yhdestä rajapintayhteyden elementistä. Toinen päivän kohokohta oli vanhemman kehittäjän pitämä oppitunti DevOpsin käännös- ja julkaisuputkista. Viikon yhtenä aiheena on saada DevOps kuntoon työtilaus- ja muiden integraatioiden osalta. Tiistai 30.3 Päivän aiheena oli tehdä tarvittavat muutokset integraatioon, johon kaksi viikkoa sitten tehtiin Dynamics 365 ERP -laajennoksia. Integraatiossa kirjoitetaan tuotteita järjestelmään apirajapinnan kautta, joten muutos ei ole monimutkainen. Keskiviikko 31.3 Päivän aiheena oli tehdä DevOps-käännösputkea työtilausintegraatiota varten. Yhdeksi ongelmaksi muodostui se, että käännösputken pitäisi saada Bicep-tiedostot käännettyä JSON-muotoon, että ne voidaan julkaista Azureen. Torstai 1.4 Päivän aiheena oli saada työtilausintegraation DevOps-julkaisuputki valmiiksi ja testattua. Pieniä ongelmia muodostui parametrisoinnin ja Logic Appien julkaisun kanssa, mutta niistä selvittiin nopeasti. Seuraavana vuorossa on juuri julkaistujen integraatioputkien testaus ennen UAT-julkaisua. Viikko 10 yhteenveto Viikon aikana on ollut tehtävänä tehdä DevOpsin kautta logiikkaa jatkuvaa käyttöönottoa varten työtilausintegraation projektissa. Joissain projekteissa DevOpsin rakennus annetaan asian osaaville henkilöille. Tämän projektin lähes kaikki integraatiot on tehty nuorempien kehittäjien toimesta, joten on sopivaa, että samat henkilöt hoitavat koko toimituksen alusta 37 loppuun. Tässä projektissa integraatioita varten käytetään DevOpsia CI/CD -tarkoituksella eli DevOpsin sisällä integraatioiden lähdekoodit testataan Visual Studio -projektien sisällä olevien yksikkötestien perusteella, projektit käännetään ja lopulta julkaistaan Azureen. DevOps-putki laukaistaan joko manuaalisesti tai automatisoidusti esimerkiksi versionhallinnan haaran commitista (Microsoft 2019e.) Tästä syystä yksikkötestien tekeminen integraatioihin on tärkeää julkaisun kannalta. Testauksen ja lähdekoodin käännön jälkeen ARM-mallit ja Visual Studio -projektien funktiot kerätään kokoon ja siirrytään julkaisuvaiheeseen. Julkaisussa ARM-mallien perusteella julkaistaan Azure-komponentit ja Visual Studio -projektien sisältö Azure funktioihin. Julkaisun jälkeen komponentit ovat valmiita käytettäväksi, jos yhdessäkään komponentin julkaisuprosessissa ei tapahtunut virheitä (Microsoft 2021c.) DevOps-osaamiseni käännös- ja julkaisupuolella on jo suhteellisen hyvällä tasolla, mutta hiottavaa toki vielä olisi. eCraftilla ei ole parhaita käytäntöjä DevOpsin putkien suhteen, mutta erilaisia toimintamalleja on ja niiden toimintaa olisi hyvä opiskella osaamisen parantamiseksi. DevOpsin taustalla pyörii käyttäjäprofiileja ja autentikointeja, joista minulla ei ole toistaiseksi vielä mitään tietoa, joten tästä olisi hyvä löytää lisää tietoa tai osallistua koulutuksiin. Integrations & API -liiketoimintayksikössä on myös hyvää osaamista DevOpsiin liittyen, joten hyviä opettajia on saatavilla. 5 Yhteenveto Opinnäytetyön alussa olin hyvin epävarma omasta osaamisestani ja työprosessit tuntuivat hankalilta. Esimerkiksi muutoksen tekemisen prosessi oli vieras ja vaikea ymmärtää sekä en tiennyt kaikkia toimintatapoja mitä siinä tarvitaan. Työpäivän aikana tuntui, että oli suuret suorittamispaineet osaamisen kehittymiseen. Kehitys on kuitenkin ollut hyvää. En tiennyt ennen aloitusta mitään yksikkötesteistä tai ohjelmiston osa-alueiden dokumentoinnista ja nyt osaamiseni ja tietämykseni on jo huomattavasti paremmalla tasolla näiden osalta. Ehkä suurimpana heikkoutenani pidin sitä, että omaan tekemiseen ei ollut vahvaa luottoa ja itsevarmuus oli heikkoa. Seurantajakson aikana olen päässyt tekemään monia erilaisia töitä erilaisissa projekteissa erilaisien ihmisien kanssa ja uskon, että tämä on antanut tarvittavaa itsevarmuutta tulevaisuutta varten. Projektitiimien jäsenet myös kannustivat tähän seurantajakson aikana olleessa kehityskeskustelussa. Paremman itsevarmuuden kautta työpäivä tuntuu myös huomattavasti rennommalta, koska paineet eivät ole niin korkealla. 38 5.1 Oman työn analysointi Työni analysoinnissa olen huomannut, että pienienkin osa-alueiden hyvään osaamiseen tarvitaan paljon kokemusta ja kertausta. Viime syksynä olin koulutuksessa miltei joka aiheesta, mutta oikeaan osaamiseen kuitenkin tarvitaan toistoja ja käytäntöä. Koulutusohjelman aikana käydyt koulutukset olivat enemmänkin kosketuspinta aiheeseen ja vasta myöhemmin käytännön töissä tai harjoituksissa saa tehokasta oppia ja kokemusta käsiteltävästä asiasta. 5.2 Tulokset ja kehittämisehdotukset yritykselle eCraft tulee hyödyntämään opinnäytetyötä tulevia koulutuksia varten. Uudet oppilaat voivat lukea opinnäytetyön ja saada parempaa kuvaa tulevasta työstä. Oppilailla voi olla samanlainen näkemys tulevasta työstä kuin minulla oli eli tietää peruskonsepteja ohjelmistokehityksestä, mutta konkreettiset työtavat ja prosessit ovat täysin hämärän peitossa. Opinnäytetyöllä voidaan myös validoida nykyisiä toimintatapoja ja yrittää löytää kehittämisen kohteita koulutusohjelmissa ja prosesseissa. Minun saapumiseräni oli vasta ensimmäinen kokeilu devcrafters-koulutusohjelmassa ja uusia on todennäköisesti tulossa. Yrityksen nykyisellä kasvutahdilla uusia kehittäjiä varmasti tarvitaan tulevaisuudessa ja voi olla, että itsekin pääsen pitämään jotain koulutusta jostakin aiheesta. Tulevissa kehittäjille tarkoitetuissa koulutusohjelmissa voisi olla enemmän läksyjen tapaisia tehtäviä koulutuksien välissä, jossa kehitetään jotain integraatiota eteenpäin. Esimerkiksi jos viikon alussa opetellaan Logic Appien ja Function Appien toimintaa, niin koulutuksien jälkeen voisi olla yksi välipäivä koulutuksista, jolloin ideoiden perusteella integraatioita voisi kehittää eteenpäin. Lisäksi ensimmäisissä projektitehtävissä olisi tärkeää, että toteutettava liittymä olisi hyvin ja selkeästi dokumentoitu ja suunniteltu. Juuri aloittanut ja kokematon ohjelmistokehittäjä on hyvin epävarma toteutettavasta työstä ja omista taidoistaan.

question:Analysoitko tekstin? The aim of this study was to consider and observe the introduction of a new ERP system by Lakea Oy. The electronification of work and growth in the effectiveness of work were chosen as the points of view of the thesis. The theoretical section the study deals with the history and grounds of ERP, as well as its key advantages and challenges. It also deals with the electronification of operations and the increase in their efficiency, as well as the effects of this on the operations of the company. In the applied section of the study, semi-structured interviews were carried out with selected staff members in order to obtain as extensive and practical information as possible. The interviewees were chosen in a way that would allow bringing out the different perspectives on the working methods observed at the company. Based on the thesis study, electronic financial management increases automation, which, in turn, increases the effectiveness of work, which allows influencing the quality of the company. In electronic financial management, the man-hours saved thanks to automation can be allocated e.g. for development. However, the creation of active and efficient processes and automated procedures may increase manual work in some functions. Keywords: ERP, electronic financial management, intensifying of operations, effectiveness of work 4 SISÄLTÖ Opinnäytetyön tiivistelmä..................................................................... 2 Thesis abstract.................................................................................... 3 SISÄLTÖ............................................................................................. 4 Kuva-, kuvio- ja taulukkoluettelo.......................................................... 6 Käytetyt termit ja lyhenteet .................................................................. 7 JOHDANTO ........................................................................................ 8 1.1 Tausta ja perusteet tutkimukselle................................................................9 1.2 Tutkimuksen rakenne..................................................................................9 2 TOIMINNANOHJAUSJÄRJESTELMÄ .......................................... 11 2.1 Historia ja kehitys ......................................................................................12 2.2 Hyödyt.......................................................................................................16 2.3 Haasteet ja ongelmat ................................................................................17 3 TOIMINNAN TEHOSTUMINEN JA SÄHKÖISYYS........................ 19 3.1 Työtehokkuus ja laatu ...............................................................................20 3.2 Sähköisyys ja sähköinen taloushallinto .....................................................21 3.2.1 Integroitu taloushallinto ...................................................................24 3.2.2 Digitaalisuuden vaikutus .................................................................25 3.3 Seuranta ...................................................................................................26 4 MENETELMÄT ............................................................................. 27 5 CASE LAKEA OY ......................................................................... 29 5.1 Yritys esittely.............................................................................................29 5.2 Taustatekijät järjestelmän vaihtoon...........................................................29 5.3 Visma L7 ...................................................................................................31 5.3.1 Ominaisuudet..................................................................................31 5.4 Netvisor.....................................................................................................31 5.4.1 Ominaisuudet..................................................................................32 5.5 Järjestelmän vaihdos ................................................................................33 6 HAVAINNOT................................................................................. 35 6.1 Sähköisyys................................................................................................35 5 6.2 Toiminnan tehostuminen...........................................................................36 7 YHTEENVETO JA POHDINTA ..................................................... 39 7.1 Sähköistyminen.........................................................................................39 7.2 Työntehokkuus..........................................................................................40 7.3 Integraatio haasteet ja laadun paraneminen .............................................40 7.4 Pohdinta....................................................................................................41 LÄHTEET.......................................................................................... 42 LIITTEET........................................................................................... 44 6 Kuva-, kuvio- ja taulukkoluettelo Kuvio 1. Tutkimuksen rakenne..............................................................................10 Kuvio 2. ERP-järjestelmän osa-alueet (Visma 2019). ...........................................12 Kuvio 3. Toiminnanohjausjärjestelmän kehitys (Lahti & Salminen 2014, 34–38). .13 Kuvio 4. Talousjärjestelmien nykytila (Kaarlajärvi & Salminen 2018, 41)..............15 Kuvio 5. Taloushallinnon kehittyminen paperittomasta älykkääseen (Lahti & Salminen 2014, 27)...............................................................................................22 Kuvio 6. Integroitu taloushallinto (Kaarlajärvi & Salminen 2018, 44).....................25 Kuvio 7. Eritasojen Netvisorin käyttö case-yrityksessä. ........................................28 Kuvio 8. Netvisorin rajapinnat (Visma 2019). ........................................................32 Taulukko 1. SWOT-analyysi (Itewiki, [viitattu 24.10.2019]). ..................................18 7 Käytetyt termit ja lyhenteet Digitaalisuus Digitaalisuuden tavoitteena on lisätä konekielisyyttä ja sähköisyyttä sekä vähentää paperin käyttöä muun muassa arkistoinnissa ja raportoinnissa. (Kaarlajärvi & Salminen 2018, 14–16.) Toiminnanohjaus Toiminnanohjausta pidetään ohjelmistona, joka koordinoi yhteisen tietokannan kautta yrityksen eri osa alueiden tietoja. (Lahti & Salminen 2014, 40–41.) Erp-järjestelmä ERP-järjestelmä on yritysten tietojärjestelmä, joka hyödyntää keskitettyä tietokantaa, mikä on yhtenäisten sovellusten käytössä. Järjestelmissä on usein yksi päämoduuli, jonka tietoihin syötetään muihin moduuleihin vaikuttavia perustietoja, joita koko järjestelmä hyödyntää. (Lahti & Salminen 2014, 40–41.) Integraatio Kahden tai useamman erillisen tiedon yhtenäistäminen yhdeksi toimivaksi kokonaisuudeksi. (Kaarlajärvi & Salminen 2018, 42.) Digitaalinen taloushallinto Kaikki tapahtumat ja prosessit toimivat automaattisesti digitaalisen järjestelmän avulla. Eli tällöin tietovirrat ja käsittely ovat siirtyneet digitaaliseen muotoon. (Kaarlejärvi & Salminen 2018, 14–15.) Sähköinen taloushallinto Taloushallinnon tehtävien kirjauksia ja käsittelyä sähköisesti (vain kerran) yhdessä järjestelmässä ja rutiini tehtävien automatisoitumista, toimintaketjun katkeamatta. (Kaarlejärvi & Salminen 2018, 14-15.) 8 JOHDANTO Tässä opinnäytetyössä kuvataan Lakea Oy:n taloushallinnon toiminnanohjausjärjestelmää, joka on otettu käyttöön keväällä 2019. Työssä kuvataan uuteen toiminnanohjausjärjestelmään siirtymisen vaikutuksia yhtiössä ja pyritään kartoittamaan uuden järjestelmän hyödyt suhteessa vanhaan järjestelmään. Sähköistyminen ja sähköinen taloushallinto luovat nyt ja tulevaisuudessa yrityksille mahdollisuuksia tavoittaa asiakkaansa nopeammin ja kilpailukykyisemmin. Yritysten on pystyttävä kehittymään ja täten toiminnanohjausjärjestelmän on oltava yrityksen toimintaan soveltuva sekä tarpeeksi tehokas. Riittävä kehittyminen on välttämätöntä ja järjestelmä valinnoilla on kauas kantoisia vaikutuksia, kuinka laajasti ja tehokkaasti yrityksen taloushallinto digitalisoituu. (Lahti & Salminen 2014, 34.) ERP-järjestelmä (Enterprise Resource Planning) eli tutummin toiminnanohjausjärjestelmä on tärkeässä roolissa taloushallinnon työssä. Usein syynä järjestelmän vaihtoon on puutteet edellisessä järjestelmässä. (Kaarlajärvi & Salminen 2018, 35.) Lahti ja Salminen (2014, 40) tietävät taloushallinnon moduulin olevan merkittävimmässä asemassa järjestelmissä. Sen kautta voidaan syöttää ohjaustietoja muihin valittuihin moduuleihin. Suomi on ollut edelläkävijä lainsäädännön ja sähköiseen taloushallintoon siirtymisen suhteen. Vielä 20 vuotta sitten materiaalit säilytettiin paperisina, kuitenkin kuluneiden vuosien aikana on tapahtunut suuri muutos automatisaation suuntaan. Muutos sai aikaan sen, että taloushallinnon ohjelmilta vaaditaan nykyään paljon. Alati kasvavien raportointi velvollisuuksien täyttäminen kustannustehokkaasti samalla hoitaen rutiini työt sujuvasti aikaa säästäen. Uskotaan, että keskitetyllä ja digitalisoidulla prosessilla voidaan kasvattaa yrityksen laatua ja vähentää virheitä. (Kaarlajärvi & Salminen 2018, 14–16.) 9 1.1 Tausta ja perusteet tutkimukselle Tutkimuksen tavoitteena on tarkastella Lakea Oy:n toiminnanohjausjärjestelmän vaihtoa työn tehokkuuden ja työn sähköistymisen näkökulmista sekä pyritään havainnoimaan uuden järjestelmän hyötyjä suhteessa vanhaan järjestelmään. Tavoitteena on kuitenkin myös tutkia järjestelmän heikkouksia tai puutteita yhtiölle sekä pyrkiä kartoittamaan mitä hyötyjä yritys voisi uuden ohjelmiston avulla vielä saavuttaa. Tutkimusongelmana tässä työssä uuden investoinnin tehokkaan käyttöönoton varmistaminen Lakea Oy:lle. Sekä pyrkiä osoittamaan miten yritys voi saada uudesta toiminnanohjausjärjestelmä kaiken hyödyn irti nyt ja tulevaisuudessa. Opinnäytetyö on rajattu käsittelemään toiminnanohjausjärjestelmää sen käyttöönoton jälkeen. Tutkimuksen empiirisessä osiossa kuvataan kuitenkin uuden ohjelman käyttöönoton sujuvuutta. 1.2 Tutkimuksen rakenne Seuraavassa on havainnollistava kuvio tutkimuksen rakenteesta ja kytköksistä toisiinsa. Toiminnanohjausjärjestelmä - historia ja kehitys - hyödyt - ongelmat ja haasteet Case Lakea Oy - yritysesittely - L7 - Netvisor - menetelmät - havainnot - johtopäätökset Toiminnan tehostuminen ja sähköisyys - työntehokkuus ja laatu - sähköisyys ja sähköinen taloushallinto - integroitu taloushallinto - käyttöönoton seuranta 10 Luvussa yksi kerrotaan tarkemmin toiminnanohjausjärjestelmästä, mikä se on ja mihin sitä käytetään, sen historiasta ja kehittymisestä nykypäivän mukaiseksi. Sekä perehdytään toiminnanohjausjärjestelmien hyötyihin ja sen haasteisiin ja ongelma kohtiin. Toisessa luvussa käsitellään ja määritellään sähköisen taloushallinnon kehittymistä ja käyttöönottoa. Sekä mietitään yrityksien tehokkuuteen sähköistymiseen vaikuttavia tekijöitä. Luvussa sivutaan myös hieman integroitua taloushallintoa sekä investoinnin seurantaa. Kolmannessa luvussa pureudutaan case yritykseen ja sen toimintaan, esitellään hiukan aiemmin käytössä ollutta toiminnanohjausjärjestelmää sekä uutta järjestelmää. Luvussa kerrotaan tutkimuksen menetelmät ja havainnot sekä johtopäätökset ja pohdinta. Kuvio 1. Tutkimuksen rakenne. 11 2 TOIMINNANOHJAUSJÄRJESTELMÄ ERP eli Enterprise resource planning eli tutummin toiminnanohjausjärjestelmä tarkoittaa yrityksen toimintaan olennaisesti liittyvien prosessien keskinäistä integraatiota (Sap 2019). Keskinäisiä toimintoja ovat yleisesti henkilöstöhallinto, taloushallinto, tuotanto sekä palvelut. Järjestelmiä on kehitetty ja paranneltu vuosien aikana tukemaan yrityksen toimintaa. ERP-järjestelmien keskinäinen integraatio hyödyntää yhtenäistä tietokantaa, jolloin yrityksillä voi olla käytössään niin kutsuttu ERP-järjestelmien muodostama ohjelmistopaketti, jossa liiketoiminnan eri osa-alueille on käytössään oma järjestelmä. Lahti ja Salminen (2014, 210) tietävät, että yritykset tavoittelevat tehokasta ja yhdenmukaista toimintaa sekä raportointia, vaikka toimipisteet sijaitsisivat ympäri maata. He kirjoittavat myös tällaisen olevan mahdollista ERP-järjestelmän avulla, ohjelmisto hyödyntää yrityksen yhtenäisiä tietoja, kuten tilikarttaa ja yrityksen perustietoja. Tiedot syötetään kerran järjestelmään, jolloin ne ovat kaikkien keskenään integroitujen ohjelmien käytössä. Järjestelmä ja siihen integroidut järjestelmät tuottavat raportteja näiden tietojen pohjalta. Kaarlejärvi ja Salminen (2018, 40–41) kirjoittavat, että eri järjestelmiä tullaan yhdistämään toisiinsa tehokkuuden parantamiseksi. He korostavat myös, että jossain vaiheessa kuluttajalle tarjotaan oikeuksia järjestelmän käyttöön ja omien tietojen selailuun. Tällä yritykset pystyvät kohdistamaan säästyvän työajan muualle. Kirjoittajan mielestä kuluttajien mahdollisuus päästä näkemään omia tietojaan on hyödyllinen ja yrityksien kannalta tehokas. Kuviossa yksi esitetään ERP-järjestelmän sisältämät osa-alueet ja sovellukset, joita yritykset voivat ottaa käyttöön. 12 Kuvio 2. ERP-järjestelmän osa-alueet (Visma 2019). 2.1 Historia ja kehitys Taloushallinnolla on pitkä historia, jonka juuret ulottuvat yli sadan vuoden päähän. Silloin käytettiin Taylorix-menetelmää, joka perustui reikäkortin avulla tapahtumien jäljentämiseen. Sähköistymisen kehittyessä ja kasvaessa 1950-luvulla siirryttiin varsinaiseen tietotekniseen kirjanpitoon, josta alkoi internet-vallankumous. (Lahti & Salminen 2014, 35.) Huomattava sähköisen taloushallinnon uudistus 1970-luvulla oli EDI-standardi, joka mahdollisti organisaatioiden välisen tiedonsiirron (mp.). MRP-järjestelmä (Manufacturing Recource Planning) kehitettiin 1970-luvulla avustamaan tuotantojärjestelmien materiaalihallintoa ja logistiikkaa (Virtanen 2016, 12– 14.) Myöhemmin ohjelmistosta kehitettiin uusi päivitys MRP II -järjestelmä, jonka toimivuus pohjautui MRP:hen. Kehityksen myötä ohjelmistoon kuului kuitenkin jo toiminnanohjaus. Myöhemmin 1990-luvulla alettiin lisätä ohjelmistoja keskenään yritysten tarpeen ja kehityksen mukaan. (Lahti & Salminen 2014, 40.) ERP Henkilöstönhallinta Taloudenhallinta Varastonhallinta Asiakkaidenhallinta Tilaustoimitusketjun hallinta 13 ERP-järjestelmä syntyi 1960-luvulla varaston hallinnan kehittämisen seurauksena. ERPin yleistyessä ja ollessa uusi sen toivottiin ratkaisevan talousohjauksen ongelmia. (Pellinen 2005, 12–13.) ERPin voidaan ajatella syntyneen MRP-järjestelmistä, jotka oli pääasiassa tarkoitettu logistiikkaan tuotannon- sekä materiaalin hallintaan. ERP puolestaan kykenee eri toimintojen suorittamiseen keskitetysti jopa yli osasto rajojen. (Lahti & Salminen 2014, 40.) Suurien tietomäärien käsittely ja ohjaus helpottui ERP-järjestelmän myötä. Kuviossa kaksi kuvataan toiminnanohjausjärjestelmien kehitystä aikajanalla 1970- luvulta 1990-luvulle ja nykypäivän ERPiin. Kuvio 3. Toiminnanohjausjärjestelmän kehitys (Lahti & Salminen 2014, 34–38). Lahti ja Salminen (2014, 34–38) tietävät, että ERP-järjestelmä on varsin nuori, vasta parinkymmen vuoden ikäinen. Sen aikakausi alkoi, kun sähköistyminen ja digitalisaatio pääsivät kunnolla vauhtiin. Niiden myötä on myös panostettu loppukäyttäjien eli kuluttajien näkökulmaan, ohjelman käyttämisen helppouteen sekä niiden keskinäiseen integraatioon. Lahti ja Salminen (2014, 34–36) osoittavat todeksi vuosien kehityksen järjestelmien välillä olleen niin huimaa, että enää ei tarvitse välttämättä komentokielistä suoraa pääyhteyttä keskuskoneelle vaan integroitujen järjestelmien käyttö onnistuu nettiselainten kautta. Tällöin järjestelmää voi käyttää missä vain tietokoneen tai älylaitteen kautta. Eli ohjelmistot ovat kehittyneet erillisistä ohjelmistoista kokonaisiksi pakettisovelluksiksi. MRP 1970- luvulla MRP II 1980- luvulla ERP 1990-luvulla 14 Viime aikoina ERP kehitys on edennyt nopeasti kohti alustaratkaisuja. Tämä tarkoittaa juuri sitä, että ERP-järjestelmään integroidaan oma erillisohjelma tukemaan jotain yrityksen toiminnan osa-aluetta, kertovat Kaarlajärvi ja Salminen (2018, 35–36.) Nykyään useilla yrityksillä on myös käytössään ohjelmistojen pilvipalvelut ja tämä juuri on kasvattanut alusta ja pakettiratkaisujen määrää. Lahti ja Salminen (2014, 46) tietävät, että pilvipalvelussa ulkopuolinen palveluntarjoaja on vastuussa sovelluksen toiminnasta ja tarjoaa asiakasyrityksille palvelun käyttöoikeutta sekä tarvitsemiaan sovelluksia internetin välityksellä, tätä kutsutaan BSP-palveluntarjoajaksi. Kaarlajärvi ja Salminen (2018, 45–46) painottavat pilvipalvelun etuina olevan muun muassa kehityksen nopeuttaminen, ennakoitavat IT-kulut ja edullinen käyttö käyttäjäyrityksille. Pilvipalvelun helppous viehättää monia yrityksiä, sillä palveluntarjoaja vastaa sovelluksen toiminnasta ja päivityksistä. Käyttäjän vastuulle jää vain internetyhteyden hankkiminen. Kuviossa kolme esitetään taloushallinnon nykytilannetta yrityksissä ja sen kehitystä sekä niillä saatavia hyötyjä. Esimerkiksi integroidut järjestelmät lisäävät yrityksien automaatiota ja reaaliaikaisuutta. 15 Kuvio 4. Talousjärjestelmien nykytila (Kaarlajärvi & Salminen 2018, 41). Älykkäällä taloushallinnolla pyritään tehostamaan yrityksen eri prosessien keskinäistä toimintaa. Kaarlajärven ja Salmisen (2018, 49–53) mukaan yksi digitalisaation suurimpia uudistuksia 2020-luvulla ovat automaation käyttöönotto sekä ohjelmistorobotiikan käytönlisääntyminen yritysten arjessa. Tekoäly ja koneoppiminen mahdollistavat suuren määrän automaatiota, joka vapauttaa työntekijöiden työaikaa muuhun työskentelyyn. Näillä työkaluilla pystytään tehostamaan työntekijöiden työskentelyä. He mainitsevat myös, että tulevaisuudessa on mahdollista, että koneoppimisella voidaan korvata ERP-järjestelmien monimutkaisuutta ja yksinkertaistaa järjestelmää. Kaarlajärvi ja Salminen (2018, 53–55) kertovat ohjelmistorobotin hyödyntävän tietoa samoin, kuin työntekijä, mutta digiversiona. Ohjelmistorobotiikka toimii mainiosti tilanteissa, joissa on tarvetta automatisoinnille, jos se ei onnistu ohjelmiston avulla. Robotiikka toimii hyvin taloushallinnon automaation täydentäjänä. Integroidut järjestelmäympäristöt •Automaatio, tehokkuus ja audit trail •Reaaliaikainen kirjanpito Pilvipalvelut •Nopeus +kustannustehokkuus •Paikasta riippumattomuus Käyttäjäystävällisyys •Mobiilikäyttö Digitaalinendata •Prosessiautomaation perusta •Läpinäkyvyys Robotiikka ja tekoäly •koneoppiminen 16 2.2 Hyödyt Erp-järjestelmän suurimpia hyötyjä on tietojen reaaliaikainen päivittyminen ja seuranta myös eri yksiköiden välillä. Jo toteutuneiden lukujen avulla järjestelmä voi laskea ennusteita ja suunnitelmia pitkällekin tulevaisuuteen. Näin pystytään ohjaamaan yrityksen kehitystä oikeaan suuntaan. ERP-järjestelmien vahvuuksina voidaan myös mainita työn nopeutuminen moninkertaisen tiedon syötön jäädessä pois. Yrityksien työskentelyä nopeuttaa myös eri ohjelmien keskinäinen yhtenäistäminen, jolloin kaikissa käytössä olevissa ohjelmissa on samat yhtenäiset tiedot. Myös Kaarlejärvi ja Salminen (2018, 22–23) kuvailevat ERP-järjestelmän ja sähköisyyden hyviksi puoliksi sen reaaliaikaisuutta, vähentyneitä virheitä, vapautunutta työaikaa, jota voidaan kohdistaa tehokkaammin, lisääntynyt kilpailukykyä ja näiden myötä lisääntynyttä työtyytyväisyyttä. Granlund ja Malmi (2004, 23) pohtivat reaaliaikaisuuden lisäksi ERP:in hyödyksi yhdenmukaista tietokantaa yrityksen järjestelmässä. Lahti ja Salminen (2014, 32–33) korostavat ERP-järjestelmien hyötyinä työtehokkuuden sekä toiminnanlaadun paraneminen ja virheiden väheneminen ja kilpailukyvyn lisääntyminen. ERP-järjestelmä helpottaa ja edistää yritysten arkistointia sähköistymisen ja integraation ansiosta. Riippumattomuus ajasta ja paikasta lisäävät mahdollisuuksia esimerkiksi työmatkalla työntekoon. Edellä mainitut lisäävät työntekijöiden työtyytyväisyyttä. Kaarlejärvi ja Salminen (2018, 247–249) kirjoittavat, että läpimenoaikojen nopeutuminen, yleinen sujuvuus ja nopeus käytössä puhuvat ERP-järjestelmän puolesta. He (s.249) kertovat, että myös rutiiniprosessien korvaaminen automaatiolla mahdollistaa työajan kohdistamisen uusiin tehtäviin. Lahti ja Salminen (2008, 176) toteavat myös, että yritykselle oikeanlaisen järjestelmän avulla pystytään luomaan säästöjä manuaalisen työn vähenemisen ja tehostumisen myötä. Lahti ja Salminen (2008, 190–191) korostavat, että järjestelmämuutoksella saavutettuja hyötyjä on tarkasteltava ennalta asetettujen tavoitteiden pohjalta. Yrityksien on arvioitava esimerkiksi, miten toimintatavat ovat muuttuneet uuden ohjelmiston myötä sekä hiukan laajemmalti sidosryhmiin asti ulottuvat mahdolliset muutoksen hyödyt. 17 2.3 Haasteet ja ongelmat Toiminnanohjausjärjestelmien haasteina voidaan pitää uuteen järjestelmään siirryttäessä aikataulun venymistä ja kustannuksien ylittymistä. Toiminnanohjausjärjestelmä kokonaisuudet ovat hintavia. Työntekijöiden tietotekninen osaaminen saattaa heikentää digitaalisen toiminnanohjausjärjestelmän käyttöönottoa, käyttämistä ja kehittämistä yrityksissä. Tällöin kustannukset saattavat kasvaa verrattuna budjetoituihin. (Sundström 2012, 6–10.) Uuteen toiminnanohjausjärjestelmään opeteltaessa muiden työtehtävien teko saattaa häiriintyä. Uuden ohjelman käyttöönotto ja sisäänajo vaativat paljon resursseja. Tietojen siirrossa vanhasta järjestelmästä uuteen saattaa syntyä ongelmia esimerkiksi erilaisten tietomuotojen takia. Myös pankkiyhteysongelmien takia tiedonsiirto voi olla hidasta. (Sundström 2012, 6–10.) Visman (2019) mukaan ERP-järjestelmissä on erilaisia piirteitä ja niiden ennalta selvittäminen helpottaa käyttöönottoa ja käyttöä. Yritysten ja toiminnanohjausjärjestelmien väliset yksilölliset erot paljastuvat usein vasta, kun niitä yritetään sovittaa yhteen. Näitä yksityispiirteitä ei välttämättä voida tietää ennalta, joten ERPin sovittaminen yrityksen toimintaan saattaa olla haasteellisempaa, kuin luultiin tai luvattiin. Järjestelmä toimittajan valinnalla todella on väliä. Kokenut aiemmin saman toimialan järjestelmätoimituksia hoitanut osaa kertoa ja ymmärtää yleisimmistä haasteista. (Itewiki, [viitattu 24.10.2019].) Murch (2002, 163–164) kertoo, että riskit voidaan jaotella viiteen pääkategoriaan, joita ovat: ulkoiset- ja kustannusriskit, aikatauluun-, tekniikkaan- ja toimintaan liittyvät riskit. Taulukossa yksi esitetään ERP-järjestelmän SWOT-analyysi. Tiedot kuvaavat pilvipalveluna toimivan ERPin ominaisuuksia. 18 Taulukko 1. SWOT-analyysi (Itewiki, [viitattu 24.10.2019]). Vahvuudet Heikkoudet Uhat Mahdollisuudet tehokas riippuvuus internetistä muutosvastarinta yhteiskäyttö reaaliaikainen pelko tieturvasta osaaminen työajan säästö kokonaisuuden seuranta velvoite aineiston säilytyksestä rutiinit paikasta riippumattomuus helppous joustavuus 19 3 TOIMINNAN TEHOSTUMINEN JA SÄHKÖISYYS Ahoniemi ym. (2007, 66–67) kertovat, että tieto- ja viestintätekniikan kehittyessä sen tehtävä on muuttunut tukitoiminnoista, strategiseen kilpailuaseen kautta aina nykypäivän liiketoimintaa ja sen toimintatavat mahdollistavaksi teknologiaksi. Teknologian nopean kehityksen myötä myös taloushallinon ala kokee suuria muutoksia työnkuvissa ja järjestelmien ja ihmisten välisessä työsuhteessa. Yrityksen taloushallinnon kehittyminen vaatii uudelleen organisointia järjestelmien ja ihmisten kesken. Ihmiset ja järjestelmät yhdessä tuottavat tehokkaan datan, raportoinnin ja prosessit. Useimmat taloushallinnon prosessit digitalisoineista yrityksistä on saavuttanut noin 30 % kustannustehokkuuden parannuksen. (Kaarlajärvi & Salminen 2018, 19–22.) Prosessien digitalisoinnin tavoitteena on vähentää päällekkäisiä ja turhia työvaiheita automaation avulla. Tällaisissa toimintaketjuissa prosesseja täytyy tarkastella myös sidosryhmärajojen yli eli kaikkien yrityksen talousprosessien kehittämisen ja yhteensovittamisen kannalta. (Lahti & Salminen 2014, 25–26.) Kaarlajärvi ja Salminen (2018, 159–161) kertovat, että muun muassa kirjanpitäjän työnkuva tulee muuttumaan ja kehittymään lähivuosina. He mainitsevat, että sähköinen taloushallinto ja automatisoidut työvaiheet, kuten reskontrien täsmäytys helpottavat ja tehostavat kirjanpitäjien tehtäviä. Näin saadaan kohdistettua työaikaa sinne missä sitä tarvitaan. Tulevaisuudessa kirjanpitäjä tulee olemaan enemmän asiantuntija työtä, myös muualla organisaatiossa. He kirjoittavat myös (s. 262–263), että sähköisellä taloushallinnolla ja automaatiolla yritys voi hoitaa myös kokonaan itsepalveluna aiemmin talousosaston vastuulla olleita tehtäviä. Myös Granlund ja Malmi (2002, 16) kertovat, että tulevaisuudessa yrityksien olisi tuotettava taloushallinnon tehtävät entistä tehokkaammin ja virheettömästi. Työn tehokkuutta kehittäessä on olennaista miettiä mitä lähdetään kehittämään. Saavutetaanko tehtävän tekemisellä hyötyjä. Esimerkiksi paperitositteen tulostaminen ei välttämättä ole tarpeellista eikä hyödyllistä. (Kaarlajärvi & Salminen 2018, 178.) He painottavat (s. 247) myös, että prosesseja kehittäessä onkin mietittävä yrityksen toimintatapojen yhtenäisyyttä ja toimivuutta sekä laatua. 20 3.1 Työtehokkuus ja laatu Työajan säästäminen ja oikein kohdistaminen ovat tärkeitä ratkaisuja, joita tehokas toiminannanohjausjärjestelmä tukee. Kaarlajärvi ja Salminen (2018, 264–266) kertovat Lean-ajattelun hyödyntämisestä yrityksen kehittämisessä ja erityisesti asiakkaan näkökulmasta, tuottamaan lisäarvoa ja yrityksen näkökulmasta, laskemaan kustannuksia. He kertovat muutamia esimerkkejä, kuten ylilaadun välttäminen, hukka-ajan minimointi ja työtaakan tasaaminen kuukauden sisällä. Näillä kolmellakin yritys pystyy nostamaan työntehokkuutta ja lisäämään tarpeellista raportointia sekä työnimua. Kaarlajärvi ja Salminen (2018, 264–266) kertovat, että taloushallinnonhenkilöillä on luontainen taipumus tehdä työnsä viimeisen päälle, esimerkiksi raporttiin tästä saattaa kuitenkin kertyä epäolennaista lisätietoa, jota raportin käyttäjä ei tarvitse. Olisi keskityttävä enemmän olennaiseen. He (s.264–266) kirjoittavat myös, että yrityksen olisikin jatkuvasti oltava hiukan skeptinen raportoinnille ja yleiselle työntekemiselle. Jonkun on hyödyttävä tehdyistä raporteista ja työstä, mikäli näin ei ole ne ovat ajan hukkaa. Monet työntekijät tuntevat työssään tekemättömän työn painetta. Paine saattaa vaihdella kauden mukaan. Tasaisemmin jaettu työtaakka esimerkiksi automaation avulla lisäisi työtyytyväisyyttä sekä yrityksen raportoinnin tasoa. Kaarlajärvi ja Salminen (2018, 268–269) kertovat yrityksen eri sidosryhmien kokemasta laadun paranemisesta taloushallinnon kehittyessä yrityksessä. Yrityksien toiminnassa sähköistyminen ja automaatio lisääntyvät ja helpottavat työntekijöiden työkuormaa. He korostavat kuinka yritykset voivat luoda asiakasportaaleista hyvin asiakasystävällisiä. Teknologian lisääntyminen yrityksien toiminnassa kasvattaa myös taloushallinnon laatua ja läpinäkyvyyttä. Myös Paulin (2017) kirjoittaa, että automaation avulla pystytään parantamaan yrityksen toiminnan laatua. Esimerkkinä hän kertoo virheiden minimoimisen yhdenkertaisella tietojen syöttämisellä, jolloin virheiden riski pienenee ja tätä kautta yrityksen laatu voi parantua. Hän korostaa myös, että tehokkaalla ja yrityksen toimintaan sopivan järjestelmän avulla pystytään tekemään tulevaisuuden kannalta kannattavampia päätöksiä. Edellä mainittujen perusteella yritys pystyy varmistamaan laadun kehityksen ja täten kilpailukykyisemmän toiminnan. 21 Lahti ja Salminen (2014, 209–211) kertovat automatisoinnin kautta saaduista resurssi säästöistä, joita yritykset voivat kohdistaa muun muassa laadun parantamiseen. He mainitsevat myös automaation kautta saadusta työhyvinvoinnin lisääntymisestä. Yrityksen laatuun voidaan myös vaikuttaa johtamisen ja työntekijöiden ohjauksen kautta. Pellinen (2005, 50–51) kertoo yrityksen laatuun vaikuttavasta ohjausmekanismista. Klaaniohjauksella tarkoitetaan ihmisten halua olla osa organisaatiota ja toimia sen arvojen mukaisesti. Tätä toimintaa esimiehet voivat vahvistaa esimerkiksi koulutuksilla ja työn suunnittelulla. Työntekijät voidaan sitouttaa hyvällä tiedon kululla ja taloudellisilla kannusteilla, jotka koskevat koko organisaatiota. Yrityksen toimintakulttuurin kehityksessä ylimmän johdon toiminnalla on suuri vaikutus ja vastuu. 3.2 Sähköisyys ja sähköinen taloushallinto Yritykset tavoittelevat sähköistetyllä taloushallinnolla toiminnan tehostumista tietotekniikan ja erilaisten sovelluksien avulla. Siinä merkittävässä roolissa on sähköiset pankkiyhteydet, verkkolaskutus ja tehokas taloushallinnonjärjestelmä. (Suomela 2015.) Lahti ja Salminen (2014, 24–26) kertovat, että sähköisellä taloushallinnolla työnluonne muuttaa muotoaan, jolloin pystytään säästämään aikaa, jota voidaan kohdistaa muualle. Digitaalisessa taloushallinnossa prosesseja hoidetaan digitaalisessa muodossa. Suomela (2015) korostaa, että tehokkaan toiminnanohjausjärjestelmän ja koulutuksen avulla sen edut näkyvät nopeasti. Kuviossa viisi esitetään, kuinka nopeasti yritykset ovat kokeneet muutoksen paperittomasta kirjanpidosta aina älykkääseen kirjanpitoon saakka. Vielä 1990-luvulla eletiin paperittoman kirjanpidon aikaa, jolloin vain välttämättömät raportit esitettiin sähköisinä (Kaarlejärvi & Salminen 2018, 14–17). Sähköistymisen nopean kehittymisen myötä jo 2000 ja 2010-luvulla alettiin yrityksissäkin elää sähköisessä ja digitaalisessa maailmassa. Se nopeutti ja tehosti monien työtä. Tässä opinnäytetyössä ei sen syvällisemmin pureuduta älykkääseen taloushallintoon. 22 Kuvio 5. Taloushallinnon kehittyminen paperittomasta älykkääseen (Lahti & Salminen 2014, 27). Viime vuosina yritykset ovat keskittyneet tietovirtojen luomiseen digitaliseen muotoon organisaatioiden ja toiminnanohjausjärjestelmien välille. Kun tiedot kulkevat digitaalisesti yrityksen eri ohjelmien ja yksiköiden välillä voidaan niihin luoda automaatioita helpottamaan työtä ja säästämään aikaa. (Lahti & Salminen 2014, 27.) Kaarlajärvi ja Salminen (2018, 43) pohtivat, että nykyään on mahdollista ja jopa digitaalisen taloushallinnon kannalta välttämätöntä integroida ERP-järjestelmään erillisjärjestelmiä. Tätä kutsutaan tiedon jakamiseksi ohjelmistojen välillä, jolloin käytössä on keskitintyökalut. Keskitintyökalut tunnetaan myös nimellä EAI-ratkaisu (Enterprise Application Intergration). EAI-ratkaisulla luodaan ohjelmistojen välille rajapinnat, joiden avulla käsitellään tiedon kulkua ohjelmistojen välillä. Pellinen (2005, 68) toteaa yrityksien laadun mittaamisen olevan haasteellista, mutta todella tarpeellista yrityksien kehityksen kannalta. Yrityksien on määriteltävä haluttu tavoitetaso, kuinka se saavutettaisiin ja miten sitä mitataan saadakseen mittaustuloksia. Sähköisyyden ja paperittomuuden mahdollisuus oli Suomessa jo 1990-luvulla, kun lainsäädäntö muuttui. Suomi olikin tällöin netin käytön kärkimaa. Ilmiötä edesauttoivat myös yhteiset pankkistandardit ja viitteet, joiden avulla tapahtumat käsiteltiin automaattisesti. Sekä sähköisesti käsiteltävät tiliotteet. Suomessa yleistyi nopeasti netissä maksaminen, joka kasvatti luottamusta internettiä kohtaan. (Lahti & Salminen 2014, 28–29.) Paperiton kirjanpito Sähköinen taloushallinto Digitaalinen taloushallinto Älykäs taloushallinto 23 Verkkolaskutuksen yleistyminen Suomessa on ollut kuitenkin hidasta. Isolla osalla yrityksistä on käytössään mahdollisuus verkkolaskujen käyttöön sitä ei kuitenkaan hyödynnetä niin hyvin kuin mahdollista. Yksityishenkilöiden kohdalla e-laskujen käyttö on lisääntynyt merkittävästi viime vuosina. (Lahti & Salminen 2014, 28–30.) He mainitsevat myös, että yrityksien sähköistä kehitystä on saattanut hidastaa toimialoille epäsopivat taloushallintojärjestelmät myös tiivis teknologioiden ja uusien toimintamallien oppiminen on vaatinut aikansa organisaatioilta sekä sähköisyyden monimutkaisuus. Yli 70 prosenttia Suomen yrityksistä kuitenkin hyödyntää verkkolaskuja ja useissa yrityksissä niiden käyttö on sata prosenttia. (Similä 2019.) Similä (2019) kirjoittaa, että tehokkaalla sähköisellä ohjelmistolla on tärkeä rooli yrityksien kannattavan kasvun tiellä. Hän kertoo sähköistymisen olevan taloushallinnon alalla tällä hetkellä vallitseva trendi. Edellisen 12 kuukauden aikana noin 20 prosenttia yrityksistä on aloittanut sähköisen taloushallinnon ohjelmiston käytön. Kirjanpitolain (L 30.12.1997/1336) 6–10§:n mukaan tositteita on mahdollista säilyttää sähköisessä muodossa. Lain mukaan sähköistä tositetta voi säilyttää maantieteellisesti missä vain eikä siitä tarvitse olla kopiota, kunhan se on todennettavissa ja tulostettavissa Suomessa. Vaatimukset sähköisen kirjanpidon säilytyksestä ovat muuttuneet viimevuosina tulleen lainuudistuksen myötä. Lainuudistus edesauttaa sähköistä tallennusta. Sähköisen arkistoinnin hyvinä puolina voidaan mainita muun muassa tietojen hakemisen nopeus ja paikasta riippumattomuus, joustavan työnteon lisääntyminen sekä tietojen hyödynnettävyys tulevaisuudessa on parempi. Myös tilojen ja luonnon säästäminen ovat merkittävä seikka yrityksille. (Kaarlajärvi & Salminen 2018, 90–92.) Raportoinnin merkitys on aina ollut yrityksien talouden ja kehityksen kannalta merkittävä (Pellinen 2005, 75). Havainnoijan mukaan sähköisyyden kasvaessa myös raportointi on helpompaa ja ohjelmilla erilaisten raporttien muodostaminen yksinkertaisempaa. Myös eri ohjelmien välillä raporttien laatiminen lisää tehokkuutta yrityksen toiminnassa ja helpottaa raportointi ja johtotason yhteistyötä ja päätöksentekoa. Uusi toiminnanohjausjärjestelmä tai sähköisyys eivät takaa tehokasta raportointia 24 vaan sen kehityksessä tulee ensin laittaa perusasiat kuntoon, että on vain yksi totuus ja yhdet luvut. Tällöin sisäinen ja ulkoinen laskenta integroituvat yhteen. (Lahti & Salminen 2014, 172.) 3.2.1 Integroitu taloushallinto Toiminnanohjausjärjestelmä teknologia on kehittynyt vahvasti eri ohjelmistojen yhteen liittämisen aikakaudelle. Yritykset ottavat käyttöönsä toiminnanohjausjärjestelmän ja liittävät siihen tarvitsemansa ohjelmat. Tämän kokonaisuuden tarkoituksena on muodostaa reaaliaikainen lopputulos. (Granlund & Malmi 2004, 148.) Integroidulla taloushallinnolla pyritään tehokkaasti kohti yhtenäisiä lukuja niin sisäisessä kuin ulkoisessakin laskennassa. Tämä tehostaa ja helpottaa yrityksien raportointia, ja huomattava kehitys on yrityksien sisäisen laskennan reaaliaikaisuus. (Granlund & Malmi 2004, 149.) He kirjoittavat kuitenkin myös, että reaaliaikaisella tiedolla on myös varjopuolensa, joka saattaa yrityksissä johtaa liian nopeisiin ja lyhyesti harkittuihin päätöksiin. Sähköisen ja integroidun taloushallinnon hyvinä puolina voidaan vielä kertoa tapahtumien haun kehittymisen todella yksinkertaiseksi esimerkiksi pelkällä laskunnumerolla sähköisestä arkistosta (Kaarlajärvi & Salminen 2018, 42–43). Granlund ja Malmi (2004, 150) painottavat myös aiemmin jopa kymmenien mappien kellarissa selaamisen sijaan tähän kuluu aikaa sekunneista muutamaan minuuttiin. Kuviossa kuusi havainnollistetaan mitä integroitu taloushallinto yhdistää ja mitä hyötyjä siitä muun muassa on. 25 Kuvio 6. Integroitu taloushallinto (Kaarlajärvi & Salminen 2018, 44). 3.2.2 Digitaalisuuden vaikutus Aiemmin yrityksien oli mietittävä, ulkoistetaanko palveluita vai ei. Se oli niin sanotusti hyvin mustavalkoisesti joko-tai-ajattelua. Digitaalisuus on tuonut mukanaan vaihtoehtoihin paljon harmaan eri sävyjä, joista valita omansa. Esimerkiksi yritykset voivat valita, hankitaanko kokonaisuus vai muodostetaanko se itse täsmäratkaisuista. Näillä valinnoilla on yrityksen kustannuksien ja tavoiteltavan tehokkuuden kannalta suuri merkitys. (Kaarlajärvi & Salminen 2018, 207–214.) He kertovat tehokkaan taloushallinnon muodostuvan useista tekijöistä, kuten: – yhteinen ERP-järjestelmä – yhtenäistetyt toiminnot – automatisoidut ja integroidut joustavat prosessit – yksi yhtenäinen tieto – selkeät roolit ja vastuut – systemaattinen kehitys Integroitu taloushallinto Yhtenäiset tehokkaat prosessit Reaaliaikaiset automaattiset tiliöinnit Tiliöintien ohjaus Audit trail Verkkolaskut Automaattiset täsmäytykset Raportointi 26 3.3 Seuranta Järvenpää ym. (2017, 402–403) kirjoittavat, että investoinnin onnistumista yrityksissä tulee seurata koko prosessin ajan. Seurannan olennaisin hyöty saadaan sen parantaessa tulevaisuuden investointitoimintaa. Tällä tarkoitetaan tulevaisuudessa realistisia esityksiä investointi uudistuksista ja ohjelmista, myös korjaustoimenpiteet paranevat. Investointiprosessin alussa yrityksissä tulee nimetä vastuuhenkilöt eri osa-alueille selkeyden lisäämiseksi ja prosessin onnistumisen takaamiseksi. He kertovat myös, että tarkkailulla on mahdollista vaikuttaa positiivisesti tulevissa investoinneissa virheiden uusiutumattomuuteen ja kannattavuuden paranemiseen sekä tavoitteiden saavuttamiseen. Lahti ja Salminen (2014, 227) pohtivat, että investoinnin onnistumisessa on myös olennaista arvioida ovatko toimintatavat muuttuneet sekä arvioida hyödynnetäänkö digitaalisuutta parhaalla mahdollisella tavalla ja asetettujen tavoitteiden mukaisesti. He kirjoittavat myös, että yrityksen on arvioitava ovatko prosessit kehittyneet yksinkertaisemmiksi ja automatisoiduimmaksi. Pystyvätkö työntekijät keskittymään olennaisiin työtehtäviin ja järjestelmän hoitaessa rutiinitöitä. Ovatko työntekijät tyytyväisempiä työhönsä. Granlund ja Malmi (2004, 16) kirjoittavat yrityksien järjestelmävaihdosprojektien olevan pitkiä prosesseja. Järjestelmävaihdoilla tavoitellaan usein tehokkuutta, etenkin taloushallintoon. Tällaiset järjestelmävaihdokset voivat työllistää yritystä pitkäänkin sen käyttöönoton jälkeen, jopa puolet controllerin työajastaa saattaa kulua järjestelmän kehittämiseen ja muovaamiseen yrityksen käyttöön sopivaksi, ennen tehokkuuden näkymistä tuloksissa (mp.). 27 4 MENETELMÄT Tutkimus on tyypiltään kvalitatiivinen eli laadullinen. Siinä pyritään kuvaamaan ongelmaa mahdollisimman kokonaisvaltaisesti. Aineisto kootaan todellisissa tilanteissa ja kohdejoukko valitaan tarkoin. Tutkimusaineisto saadaan kohdejoukkoa haastattelemalla ja havainnoimalla. (Hirsjärvi ym. 2007, 207–210.) Haastattelut voidaan toteuttaa esimerkiksi teemahaastatteluina, jolloin tutkimusjoukolla on aihepiiri etukäteen tiedossa, mutta he eivät tiedä tarkkoja kysymyksiä (Liukkonen & Liuksiala 2008, 3–4). Tässä työssä tutkimus suoritetaan teemahaastatteluina, jotka nauhoitetaan laadun varmistamiseksi. Tutkimusjoukko on ennalta valittu ja he tietävät haastattelun aihepiirin ennalta, mutta eivät tarkkoja kysymyksiä. Haastattelutasoiksi on valittu suorittaja, raportointi sekä yrityksen johtotaso. Suorittajatasolta haastatellaan kahta eri henkilöä, samoin johtotasolta. Haastattelut suoritetaan suoritus ja raportointi tasolle viikolla 39 ja uudelleen viikolla 46. Johtotason haastattelut suoritetaan viikolla 43. Haastatteluita suoritetaan mahdollisimman kattavan ja käytännönläheisen tiedon saamiseksi. Haastateltavat valitaan siten, että yrityksen eri työskentely näkökulmat tulevat esille toiminnanohjausjärjestelmän käyttöön ja käyttöönotto projektiin vankasti liittyen. Haastateltaviksi on valittu Lakea Oy:n toimitusjohtaja, talousjohtaja, controller ja yksi kirjanpitäjistä. Haastateltavat ovat olleet toiminnanohjausjärjestelmän vaihdoksessa mukana alusta saakka ja osa heistä työskentelee päivittäin sen kanssa. Johtotasoja valittiin työhön kaksi, koska kirjoittaja haluaa kokonaisvaltaisesti koko yrityksen toimintaa koskevia kommentteja, joita toimitusjohtaja pystyy tarjoamaan. Talousjohtajan näkökulma pureutuu hyvin lähelle järjestelmää ja sen käyttöönottoa, kun toimitusjohtaja havainnoi hiukan enemmän yrityksen kokonaiskuvaa. Kirjanpitäjän näkökulma on hyvin käytännönläheinen, kun taas controller tarjoaa kirjanpitäjän ja talousjohtajan väliltä hyvin tiiviitä ja asiapitoisia yrityksen raportointiin ja kehitykseen vaikuttavia kommentteja. Näistä neljästä näkökulmasta koostuu hyvin kokonaisvaltainen näkemys uudesta toiminnanohjausjärjestelmästä ja sen vaikutuksista Lakea Oy:n tulevaisuuden kehitykseen. 28 Työssä haastateltavista käytetään seuraavia nimikkeitä: – kirjapitäjä = tekijätaso – controller = raportointitaso – talousjohtaja = johtotaso 2 – toimitusjohtaja = johtotaso 1 Kuviossa seitsemän havainnollistetaan kuinka paljon eritasot käyttävät uutta toiminnanohjausjärjestelmää. Ympyrämallilla pyritään kuvaamaan, kuinka lähellä järjestelmää taso toimii. Esimerkiksi tekijä eli kirjanpitäjä käyttää järjestelmää päivittäisessä työssään sijoittuu hän lähimmäksi keskustaa, kun taas johto 1 eli toimitusjohtaja käyttää järjestelmää vain satunnaisesti hän sijoittuu ympyrässä uloimmaksi. Ympyrä ei sijoita haastateltavia työtehtäviltään vaativuusjärjestykseen Kuvio 7. Eritasojen Netvisorin käyttö case-yrityksessä. . Johto 1 Johto 2 Raportointi Tekijä 29 5 CASE LAKEA OY 5.1 Yritys esittely Lakea Oy on perustettu vuonna 1975 ja sen omistaa 15 pohjalaista kuntaa. Aiemmin Lakea Oy tunnettiin nimellä Pohjanmaan YH-rakennuttajat, mutta sittemmin nimi muuttui. Yritys on toiminut asuntojen rakennuttamisen, vuokraamisen sekä myynnin ja isännöinnin alalla jo 40 vuotta. Lakea Oy:n tavoitteena on kehittää palvelujaan jatkuvasti ja vaikuttaa siten asumisen laatuun sekä turvallisuuteen. Yrityksen arvoihin sisältyvät luotettavuus ja vastuullisuus. (Lakea Oy 2019.) Yrityksessä työskentelee noin 50 työntekijää erilaisissa työtehtävissä. Toimipisteitä Lakea Oy:llä on viidellä eri paikkakunnalla Seinäjoella, Vaasassa, Vantaalla, Kokkolassa ja Jyväskylässä. Tulevaisuudessa yritys kehittää toimintaansa muun muassa puurakentamista kohti. (Lakea Oy 2019.) 5.2 Taustatekijät järjestelmän vaihtoon Lakealla on aiemmin ollut käytössään Visma L7 -niminen toiminnanohjausjärjestelmä, joka oli vastannut hyvin yrityksen tarpeita. Viime vuosina yrityksen toiminnan kasvaessa L7:n resurssit jäivät pieniksi, mikä ilmeni päivittäisessä työssä hitautena. Esimerkiksi toisen kirjanpitäjän ajaessa raporttia, ei toinen voinut ajaa tarvitsemaan raporttia yhtä aikaa. Järjestelmään ei tiedettävästi sellaisenaan enää ollut päivityksiä saatavilla, joten uuden ohjelmiston hankinta tuli ajankohtaiseksi. Uudelle toiminnanohjausjärjestelmälle asetettiin tavoitteita mitä sen avulla tuli saavuttaa. Haastateltavat kertoivat suurimpina syinä järjestelmän vaihtoon seuraavia kohtia – halu kehittää yrityksen toimintaa sähköisemmäksi, – prosessien tehostaminen – edellisen järjestelmän vanhanaikaisuus suhteessa yhtiön toimintaan. 30 Lakea Oy:lla tavoitellaan uuden toiminnanohjausjärjestelmän myötä sähköisempää taloushallintoa ja tämän myötä laadukkaampaa palvelua asiakkaille ja nykyaikaisempaa työskentelyilmapiiriä työntekijöille. Lakea Oy:n toimialalle sopivia järjestelmiä ei ole monia. Järjestelmän täytyy vähintään integraatio ratkaisujen avulla pystyä tukemaan muun muassa isännöintiä, myyntiä ja markkinointi, rakennuttamista ja kiinteistönhallintaan liittyvää toimintaa. Lakealta kerrotaan, että järjestelmä valintaan vaikuttavan muun muassa liiketoiminta ja toimintasuunnitelma sekä mitä ohjelmistolla halutaan saavuttaa, esimerkkinä he kertovat, että voimakas digitaalisuus asettaa omat rajansa ohjelmisto valinnalle. Yrityksessä punnittiin neljän eri ohjelmiston välillä ennen Netvisoriin päätymistä. Aiemmin oli kuitenkin tehty päätös rakentaa ohjelmisto uudistus uutta vuokrareskontraohjelmaa tukien, joten tämä vaikutti myös valintaa. Visman ollessa toimialallaan markkinajohtaja mietittiin tuoteperheestä eri vaihtoehtoja. Näin ollen Lakea Oy:n oli helpompaa päätyä valitsemaan toiminnanohjausjärjestelmä samalta toimittajalta. Lakea Oy on viime vuosina tehnyt uudistuksia, kuten saavuttanut uusia liiketoiminta alueita, rekrytoinut uutta henkilöstöä, taloushallinnon toimintoja on muokattu kustannuspaikkojen ja raportoinnin osalta. Tällaiset muutokset ovat rankkoja koko henkilöstölle. Suurien muutosten johdosta yrityksen toiminnassa oikean ajankohdan löytäminen toiminnanohjausjärjestelmän vaihtoon on todella tärkeää. Havainnoijan mukaan Lakea Oy:llä kirjanpitäjien työn kuvan muuttuminen ja työn tehostuminen näkyvät esimerkiksi integraation liitännän avulla Netvisoriin liitetyn kiinteistöhallinta ohjelmiston avulla, joilla taloyhtiön asukkaat pääsevät näkemään omat laskunsa ja maksutietonsa. Näin ollen asukkaiden ei tarvitse enää soittaa saadakseen tietää maksujen tilan. Kirjanpitäjien työaikaa säästyy ja se voidaan kohdistaa muualle. 31 5.3 Visma L7 Visma L7 on 1990-luvulla kehitetty toiminnanohjausjärjestelmä, joka on saatavilla muun muassa pilvipalveluna sovelluspalvelu, joka takaa yrityksille työskentelyyn ajasta ja paikasta riippumattomuuden. Havainnoijan mukaan L7 polveutuu Linus 6 -ohjelmistosta kehityksen myötä. Visma L7 -toiminnanohjausjärjestelmään yritykset pystyvät valitsemaan mitä sovelluksia ottavat käyttöön, esimerkiksi palkanlaskennan voi jättää pois, jos sille ei ole tarvetta. L7 on suunnattu enemmän teollisuuden, energiatuotannon ja urakoinnin toimialoille, niille yhteisen toiminnan luonteen jatkuvan muutoksen takia. (Visma 2019). 5.3.1 Ominaisuudet Havainnoijan mukaan ohjelmisto on kehitetty pala kerallaan ja ohjelmaa käyttäessä ohjelmisto avaa ikkunoita toistensa päälle. Tällainen monien ikkunoiden päällekkäisyys saattoi aiheuttaa ohjelmiston hitaus ongelmat Lakea Oy:llä. Myös ohjelmiston käyttö oli ehkä suunnattu hiukan pienempään tarkoitukseen. Ohjelmiston kapasiteetti loppui kesken. Ohjelmiston hyviä puolia tarkkailijan mukaan ovat tiedonhallinnan helppous ja tiedon luotettavuus. 5.4 Netvisor Netvisor on Visman ylläpitämä toiminnanohjausjärjestelmä, joka on kehitetty 2000- lun alkupuolella. Se soveltuu monipuolisuutensa ansiosta myös rakennuttamistoimialalle. Järjestelmään ostetaan lisenssejä, joita yrityksen työntekijät voivat käyttää älylaitteillaan paikasta riippumatta. Järjestelmä on SAAS-ohjelmisto alusta eli pilvipalveluna. Netvisorin rajapintojen avulla yritykset pystyvät luopumaan lähes kokonaan manuaalisesta tiedon syötöstä. Syksyllä 2019 Netvisor ohjelmaan oli integroitu kaikkiaan 300 eri ohjelmistoa. Netvisor on kasvattanut suosiotaan markkinoilla viime vuosina 32 ja saman suosion uskotaan jatkuva tulevaisuudessakin. (Visma Solutions 26.8.2019; Visma 2019.) Kuviossa kahdeksan esitetään kuinka Netvisorin tarjoama ohjelmistojen välinen rajapinta mahdollistaa edes takaisen tiedon liikkeen ohjelmistojen välillä. Netvisor vaatii kuitenkin kanssa yhtenäistettävältä ohjelmalta joitain ominaisuuksia, kuten esimerkiksi tietyt maakoodit ja päivämäärien kirjoittaminen ANSI-muodossa. Ansi tunnetaan nimellä American National Standards Institutein eli standardi merkistöjen koodaamiselle. (Visma 2019.) Kuvio 8. Netvisorin rajapinnat (Visma 2019). 5.4.1 Ominaisuudet Havainnoijan mukaan ohjelmiston hyviä puolia ovat eri välilehdissä toimiminen, nopeus ladatessa, tositteiden kautta tietoihin porautuminen on helppoa sekä ohjelmiston kyky kertoa missä virhe on esimerkiksi alv-laskelmaa täyttäessä. Heikkoina ominaisuuksina yhteydet muihin järjestelmiin sekä kustannuspaikka herkkyys. Myös eräänlainen tiedon luotettavuus ongelma on tullut esille. Isoimmat erot yritysten välillä yleensä havainnoidaan raportointiprosesseissa sekä integraatioissa. (Kaarlejärvi & Salminen 2018, 33.) Netvisor on hyvin laaja-alainen järjestelmä, joka sisältää eri toiminnallisuuksia, joista yritys voi valita käyttöönsä sopivimmat. Näin ollen yritykset voivat liittää Netvisoriin myös muita tarvitsemiaan ohjelmia. Granlund ja Malmi (2004, 151) toteavat, että 33 usein yhden järjestelmän tehokas kokonaisuus jää vain ideaalitilanteen haaveeksi. He kirjoittavat (s. 152) myös, että yritysten integraatio tarpeet tulevat tulevaisuudessa kasvamaan ja, että yritysten, jotka ovat ottaneet ERP: in käyttöönsä kannattavuuskehitys on parantunut. Tätä tarvetta Netvisor järjestelmä tukee. Kaarlejärvi ja Salminen (2018, 263–264) muistuttavat, että kehitys ei ole vain teknologiaa. He korostavat toimivaa kokonaisuutta ja niin kutsuttua maalaisjärkeä. Ihmisten sopeutuvuus ja halu hyötyä uudesta määrittelee hyvin pitkälle tehokkuuden. 5.5 Järjestelmän vaihdos Haastatteluiden mukaan Lakea Oy:n uuteen toiminnanohjausjärjestelmään siirtyminen sujui teknisesti hyvin. Raportointitaso kertoi, että ohjelmisto ei kuitenkaan sisällä aivan kaikkia ominaisuuksia, mitä oli annettu ymmärtää. Esimerkkinä hän kertoi yrityksen hyödyntävän toiminnassaan kustannuspaikkoia, ne ovat hyvin tärkeässä asemassa rahavirtojen kohdistuksessa ja seurannassa. Nämä ominaisuudet jäivät uudessa ohjelmassa hiukan vajavaisiksi verrattuna edelliseen ohjelmaan. Haastatteluiden mukaan käyttöönotossa ilmeni hiukan hankaluuksia integraatioissa muiden yrityksessä käytössä olevien ohjelmien välillä. Ohjelmien välisten rajapintojen muodostaminen on ollut haastavaa. Ongelma ilmeni esimerkiksi yrityksellä käytössä olevan vuokrareskontraan tulevien suoritusten kirjauksissa, jotka täytyy syöttää käsin järjestelmään yhteyden puuttuessa, havainnollisti suorittajataso. Granlund (2011) kirjoittaa, että olisi hyvä paneutua rajapintojen luomiseen ja mahdollisiin haasteisiin hyvin ennen ohjelman vaihdosta. hän kertoo, että hyvällä suunnittelulla ja toteutuksella pahimmilta ongelmilta voisi välttyä. Haastatteluiden mukaan uuden järjestelmän käyttöönotossa koettiin hiukan hankalana myös historia tietojen siirtäminen edellisestä järjestelmästä uuteen. Tähän suurimpana syynä paljastui tietojen paljous sekä tiedostojen oikea muoto. Siirrettävän datan tulee olla oikeassa muodossa, jotta sen voi siirtää Netvisoriin napin painallukselle. Siirto vaati siis yritykseltä paljon pohjatyötä, ennen itse siirtoa. Lakea Oy: n oli myös valita kuinka paljon historiatietoa kannattaa siirtää. Massaa on niin paljon, että sitä on pakko karsia. 34 Haastatteluissa ilmeni tarve Netvisorin data-analysaattorille, joilla tietoa voisi suodattaa raporteille. Tällä hetkellä järjestelmä ei pysty hakemaan yrityksen tarpeeseen sopivia kustannuspaikkakohtaista raporttia ollenkaan. Lakea Oy:lle se olisi tärkeää ja hyödyllistä. Lakea Oy elää Netvisorin käyttöönoton myötä enemmän sähköisen ja digitaalisen taloushallinnon välimaastossa, kuin aiemmin. Yksi järjestelmän vaihtamiseen vaikuttanut tekijä olikin yrityksen halu päästä eroon paperista ja siirtyä enemmän sähköiseen ja digitaalisempaan taloushallintoon. Automatisointi ei Lakealla ole kovin suuressa roolissa, sillä se ei ole toiminnan monimuotisuuden takia järkevää. Automaattikirjauksien korjauksiin menisi enemmän aikaa, kuin siihen, että työntekijä kirjaa itse. Lakea Oy: n kannalta on ainakin toistaiseksi tehokkaampaa tiliöidä itse ostolaskut kuin käyttää automaatiota. Havainnoijan mukaan automaattikirjauksia tullaan kuitenkin ottamaan käyttöön tulevaisuudessa tietyissä toistuvissa kuukausittaisissa kirjauksissa. Yritys suunnittelee myös automaation käyttöä laskujen kierrätyksessä. 35 6 HAVAINNOT Haastattelujen tuloksia havainnoidaan asetettujen tavoitteiden sähköisyyden lisääntymisen ja työn tehostumisen näkökulmista. Haastatteluissa nousivat useasti esiin myös integraatio haasteet ja laadun paraneminen. Uusi ohjelmisto on ollut käytössä Lakea Oy:llä kyselyjen toteutus hetkellä puoli vuotta. 6.1 Sähköisyys Yksi tavoitteista järjestelmän vaihdolle on paperittomuus ja sähköisten tositteiden lisääntyminen eli askel kohti sähköistä taloushallintoa. Netvisorin käyttöönoton jälkeen yrityksen paperitositteet ovat vähentyneet huomattavasti yrityksen toiminnassa ja esimerkiksi kuukausittainen tositemappi on nykyään sähköisessä muodossa. Johtotason 1 mukaan tarve sähköiselle taloushallinnolle ja sen kehittämiselle tuli ajankohtaiseksi yritykselle nyt, yhtiön aiempien vuosien muutos töiden jälkeen. Raportointitason mukaan papereista on päästy eroon, aivan kuten tavoiteltiin. Johtotaso 2 uskoo sähköisyyden lisääntyvän vielä tulevina vuosina. Paperilaskujen käyttö Lakealla on nykyisinkin maltillista. Yritys lähettää vuokra asukkaille laskuja postitse kerran vuodessa ja tätä laskua hyödynnetään koko vuosi. Lasku sisältää kuukausittaisen maksuerittelyn ja maksutiedot. Tulevaisuudessa postin kulun luotettavuuden heikentyessä sähköisenlaskun lähetys tulee ajankohtaiseksi. Lakea Oy pystyy uuden toiminnanohjausjärjestelmän ja sen integraatioiden myötä tarjoamaan verkkolaskuja asiakkailleen yhä tehokkaammin, siitä huolimatta yrityksessä käytetään myös edelleen paperilaskuja. Vuokralaskutuksessa asiakkailla on käytössään vielä noin puolella paperilasku, kun yrityksen myynti ja ostolaskutus hoidetaan pääsääntöisesti verkkolaskuina. Lakealla on otettu käyttöön asukkaille portaali, jossa asukkaat pääsevät näkemään omia tietojaan, esimerkiksi suorituksia ja varamaan saunavuoroja. Portaalia on tällä hetkellä otettu käyttöön maltillisesti. Se lienee sen uutuuden viehätyksen ansiota. 36 Johtotaso 2 uskoo, että portaalin kautta sähköistenlaskujen osuus nousee ja paperisten osuus vähenee. Tulevaisuudessa portaalin kautta mahdollisesti pystytään lähettämään laskut suoraan asiakkaan sähköpostiin. Sähköinen taloushallinto helpottaa yritysten jokapäiväistä toimintaa. Lakea Oy:llä sähköisyyden lisääntyminen helpottaa muun muassa raportointia, laskutusta ja kuukausi kirjapitoa eli jokapäiväistä työntekoa. Sähköisen taloushallinnon ja automaation avulla yritys voi säästää työaikaa ja lisätä asiakkaiden tyytyväisyyttä ja kiinnostusta yritystä kohtaan. Johtotason 2 mukaan sähköinen taloushallinto ja sähköisyyden lisääntyminen Lakea Oy:n toiminnassa kasvattaisi yrityksen laatua. Hän kuvailee, että esimerkiksi postin toimintaa liittyy riski, lähettäjä vain toivoo kirjeen päätyvän joskus perille määrittelemättömässä ajassa. Sähköisesti lähettäessä kirjeen perille löytäminen on varmempaa ja nopeampaa. Johtotaso 2 mainitsee säästyvän työajan lisääntyvän, kun nyt vielä puhelimitse ja henkilökohtaisesti hoidettavat asiat siirtyvät sähköiseen asukasportaaliin. Johtotaso 1 näkee, että sähköistyminen kasvattaisi yrityksen laatua. Asukkailla voisi olla puhelinsovellus, josta näkee hintakertymän, kuten pankkien sovelluksista näkee lainakertymän ja seuraavat erät. Sovelluksen käytettävyyttä lisäisi johtotaso 1 mielestään toiminnanlisäys esimerkiksi saunavuorojen merkeissä. 6.2 Toiminnan tehostuminen Sähköistynyt tositteiden ja raporttien tallennus on lisännyt työn tehokkuutta. Työntekijöiden on nopeampi hakea eri aikakausien raportteja tai tositteita sähköisestä tallennuskansiosta. Ylimääräinen odottelu ohjelman ladatessa on vähentynyt ja työajan voi käyttää tehokkaammin. Yrityksen johtotaso 2 ja raportointitason mukaan raporttien noutaminen uudesta järjestelmästä on nopeampaa ja tehokkaampaa, kuin entisestä järjestelmästä. Suorittajataso kertoo reskontrien täsmäytyksen olevan helpompaa ja yksinkertaisempaa, kuina aiemmin, työn helppous. 37 Haastatteluissa ilmeni myös uuden ohjelmiston hiukan haasteelliset integraatio yhteydet. Hitaat tai olemattomat yhteydet yrityksen eri ohjelmistojen välillä hidastavat ja jopa vaikeuttavat työtä. Ohjelmiston käyttöönotto vaiheessa on tärkeää, että yrityksellä säilyy kontakti ohjelmiston tarjoajaan ja ongelmaa ratkotaan yhdessä. Suorittajatason mukaan puutteita on ilmennyt integraatioissa Netvisorin ja muiden ohjelmien välillä ja Lakealla on jouduttu syöttämään tietoja käsin yhteyksien puuttuessa. Haastateltava uskoo kuitenkin uuden ohjelmiston mukautuvan ajan myötä Lakean käyttöön sopivaksi ja että toiminnasta tulevan sujuvaa. Suorittajataso toteaa kustannuspaikoittain kohteiden raporttien ja rahavirtojen seuraamisen olevan Netvisorissa haastavaa. Yritys onkin hyödyntänyt tässä integraatio ratkaisuja. Hän toteaa myös, että järjestelmä vaihdos on muuttanut työnkuvaa enemmän manuaaliseksi kuin oli tarkoitus. Suorittaja- ja raportointitaso näkevät tulevaisuuden Netvisorin kanssa positiivisena, mutta toivovat toiminnanohjausjärjestelmän ylläpitäjältä päivityksiä ja kehitystä muun muassa raportointiin. Näiden avulla he uskovat järjestelmän tuovan tehokkuutta yrityksen toimintaan. Uuden toiminnanohjausjärjestelmän käyttöönoton myötä Lakealla on alettu hyödyntämään enemmän ohjelmien välisiä integraatioita. Näiden avulla tiedon kulku eriohjelmien ja yksiköiden välillä on tehostunut. Johtotason 2 mukaan tiedot on saatu linkitettyä paremmin yhteen, kuin aiemmalla ohjelmalla, mikä tehostaa niiden käytettävyyttä, muiden yhtiön ohjelmien välillä. Tänä vuonna Lakea Oy:n työpanokset ovat kuluneet Netvisorin käyttöönottoon ja eri työnvaiheiden sisäänajoon. Uuden ohjelmiston käyttöönotto on suuri investointi, joka vaatii panostuksia koko työntekijäkunnalta ja jonka vaikutukset näkyvät yrityksen toiminnassa vasta tulevaisuudessa. Johtotaso 2 uskoo työntehokkuuden nousevan tulevina vuosina. Hän uskoo myös, että tulevaisuudessa Netvisor säästää työaikaa, joka tullaan mahdollisuuksien mukaan kohdistamaan työnkehitykseen. Turhien työvaiheiden jäädessä pois johtotaso 2 ajattelee työntekijöiden työnimun ja työmotivaation kasvavan. Johtotaso 1 uskoo, että sisäänajo vaiheen jälkeen, kun ohjelmaa opitaan käyttämään vielä paremmin ja hyödyntämään sen ominaisuuksia paremmin sekä saadaan 38 muokattua sitä yrityksen käyttöön vielä sopivammaksi se tehostaa yrityksen toimintaa. Tämän myötä säästämään työaikaa. Hän myös uskoo sen vaikuttavan positiivisesti työntekijöiden työmotivaatioon turhien työvaiheiden jäädessä pois. Automaation avulla voidaan tulevaisuudessa helpottaa kuukausittaisia työtehtäviä, kuten esimerkiksi myyntireskontran hoitoa. Netvisoriin on integroitu muita ohjelmia luomaan kokonaisvaltainen juuri Lakea Oy:lle sopiva kokonaisuus. Näillä ohjelmilla ja automaatiolla pystytään helpottamaan ja yksinkertaistamaan työntekijöiden työtä. Johtotason 2 mukaan tulevaisuudessa voidaan automaation avulla helpottaa kuukausittain jakautuvaa työkuormaa tasaisemmaksi, sekä helpottaa raporttien ja kirjanpidon muodostamista. Johtotaso 1 mukaan kaikilla toimialoilla on mahdollista hyödyntää digitalisaation tuomia automaatio mahdollisuuksia. Rakennuttamistoimialalta esimerkiksi hän kertoi suunnittelijan piirtämän rakennuksen kolmiulotteisen malliin, johon voitaisiin liittää tietoja. Esimerkiksi paljonko siihen kytkeytyy lainaa, lainan korko -%, rakennusmateriaalit, hinnat, toimittajat. Tällä hetkellä edellä mainittu tehdään kaikki erikseen. 39 7 YHTEENVETO JA POHDINTA Tämän opinnäytetyön tarkoitus oli tarkastella rakennuttamisen toimialalla toimivan Lakea Oy:n toiminnanohjausjärjestelmän vaihdosta työn tehokkuuden ja työn sähköistymisen näkökulmista. Työssä tutkittiin myös järjestelmän heikkouksia tai puutteita yhtiölle sekä pyrittiin kartoittamaan mitä hyötyjä yritys voisi uuden ohjelmiston avulla vielä saavuttaa. Opinnäytetyö toteutettiin teemahaastatteluina tarkkaan valituille henkilöille. Haastatteluita suoritetaan mahdollisimman kattavan ja käytännönläheisen tiedon saamiseksi. Haastateltavat valittiin siten, että yrityksen eri työskentely näkökulmat tulevat esille toiminnanohjausjärjestelmän käyttöön ja käyttöönotto projektiin vankasti liittyen. Haastateltaviksi on valittu Lakea Oy:n toimitusjohtaja, talousjohtaja, controller ja yksi kirjanpitäjistä. Opinnäytetyössä on kaksi päänäkökulmaa, joiden perusteella haastatteluja suoritettiin. Haastatteluissa esiin nousi, kuitenkin myös muutama muu näkökohta, joita olivat integraatio haasteet ja toiminnan laadun paraneminen. 7.1 Sähköistyminen Yksi tavoitteista oli tarkastella toiminnanohjausjärjestelmän vaihdosta työn sähköistymisen kannalta. Haastatteluiden perusteella voidaan todeta, että tämä on toteutunut hyvin. Uuden toiminnanohjausjärjestelmän avulla yritys on päässyt eroon muun muassa kirjanpidon kuukausiraportointi mapeista. Laskutuksessa sähköisyys näkyy vielä maltillisesti, mutta uuden asiakasportaalin ansiosta sähköinen laskutus varmasti vielä kehittyy. Lakea Oy:llä sähköisyyden lisääntyminen helpottaa jokapäiväistä työntekoa. Sähköisen taloushallinnon ja automaation avulla yritys voi säästää työaikaa ja lisätä asiakkaiden tyytyväisyyttä ja kiinnostusta yritystä kohtaan. 40 7.2 Työntehokkuus Yksi tavoitteista oli tarkastella toiminnanohjausjärjestelmän vaihdosta työn tehokkuuden kannalta. Haastatteluiden tulokset olivat tältä osa alueelta hiukan jakaantuneet. Haastatteluissa kerrottiin, että sähköistynyt tositteiden ja raporttien tallennus on lisännyt osaltaan työn tehokkuutta. Työntekijöiden on nopeampi hakea eri aikakausien raportteja tai tositteita sähköisestä tallennuskansiosta. Ylimääräinen odottelu ohjelman ladatessa on vähentynyt ja työajan voi käyttää tehokkaammin. Toisaalta taas haastatteluissa ilmeni, että manuaalinen työ on hiukan lisääntynyt suhteessa aiempaan työnkuvaan. Esimerkiksi kustannuspaikkakohtaisia raportteja työstäessä. Yrityksessä kuitenkin uskotaan Netvisorin kanssa positiiviseen tehokkaaseen tulevaisuuteen, jolloin säästynyt työaika tullaan mahdollisuuksien mukaan kohdistamaan työnkehitykseen. Turhien työvaiheiden jäädessä pois työntekijöiden työnimun ja työmotivaation uskotaan kasvavan. 7.3 Integraatio haasteet ja laadun paraneminen Haastatteluissa ilmeni yrityksen kokemat hankaluudet integraatioissa Netvisorin ja muiden käytössä olevien ohjelmien välillä. Haastatteluiden perusteella voidaan todeta, että hitaat tai olemattomat yhteydet yrityksen eri ohjelmistojen välillä hidastavat ja jopa vaikeuttavat työtä. Yrityksessä uskotaan kuitenkin uuden ohjelmiston mukautuvan ajan myötä käyttöön sopivaksi ja että toiminnasta tulevan sujuvaa. Tänä vuonna Lakea Oy:n työpanokset ovat kuluneet Netvisorin käyttöönottoon ja eri työnvaiheiden sisäänajoon. Uuden ohjelmiston käyttöönotto on suuri investointi, joka vaatii panostuksia koko työntekijäkunnalta ja jonka vaikutukset näkyvät yrityksen toiminnassa vasta tulevaisuudessa. Haastatteluissa esiin nousi myös, että sähköinen taloushallinto ja sähköisyyden lisääntyminen Lakea Oy:n toiminnassa kasvattaisi yrityksen laatua. Esimerkiksi tulevaisuudessa asukkaiden puhelinsovellus maksu- ja asumistietojen selailua varten. 41 7.4 Pohdinta Voidaan ajatella, että opinnäytetyön keskeisissä tavoitteissa eli tarkastella toiminnanohjausjärjestelmän vaihdosta työn sähköistymisen ja työn tehostumisen kannalta on onnistuttu. Uuden toiminnanohjausjärjestelmän myötä yrityksen toiminta on sähköisempää ja tulevaisuudessa työaikaa voidaan transaktioiden sijaan kohdistaa esimerkiksi työn kehittämiseen. Sähköinen taloushallinto edes auttaa ja tukee myös työn tehostumista automaattikirjausten avulla, toistaiseksi kuitenkin manuaalistakin työtä joudutaan tekemään hiukan enemmän. Uusi toiminnanohjausjärjestelmä vastaa teholtaan paremmin yrityksen tarpeita, joten odottelut prosessien välillä ovat jäänet pois. Tämä opinnäytetyö on tarkoituksellisesti rajattu käsittelemään toiminnanohjausjärjestelmän tuomia hyötyjä sähköistymisen ja työntehokkuuden näkökulmista yritykselle heti käyttöönottovaiheen jälkeen. Kaikkien hyötyjen kartoittaminen ja vertailu olisi tehnyt työstä liian laajan. Tulevissa tutkimuksissa ja opinnäytetöissä kannattaisi tutkia uuden järjestelmän ollessa käytössä jo vähän pidempään, jolloin tulokset tulevat yrityksen toiminnassa kunnolla näkyviin. Tulevissa tutkimuksissa voisi myös kiinnittää huomiota automaation ja digitaalisuuden tuomiin työnkuva muutoksiin ja niiden myötä työnimun ja työmotivaatio muutoksiin. 42 LÄHTEET Ahoniemi, L. Mertanen, M. Mäkipää, M. Sievänen, M. Suomala, P. & Ruohonen, M. 2007. Massaräätälöinnillä kilpailukykyä. Helsinki: Kopio-Niini Oy. Granlund, M. & Malmi, T. 2004.Tietotekniikan mahdollisuudet taloushallinnon kehittämisessä. Helsinki: Suomen Ekonomiliitto ja WSOY. Granlund, M. 2011. Extending AIS research to management accounting and control issues: A research note. [Verkkolehtiartikkeli]. International Journal of Accounting Information Systems, 3–19. [Viitattu 23.11.2019]. Saatavana: Finna.fi - tietokannasta. Vaatii käyttöoikeuden. Hirsjärvi, S., Sinivuori, E. Remes, P. & Sajavaara, P. 2007. Tutki ja kirjoita. Helsinki: Tammi. Itewiki. Ei päiväystä. Toiminnanohjaus ERP. [Verkkosivu]. [Viitattu 24.10.2019]. Saatavana: https://www.itewiki.fi/opas/toiminnanohjaus-erp/ Järvenpää, M. Länsiluoto, A. Partanen, V. Pellinen, J. 2017. Talousohjaus ja kustannuslaskenta. Helsinki: Sanoma Pro Oy. Kaarlajärvi, S. & Salminen, T. 2018. Älykäs taloushallinto: Automaation aika. Helsinki: Alma Talent. L 30.12.1997/1336. Kirjanpitolaki. Lahti, S & Salminen, T. 2014. Digitaaline