hernad

Potpuno mi je jasno da mi u bring.out nismo jedini "genijalci" kojima je palo na pamet da iskoriste postojeća svjetska open source ERP rješenja za ponudu na BH tržištu.

Međutim, da je to nikako nije i jednostavan posao, kazuje činjenica da na tržištu nema takvog rješenja.

Klonimo se zabluda: IT biznis baziran na open source software-u nije na kraju ništa drugo do i svaki IT biznis.

IT biznis ovisi o korisnicima. Korisnici trebaju trebaju software koji će zadovoljiti njihove potrebe i zahtjeve.

ERP software, poslovni software općeniti, se od drugih softverskih aplikacija razlikuje po tome što je poznavanje poslovnih procesa od strane IT provajdera must-be. I tu se većina infomatičara "nasanka". Prodaja ERP rješenja je zanimljva. Svima naziru da tu ima prostora za zaradu. Ali mnogi ne shvataju da je biti ERP provajder rudarski posao. 

ERP je po definiciji dinamična materija - zakonska regulativa se stalno mijenja, sam ekonomski prostor je podložan stalnim promjenama. Sve to dovodi do toga da je ERP software uvijek nedovršen. Da sada ne pretjerujem, njegova bazne funkcije se ne mjenjaju tako često. Ali proizvod u cjelini stalno trpi manje ili veće promjene. Ko to ispusti iz vida može vrlo brzo popiti "gorku pilulu" bio on kupac ERP software-a ili neko ko želi ući u biznis kao ERP provajder.

Rad na implementaciji mnogih od tih promjena su za mnoge informatičare ... dosadne.

Međutim, upravo je način rješavanja ovih zahtjeva glavni diferencijator između dobrih i loših ERP provajdera.

Nakon 15 godina rada u ovom području mi u bring.out smo prošli puno toga. 

Od toga da su nam govorili kako smo genijalci, da naši programi "jedu malu djecu", do toga da nikada gori software nisu vidjeli.

Ali, sada neću razglabati o tomeli naša postojeća rješenja vrijede ili ne vrijede. 

Ovdje ću tragati za odgovorima na sljedeća pitanja:

1. Da li postoji open source software koji se može iskoristiti na bosanskom tržištu ?
2. Ako postoji, i ako postoji mogućnost izbora, koji je su to kriteriji za odabir ?

Da se podsjetimo, krajnjeg korisnika interesuju prije svega slijedeće stvari:

1. da li taj software može zadovoljiti njegove sadašnje i  buduće potrebe 
2. koja je cijena korištenja tog software-a 

Korisnik software-a u konačnici software dijeli na dobar i loš, te na onaj koji sebi može priuštiti ili  je preskup za njegov džep. Ukratko nije bitno da li je SAP ili Navision dobar software ako ga sebi ne možete priuštiti.

Znači, korisnici software ne dijele na open source i closed source. Njih te stvari ne interesuju.

Neupućeni u ovu temu povezuju open source software sa softwarem čija je cijena = 0. Međutim, ta konstatacija je potpuno pogrešna.

Svaki software ima cijenu korištenja. Open source takođe. Open source rješenje može biti duplo skuplje od konkurentskog zatvorenog proizvoda.

Matematika cijena

Evo jednostavne matematike

Provajder 1 nudi ERP 1 koji je open source na sljedeći način:

• Licence za korištenje 0 KM
• Usluga pripreme podataka za novu poslovnu godinu 500 KM
• Troškovi mjesečna podrške za 10 radnih mjesta 10 x 45 = 450 KM/mjes
• Troškovi nadogradnji u slučaju zakonskih promjena nisu uračunati u tekuće troškove

U toku godine su bile dvije zakonske nadogradnje, ukupni troškovi 1000 KM.

Godišnji troškovi su OSS ERP 1:  500 + 450 * 12 + 1000 = 6900 KM

Provajder 2 nudi ERP 2 koji je vlasnički - zatvoreni software:

• Licence za korištenje 200 KM/radnom mjestu godišnje
• Usluga pripreme podataka za novu poslovnu godinu 250 KM
• Troškovi mjesečna podrške za 10 radnih mjesta 30 x 100 = 300 KM/mjes
• Troškovi nadogradnji u slučaju zakonskih promjena uračunati u tekuće troškove

Godišnji troškovi ERP 2: 200 * 10 + 250 + 300 * 12 = 5850 KM

