Projekt Odoo, ki zamuja, preseže proračun ali ga uporabniki preprosto obidejo z Excelovimi preglednicami, ni nujno izgubljen. V večini primerov je mogoče natančno ugotoviti, kaj je narobe, in popraviti samo to. Prav temu služi audit Odoo: neodvisen tehnični in procesni pregled obstoječe namestitve, na koncu katerega imate pisno oceno stanja in načrt, ali projekt popraviti, nadaljevati z drugim izvajalcem ali nekaj področij zasnovati znova.
Ta stran je namenjena podjetjem, ki so Odoo že uvedla (ali ga poskušala uvesti) in jih zanima prevzem projekta Odoo, menjava integratorja Odoo ali samo trezna ocena, kje so. Če šele izbirate izvajalca, je bolj uporabna stran o izbiri partnerja za Odoo.
Znaki, da je audit Odoo potreben
Projekt redko propade naenkrat. Najprej se nabirajo majhni signali, ki jih vodstvo pogosto prepozna šele, ko je škoda večja. Najpogostejši so:
- Računovodstvo ne zaupa sistemu. Računovodja še vedno primerja knjižbe z lastnimi evidencami, uskladitve konec meseca pa trajajo dlje kot pred uvedbo.
- Zaposleni delajo mimo sistema. Skladiščnik zapisuje zaloge na papir, prodaja vodi ponudbe v preglednicah, ker je vmesnik prepočasen ali nerazumljiv.
- Vsaka posodobitev nekaj poruši. Po nadgradnji ali namestitvi novega modula se pokvarijo poročila, izpisi ali integracije.
- Izvajalec se izogiba vprašanjem. Odgovori so nejasni, odgovorna oseba se menja, odprti zahtevki rastejo brez roka.
- Nihče ne zna razložiti, kaj je narejeno. Dokumentacije ni, lastni moduli nimajo opisa, vi pa ne veste, kaj je standardno in kaj prilagojeno.
- Uvedba nima konca. Ključni datumi se premikajo, obseg pa se širi, ne da bi bilo jasno, kaj je že dokončano.
Če prepoznate tri ali več teh znakov hkrati, je pregled bolj smiseln kot dodatno doplačevanje po urah. Podobne vzorce opisuje tudi vodič o najpogostejših napakah pri ERP projektih.
Kaj pregledamo pri auditu Odoo
Dober audit ni splošno mnenje, temveč strukturiran pregled po jasnih področjih. Vsako področje dobi oceno tveganja in priporočilo.
Paramerizacija in procesi
Najprej se preveri, ali sistem odraža dejanske poslovne procese. Pregledajo se nastavitve podjetja, davčne pozicije, kontni načrt, skladiščne lokacije, cenovne liste in poti odobritev. Pogosta ugotovitev je, da je paket nastavljen po splošni predlogi, ne po vašem dejanskem poslovanju. Posledica so obvozi, ročni popravki in podvojeno delo.
Podatki
Preveri se kakovost prenesenih in vnesenih podatkov: podvojeni partnerji, neusklajene šifre artiklov, napačne enote mer, odprte postavke, ki jih v resnici ni več. Slabi podatki so najdražja dediščina neuspele uvedbe, saj jih vsaka nova funkcija le še razmnoži. Če je bila podatkovna migracija slaba, je smiselno pogledati tudi migracijo Odoo.
Razvoji in prilagoditve
Tu se običajno skriva največ tveganja. Pregleda se, kateri moduli so lastni, kateri so iz skupnosti in ali so bili spremenjeni standardni deli paketa. Ocenjuje se kakovost kode, odvisnost od različice, ali obstajajo testi in ali bo modul preživel naslednjo nadgradnjo. Več o ravnanju s prilagoditvami je na strani o prilagoditvah in razvoju v Odoo.
Zmogljivost
Počasni seznami, dolgi izpisi in zastoji ob obračunih pogosto izvirajo iz neprimerne konfiguracije strežnika, nepotrebnih avtomatskih opravil ali slabo napisanih poizvedb v lastnih modulih, ne iz Odooja samega. Preveri se tudi, ali gostovanje ustreza obsegu uporabe; o možnostih piše stran o gostovanju in oblaku Odoo.
Varnost
Pregledajo se uporabniški računi in pravice (ali ima nekdanji sodelavec še dostop), skrbniška gesla, varnostne kopije in preizkus obnove, dostop zunanjih sistemov prek vmesnikov ter ločenost testnega in produkcijskega okolja. Pri Odoo je pomembno tudi, kdo je plačan uporabnik: po ceniku podjetja so plačani uporabniki tisti z dostopom do zaledja, uporabniki portala pa se ne štejejo kot plačani, zato napačna razporeditev pravic vpliva tako na varnost kot na stroške.
Različica in licenca
Preveri se, katera različica teče in ali še prejema podporo. Po dokumentaciji ima vsaka večja različica tri leta standardne podpore, varnostni popravki pa so na voljo samo v tem obdobju. Pri razširjeni (plačljivi) podpori so pomoč in popravki napak še mogoči, vendar le, kadar je to tehnično izvedljivo. Po objavljenem urniku je standardna podpora za različico 17.0 potekla septembra 2026, za 18.0 poteče septembra 2027, za 19.0 pa septembra 2028. Podrobnosti o izdajah so na strani o različicah Odoo.
Preveri se tudi licenčna skladnost. Odoo 19 Community je pod licenco LGPLv3, Enterprise pa pod licenco Odoo Enterprise Edition v1.0, ki jo je dovoljeno uporabljati le z veljavno naročnino Enterprise za pravo število uporabnikov. Podjetja pogosto ne vedo, da so namestila Enterprise module brez ustrezne naročnine ali da so z dodajanjem Studia ali družb preusmerila bazo v dražji paket; v tem primeru ima paket Custom še več funkcij, na primer dostop do zunanjega vmesnika API.
Pregled področij na kratko
| Področje | Kaj preverimo | Tipično tveganje |
|---|---|---|
| Paramerizacija | Procesi, davki, kontni načrt, pravice | Ročni obvozi, napačni obračuni |
| Podatki | Partnerji, artikli, odprte postavke | Netočna poročila, podvajanje |
| Razvoji | Lastni moduli, spremembe jedra | Blokirana nadgradnja |
| Zmogljivost | Strežnik, poizvedbe, avtomatska opravila | Počasnost, zastoji |
| Varnost | Računi, kopije, dostop zunanjih sistemov | Uhajanje podatkov, izguba |
| Različica | Podpora, nadgradnja, licenca | Brez varnostnih popravkov |
Prevzem projekta Odoo od drugega integratorja
Menjava izvajalca je pogosta in ni nujno konfliktna. Razlogi so lahko poslovni (izvajalec ni več dosegljiv, je zamenjal ekipo, ni usposobljen za vaše področje) ali tehnični (znanje o konkretnem modulu ni več v hiši). Ključno je, da menjavo izpeljete pregledno in da se ne zgodi, da bi novi izvajalec začel povsem znova brez razloga.
Kaj dobiti od dosedanjega izvajalca
Še preden se dogovorite o prevzemu, pripravite seznam stvari, ki jih potrebujete. Podatki in koda, plačani iz vašega proračuna, so v vaši domeni.
- skrbniški dostop do produkcijske in testne baze ter do strežnika oziroma gostovanja,
- izvorna koda vseh lastnih in prilagojenih modulov, po možnosti z zgodovino sprememb,
- seznam nameščenih modulov, njihovih različic in virov,
- dokumentacija procesov, specifikacije in zapisniki sestankov,
- dostop do varnostnih kopij in navodila za obnovo,
- pregled odprtih zahtevkov in neizpolnjenih zahtev,
- podatki za dostop do povezanih storitev, kot so plačilni sistemi, spletne trgovine ali banke.
Če izvajalec sodelovanje ukine nenadoma, ne čakajte na dobro voljo: pogodba mora določati predajo gradiva, zato pregledajte njena določila o lastništvu kode in dostopu do podatkov. V sporu ali dvomu o pogodbenih vprašanjih se posvetujte s pravnikom; ta stran pravnega svetovanja ne nadomešča.
Kako poteka prevzem
- Zamrznitev stanja. Naredite popolno kopijo produkcijske baze in kode, preden karkoli spremenite.
- Audit na kopiji. Pregled poteka na testnem okolju, produkcija ostaja nedotaknjena.
- Poročilo z oceno. Za vsako področje: stanje, tveganje, predlagan ukrep in vrstni red.
- Odločitev po področjih. Kar deluje, ostane. Kar je krhko, se popravi. Kar je neuporabno, se zasnuje znova.
- Postopen prevzem odgovornosti. Najprej podpora in odpravljanje napak, potem razvoj, nazadnje nove funkcije.
Takšen vrstni red zmanjša tveganje, da bi poslovanje zaradi prevzema obstalo. Odgovornost za posamezne naloge naj bo ves čas zapisana: kdo skrbi za podporo, kdo za razvoj, kdo za nadgradnje. O tem več na strani o podpori in vzdrževanju Odoo.
Kaj ne gre prenesti in ga je treba narediti znova
Ne gre vse prevzeti. Moduli, ki spreminjajo jedro paketa, kodo brez razumljive strukture ali integracije, ki jih nihče ne zna vzdrževati, je pogosto cenejše zamenjati s standardnimi funkcijami ali čistejšo izvedbo. Pred tem vedno preverite, ali Odoo ta del že podpira kot standard; vsaka lastna rešitev je trajen strošek vzdrževanja ob vsaki nadgradnji. Pregled standardnih sklopov je v modulih Odoo, povezave z zunanjimi sistemi pa na strani o integracijah.
Načrt sanacije po auditu
Poročilo je uporabno le, če iz njega nastane izvedljiv načrt. Dober načrt sanacije vsebuje:
- Hitre zmage: odprava napak, ki jih uporabniki čutijo vsak dan, čiščenje pravic in podvojenih podatkov.
- Stabilizacijo: varnostne kopije z dokazano obnovo, ločeno testno okolje, dokumentiranje procesov in lastnih modulov.
- Ponovno zasnovo najbolj problematičnih področij: na primer skladišča, obračuna ali proizvodnje, če so se pokazale kot slabo zasnovane.
- Nadgradnjo različice: na Odoo Online in Odoo.sh je mogoča mala ali večja nadgradnja, večja pa je obvezna na dve leti, za vmesne različice pa velja rok nekaj tednov po izidu naslednje. Pred zagonom je treba pridobiti nadgrajeno testno bazo in na njej preveriti procese.
- Usposabljanje uporabnikov: pogosto je izvorni vzrok težav slabo usposobljena ekipa, ne napaka v sistemu. Glejte usposabljanje za Odoo.
- Merila uspeha: jasno zapisano, kdaj se šteje, da je področje urejeno, na primer da računovodstvo zapre mesec brez ročnih uskladitev.
Vrstni red naj sledi poslovnemu tveganju. Najprej vse, kar vpliva na obračun DDV, e-račune, davčno potrjevanje računov in oddajo podatkov v eDavke, nato skladišče in prodaja, nazadnje priročne izboljšave.
Posebnosti v Sloveniji
Pri slovenskih podjetjih se težave pogosto skrivajo v lokalnih podrobnostih: knjiženje in obračun DDV, izdajanje e-računov, davčno potrjevanje računov pri gotovinskem poslovanju, poročila za računovodjo in za organe. Če so bile te zahteve rešene z improviziranimi moduli, so prvi kandidat za pregled. Dobro je vedeti, da Odoo v uradnem imeniku navaja pet partnerjev v Sloveniji, zato izbira izvajalca za audit ni omejena na enega samega; kako je s tem v praksi, opisuje stran Odoo v Sloveniji.
Za neodvisnost je koristno, da audit ne opravi isti izvajalec, ki je projekt vodil do zdaj. Naša storitev je brezplačno povezovanje: opišete stanje, mi pa vas povežemo z integratorjem, ki ima izkušnje s prevzemi. Kako to poteka, je pojasnjeno na strani kako deluje povezovanje; izvajalec se izbere po merilih iz vodnika za izbiro ERP integratorja.
Kaj naj vsebuje dober zahtevek za audit
Ko povprašujete, bodite natančni. Opišite različico in vrsto gostovanja, število aktivnih uporabnikov po področjih, seznam znanih težav, morebitne lastne module in povezane sisteme, ter kaj želite doseči: stabilnost, nadgradnjo, prevzem ali neodvisno oceno za vodstvo. Čim jasnejši je opis, tem natančnejši je predlog izvajalcev in tem manj je nepotrebnega dela.
Pogosta vprašanja
Kdaj je audit Odoo smiseln?
Takrat, ko se uvedba vleče brez jasnega konca, ko računovodja še vedno vzporedno vodi preglednice, ko po vsaki posodobitvi nekaj preneha delovati ali ko ne zaupate več podatkom v poročilih. Audit je krajši od novega projekta in vam da podlago za odločitev: popraviti, nadaljevati z drugim izvajalcem ali ponovno začeti na posameznem področju.
Ali lahko zamenjam integratorja Odoo, ne da bi začel znova?
Praviloma da, če imate dostop do baze, izvorne kode lastnih modulov in dokumentacije. Novi izvajalec najprej naredi pregled obstoječega stanja, nato pa nadaljuje tam, kjer je delo ostalo. Znova se začne le tisto, kar je tehnično neuporabno, na primer slabo zasnovan modul, ki ga ni mogoče vzdrževati.
Kaj moram dobiti od prejšnjega integratorja ob prevzemu projekta?
Zahtevajte skrbniški dostop do produkcijske in testne baze, izvorno kodo vseh lastnih in prilagojenih modulov, seznam nameščenih modulov in različic, dokumentacijo procesov, podatke za dostop do gostovanja ter pregled odprtih zahtevkov. Ker ste naročnik, so to vaši podatki in vaša poslovna logika, zato jih lahko upravičeno zahtevate.
Ali audit Odoo zajema tudi varnost in skladnost s slovenskimi predpisi?
Da. Pregleda se upravljanje uporabnikov in pravic, dostop prek vmesnikov, varnostne kopije ter ali različica še prejema varnostne popravke. Posebej se preveri, ali obračun DDV, izdajanje e-računov in davčno potrjevanje računov (FURS) delujejo skladno z vašim dejanskim poslovanjem, saj tu napake najprej postanejo drage.
Ali se splača popravljati projekt ali je bolje začeti znova?
Odvisno od tega, kje je težava. Če so podatki čisti in je jedro paketa uporabljeno standardno, je popravilo skoraj vedno cenejše. Če je veliko lastnih posegov v jedro, podatki so neuporabni ali je različica zastarela, je lahko selektivna ponovna zasnova modula smiselnejša. Odločitev naj temelji na pisnem poročilu o auditu, ne na vtisu.
Viri
- Odoo – dokumentacija: standardna in razširjena podpora
- Odoo – dokumentacija: podprte različice
- Odoo – dokumentacija: nadgradnja različice
- Odoo – dokumentacija: licence
- Odoo – cenik
- Odoo – imenik partnerjev v Sloveniji
Imena programske opreme so blagovne znamke njihovih izdelovalcev in so navedena zgolj informativno. Spletno mesto je neodvisno in ni povezano z nobenim izdelovalcem.