hernad

U prvom dijelu sam naveo motive i kriterija za odabir open source (nadalje OSS) ERP software-a.

Ovdje ću iznijeti svoja dosadašnja iskustva i utiske o OpenERP-u.

Napomena: mnoge konstatacije ovdje navedene nisu do kraja provjerene ili su rezultat mojih subjektivnih dojmova. Ako sam nešto pogriješio, biću zahvalan na komentarima koji će ukazti na neispravnosti.

OpenERP istorija

OpenERP je jedan od najagresivnijih "igrača" na OSS ERP tržištu. Vrlo vjerovatno da su i u komercijalnom smislu najuspješniji.

Pojavili su se nakon Compiere & forks rješenja. Za razliku od ostalih oni su odabrali kao programski jezik python.

Na tržištu su brzo dobili epitet open source (nadalje OSS) "gerile". OpenERP autori su definitivno razbili mnoge stereotipe po pitanju percepcije open source software-a na tržištu ERP rješenja. Može se reći da su oni prvi ozbiljan "igrač" na tržištu ERP aplikacija koji je puno toga bacio na "open source karte".

Tehnologija

U startu projekta su krenuli sa 3-tier arhitekturom koja je omogućila jednostavnu implementaciju različitih klijenata. Oficijelni su desktop rich klijent Gnome/GTK (PyGTK) i web klijent. Vidio sam čak i implementaciju konzolnog klijenta od strane neovisnog developera.

Većina resursa se ulaže u razvoj web interfejsa. Ne bih se začudio da se u skorije vrijeme skroz napusti razvoj desktop klijenta.

Python kao dinamički jezik da je razvoju značajnu agilnost. Kako je omiljen jezik kod OSS developera, vjerovatno je i njegov odabir jedan od značajnih faktora velike popularnosti OpenERP-a kod developera

Licenca

OpenERP S.A. je dosta "šarao" sa licencama. Juče sam vidio da je došlo do nove promjene licenci, tako da je izgleda sav OSS OpenERP software prebačen na AGPLv3 licencu.

Par mjeseci unazad licenciranje je bilo različito:

• GTK klijent je bio licenciran sa GPLv2
• web klijent sa OpenERP public licencom (slična OpenBravo public license)
• backend - application server sa AGPLv3 licencom

Community, principi developmenta

OpenERP je veoma dinamičan software. Svaki dan raste i u kvantitativnom i u kvalitativnom smislu.

Ima veliki community, istinski "world-wide" zastupljen. Posebno su aktivni u Španiji, Francuskoj, Belgiji.

Vlasnik software-a je OpenERP S.A. iz Belgije.

Mislim da su i oni, kao i OpenBravo, imali jako VC finansiranje radi proboja na američko tržište.

Uočio sam da u developerskom dijelu dosta polažu na podizanje kvaliteta source koda, na uvođenje TDD/BDD testova, refactoring. Sjećam se da su u sklopu refactoringa kodne baze pokrenutli zamjenu svog in-house ORM database managera sa SQLAlchemy-jem. 

Međutim, dokle je to sve došlo ne znam. Zadnja tri mjeseca ne pratim openerp.

Takođe su kod web klijenta urađene značajne promjene sa prelaskom sa 5 na verziju 6 OpenERP-a.

OpenERP, moja iskustva

OpenERP je bio moj prvi izbor baznog software-a za knowhow ERP.

U tom periodu sam najviše vremena utrošio na upoznavanje funkcionalnih karakteristika OpenERP-a, te njegove strukture sa stanovišta instalacije i konfiguracije.

Par dana sam se "ganjao" sa problemima naših slova u reportima (UTF-8 enkodiranje). To je standardna boljka software-a koji je primarno razvijan za englesko govorno područje područje. 

Pregledom funkcionalnih karakteristika uočio sam velike razlike kod robno-materijanlog knjigovodstva. U određenim segmentima postoje značajne razlike - o tome sam već pisao u ranijem članku (vidi K7.2). Jedna od stvari koja uopšte nije obrađena je obračun zavisnih troškova (eng. landed costs). Dalnjim traganjem sam došao do zaključka da je to najbolje razrađeno u Adempiere-u, i djelimično u xTuple-u.