Očekivano, znatno veći troškovi tekuće podrške su eliminisali prednost OSS ERP-a ERP-1 u odnosu na ERP-2.

Integralna matematika

Međutim, da bi se analizirala prednost pojedinačnih ponuda moraju se uzeti u obzir i sljedeći parametri:

1. Da li su troškovi infrastrukture značajno različiti kod ERP-1 i ERP-2 ?
2. Kakav je kvalitet i brzina servisne podrške pojedinih provajera ?
3. Kakva je sposobnost i spremnost provajdera da odgovore na specifične zahtjeve klijenata ?
4. Da li, ako sa njom nismo zadovoljni, možemo promijeniti firmu koja nam daje IT podršku, a da pri tome sačuvamo postojeće programsko rješenje ?
5. Da li za potrebe realizacije određenih zahtjeva možemo "miksati" IT provajdere (tekuća podrška ERP-1 provajder-1, nadogradnja - izrada novih funkcija ERP-1 neki drugi provajder koji takođe radi razvoj baziran na ERP-1 rješenjima)

Tek kada se sva ova pitanja uzmu u obzir dolazimo do integralne slike o karakteristikama i troškovima određenog ERP rješenja.

Vođen ovim pitanjima, te činjenicom da je BH tržište malo, ovo je potencijal koji mi vidimo u OSS ERP rješenjima: 

1) Infrastruktura

Open source software se u pravilu može koristiti na više operativnih sistema, na različitim database serverima. Mogućnost izbora po ovim pitanjima, posebno kod većih instalacija daje ogroman manevarski prostor ERP provajderu.

Na 50-tak radnih mjesta + aplikacijski server troškovi za licence čine 20-tak hiljada KM. Na to sve dodatno idu troškovi instalacije i konfiguracije. Open source vendor svoju kalkulaciju ne opterećuje licencama.

2) Kvalitet podrške

Sama podrška je limitirana tehničkim karakteristikama software-a. Ona nikada ne može u cjelosti kompenzirati tehničke nedostatke. Međutim, open source software omogućava da se u proces analize i ispravke pogrešaka svi zainteresovani puno lakše i AKTIVNIJE uključe.

Jaka zajednica korisnika i developera daje OSS software-u potencijal koje zatvoreni software teško može postići.

4) Specifični zahtjevi klijenata

Za razliku od aplikacija kao što je npr. tekst procesor, broj opcija i varijanit korištenja tih opcija kod ERP software-a je puno veći.

To održavanju takvog sistema daje kompleksnost koja u toku eksploatacije software-a može postati ključni problem za korisnike ERP software-a.

Investicije u realizaciju takvih zahtjeva na malom tržištu bivaju znatno veće. Razlog je jednostavan: Ako IT vendor to što je napravio za jednog klijenta ne može plasirati kod velikog broja drugih klijenata, on će sve troškove "privaliti" primarnom naručiocu.

Zato je kod korisnika ERP software-a veoma česta konstatacija da njihov ERP software ne radi puno toga što im treba, ali im njihov ERP vendor to ne može po razumnoj cijeni (ili ikako) ponuditi.

Mi smo sa našim kupcima kao lokalni vendor zatvorenih rješenja veoma često dolazili u takve situacije.

Po nama, jedini izlaz iz takve situacije na malom tržištu kao što je bosansko jeste upravo koncept open source zajednica: Eko sistema - zajednice korisnika i developera ERP rješenja koje će sarađivati na istoj OSS ERP platformi.

Platfoma koju će svi slobodno koristiti. Unapređenje te platforme će takođe biti u zajedničkom interesu. 

Osnova diferencijacije pojedinih vendora biće ekspertiza u implementaciji i podršci ERP rješenja a ne u vlasništvu nad platformom.

5) "Miksanje" različitih vendora

Pored mogućnosti izbora koja se korisniku pruža ovim konceptom, pojavljuju se i opcije da korisnik za veće poslove anagažuje više vendora koji koriste istu OSS ERP platformu.

Takođe, vendori se jednostavno mogu udruživati u većim poslovima. OSS platforma značajno olakšava i pospješuje poslovnu saradnju različitih vendora.

Gotov uvod :)

Nakon ovog gigantskog uvoda koji objašnjava ZAŠTO smo usmjereni na OSS software, dolazimo do tačke u kojoj prelazimo na traganje za OSS software-om koji može biti osnova DOBROG ERP rješenja u Bosni.

