hernad

Dinamika,  mjesec kašnjenja

Nakon objave projekta, utvrđena je dinamika projekta.

Faza "knowhow-init" je određen za januar, ali taj rok nije postignut. Razloga za to je više, od čega bih izdvojio dva glavna:

1. problemi sa fiskalizacijom
2. "širenje" teme u odnosu na prvobitnu zamisao(*)
   1. prvobitno je zamišljeno da se urade prilagodbe za naše zakone bez bitnih programerskih intervencija, međutim, u toku realizacije pokazalo se da će takve stvari biti neophodne
   2. dosta vremena je posvećeno na upoznavanje OpenERP koncepata, koji opet ukazuju na standardne principe knjigovodstva u "bijelome svijetu". Mnogi od otvorenih ticketa upravo obrađuju ovu temu: #21925, #22137, #22021, #22053, #22068

Od stvari koje je bitno naglasiti, istaknuću činjenicu smo u bring.out uspjeli napraviti potrebnu reorganizaciju, tako da su sve tekuće operacije preuzele kolege.

Naime, prvobitni plan je taj da u prve dvije faze na projektu radim samostalno, a da upravljačke funkcije preuzme kolega Saša. Taj proces je uspješno završen, tako da ova organizacija funkcioniše od početka godine.

Jedan od glavnih razloga za ovu "zgusnutu" dinamiku jeste nastojanje da se knowhow pokrene zajedno sa fiskalizacijom.

Dobra okolnost je taj da je država ovaj projekat takođe promjerila za mjesec dana, tako da ovo kašnjenje ne isključuje mogućnost da se knowhow i fiskalizacija u "Rama-glas"-u realizuju zajedno.

Pored gore navedenih događaja, drugi bitan faktor realizacije moje privatne obaveze na fakultetu. Nadam se da u narednom izvještaju neće stajati: "S obzirom da sam popad'o sve ispite u prvom roku ... morao sam spremati drugi ... pa sam opet toga pao u drugom  ... pa evo spremam za treći rok ..." :)

Redmine statistika

Redmine se u bring.out koristi i za praćenje radnog učinka.  Tu praksu sam nastavio i na knowhow. Ta evidencija kazuje da je do sada utrošeno 60 programer/analiza-priprema sahata. Procjena je da je ukupno 100-120 sahata vrijeme potrebno za realizaciju faze knowhow-init.   To bi bilo još cca 10 dana efektivng rada, odnosno dvije hefte.

U proteklom periodu kreirana 54 ticketa, od toga status "otvoreno" ima 40.

Realizacija

Programiranje

"Zgnječen" je i prvi pravi bug :). Evo o čemu se radi:

OpenERP, kao internacionalni projekat, ima standardnu boljku podrške naših diakritika (naših slova). Ispitivajući reporting opcije, došao sam do opcije podešenja reporta na korisničkom nivou. Opcija funkcioniše ovako:

• u openoffice writer instaliramo "openerp designer" ekstenziju
• ta ekstenzija, kao i svaki drugi klijent pristupa knowhow serveru
• iz liste odabiremo željeni report, designer nam prebaci taj report kao standardni openoffice dokument
• napravimo ispravke - send to server i posao je gotov ... imamo prilagođeni report

 
Međutim, kod testiranja te opcije sam dobio greške, za koje sam brzo (čitajući forume) uočio da je uzrokovana našim diakriticima.
 
Idući tim putem došao sam do informacije da je u developerskom stablu taj problem riješen. "Pokupio" sam to rješenje, ali se ispostavilo da to rješenje ne radi dobro. Ako u report ubacim naša slova, greška se ponovo dešava.

Iako sam u ovoj fazi projekta, sa funkcionalog stanovišta, komotno mogao ovaj problem ostaviti po  strani, odlučio sam da ga ipak "napadnem". Razlog:

To je znanje - knowhow koji trebam - idem ga uzeti bez odlaganja.

Svaki netrivijalni debug uključuje upoznavanje detaljno upoznavanje projekta. Očekivano, borba sa ovim bugom je pomogao da steknem i/ili osvježim znanje iz python-a, te da napravim testno developersko okruženje u svrhu izolacije greške.

Dva dana sam utrošio na ovom bug-u. Ali sada, ako ništa drugo, mogu reći da knowhow nije čisti džon OpenERP-a :).

