Prilagoditev Odoo: razvoj po meri, ki ostane vzdržljiv

Kdor v podjetju išče razvoj Odoo, običajno že ve, da standardna rešitev ne pokrije vsega: obračun po posebnem pravilu, odobritev, ki je drugačna kot v učbeniku, ali povezava z orodjem, ki ga uporablja skladišče. Prava odločitev pa ni »ali programirati«, temveč koliko programirati in kje. Ta stran razlaga, kako ločiti nastavitev od prilagoditve Odoo in od modula po meri za Odoo, kaj vsaka pot pomeni za posodobitve ter kako presoditi razvijalca ali integratorja.

Tri stopnje prilagajanja Odoo

Odoo je mogoče prilagoditi na več načinov in vsak ima drugačen strošek v času. Pravilo, ki ga potrdi večina izkušenih izvajalcev: začnite pri najnižji stopnji in na višjo stopite šele, ko nižja dokazano ne zadošča.

Nastavitev: najcenejša in najbolj stabilna pot

Veliko zahtev, ki se na delavnici zdijo posebne, se izkaže za običajno nastavitev: drugačen potek potrditve ponudbe, več skladišč z lastnimi pravili, določena struktura kontov ali predloga računa. Preden se zahteva zapiše kot razvojna naloga, naj jo svetovalec poskusi rešiti z obstoječimi parametri. Pri aplikacijah, kot so prodaja in CRM v Odoo ali zaloge in nabava, je manevrskega prostora pogosto več, kot se zdi na prvi pogled.

Odoo Studio: prilagajanje brez kode

Po dokumentaciji Odoo Studio omogoča brez kode urejanje polj, pogledov, modelov, aplikacij, pravil avtomatizacije, spletnih kljuk, PDF poročil, pravil odobritve in varnostnih pravil. Za marsikatero manjšo zahtevo, na primer dodatno polje na ponudbi ali pravilo odobritve nad določenim zneskom, je to hitra pot.

Pri tem pazite na licenčni vidik. Namestitev Studia na bazo s paketom Standard sproži samodejen prehod na paket Custom: pri letni pogodbi kot dodatno naročilo z rokom 30 dni, pri mesečni pa samodejno ob naslednjem obračunskem ciklu. Paket Custom stane 44,90 EUR na uporabnika na mesec (z akcijo, ki velja 12 mesecev, iz izhodiščnih 56,90 EUR), paket Standard pa 24,90 EUR na uporabnika na mesec (iz izhodiščnih 31,10 EUR). Razlika se pri večjem številu uporabnikov hitro nabere, zato jo vključite v račun, preden Studio postane običajno orodje. Več o paketih najdete na strani cene Odoo.

Obstoječi moduli: najprej poiščite, nato pišite

Odoo navaja 50 glavnih aplikacij in skupnost, ki je prispevala več kot 50 000 dodatnih aplikacij. Zato ima smisel pred vsakim razvojem preveriti, ali ustrezen modul že obstaja. Pogled na module Odoo pomaga razumeti, kaj je del osnove in kaj pride od drugod.

Moduli skupnosti pa niso brez tveganja. Pred uporabo preverite:

• ali je modul na voljo za različico, ki jo uporabljate ali jo načrtujete,
• ali ga avtor še vzdržuje,
• kakšna je njegova licenca in ali je združljiva z vašo izdajo,
• ali je koda pregledna, da jo lahko vaš izvajalec prevzame.

Modul, ki ga nihče več ne vzdržuje, je v resnici skrit razvoj po meri brez razvijalca.

Kdaj je razvoj po meri upravičen

Razvoj se splača, ko zahteva izhaja iz procesa, ki vam daje konkurenčno prednost, in ga ni mogoče pokriti z nastavitvijo ali obstoječo razširitvijo. Tipični primeri v slovenskem okolju:

• Posebna logika izračuna pri proizvodnji ali storitvah, ki je ne pokriva nobena standardna formula. Podrobnosti o aplikaciji najdete na strani proizvodnja v Odoo.
• Povezava z lastnim ali panožnim sistemom, na primer s spletno trgovino, prevoznikom ali bančnim izvozom. Glejte integracije Odoo.
• Prilagoditev dokumentov za potrebe slovenskih poslovnih partnerjev, na primer e-računov za javni sektor ali izpisov, ki jih zahteva računovodja.
• Lastna poročila, ki jih ni mogoče sestaviti iz obstoječih pogledov.

Odoo eCommerce na primer že obvladuje katalog z variantami, B2B in B2C, opuščene košarice, načine dostave in vračila ter se povezuje z več kot dvajsetimi ponudniki plačil. Če načrtujete spletno prodajo, najprej preverite, kaj od tega je že pripravljeno, in šele nato naročite lastno logiko.

Kaj razvijalec dejansko dela

Odoo je napisan v Pythonu in uporablja zbirko PostgreSQL. Običajen modul po meri vsebuje Pythonove modele, poglede v XML in datoteke pravic dostopa. Za povezave z zunanjimi sistemi dokumentacija zunanjega API-ja kot sodoben vmesnik navaja JSON-2 s ključi API, pravicami dostopa, izbiro baze in transakcijami. Starejša vmesnika XML-RPC in JSON-RPC sta v dokumentaciji obravnavana kot zgodovinska, za prehod pa obstaja vodnik za selitev na JSON-2.

Zunanji API je del paketa Custom. Če vaš načrt temelji na povezavah, to upoštevajte pri izbiri paketa, ne šele po podpisu pogodbe.

Vpliv na posodobitve: najpogostejša past

Najdražja prilagoditev je tista, ki je danes poceni. Odoo izdaja nove različice, razvoj po meri pa je vezan na tisto, za katero je bil napisan. Zato je vsaka prilagoditev tudi dolg, ki ga boste plačevali ob vsakem prehodu. Več o tem, kaj pričakovati, je na straneh različice in izdaje Odoo in migracija Odoo.

Tveganje se zmanjša z nekaj disciplinami:

1. Dedovanje namesto spreminjanja jedra. Modul razširja obstoječe modele in poglede, osnovne kode pa ne prepisuje. Poseg v jedro je razlog, da posodobitev postane projekt.
2. Majhni, ozko namenski moduli. En modul za eno zadevo je lažje prenesti kot en velik modul za vse.
3. Avtomatski testi. Brez njih nihče ne ve, kaj je po posodobitvi nehalo delovati.
4. Preizkus na kopiji baze. Nova različica se najprej preveri na kopiji z resničnimi podatki, nikoli neposredno v produkciji.
5. Jasna lastnina kode. Pogodba naj določa, da koda pripada vam ali da jo imate v hrambi, tako da zamenjava izvajalca ni ujetništvo.

Vprašanje licence ni formalnost. Odoo 19 Community je pod licenco LGPLv3, Odoo 19 Enterprise pa pod licenco Odoo Enterprise Edition v1.0, ki jo je dovoljeno uporabljati le z veljavno naročnino Enterprise za pravilno število uporabnikov. Moduli, ki jih razvijete, smejo imeti licenco po vaši izbiri, če je združljiva z licenco izvorne izdaje.

Dobre prakse: ostati pri standardu, dokumentirati, testirati

Ostanite pri standardu, kolikor je mogoče

Standard ni omejitev, temveč prihranek. Vsak proces, ki ga prilagodite sebi, namesto da bi prilagodili poslovanje standardu, ustvari trajen strošek vzdrževanja. Pri vsaki zahtevi si zastavite tri vprašanja: ali ta razlika res vpliva na stranke ali marže, ali jo je mogoče rešiti z organizacijo dela in ali bo še pomembna čez nekaj let.