Tragajući za odgovorima na ova pitanja po internetu, našao sam samo "analize" (review) i "analitičarime" (reviewer) koje pripadaju jednoj od ovih grupa:

1. analitičaru fali znanja i iskustava iz oblasti ERP-a. Bez dobrog poznavanja domena software-a ne mogu se davati valjane kvalifikacije
2. analitičar već pripada određenoj zajedici, tako glorificiraju sopstveno, krajnje subjektivno govore o drugim rješenjima
3. analitičar je površno prošao osnovne operacije (instalacija, nekakve najosnovnije - hello world operacije) rješenja o koji su predmet analize tako da su njihove ocjene uopćene, ili po sistemu "gatanja" (ova funkcija postoji - nije bitno što to postoji bitno je kako to fukcioniše). Ishod je da takve analize i kvalifikacije nemaju potrebnu težinu.

Nažalost, moram reći da će i moj daljni tekst biti pun zaključaka i konstatacija koje se uklapaju u jednu od gornjih kategorija.

Svjestan da daljnjem tekstu definitivno fali sistematičnost, više vremena utrošenog na testiranje konkretnih rješenja. Međutim, vremena nemam, tako da će čitalac biti osuđen na ono se može nazvati "ocjene po sopstvenom feeling-u".

Kriteriji

Kod svakog odabira je bitno utvrditi kriterije i ponder kriterija za odabir. Ovo su bitni kriteriji koje sam ja tokom traganja za optimalnim OSS ERP rješenjem identificirao:

K1) Licenca

Osnovna podjela licenci je na "strong copyleft" i "weak copyleft" licence. Predstavnik ovih prvih je GPL familija licenci: GPLv2, GPLv3, AGPLv3. 

One su takve da zahtjevaju od korisnika GPL licenciranog koda da sve modifikacije i nova rješenja u kojima se koristi GPL software takođe objavljuju kao GPL software. Zato ih mnogi zovu "viroznim" jer se GPL licenca prenosi i na novi software (u licencama se taj software najčešće naziva "larger works based on subject of license") koje se koristi GPL licenciranim software-om.

Druga grupa je ona koja omogućava da se postojeći software "miješa" sa novim software-om pri čemu taj novi software autor može licencirati kako god želi - pod istom licencom ili čak kao zatvoreni software. Toj grupi pripadaju MPL i MPL bazirane licence. Takav je i CPAL koji mi koristimo.

Jedino ograničenje je da se modifikacije postojećeg software-a moraju objavljivati pod istom licencom, znači kao OSS software.

Weak copyleft se smatra puno popularnijim za kompanije, znači za komercijalnu upotrebu. Izdavanjem software-a pod nekom weak copyleft licencom omogućava firmi se zaštiti od konkurencije. Ako konkurentska firma uzme vaš OSS software licenciran na takav način, sve modifikacije koje napravi na vašem software-u ona mora objaviti. Ta firma se pojavljuje kao partner - saradnik (Contributor) na vašem projektu.

Sav dodatni software (larger works) međutim partneri mogu objaviti pod licencom koju žele, ili ga uopšte ne objaviti - proizvoditi kao zatvoreni software.

Treba tu još dodati i treću kategoriju licenci koje su kranje liberalne (kao npr. MIT). Njihovo korištenje se svodi na to autori dozvoljavaju korištenje i modifikaciju tog software-a bez ikakvog ograničenja kako po pitanju modifikacije tako i za novi software (larger works).

Mnoge developer oriented biblioteke (library) i developerske platforme (developer framework) su upravo ovako licencirani. Tako su npr. licencirani ruby, ruby on rails framework.  

Za kraj treba dodati i dual license politiku (ili multiple license). Autor može kod licencirati kao MPL i GPL licenciran kod. Na taj način će primalac software-a u daljnjem korištenju aktivirati jednu od raspoloživih licenci ili zadržati višestruko licenciranje.

Koji će se model licenciranja odabrati zavisi od toga šta su glavni ciljevi autora.

Ako je to želja da se njegov sourc kod što više koristi koriste se licence kao što su MIT. Ako autor želi da se njegov software ne može iskoristiti za zatvorena rješenja - vlasnički sofware (proprietary software) onda se koriste GPL-like licence. Komercijalni vendori najčešće idu na MPL-like licence.  

K2) Community - zajednica korisnika i developera,

Software bez korisnika je mrtvo slovo na papiru. Zato je raširenost software-a kod korisnika jedan od ključnih pokazatelja kvaliteta tog software-a. Pored toga, software koje ima jaku zajednicu se ne može tako lahko "ugasiti".