Šta OpenERP nema, a FMK ima ?

Kao i za sve ostalo, po ovom pitanju postoji ticket.

Glavna stvar koja nedostaje je kalkulacija zavisnih troškova kod ulaza robe/sirovina. Na openerp forumima sam došao do toga da su se sa istim problemom susreli mnogi, a da su najdalje stigli - ni manje ni više nego Tajlanđani :)
 
Prema onome što sam pročitao, u modulu addon "ac_account_thai" ta opcija je već implementirana. Ostaje da se opcija analizira na nivou source koda. Naime, ovaj dio će sigurno tražiti prilagodbe za naše potrebe, tako da je "napamet" instalacija modula izvjesno put koji neće dati željene rezultate. Dobra je stvar što sam se za to već dobro pripremio pri otklanjaju bug-a #22037.

Šta od gornjih nedostajućih stavki pripada bosanskoj legislativi, a šta navikama ?

Otvorenost knowhow projekta je njegov bitan atribut. Jedan od knowhow foruma nosi naziv  knjigovodstvo . Objasniću zašto je ovaj forum bitan, i šta od njega očekujem.

Cilj knowhow projekta nije samo tehnološko unapređenje naših ERP rješenja. Taj dio nažalost i nije teško postići :(.

Podjednako je bitno da da knowhow bude realizovan na takav način da se u njega na najbolji načinu ugradi naše dugogodišnje iskustvo iz oblasti knjigovodstva i poslovnih procesa općenito.

U članku "Tražimo knjigovođu" sam objasnio strategiju koju smo primjenili kod implementacije PDV zakoske regulative. "Slijepo" prihvatanje zahtjeva korisnika nije dobar način za izgradnju kvalitetnog IT rješenja. 
 
Taj princip primjenjujemo i u knowhow projektu.

Računovodstvena legislativa u u BiH se iz godine u godinu mijenja u jednom smijeru: Međunarodni računovodstveni standardi.

Tako recimo u standardu "MRS-2 - zalihe", se nigdje navodi da se prodavnica treba voditi po prodajnim cijenama.

Jedna od stvari koja u OpenERP u odnosu na Fmk nedostaje jeste nedostatak opcije nivelacije u prodavnicama.

OpenERP u dijelu zalihe (stock) isključivo barata sa nabavnim cijenama, bez obzira da li se radi o prodavnici (shop) ili prodaji iz magacina (warehouse).

S druge strane, OpenERP ima detaljno razrađen sistem cjenovnika (price list).

Ovo je sve uvod u princip nadogradnje koji želimo primjenjivati u knowhow projeku:

Prilagodbama OpenERP pristupiti sistematski. Dobro prostudirati postojeću logiku i vidjeti da li su stvari koje mi sada (u postojećim rješenjima ) radimo drugačije iz radi naše zakonske regulative ili radi naših *ranijih navika*.

Primjer:

Prilikom uvođenja PDV-a, većina naših korisnika je insistirala na tome da se magacin vodi (kako je do tada bilo) po prodajnim cijenama. Zašto ? Zato što su to tako navikli, i zato što je to tako bilo obavezno u staroj zakonskoj regulativi (porez na promet, porez na razliku u cijeni u veleprodaji).

Kada smo prilikom uvođenja PDV-a rekli da prelazimo na vođenje magacina po nabavnim cijenama (te da se posljedično ukidamo opciju nivelacije magacina), imali smo niz pritužbi korisnika. Međutim, kasnije se pokazalo se da je naša odluka bila ispravna.

OpenERP community

U toku programerskih aktivnosti, veliki dio vremena sam utrošio na upoznavanje openerp community-ja.

Pored zemalja koje gravitiraju oko Belgije (tvoraca OpenERP-a), našao sam firme i pojedince iz Španije, Tajland, Pakistana koji su iskusni implementatori i/ili developeri (najčešće oboje) rješenja baziranih na OpenERP-u.

Uočio sam da su te firme mahom dijele našu filozofiju otvorenosti. Naravno, OpenERP licence ih "tjeraju" da source kod objavljuju, ali nije sve u source kodu. Bitno je da su oni aktivni učesnici foruma, da dijele svoja uspješna iskustva ali i probleme.

To je "karta" na koju sam puno položio. Informacije koje sam u proteklom periodu prikupio mi kažu da nisam oful'o.

Nerealizovano

Nisam napravio ni jednu video prezentaciju do sada urađenih stvari. Jedna je riječ, a drugo je slika.

To ću staviti kao prioritet. Takvi materijali će pomoći publicitetu projekta, i uključivanju drugih zainteresovanih.

Kako "stvar" radi ?

Prema onome što sam tokom rada testirao mogu konstatovati da su bazne komponente dobro riješene: sistem knjiženja, hijerarhijski kontni plan, hijerarhijski BOM (bill - of materijal - sastavnice u proizvodnji).

Način unosa podataka je jednostavan i intuitivan. Najveći dio vremena sam utrošio na standardnom GUI (gtk) klijentu. Korisnicima Fmk će sigurno trebati stanovito vrijeme za drugačiji korisnički interfejs, ali nisam sreo ništa za šta očekujem komentare tipa: "Šta nam ovo uvaliste ljudi !?"

Reporting sistem je jača strana knowhow. Upravljački dio firme će veoma brzo, aBd, dobiti ono što u Fmk nije mogao dobiti.

Zaključak

1. tokom rada je potvrđena pretpostavka sa kojom se ušlo u projekat: knowhow ima dobru tehnološku osnovu
2. potvrđena je i kvalitetna funkcionalna osnova (kontni plan, proizvodi, sastavnice, sistem izvještavanja)
3. sve do do sada tražene informaciju su javno dostupne. Pored "source koda" dostupna je i velika količina popratne dokumentacija kako od OpenERP s.a. (vođe projekta) tako i od community-ja.
4. OpenERP projekat je veliki eko-sistem. Unutar njega funkcioniše globalni - širom svijeta raspoređen "community". Kao takav, on je odlična baza za knowhow projekat.

Lični dojam

Najviše sam nezadovoljan vremenom koji sam proveo efektivno na projektu. Sam rad na projektu najbolje bih opisao na ovaj način:

Jest' lijepo radit' pametne stvari !

Statistika pokazuje da sam u ovih dva mjeseca tek 10-tak dana bio kompletno "u knowhow". To moram popraviti.

S druge strane, takvo što je bilo očekivano jer je kompletnu firmu bilo neophodno "preswitchati" u drugačiji režim rada. Taj switch je izvršen, i to mi daje realnu osnovu da u narednom periodu očekujem znatno veći omjer knowhow/ostale_aktivnosti.  Iskreno, najviše se bojim obaveza na fakultetu.

Činjenica je međutim da se stvar "zakolutala", da imamo progres, da su pretpostavke sa kojima se u projekat ušlo u najvećoj mjeri potvrđene, te da je knowhow projekat koji je i meni i svima u bring.out vratio optimizam po pitanju budućnosti firme. A to nam je "k'o kruh" trebalo :).

