hernad

Update (21.11.2012): ovo je treća revizija članka. Svi dijelovi u kojima su navedeni stavovi kolege ili moje razumjevanje tih stavova su uklonjeni. Stoga je članak većim dijelom nepovezan. 

Prije par dana sam otišao sam na kahvu kod kolege informatičara na temu "knowhow ERP".

Na moje veliko iznenađenje, glavni utisak o materijalima je bio: nejasno.

<izbrisano>

Pomislio sam:

Auuu ljudi moji ... zar sam tako nerazumljiv ?!

Znam da su sadržaji na mom blogu puni "šuma" (eng. noise).

Šuma koji se generiše čestim digresijama i načinom na kojim izlažem svoje emocije i lični stav. Nekima je taj stil interesantan, nekima smješan, ali mnoge očigledno odbija u razumjevanju "ozbiljnog" dijela priče.

Većina materijala koje sam objavio na temu "knowhow ERP" napisana su na personalnom blogu, upravo iz tog razloga.

Da bih razdvojo lične od članaka koji nisu opterećeni pomenutim "šumom", pokrenut je poseban tehnički blog pod naslovom "Do we know how to make a good software ?" .

I ovaj blog je svojim potpisom "Informatičke priče by bring.out" obojen "casual" stilom komuniciranja, ali je ipak rasterećen od mojih opaski.

Treba tome dodati da se i na mom blogu nalaze članci pisani različtim stilom po istim temama:

http://hernad.bring.out.ba/trazi-se-knowhow-erp-project-manager

http://hernad.bring.out.ba/trazi-se-serviser-knowhow-erp

Kako je moja supruga prokomentarisala, za većinu je prvi članak obična zafrkancija. Ona je kao veliki poznavalace mene :) ipak shvatila poruku oba članka.

Za drugi je prokomentarisala: "Super, imaš pravi test poučljivosti i motivacije". 

Dženana nije informatičar pa da zna da li sam postavio dobre testove, ali je očito posljednji oglas strukturom i konceptom dobro napisan za širi auditorij.

"Pupa-hava"

<izbrisano>

Dosadni video

<izbrisano>

Objasnio sam da je kao tehnološka osnova uzet "xTuple ERP", da smo prezentovali dio samo xTuple-a kojim smo mi "ovladali" (a to je manje od pola) te da "xTuple Reference Guide" daje dobar pregled funkcionalnih karakteristika xTuple-a: 

http://do-we-know-how.bring.out.ba/xtuple-openrpt-users-guide 