U slučaju autor iz bilo kojih razloga odstupi od OSS projekta, ako postoji jaka i "zdrava" zajednica korisnika, izvjesno je da će se projekat nastaviti svoj život.

Takođe, ako se radi o firmi koja iz svojih korporativnih razloga napusti open source razvoj, jak community će nastaviti OSS razvoj.

Ukratko, ako postoji dovoljan broj onih koji su svoju energiju i vrijeme investirali u open source software, ako se taj software koristi, za njega "nema zime".

On u svom životnom vijeku može doživljeti razne metamorfoze (spajanje sa drugim projektima, razbijanje na više manjih ...) ali u suštini, ono što je najbitnije - trud uložen u njega neće propasti kao što se to u sličnim situacija sa zatvorenim software-om dešava.

K2.1) Enterprise support - firma(e) koja stoji iza software-a

U poslovnom software-u nema prostora za čisti volonterizam. Zato je razvoj OSS ERP software-a redovno finansiran od jedne ili više firmi.

Takođe postoji opcija da firma svoj postojeći zatvoreni software otvori - "opensorsira".

Bez obzira koja od varijanti je inicirala OSS ERP projekat, bitno ponašanje autora, odnosno tih "glavnih igrača" unutar "community"-ja.

Ukoliko se sav razvoj dešava unutar firme originalnog autora, onda su pozitivni efekti djelovanja veće zajednice značajno umanjeni, a sam projekat gubi kredibilitet istinskog otvoreno projekta.

U tom slučaju imamo projekat sa otvorenim source kodom je u samom procesu razvoja zatvoren.  

K3) Klijentske reference, period razvoja

Reference u korištenju ERP software-a (pri čemu se isključivo misli na korisnike koji ERP koriste u realnom poslovnom okruženju) i period razvoja su značajni parametri kvaliteta i kredibiliteta svakog proizvoda. 

U slučaju ERP software-a treba imati na umu dvije stvari:

a) Pozitivni efekti dugogodišnjeg razvoja

Pozitivno je značenje to što je u software-u koji je dugo na tržištu integrisano značajno iskustvu onih koji su taj software instalirali i obezbjeđivali podršku za njega - IT vendora.

b) Mogući negativni efekti

Dug period razvoja može imati i jake negativne konotacije.

Tokom višegodišnjih nadogradnji ERP software sa stanovišta razvoja može postati nepregledna šuma. Ako se razvojni time ne drži određenih principa po pitanju developerskih tehnologija (obavezno dokumentovanje, TDD/BDD, code refactoring) source kode postane vrlo brzo labirint u kome se samo rijetki mogu snaći.

IT industrija, odnosno industrija razvoja software-a je jedna od najdinamičnijih. Programerski alati i tehnologije se mjenjaju u ciklusima od cca 5 godina. 

K4) Bazne tehnologije i alati

Tako recimo prije 5 godina razvoj aplikacija za mobilne platforme u poređenju sa današnjim stanjem gotovo da i nije postojao. Slično je sa trendom web-izacije rješenja.

Iz tih razloga kompetencije developera koje su potrebne za razvoj rješenja koja su konkurentna na današnjem IT tržištu se značajno mijenjaju.

Kada sam se ja počeo baviti programiranjem - ratnih 90-tih, računarske mreže su bile rijetkost. U toku je bio proces okrupnjavanja vendora (gašenja malih koje su kupovale "velike ribe"). Era otvorenog software-a još nije počela, pogotovo ne u ratom zatvorenoj Bosni.

U to vrijeme, "Clipper" programski alat je bio najproduktivnije i najpopularnije programsko okruženje za domen poslovnih aplikacija na PC-u.

Međutim, nakon par loših akvizicija (naravno sa stavništa "Clipper" korisnika) taj,  u to vrijeme sjajan developerski proizvod, je otišao u stagnaciju, da bi na kraju završio u muzeju IT-a. 

Koliko je odabir baznih tehnologija i alata bitan, mi smo nažalost osjetili na svojoj koži.

Zato je kod odabira baznih alata za razvoj u bring.out prvi i eliminirajući faktor: open source software, sa jakom korisničkom zajednicom.

K4.1) Prevod i lokalizacija

Prevod je najčešće jednostavna stvar.  Koriste se alati kao što je gnutext ili qtLinguist. I tu se nema puno filozofile. OSS software generalno ima dobru podršku za višejezičnu podršku.

