Kui projektijuhtimine on seni toimunud Excelis, e-kirjades või eraldi tööriistades, siis Business Central toob projektid, kulud, tulud, ressursid ja arvelduse ühte süsteemi. See loob parema ülevaate ja kontrolli, kuid eeldab teadlikke otsuseid enne juurutust.
1. Protsessid enne tehnoloogiat
Üks levinumaid vigu on hakata juurutama süsteemi enne, kui ettevõtte tegelikud projektiprotsessid on läbi mõeldud. Enne seadistamist tuleb selgelt kirjeldada, kuidas projekt algab, kuidas toimub töö planeerimine, kuidas arvestatakse kulusid ja aega ning millal tekib alus arveldamiseks.
Business Central ei paranda kehva protsessi automaatselt – ta muudab selle lihtsalt nähtavamaks ja süsteemsemaks. Seetõttu tasub enne juurutust koostada protsessiskeem: müük → projekt → töö → akteerimine → arve. Samuti tuleb kokku leppida rollid: kes vastutab projekti loomise, tööde kinnitamise, andmete õigsuse ja finantskontrolli eest.
2. Dimensioonid ja andmete struktuur
Projektimooduli edukas kasutamine sõltub väga palju andmestruktuurist. Eriti oluline on läbi mõelda dimensioonide loogika. Näiteks tuleb otsustada, kas kasutatakse dimensioone nagu projekt, osakond, tegevus, objekt või klient ning millised neist on kohustuslikud.
Oluline otsus on ka see, kas projekt toimib Business Centralis eraldi projektikaardina, dimensioonina või kasutatakse mõlemat paralleelselt. Vale või liiga hilja tehtud dimensioonide otsus võib muuta aruandluse ebatäpseks, Power BI mudeli keeruliseks ja finantsanalüüsi ebausaldusväärseks.
3. Tööde akteerimine ja arveldamine
Praktikas on tööde akteerimine üks kõige olulisemaid, kuid sageli alahinnatud teemasid. Ettevõte peab kokku leppima, millal loetakse töö tehtuks, kes selle kinnitab ja millal tekib õigus kliendile arve esitada.
Akteerimine võib toimuda ajakannete, töömahu, projekti etapi või projektijuhi kinnituse alusel. Kui akteerimise loogika puudub, tekivad probleemid arveldamisega: arved hilinevad, tulu ei kajastu õiges perioodis ja projektide kasumlikkus võib näida valena.
4. Ajakanded ja kasutajate distsipliin
Kui projektides kasutatakse tööaja arvestust, on ajakanded üks kriitilisemaid andmeallikaid. Projektimooduli väärtus tekib ainult siis, kui kasutajad sisestavad ajad korrektselt ja õigeaegselt.
Levinud probleemid on tagantjärele sisestamine, liiga keeruline kasutusloogika või olukord, kus kasutajad ei mõista, miks aega üldse sisestatakse. Seetõttu tuleb hoida ajakande protsess võimalikult lihtne, koolitada kasutajaid ning selgitada, kuidas nende sisestatud andmed mõjutavad projekti kasumlikkust ja juhtimisotsuseid.
5. Olemasolevate pooleliolevate projektide ülekandmine
Juurutuse üks kriitilisemaid hetki on olemasolevate pooleliolevate projektide üleviimine uude süsteemi. Enne ülekannet tuleb otsustada, millises seisus projektid üle tuuakse ja milline on ülemineku kuupäev ehk cut-off.
Oluline on kokku leppida, kas üle tuuakse ainult avatud tööd, eelarved, tegelikud kulud, arveldamata tööd või kogu ajalooline info. Kui ülekandeloogika on ebaselge, võib projekti kasumlikkus alata valest kohast ning kasutajad võivad kaotada usalduse uue süsteemi vastu.
6. Finantsintegratsioon
Business Centrali suur tugevus on projektide ja finantside ühendamine. Samas tähendab see, et seadistused peavad olema väga täpselt läbi mõeldud. Tuleb otsustada, millal tekib kulu, kuidas kajastatakse tulu ning kuidas liiguvad projekti kanded pearaamatusse.
Samuti tuleb kontrollida kontode, kanderühmade ja dimensioonide seoseid. Vale seadistus võib põhjustada olukorra, kus projektiraport näitab üht tulemust, kuid finantsaruandlus teist. Seetõttu tuleb finantsloogika testida juba enne live’i.
7. Aruandlus ja juhtimisvaade
Sageli eeldatakse, et projektide aruandlus tekib süsteemist automaatselt. Tegelikkuses tuleb juhtimisvaade eraldi läbi mõelda: milliseid mõõdikuid juhtkond vajab ja millisel detailsuse tasemel neid jälgitakse.
Tüüpilised ootused on projekti kasumlikkus, eelarve vs tegelik, arveldamata tööde maht, akteerimise staatus, tööjõu kasutus ja projektide prognoos. Kui need vajadused ei ole alguses defineeritud, on oht, et kasutajad liiguvad tagasi Excelisse.
8. Rollid ja vastutus
Projektimooduli juurutamine muudab sageli tööjaotust ettevõttes. Projektijuht ei vastuta enam ainult töö sisulise juhtimise eest, vaid ka andmete õigsuse, akteerimise ja projektiga seotud otsuste eest süsteemis.
Raamatupidamine peab mõistma projektide loogikat ning juhtkond peab kasutama samu andmeid otsuste tegemiseks. Kui rollid ei ole selged, tekivad vaidlused, andmete kvaliteet langeb ja süsteemi kasutamine muutub ebajärjekindlaks.
9. Juurutuse ulatus ja etapid
Kõike ei pea tegema korraga. Praktikas on sageli mõistlik alustada põhifunktsionaalsusest: projektide loomine, kulude ja tulude jälgimine, dimensioonid ning lihtne aruandlus.
Järgmistes etappides saab lisada ajakanded, tööde akteerimise, eelarvestamise, prognoosimise ja Power BI aruandluse. Liiga suur korraga tehtav juurutus võib koormata kasutajaid ja vähendada lahenduse tegelikku kasutuselevõttu.
10. Muutuste juhtimine
Tehnoloogia juurutamine on tegelikult inimeste tööviisi muutmine. Suurim risk ei ole tavaliselt tarkvara ise, vaid see, kas inimesed hakkavad uut lahendust õigesti ja järjepidevalt kasutama.
Edu eelduseks on juhtkonna tugi, selge kommunikatsioon, praktiline koolitus ja kiire kasu näitamine. Kasutajatele tuleb selgitada, miks uus töökorraldus on vajalik ja kuidas see aitab paremini juhtida projekte, kasumlikkust ja kliendiarveldust.
Kokkuvõte
Eduka projektimooduli juurutuse aluseks on:
• läbimõeldud protsessid;
• hästi disainitud dimensioonid;
• selge tööde akteerimise ja arveldamise loogika;
• korrektselt planeeritud pooleliolevate projektide ülekandmine;
• kvaliteetsed algandmed ja kasutajate distsipliin;
• toimiv finantsintegratsioon ja aruandlus;
• selged rollid ning tugev muutuste juhtimine.
Kui need teemad on enne juurutust läbi mõeldud, muutub projektimoodul võimsaks juhtimistööriistaks, mis aitab ettevõttel paremini jälgida projektide kasumlikkust, arveldamist ja ressursside kasutust.
//Postituse koostamisel on kasutatud AI-vahendeid.