Objasnio sam da u "Reference Guide"-u postoje i funkcije koje nisu podržane u OSS verziji xTuple-a (podrška za više organizacijskih jedinica - "Multisite", više magacina "Multi warehouse", "Bill of Operations", Work Centre"), te da radimo na "otvaranju" tih funkcija.

Objasnio sam da xTuple ima "open-core" model razvoja a da mi želimo obezbjediti kompletno rješenje kao open source software.

Model poslovanja

"open core" je bio polazište za diskusiju na temu poslovnog modela "knowhow ERP".  

<izbrisano>

Licence

<izbrisano>

Objasnio sam:

Prije svega, knowhow ERP je proizvod koji se razvija. Mi u ovom trenutku kao cilj imamo realizovati zahtjeve postojećih klijenata. Ali što se tiče poslovnog modela - ponude prema krajnjim korisnicima, tu nema nekog značajnog odstupanja u odnosu na standardnu ponudu.

<izbrisano>

Naravno, mi sa cijenama svog rješenja možemo za isti set funkcija biti značajno povoljniji jer naše rješenje nije opterećeno licencama eksternih vendora.

Ali princip je isti, rješenje za jednog korisnika košta 1.000 KM za drugog 10.000 KM za trećeg 20.000 KM, ovisno o kompleksnosti i veličini njegovog IS-a.

Kao osnovni parametar za troškove podrške i tekućeg održavanja uzima se vrijednost IS-a.

Međutim, otvorenost našeg rješenja daje korisniku opcije koje zatvorena rješenja ne daju:

- za realizaciju specifičnih funkcija može angažovati sopstvene IT resurse ili druge ERP vendore koji nude "knowhow ERP"

- otvoreni software ne ograničava stepen integracije rješenja trećih proizvođača  

Po formiranju većeg eko-sistema "knowhow ERP" provajdera "vendor lock" je isključen.

To sve vodi onome što je polazište razvoja "knowhow ERP"-a:

- "knowohw ERP" je alat za ERP implementatore

- otvoreni razvoj treba obezbjediti da to bude DOBAR alat

- "bring.out" se pozicionira kao "knowhow ERP" vendor.

Znači, "knowhow ERP" sam po sebi nema poslovni model. On je ALAT koji koristi i razvija eko-sistem "knowhow ERP" vendora.

Cijene, ciljna korisnička grupa

Diskusija se nastavila na relaciji vendor - klijent:

<izbrisano>

Po ovom pitanju sam se djelimično složio:

Ciljna korisnička grupa knowhow ERP su mala i srednja bosanska preduzeća. Klijenti sa kojima mi radimo nemaju novac investirati  100 ili 200 hiljada KM u IS. Oni imaju budžet reda veličine 5-10 hiljada KM. 

Što se tiče druge konstatacije, u tome se u potpunosti slažem: Software od 1 KM je bačena para ako ne radi posao koji je korisniku potreban.

Brendovi: SAP, Navision

Cijene su nas dovele do priče o velikim ERP vendorima "SAP", Microsoft "Navision". Pitao sam ga:

Zar se nećeš složiti da su SAP, Navision rješenja čiji su ozbiljni kupci jedino BH Telecom i JP Elektroprivreda i to koliko radi njihovih funkcija toliko i radi činjenice da se radi o kupovini brenda. "Mi smo 'SAP' ERP korisnici", je često dio priče o rejtingu same firme. ... Slično kao što biznismen koji drži to svog statusa kupuje kupuje "Porche" ili "Audi" džip, a ne "Hyndai"-a.

Kolega je prokementarisao:

<izbrisano>

Nastavio sam:

Tačno. "knowhow ERP" je i dao ime po tome što smatram da je "know-how" vendora puno više od onoga što sam software predstavlja.

Loš i neupućen ERP vendor može i SAP i Navision pretvoriti u noćnu moru za korisnika.

Taj dio implementacije je polje u kojima se svaki budući vendor baziran na "knowhow ERP" može diferencirati.

Software je alat. Korisnik software vidi primarno kroz prizmu kvaliteta implementacija ERP-a od strane konkretnog vendora.

Njega ne interesuje ni kako je software pravljen ni ko ga je pravio, ni je li otvoren ili zatvoren. Njega interesuje ŠTA može dobiti od svog vendora i po kojoj CIJENI.

Ciljno tržište samo Bosna ?

Pomenuo sam u toj priči da je sada ciljno tržište "knowhow ERP" isključivo Bosna. Pitao me je:

<izbrisano>

Objasnio sam:

Projekat je otvoren. Smo motivirani tekućim zahtjevima naših klijenata. Kvaka je u tome što je projekat otvoren, i kao takav nije ograničen na naše poslovne planove. "Sutra" može da se pojavi firma ili pojedinac u Prijedoru ili Ljubuškom ili Osijeku ili Nišu koja će unutar "knohow ERP" ili unutar "XYZ ERP" projekta proširiti cijnu korisničku grupu.  

Naš poslovni cilj je u ovom momentu zadovoljiti zahtjeve naših postojećih klijenata. To je fokus našeg razvoja. Tek kada taj cilj ispunimo, aBd, slijede novi poslovni ciljevi.

Treba uočiti da realni domet tih ciljeva značajno ovisi od eksternim faktorima. Ako se formira kvalitetna i velika "knowhow ERP" zajednica, nešto što je danas neostvarivo može u tom scenariju biti nadohvat ruke.

DOBAR software, <izbrisano>

Ono što me je poprilično zateklo jeste gledanje na ključnu ideju u kreiranju i razvoju "knowhow ERP": napraviti dobar software kao alat.

<izbrisano>

I onda ponovo dolazim do početnog pitanja: "Kako organizovati razvoj ? Kako doći do tog boljeg software-a ?"

<izbrisano>. Vjerovatno je moja okrenutost razvoju software-a predimenzionirana.

Ali čak i kada pokušam napraviti mentalni pomak u tom smjeru (pusti se razvoja, usmjeri se na kvalitetnu implementaciju onoga što imaš) ne mogu "dobaciti" daleko. Software jeste samo alat ali nije ni džaba ni poslovica: "Bez dobrog alata nema zanata."

Moji zaključci

Na kraju sam došao do sljedećih konstatacija

<izbrisano>

Paradigma "DOBRO programsko rešenje" se u IT sektoru mijenja. Bosansko IT tržište poslovnog software-a je, moj je dojam u velikoj mjeri "okovano" u ustaljene klišee i prakse. 

"Data Lab" i "Pahtneon" kao osvježenje

Jedino osvježenje na tom polju donijeli su strani vendori kao što je slovenački "Data Lab" sa svojim programskim rješenjem "Pantheon".

Napravili su jaku mrežu partnera na čitavom regionu. I bukvalno "pomeli" domaće vendore.

U tom modelu mi se nisu svidjele sljedeće stavke:

1. zatvoreni model razvoja - mogućnost razvoja "third party" rješenja(*) oko postojećeg ERP-a.
2. odabir tehnologija (Windows-only)

Upravo na razlikama po ovim pitanjima je baziran razvoj "knowhow ERP", odnosno poslovni model "bring.out" kao ERP provajdera. 

F2 fiskalni modul primjer

Vratimo se na naš razgovor. Pokušao sam na primjeru razvoja fiskalnog modula želio sam demonstrirati ideju "dobrog software"-a:

Mi smo još davno napravili podršku našeg postojećeg FMK programskog rješenja obezbjedili podršku za par fiskalnih sistema. 

Međutim, dizajn tog rješenja u startu je bio loš. Ono što je u toj priči bitno jeste da je taj loš dizajn nije rezultat previda nego proračunatog kompromisa:

Za DOBRO rješenje treba nam cca 400-500 h razvoja a ovo postojeće možemo "sklepati" za 50-100.

Kako nam vrijeme nije dozvoljalo prvu varijantu(**), u startu smo razvili rješenje koje smatramo improvizacijom. Rješenje koje radi ali nema atribut "DOBAR" software.

<izbrisano>

Objasnio sam:

Zato što se radi o jednostavoj funkciji sistema koje kod nas stvara generiše dosta servisnih aktivnosti koje bi DOBRO rješenje moglo eliminisati ili značajno reducirati.

Bez obzira što je funkcija jednostavna, njen zastoj stvara korisnicima puno problema, a time naravno i nama.

I na kraju zato, što se radi o rješenju koje je instalirano kod mnogo klijenata, tako da taj broj instalacija daje ovoj funkciji poseban značaj.

<izbrisano>

Kako god bilo, svrha ove priče je bila da objasnim na šta mislim kada kažem "DOBAR software":

1. software koji radi posao onako kako to klijent želi
2. software kod koga su manuelne servisne intervencije svedene na minimum
3. software kod koga je u slučaju problema na eksternim sistemima i bug-ova u samoj aplikaciji moguće efikasno dijagnosticirati problem, i sve to bez izlaska servisera na teren (u većini slučajeva) i sa što manjim učešćem klijenta u procesu dijagnistike
4. software kod koga je instalacija novih verzija jednostavna sa što manje ili bez intervencija od strane servisera i krajnjih korisnika
5. agilni razvoj - developerske metode koje obezbjeđuju stalnu isporuku novih verzija(***) 

Procedure i metodologija razvoja i nuđenja software-a

Kvalitetno upoznavanje domena problema  je neophodno da bi se dobio dobar softare. 

Usvajanje određenih procedura i metodologija u razvoju i nuđenju software-a je bitno.

<izbrisano>

Model sam po sebi nije cilj. Nijedan alat nije "silver bulet" za razvoj software-a. Razvoj DOBROG software-a je miks klasičnog inžinjerstva i kreacije.

Agilno modeliranje  se često odvija na komadu papira. Ovakav pristup modeliranju upravo uzima u obzir kreativnu crtu razvoja software-a.

Agilne metodologije ukazuju da sve što omogućava brzu i kvalitetnu komunikaciju između stakeholder-a, te  rezultira redovnom održavanju svih artifakata IS-a (modeli, source code, dokumentacija) bez puno "overhead"-a predstavlja prihvatljiv developerski toolset.

Komunikacija

U području vezanom za komunikaciji između developera, mislim da se od onoga što smo mi u "bring.out" postigli ima šta naučiti.

github (https://github.com/knowhow, https://github.com/bringout-fmk) i redmine (http://redmine.bring.out.ba/) su alati koji omogućavaju izvanredan nivo komunikacije unutar tima:

• Razmjenu ideja i iskustava
• Pomoć kolegama
• Prostor za diskutovanje
• Jednostavni knowhledge-base projekata.

I sve to sa minimalnim "overhead"-om.

Zato sam mišljenja da smo mi u "bring.out" na planu metodologije razvoja software-a postigli puno. Mi komuniciramo. U svakoj našoj radnoj proceduri proceduri utkan je koncept "upgrade"-a i komunikacije.

Šta je odlika dobrog (OSS) projekta ?

U kontekstu naše predhodne diskusije, postavio sam sam sebi pitanje:

Šta je to odlika onda dobrog OSS projekta ? Da li sam u konceptu "knowhow ERP" iz vida ispustio neke ključne zakonitostu struke ?! 

Sjetio sam se ranije napisanog članka na ovu temu i dijela koji se odnosi na ovo pitanje:

"K5) Developerske metodologija, preporučene prakse"

Natavio sam sa razmišljanjem o tome na šta se u drugim OSS projektima potencira:

- Prezentacija putem video materijala se najviše koristi za sticanje prvih utisaka o projektu:

http://www.xtuple.com/demo/videos

- Kvalitetna developerska dokumentacija takođe je među stavkama koje se smatraju iznimno bitnim za OSS projekte.

Ali se pri tome uvijek potencira sveobuhvatnost i ažurnost a ne određena forma te dokumentacije.

Dobro ogranizovane, ažurne wiki stranice smatraju se sasvim dovoljnim u OSS projektima sa kojima sam se upoznao. Bitno je da se što više toga može "google"-ati, da su informacije svim potencijalnim korisnicima što više dostupne. 

Mi se na "knowhow ERP" nastojimo držati upravo ovih principa. I dalje mislim da je to dobar put.

Meta-znanje, inžinjer, tehničar, FIT

<izbrisano>

Nastavio sam:

Hm ja mislim da nije. "FIT" jeste pomogao da o ovim temama intenzivnije razmišljam, ali "FIT" sam po sebi znanje o kome ti pričaš ne nudi. Ovo o čemu razgovaramo su meta-vještine, a FIT se nažalost vrlo malo bavi meta-vještinama.

Ako je nešto ostavilo traga onda je to studiranje na ETF-u 

Ovo studiranje na FIT-u definitivno nije. Ali kako god, mislim da meni meta-vještine o kojima razgovaramo ipak ne nedostaju.

Projekt menadžment definitivno nije moja jača strana, ali metodologija razvoja software jeste. 

Kada sam pomenuo "FIT", prisjetio sam se nedavno napisane priče o "Barbiki". U sebi sam rekao:

Fakultet, Kakav "crni" fakultet :(

Zaključak

Ovo posljepodne mi je bilo od velike koristi.

Pomoglo mi je da shvatim sam da je za prezentaciju projekta širem stručnom auditoriju potrebno još puno toga napisati, i sve to na jedan bitno drugačiji način. Onako kako su to ljudi navikli.

Moj postojeći stil promoviranja "knowhow ERP" može zainteresovati samo prave "open source" entuzijaste, a takvih je u Bosni malo.

Nakon ovoga sam odlučio da u narednih par mjeseci po ovom pitanju ništa značajno ni ne pokušavam. 

Trebamo se prije svega okrenuti svojim internim ciljevima - pripremi knowhow ERP za naše klijente. A nakon toga, aBd, idemo dalje.

Log promjena:

• 21.11.2011: ovo je treća revizija članka. Svi dijelovi u kojima su navedeni stavovi kolege ili moje razumjevanje tih stavova su uklonjeni.
• 16.11.2011: radi se o verziji 2 članka. Prva verzija napisana je na neadekvatan način po pitanju privatnosti.

----

(*)  Par puta sam sa kolegama iz "Data Lab"-a razgovarao na ovu temu. Svaki put sam odgovor protumačio kao klasičnu "salesman" priču - samo ti kupi i nšta se ne sekiraj. Ubjeđivan sam kako partneri ravnopravno učestvuju u razvoju. Kada sam pitao: Pa dobro, kad je to tako ravnopravno, kako mi možemo iskoristiti i sačuvati svoje developerske resurse. Da li i kako lokalni developeri mogu "Data Lab"-u nuditi svoje programerske usluge ? Na ovakva pitanja nisam dobio odgovor.

(**) Ključni koncept u po nama DOBROM dizajnu jeste realizacija web aplikacije kojoj će ERP klijenti proslijeđivati web zahtjeve, a ona će jedan po jedan po principu printer spooler-a obrađivati http://redmine.bring.out.ba/issues/24646 

(***) TDD/BDD development obezbjeđuje da se kod isporuke novih verzija reduciraju "side efekti" - neželjene regresije u postojećim funkcijama sistema usljed realizacije novih funkcija. Što bi naš narod rekao da bude što manje slučajeva: "jedno napravio drugo pokvario".