Kod lokalizacije imamo više "začkoljica". Lokalizacija se dešava na tri nivoa:

1. podrška formata brojeva, oznaka u kalendaru je primarna lokalizacija. I tu uz manje varijante imamo uglavnom dobru podršku
2. podrška našim diakrticima - UTF-8 kodni standard za znakove često znabiti problem u reporting dijelu (fontovi u pdf dokumentima). 
3. podrška na aplikativnom nivou. Idealno bi bilo sve funkcije - algoritme koji su ovisni o zakonskoj legislativi izdvojiti kao module koji se moguprilagoditi za određenu državu.  

K4.2) Programski jezik(ci)

Korištenje i poznavanje programerskog jezika samo po sebi ništa ne kazuje. "Java programer", "C# programer" u današnjem svijetu software developmenta nije dovoljno da bi odredilo kompetencije developera.

Dobar developer je puno više od nekoga ko zna sintaksu određenog programskog jezika. On je sposoban na osnovu određenog funkcionalnog zahtjeva sa alatima koji su mu na raspolaganju doći do traženog rješenja. Do optimalnog rješenja. 

Optimalno rješenje je ono do koga se dolazi za najkraće moguće vrijeme, sa minimalnim brojem bug-ova, sa mogućnosti da se i drugi bez problema uključe u održavanje i nadograndju tog source koda.

Koliko god ovi generalni principi bili neovisni o programskom jeziku, treba paziti na dimenziju problema "overload"-a programskim jezicima i tehnologijama 

Rad u projektu sastavljenog od komponenti sa puno programskih jezika i različitim tehnologija značajno "troši" developera. Ovaj problem nije značajan ako postoji jasna podjela posla, koju je moguće napraviti u velikim programerskim timovima. 

Međutim, u malim timovima kakav je slučaj sa bring.out dimenzija overload-a različitih programskih jezika može biti od presudnog značaja za produktivnost razvoja.  

Kada se uzme u obzir da je na bosanskom tržištu najrealnije očekivati da se oko OSS projekta stvori zajednica od sastavljena upravo od takvih malih timova i pojedinaca, izbjegavanje "overload"-a programskim jezikom je bitna stvar.

K4.3) Jednosavnost instalacije (software deployment)

Nakon što se proizvede, software se mora instalirati. Instalacija software-a u produkcijsko okruženje (software deploymnet) je operacija koja sa mora biti što jednostavnija sa stanovišta vremena i osposobljenosti servisnog osoblja. Zato je veoma bitno kod odabira baznih tehnologija odabrati komponente koje su nam na ciljnim sistemima (target operating system) jednostavno dostupne.

out-of-box experience

Činjenica da se PostgreSQL na ubuntu/linux-u instalira sa sudo apt-get install postgresql i da se taj paket nalazi u glavnom ubuntu repozitoriju (što sa sobom povlači činjenicu da se vendor OS-a stara o security update-ima) nije nebitna. Dapače. 

Organizacija software-a

 Organizacija software-a je takođe bitna za "installation experience". Ako i kod najmanje promjene na software-u moramo na klijentske mašine download-ovati i instalirati 100 MB-a software-a, to na većem broju klijenata postaje ozbiljan problem.

Razbijanje monolitnog sistema na manje komponente omogućava da se u slučaju manjih nadogradnji (minor update) isporučuju samo komponente kod kojih su se desile promjene.

Činjenica da su kod web baziranih klijenata troškovi instalacije nove verzije minimalni jedan je od bitnih faktora njihove popularnosti. 

K5) Developerske metodologija, preporučene prakse

Čitljivost, odnosno dokumentovanje koda bez dvojbe spada u developersku praksu koja se u projektu primjenjuje manje ili više dosljedno. 

Pored toga, imamo niz stvari koje utiču na kvalitet i prihvaćenost projekta od strane šireg auditorija.

K5.1) Source code management - github

Kada je prije 5-6 godina, Linus napravio "git" source code management alat, teško da mu je palo na pamet da će neko ideju kolaboracije u software developmentu aplicirati na na čin kako je to učinjeno sa github-om http://github.com.

Github je definitivno broj jednan servis po popularnosti na polju online source code repozitorija.

Ono što je github učinilo posebnim jeste njegova posvećenost cilju kolaboracije i jednostavne komunikacije među developerima.

Iako je github plaćeni servis ukoliko želite imati na njemu privatne repozitorije, on je za par godina uzeo nevjerovatan mind-share developera.