Bilo mi je čudno kako je jedna tako standardna funkcija (sa stanovišta sopstvenih iskustava u Bosni) jednostavno preskočena. Shvatio sam da je u određenim segmentima internacionalno računovodstvo značajno pojednostavljeno u odnosu na naše. 

Međutim, "no landed costs" definitivno nije stvar koja se ne može riješiti. Čak sam i našao neke implementacije nezavisnih developera po tom pitanju. 

Zapeo sam na slijedećoj stvari:

POS modul (maloprodaja) nije bio ni blizu onoga što takav modul treba ponuditi, a uz to se pojavila potreba da se realizira podrška za fiskalizaciju.

Zato je jedino logično rješenje bila izrada novog modula za prodaju (kasnije nazvan P1).

Međutim, onda se postavilo logično pitanje da li je bolje praviti green-field aplikaciju (iz početka) ili koristiti OpenERP kao framework za aplikaciu prodaje (vidi članak "Kašnjenje"). 

Pored ovoga,  na stolu mi je bio aktuelan zahtjev klijenta za aplikaciju mobilne prodaje (što će se kasnije pretvoriti u M3 knowhow).

Skok na appcelerator i javascript

Postavio se praktičan cilj: Koliko god je moguće razvojni proces P1 i M3 sinhronizirati, odabrati razvojne alate koji će omogućit da razvoj P1 i M3 ne budu "dva svijeta različitia".

U tom traganju se pojavio Appcelerator titanium kao atraktivno rješenje za izradu mobilnih i web-desktop hibridnih aplikacija. Programski jezik appcelerator framework-a je javascript.

Javascript ... javascript.

Sve se vrti oko javascripta a ja sam ga oduvijek zaobilazio kao "bljak" programski jezik.

Web ili web-like tehnologije. Sve aplikacije vrte se oko browser-a ... Korak po korak došao sam do zaključka da je vrijeme da se stvari prelome preko noge.

Kako je M3 u svakoj kombinaciji bio greenfield projekt, krenuli smo sa izradom prototipa mobilnog klijenta i upoznavanjem appcelerator-a. Iskustva su bila krajnje pozitivna.

Šta sa javascript u OpenERP-u ?

Vratimo se OpenERP-u. OpenERP je je takođe puno javascript programiranja. Unutar web klijenta. Međutim, taj dio developmenta je bio praktično otvoreni source zatvorenog tipa. Šta pod ovim mislim ?

OpenERP modulu koji su server-side aplikacije koje univerzalni klijent (desktop/web) "povlače" sa servera. Sva developerska dokumentacija i razvoj aplikacija od neovisnih vendora "vrtio" se oko izrade tih modula. Oni se izrađuju u python programskom jeziku. 

Razvoj web klijenta se dešava isključivo unutar OpenERP S.A.

Tokom pregleda dokumentacije nigdje nisam našao pomen na taj segment deveopment-a. 

Hmm ... Onda sam došao do pitanja: Da li je onda OpenERP optimalan framework za naš knowhow ERP ?

Ovo pitanje sam ostavio po na stand-by izvjesno vrijeme.

Jedna od opcija je bila da se kompletan ERP nakon ovih P1 i M3 krene raditi from scratch - kao greenfield projekat ... Ali to je opet bilo u velikoj mjeri utopijsko razmišljanje. Mi, ovako mali kakvi jesmo takvo šta ne možemo iznijeti. Možemo puno toga podžoniti iz FMK, ali mi ne želimo tehnički unaprijeđenu kopiju FMK mi trebamo nešto drugačije. Nešto puno bolje.

Prečica je bila neophodna. Ali prečice nigdje.

OpenERP poslovna strategija

Ali, vratimo se OpenERP-u. Pored pomenutih tehničkih dilema, pojavila se još jedna. Možda čak i presudna. 