Tu se pokaže vloga dobrega svetovalca. Včasih je najboljši razvoj tisti, ki ga ni. Če se vam zdi, da je projekt že zdrsnil v preveč posebnosti, je smiseln pregled projekta Odoo.

Dokumentirajte tako, da jo razume tudi nekdo drug

Dokumentacija modula naj vsebuje namen, poslovno pravilo, ki ga uresničuje, odvisnosti od drugih modulov in navodilo za testiranje. Zapis »kaj« je manj pomemben kot zapis »zakaj«. Ko razvijalec odide, ostane le to.

Testirajte po poslovnih scenarijih

Tehnični test pove, da koda deluje. Poslovni test pove, da delovni tok deluje: od ponudbe do računa, od naročila do prejema, od obračuna do knjiženja. Pri slovenskih podjetjih mora scenarij vključevati tudi zahteve, ki jih postavljata računovodstvo in davčni organ. To so davčno potrjevanje računov pri FURS, e-računi, obračun DDV in oddaje prek eDavkov. Vsaka prilagoditev, ki se dotika izdaje računov ali knjiženja, je tu posebej občutljiva. Preverite, kaj od tega pokriva lokalizacija, in pri izvajalcu pridobite pisno potrditev; več o tem na straneh Odoo v Sloveniji in računovodstvo in finance v Odoo.

Poskrbite za usposabljanje in vzdrževanje

Prilagoditev, ki je uporabniki ne razumejo, se kmalu obide z ročnimi preglednicami. Načrtujte usposabljanje za Odoo in dogovorite podporo in vzdrževanje, ki izrecno zajema module po meri.

Kako oceniti razvijalca ali integratorja Odoo

Izvajalec vam bo ponudil svoj razvoj, zato presojo opravite na podlagi vprašanj, ki razkrijejo način dela, ne na podlagi obljub.

Vprašanja za prvi razgovor:

• Kaj bi pri naši zahtevi rešili z nastavitvijo in kaj bi razvijali?
• Kako zagotovite, da modul ne posega v jedro Odoo?
• Kako preizkušate in kako dokumentirate?
• Kdo je po prevzemu lastnik izvorne kode?
• Kaj se zgodi ob prehodu na novo različico in kdo to plača?
• Ali ste že delali v podjetjih naše velikosti in panoge?

Opozorilni znaki:

• razvoj je predlagan, še preden je bil proces analiziran,
• ponudba je en znesek brez razčlenitve,
• dokumentacija in testi nista omenjeni,
• izvajalec ne zna pojasniti, zakaj zahteve ne bi uresničil v standardu,
• koda ostane le pri njem.

Razlika med razvijalcem in integratorjem je pomembna. Razvijalec zna napisati modul, integrator pa mora razumeti vaš proces, projekt voditi, podatke preseliti in sistem vpeljati. Za večino srednjih podjetij je primerneje, da obe vlogi pokrije ista ekipa ali da sta jasno povezani. Kako izbrati partnerja, razlagata strani izbira partnerja za Odoo in splošni vodnik izbira ERP integratorja. Če jasno napišete zahteve, boste lažje primerjali ponudbe; pri tem vam pomaga predloga zahtev za ERP.

Kako do ustreznega izvajalca

Mi ne razvijamo in nismo povezani z nobenim izdajateljem programske opreme. Kot brezplačna storitev vaše zahteve predstavimo certificiranemu integratorju, ki ustreza vašemu projektu. Opišite, kaj želite doseči in kaj ste že preverili, izvajalec pa bo predlagal, kaj nastaviti in kaj razviti. Postopek je razložen na strani kako deluje posredovanje, splošni pregled pa je na strani Odoo. Če še tehtate izbiro programa, si oglejte tudi primerjavo Odoo in Business Central.

Imena programske opreme so blagovne znamke njihovih izdelovalcev in so navedena zgolj informativno. Spletno mesto je neodvisno in ni povezano z nobenim izdelovalcem.