Svakodnevnim dodavanjem novih servisa, slušanjem zahtjeva korisnika, friendly pristupom prema OSS developerima, github je postao puno više o online source code repozitorija - on je postao mjesto na kome developeri razgovaraju. I to na najprirodniji način - putem source koda.

Koliko je odabir ovakvog servisa bitan za jedan OSS projekat, govori činjenica da postoji masovni trend migracije projekata na github. 

On je posto mjesto gdje je vidljivost projekta najveća, mjesto na kome se najlakše uključiti u projekte drugih kao posmatrač ili kao aktivni učesnik. 

K5.2) "Čitljivost" za nove developere, jednostavnost kolaboracije u polju razvoja

Čitljivost za developera prije svega predstavlja dobro organizovan source-code, odgovarajuću dokumentaciju baze podataka, postojanje developerskih cookbok-ova za odgovarajuće česte nadogradnje.

OSS software koji je jednostavno izbacio source kod bez odgovarajuće dokumentacije nema veliku vrijednost.

Ako je u tom smislu kod nedostupan, džaba što je otvoren. Niko se neće zahmetiti da čita tuđe "hijeroglife".  

Iz tog razloga smo mi odmah u startu posvetili pažnju ovom aspektu projekta, koristeći docco  igithub pages:

• http://knowhow.github.com/A4_knowhow/
• http://knowhow.github.com/M3_knowhow/

Da bi se source kod ovako ustrojio, i što je još bitnije da bi se on redovno održavao na ovakav načinu, potrebno je uložiti značajne napore.

Dokumentacija je generalno jedna od standardnih software projekata. Stvari se međutim mijenjaju, novi trendovi u software developmentu ovom aspektu posvećuju značajnu pažnju.

K5.3) TDD Test driven development, BDD Behaviour driven development

Ovo je jedna stavka u metodologiji projekta koju lično smatram veoma bitnom. TDD i BDD su dvije srodne i komplementarne metodologije. 

Svode se na to da se prilikom pisanja software-a pišu unit testovi (TDD) koji ispituju ponašanje odgovarajućih klasa odnosno dijelova koda. BDD kao predmet testiranja uzima određene funkcionalne cijeline koje redovno pokrivanju *interakciju* više klasa. BDD testovi se zato zovu integracijski testovi jer pokazuju rezultate integracije više klasa.

Projekat koji je dobro pokriven TDD/BDD testovima omogućava preventivno lociranje grešaka. 

Svaki developer dobro zna da svaka njegova promjena sa sobom potencijalno nosi side-efekat generacije nekog novog bug-a. Testovima se takve greške mogu locirati u developerskom okruženju, znači prije nego li što nova (bugovita) verzija software-a dođe do krajnjeg korisnika.

O prednostima ovog ranog otkrivanja grešaka suvišno je govoriti. Međutim, samo uspostavljanje kvalitenog test sistema je veoma zahtjevan proces.

Mnogi projekti ili nemaju ili imaju samo djelimično test-covered source code.

Ovaj sindrom je posebno kod starijih projekata prisutan. Mahom tek mlađe generacije developera TDD/BDD primjenjuju u punom kapacitetu u svojim projektima.

Međutim, nije rijetkost da se uviđa pozitivan uticaj primjene TDD/BDD-a, tako da se ulažu značajni napori da se source kod naknadno počinje pokrivati testovima, te da se za novi kod forsira potpuna pokrivenost koda testovima.

K5.4) "Cool" alati 

Pored pragmatičnih i praktičnih faktora u odabiru programskih jezika i tehnologija, postoji i nešto što je manje pragmatično ali je ipak bitno za motivaciju developera. To su "coolness" tehnologija koje se koriste.

Web je "cool". Mobilne tehnologije su "cool". Pravljenje rješenja koje će se moći instalirati na cool uređaje i cool infrastrukturu sigurno je faktor koji privlači kako krajnje korisnike tako i developere u jedan OSS projekat.

Mislim da smo u knowhow ERP odabirom titanium appcelerator-a, node.js-a i javascript-a kao univerzalnog jezika za sve ove platforme napravili dobar korak.

Da. to naš razvoj i nas kao developera čini da budemo "cool" i "trendi" :). Međutim, već do sada smo osjetili niz krajnje praktičnih pozitivnih konsekvenci tog odabira.