Praćenjem OpenERP foruma došao sam do zaključka da vlasnik OpenERP S.A. kontinuirano "upire" u smjeru komercijalizacije svog rješenja. Sve to je naravno njihovo legitimno pravo. Međutim njihova strategija je u mnogim segmentima suprostavljena interesima zajednice OSS korisnika OpenERP-a.

I opet ista priča kao sa OpenBravo: ozbiljan biznis, odnosno ozbiljne instalacije OpenERP-a se "vrte" se samo na plaćenim verzijama. Što opet znači da partnerske firme koje prihvate tu igru u posao ne mogu ući samostalno. Uvijek je tu OpenERP S.A. koji treba svoju "gengu" uzeti.

I slijedi isti zaključak kao ko OpenBravo: 

Ako je to tako, onda je biznis sa OpenERP-om u suštini biznis sa zatvorenim software-om koji ima svoju OSS varijantu ... koju niko u produkcijskom okruženju ne koristi.

To nije priča koju mi u bring.out želimo pričati. Mi želimo raditi biznis na otvorenom software-u.

Mi želimo da naš core biznis bude baziran na open source rješenjima. Ako će nam u svakoj ozbiljnoj varijanti "visiti" proprietary dodaci, ništa mi sa svim tim nismo dobili.

Novi OpenERP POS 

Pišući ovaj članak pregledao sam nove sadržanje na openerp.com. I imam šta da vidim.

OpenERP je pripremio potupno novi POS modul. Modul je napisan skroz ispočetka, baš kako sam i ja prije dva mjeseca zaključio. Takođe modul je napisan sa kao čista Javascript/HTML5/LocalStorage aplikacija. Upravo onako kako sam ja pisao u članku "Kašnjenje" :). Tada sam sam sebe pitao jesam li prolupao zbog ovih razmišljanja ... OpenERP-ovci mi kažu da nisam :).

Međutim još jednu stvar mi je novi OpenERP modul potvrdio: Strategija OpenERP-a je ta da OpenERP očigledno ide u smjeru zatvaranja. POS je atraktivan modul. Svaka druga firma treba POS.

Publikovanje pristojnog dobro realizovanog POS modula kao zatvoreni software po meni značajno ruši kredibilitet OpenERP S.A. kao open source vendora.

Ostale tehničke impresije o OpenERP-u

Internet je pun korisničkih i developerskih informacija o OpenERP-u.

Sam OpenERP ima svoju online dokumentaciju. U poređenju sa OpenBravo dokumentacijom ona je lošijeg nivoa, ali je definitivno iskoristiva.

Database je PostgreSQL, sa cca 350-400 tabela u osnovnoj konfiguraciji (svaki dodatni modul kreira svoje tabele). 

Database model mi se čini čitljivim, ali postoji problem neobjavljivanja migracijskih skripti prilikom migracije sa jedne ne drugu "major" verziju (npr sa 5.x na 6.x).

O tome sam pisao u uvodnom članku na ovu temu - vidi K6 b).

OpenERP ima odlično razrađen sistem modula, inicijalne konfiguracije klijenta putem "wizard" funkcija. 

Korisnički interfejs je dobro osmišljen. Ideja generičkog klijenta koga navigiraju serverski moduli omogućava veliki produktivnost u izradi novih modula. Međutim svugdje gdje se primjenjuju ovi "generički recepti" postoji i danak određenim specifičnim situacijama.

Zato korisnički interfejs i generalno user experience nisu na svim mjestima takvim da "upadneš na glavu". Ali svakako za par stepeni iznad Adempiere-a, ali i OpenBravo-a.

python aplikacijski serve čini serversku aplikaciju puno manjim gutačem memorije od Adempiere-a, o OpenBravo-u da ne govorim. Naravno java serverske aplikacije će na jačim serverima brzo potući python kao dinamički jezik ... ali za developera je praktičan problem kada u developerskoj sesiji trebaš čekati par minuta da se OpenBravo aplikacijski server samo "podigne".