Za kraj

Dinamika realizacije se se pomijera za mjesec dana u odnosu na prvobitni plan.

Knowhow od dana objavljivanja "živi" kao otvoren projekat. Svaka aktivnost je vidljiva za bilo kog internet korisnika. U početnoj fazi projekta, ta činjenica nema veliku važnost. Moje očekivanje je da će ta dimenzija u budućnosti biti jedan od ključnih atributa razvoja projekta, inshallah. Zato sam posebno ponosan na tu odluku.

Kada sam prije 5-6 godina pokrenuo blog o free & opensource software-u, na naslovu stranu sam stavio ovu rečenicu:

Is it possible to make good software - here in Bosnia ?(*)

Kada sam postavio to retoričko pitanje, vodio sam se stavom da na malom tržištu, kao što je bosansko, nije moguće napraviti dobar software(**) sa klasičnim - zatvorenim modelom razvoja, te da jedino otvoreni model razvoja može obezbjediti dovoljno resursa da bi u konačnici dobili software koji ima atribut "dobar".

"knowhow" projekat je upravo rezultat nastojanja da na gornje pitanje, na kraju "balade", ipak odgovorim: "Jeste !"

Bil' hajr.

---

(*) Da li je moguće napraviti dobar software - ovdje u Bosni ?

(**) Pri tome mislim prije svega na ERP/poslovni software koji je u fokusu našeg rada