Ove tehnologije okupljaju veliki broj talentovanih developera (englezi kažu "vibrant" community ... ne znam kako bih ovo na bosanski preveo ... a definitivno najbolje izražava ono što želim reći) omogućila nam je da "googlanjem" za tren dođemo do rješenja kada negdje zapnemo. 

Nova generacija developera bez ustezanja svoja iskustva dijeli sa drugima. Čak i pasivno učešće u toj zajednici ima na naš rad pozitivan feedback.

Sa pozicije developera u poznim godinama, mislim da je sjajna stvar učiti od tih mladih ljudi. Sve to generiše dodatne poticaje, vraća izazove u naš posao, izbija nas iz kolotečnine, tjera nas refresh i sopstvenih vještina i rethink ustaljenjog načina rada. Sve ovo tjera nas da da razmišljamo. Da budemo više kreativni, a manje nešto inteligentniji daktilografi koji kucaju ono što su nekada naučili i kako su ranije navikli.

Ukratko na ovaj način se integriramo u software development 21. vijeka. 

K6) Način komercijalizacije ERP software-a

ERP software je suviše dosadan da bi ga tamo neki volonteri razvijali :).

Informatičari se "osipaju" na pomen termina kao što su zaliha u magacinu i prodavnice, konto duguje/potražuje, cjenovnik, kontni plan ...

Nisam čuo za nekoga ko te stvari pravi zato što mu se sviđa praviti takav software. Ako ste vi čuli, recite mi :)

Pa ako je tako, da li je OSS ERP software utopija ? Nije.

Otvoreni software u ERP-u obezbjeđuje jeftinije i kvalitetniju razmjenu ideja i mogućnosti pravljenja kompleksnijih rješenja do kojih pojedinačni timovi developera samostalno ne bi mogli doći.

S obzirom da imamo i primjere otvaranja do tada in-house proprietary ERP software-a, jasno je da se OSS ERP software može komercijalizirati. 

Odgovor je krajnje jednostavan: izvorni kod (source code) sam za sebe ništa ne predstavlja. Potrebni su resursi - ljudi i znanje koji će taj kod staviti u funkciju. 

Ovo su glavni modeli komercijalizacije koje sam ja uočio:

a) Community verzija je OSS software, dok su "enterprise" verzije zatvoreni software

U ovoj varijanti, community verzija ima funkciju "open source marketinga" (što je u svijetu jako marketinško oružje, kod nas i nije s obzirom na veliku stopu piratstva), ali se iz te zajednice korisnika regrutuju novi plaćeni korisnici, kada im "community" verzija postane nedovoljna.

U community verziji mnoge napredne funkcije nedostaju ili postoje vještačka (a ne tehnička) ograničenja - "okljaštrene" funkcije. 

b) Određene funkcije vezane za periodično održavanje su onemogućene cummunity version korisnicima

Iako je ovo veoma slično modelu a), može u praksi predstavljati bitnu razliku. 

Ovdje se dešava "zamka" za korisnika u toku sljedećeg scenarija:

Korisnik koristi software sa svim njegovim funkcijama godinu-dvije. Nakon objavljivanja nove verzije korisnik, ukoliko želi migrirati podatke na novu verziju, mora kupiti enterprise verziju da bi izvršio prenos podataka.

Naravno on može instalirati praznu novu "community" verziju, unijeti podatke ručno, napraviti sopstvene migracijske skripte ... 

Ova opcija je, moja je procjena, u stvari prije svega ciljana prema eliminaciji konkurentnosti i samostalnosti drugih IT provajdera. Ovo im značajno otežava mogućnost da svojim korisnicima open source - "community" verzije ! 

Ovakvu strategiju sam uočio kod OpenERP S.A - vidi verzije te detalje uslova korištenja njihovoh migration servisa.

c) Konsultantske usluge prema partnerima

Integratori ERP rješenja - firme koje nude ERP rješenja kranjim korisnicima mogu biti jaka ciljna grupa za autore OSS ERP rješenja.

Kroz funkcionalne i developerske treninge i godišnje ugovore firme - vlasnici OSS software-a (ali to mogu biti i druge firme koje su prepoznate kao veliki poznavaoci software-a, ne moraju biti samo vlasnici licence - copyright holderi) stiču značanje prihode

d) Konsultanske usluge i obuka kranjih korisnika

Ovdje imamo prihode od treninga krajnjih korisnika i prodaje korisničke literature.

K7) Funkcionalne karakteristike

Osnovne funkcionalne karaktistike su ono što nam OSS ERP software out-of-box nudi. 

Tu imamo dva nivoa:

1) Glavne funkcije (base domain functions)

Nivo podrške proizvodnji, podrška accounting-u, CRM podrška, maloprodaja (retail), veleprodaja, razrada poreznog sistema, podržane vrste transakcija i dokumenata

2) Bazne, generičke funkcije (common/base functions, configuration, master data)

Ovdje spadaju generičke funkcije kao što su:

• sistem zašite
• mogućnost (jednostavnost) podešenja workflow-a na nivou korisnika
• generalni pristup prilagodbi software-a za pojedinačne primjene i pojedinačne korisnike.

Naravno, što više toga imamo out-of-box manje trebamo sami implementirati. Ali, ako su te funkcije jedna "šuma" u kojoj se teško snaći, nismo puno dobili ... Zato slijedi sljedeća karakteristika

K7.1) Inituitivnost korisničkog interfejsa

OSS ERP aplikacije koje su bile predmet mog proučavanja su bile veoma različite u smislu koncepta korisničkog interfejsa. Mnoga od rješenja su imale generički pristup unosu podataka što u mnogim slučajevima stvara krajnje neintuitivan korisnički interfejs.

Ako ja kao IT profesionalac ne mogu bez dokumentacije ni nazrijeti kako unijeti podatke, onda je definitivno pojam korisničkog interfejsa sporna stavka.

Svaki ERP software za ozbiljno korištenje tražiobuku korisnika. Međutim postoji značajan broj operacija koje korisnik moraju biti "nadohvat ruke" bez potrebe da konsultuje dokumentaciju.

ERP software veoma često krasi ružnan i neintuitivnan interefejsom. U raspravama sa korisnicima, autori ERP software-a se brane činjenicom da su "funkcije ispred lickanja", "da to tako mora da izgledati" itd ... Godinama sam i sam bio u tom "filmu" po pitanju ocjena našeg software-a. 

Sada, sa ovom pameću mislim da bez dobrog korisničkičkog interfejsa nema dobre aplikacije. 

Da ne bude nesporazuma: aplikacija sa dobrim korisničkim interfejsom može biti i čista konzolna aplikacija.  

Bitan je use-case - kontekst korištenja aplikacije.

K7.2) Funkcionalna usaglašenost sa našim zakonima i principima računovodstva

Iako zadnja, u listi kriterija u odabiru OSS ERP-a, ovo je vjerovatno za naše tržište jedan od "najškakljivijih" kriterija.

Nijedan od postojećih OSS ERP-ova ne prati našu zakonsku regulativu. 

Toj zakonskoj regulativi treba dodati i ono što bih se najprije moglo nazvati nazvao navikama korisnika i zaostacima iz ranijih metoda vođenja računovodstva.

Tako recimo niti jedan od postojećih programskih rješenja ne predviđa vođenje lagera u prodavnicama sa ukalkulisanim porezom. 

Nigdje nisam sreo dokumente "zaduženje prodavnice" u kome figuriše magacinska cijena bez poreza i maloprodajna cijena sa porezom. Tako nigdje nisam našao ono što se kod nas zove "nivelacija cijena u prodavnici". Zašto ? Zato što takav dokument ne postoji. 

U tom dijelu prodaje postoje opcije za formiranje cjenovika (price lists) na hiljadu načina. Logično postoje cjenovnici za prodavnicu, za veleprodaju. Postoji podrška za različite algoritme količinskih rabata (quantity price break) ... Ovih naših nivelacije nigdje ni u tragovima :) 

Kako god razmislim, ove razlike koje se pred naš ERP, prezicnije računovodstveni dio ERP-a postavljaju su prevashodno rezultat naših ranijih navika iz ranijih (socijalistički zakoni, porezu na promet itd). Kakav god uzrok bio, to se u određenoj mjeri mora implementirati da bi se software mogao koristiti na našem tržištu. Koliko i šta od toga - tu treba biti pažljiv. Treba nastojati što manje funkcija koje nisu prisutne u postojećoj računovodstvenoj i zakonskoj regulativi izbjeći, te pokušati maksimalni iskoristiti postojeće funkcije OSS ERP-a.

Eto nas ... na početku

Oooouch. Čitav dan mi je trebalo da pobrojim kriterije. Sada napokon mogu dati i svoje ocjene za software koji je bio predmet mojih istraživanja:

• OpenERP
• Adempiere
• OpenBravo
• xTuple

O tome, aBd, slijedi poseban članak.