Tok količina

Kada se posluje sa artiklima, najčešće postoji potreba za praćenjem realizacije po pitanju količina. Koliko je isporučeno od onoga što je poručeno? Koliko je poručeno od onoga što je trebovano? Koliko je reklamirano od isporučenog? Ta pitanja se retko svode na samo jedan deo procedure, najčešće se koraci procesa nadovezuju u niz - na primer, porudžbina, proizvodnja, isporuka, fakturisanje - i posmatraju kao celina. Bilo bi korisno znati dokle smo stigli u svakom od pojedinačnih koraka ali i imati sliku ukupnog stanja. Standardni ERP softveri najčešće daju ili globalni presek prema klijentu ili pojednostavljeno povezivanje dokumenata, što nije dovoljno za precizno praćenje. U Cyclone ERP je razvijeno originalno rešenje koje evidentira prelaze količina artikala iz jednog dokumenta u drugi i daje tačan odgovor na pitanje odakle je koja količina stigla i gde je završila. Ovo omogućava praćenje proizvoljno kompleksnih i razgranatih procesa na jednostavan način, jer je korisnikova dužnost da svaki dokument poveže sa prethodnim u nizu a sistem je tu da unete podatke analizira.

Primeri

Prodaja je relativno jednostavan primer ovakvog procesa. Postoji nekakav početni dokument u kojem je evidentirano koje količine treba isporučiti kupcu i fakturisati - to je uglavnom porudžbenica ili radni nalog. Kada se roba otprema, treba u otpremnici evidentirati koja količina iz koje stavke porudžbenice je otišla sa kojom stavkom otpremnice. Ovde su moguće varijacije, da se roba isporučuje sa više otpremnica, da se jednom otpremnicom istovremeno isporuči više porudžbenica, i slično. Veza između stavki dokumenata omogućava sistemu da zna preostalu, neisporučenu količinu i da prati realizaciju.

Slično se radi i sa fakturom, s tim što sada postoji više mogućnosti: faktura može ići iz otpremnice ili iz porudžbenice (može i iz oba dokumenta ali to izbegavamo pošto komplikuje rad). Kako god da se veže, sistem zna u kojim dokumentima su koje količine završile i vodi računa o tome da otpremimo poručenu količinu i da fakturišemo otpremljenu količinu.

Ako se u priči pojavi reklamacija, ona se računa kao negativan broj i umanjuje realizaciju na odgovarajući način: ta količina se pojavljuje ili kao neisporučena količina (pa sledeće isporuke idu na osnovu originalne porudžbenice) ili se ona računa kao nova porudžbenica (pa isporuke idu na osnovu nje). Ako se kreira knjižno odobrenje, ono zatvara date količine, tj. evidentira da one neće biti isporučivane. Sa ovim, povezani dokumenti već čine kompleksan graf: korisnicima je i dalje jednostavno da ažuriraju ove podatke jer ih zanima samo jedan korak, dakle kada unose dokument gledaju na koji prethodni dokument ga vezuju, a teži deo posla - analizu - radi sam sistem.

U nabavci se primenjuje isti princip, samo su dokumenti drugačiji i može ih biti više. Uobičajeno je da nabavka počinje trebovanjem koje označava zahtevane količine artikala, i njega kreira krajnji korisnik - odeljenje kojem je artikl potreban. Na nju se zatim nadovezuju, recimo, izdatnica (imamo robu na stanju i možemo da je izdamo) ili nalog za nabavku (nemamo na stanju, poručiti), i ove dokumente obično kreira odgovorna osoba u magacinu. Dokumenti ostaju kao tačna evidencija kako smo rasporedili trebovanu količinu, tj. šta želimo sa njom da uradimo. Nalog za nabavku stiže u nabavnu službu gde se na osnovu njega kreiraju porudžbenice za dobavljače, a kada roba pristigne u magacin na njih se vezuju prijemnice.

Primetiti da je evidencija podataka i ovde jednostavna: svaki korisnik u procesu vidi dokumente koji mu stižu na obradu i od njih kreira sledeće, prebacujući količine u njih. Naravno, teži deo posla je odlučiti šta uraditi - da li izdvojiti robu sa stanja ili je poručiti, od koga poručiti i slično. Tu sistem nudi pomoć u vidu formi za obradu koje će biti opisane u daljem tekstu. Drugi, kompleksan, problem je isti kao u prethodnom primeru, a to je analiza situacije. I ovde sistem daje odgovor na pitanja, s tim što su pitanja malo drugačija: korisnik koji je kreirao trebovanje dobiće odgovor na pitanje dokle je stigla realizacija - koliko je poručeno, koliko će biti izdato sa stanja, da li je nešto stiglo, kada će stići. Korisnik koji je na drugom kraju procesa - prijemu robe, dobiće odgovor kome je pristigla roba namenjena.

Cyclone aplikacija je dovoljno fleksibilno napravljena da je moguće napraviti varijacije svih pomenutih procesa: ako je potrebno da se neki korak izbaci (npr. radi se poručivanje direktno na osnovu trebovanja), moguće je sklopiti konfiguraciju aplikacije koja radi na traženi način. Takođe je moguće i proširivanje procesa. Sve zavisi od veličine firme i obima posla: manje firme teže jednostavnijim procesima kako bi smanjile birokratiju, dok veće nemaju izbora nego da uvedu više koraka u proces kako bi rasteretili zaposlene. Cyclone aplikacija podržava proširenja i u dubinu (više koraka u procesu) i u širinu (više zaduženih osoba u istom koraku procesa).

Slično se dešava i u proizvodnji: imamo jedan dokument (porudžbenicu klijenta) koji evidentira koje količine treba da budu proizvedene, i jedan (specifikaciju materijala - BoM) koji evidentira materijal koji treba nabaviti za artikle koji se proizvode. Količine materijala sada predstavljaju početak za već pomenuti proces nabavke a količine gotovih proizvoda za proces prodaje, i mogu direktno da se nadovežu na njih, s tim što se prilikom otpremanja uzima u obzir i proizvedena količina. Opet, sistem je taj koji analizira vezane dokumente, s tim što sada imamo tri odvojene grane: nabavku, proizvodnju i prodaju. Aplikacija vodi računa o tome da te tri grane budu izbalansirane, da se na vreme nabavi dovoljno materijala za proizvodnju i da se proizvedeno isporuči i naplati.

Karakteristike rešenja

Kao što je pomenuto, suština rešenja Cyclone aplikacije su veze između stavki dokumenata.

• U vezama se beleži količina koja je "prešla" iz jednog dokumenta u drugi, i precizno se evidentira iz koje stavke u koju je otišla. Na osnovu toga se zna koja količina je preostala i dobija se sledljivost između dokumenata tako da je moguće rekonstruisati tačno šta se dešavalo.
• Vrsta drugog dokumenta određuje šta se desilo sa datom količinom - isporučena je, reklamirana, rezervisana i slično - a moguće je imati više paralelnih vrsta realizacije istovremeno tako što se ista količina raspoređuje u različite vrste dokumenata (npr. otpremnicu i fakturu). Pritom aplikacija vodi računa o značenju dokumenata i ne dozvoljava da količine po određenim vrstama realizacije premaše tražene.
• Moguće je i vezivanje dokumenata više-na-više, što dodatno daje fleksibilnost sistemu jer može da postoji npr. više otpremnica za više porudžbenica, gde su veze ukrštene ali se i dalje tačno zna po kojoj stavki porudžbine je šta isporučeno.
• Moguće je vezivanje dokumenata u nizu, čime se dobija podrška za proizvoljno kompleksne procese, kao što je pomenuti primer nabavke sa trebovanjem, zahtevom za nabavku, porudžbenicom, prijemnicom i izdatnicom. Svaki dokument je jedan korak u procesu i za njega može biti zadužena posebna osoba ili osobe: ona u dokumentu dobija zadatu količinu (npr. nalogom za nabavku dobija zadatak da poruči robu), i kreiranjem sledećeg dokumenta vrši realizaciju (npr. kreira porudžbenicu za dobavljača kojeg izabere ili kreira odbijenicu ako roba ne može da se nabavi).
• U procesu mogu da postoje i "bočni" dokumenti koji evidentiraju različite tipove realizacije - kao što je pomenuta odbijenica ako je nešto nemoguće nabaviti, reklamacija ako nešto nije stiglo kako treba, knjižna odobrenja i slično.
• Ovakav sistem može da se podesi da ima manje ili više koraka i da u svakom koraku učestvuje jedan ili više korisnika.
• Moguće je korišćenje generičkih i konkretnih artikala ("master" i "zamenskih"), što znači da se u početnom koraku pojavljuje uopšteni artikl (npr. trebuje se filter za gorivo sa odgovarajućim karakteristikama) a tek kasnije se odlučuje koji će se konkretan artikl upotrebiti (tj. šta  će tačno i od koga biti poručeno).
• Poseban slučaj prethodnog je i korišćenje "nepoznatog" artikla za artikle koji ne postoje u sistemu. Tom prilikom se na licu mesta unose tražene karakteristike artikla, a pravi artikl će se kreirati kada bude nabavljen.

Jednostavni podaci - kompleksni alati

Kada se radi na ovaj način, korisnici nemaju problem da shvate kako sistem funkcioniše. Oni se bave samo jednim korakom u procesu i, što se aplikacije tiče, zadatak se maltene svodi na to da količine koje su im stigle u određenom tipu dokumenta proslede u neke druge - čime ih u stvari raspoređuju u različite pod-procese i predaju drugim korisnicima. Naravno, da bi ovo pravilno uradili, potrebno je da imaju adekvatne informacije, i ovde postoji opcija korišćenja specijalizovanih alata za obradu koje to omogućavaju. Ovi alati prikazuju listu ulaznih dokumenata i omogućavaju kreiranje sledećih dokumenata prostim unosom količina u odgovarajuće kolone. Na primer, u formi u kojoj se vide liste trebovanih artikala postoje kolone "poručiti", "odbiti" i "izdati sa stanja" u koje je dovoljno uneti željenu količinu kako bi se kreirala porudžbenica, odbijenica ili izdatnica. Pritom su korisniku prikazani i ostali podaci potrebni za brzo donošenje odluke, kao što je stanje artikla u magacinu, cene artikla kod različitih dobavljača (sa istorijatom promena u različitim vrstama dokumenata kao što su ponude, računi i slično), zamenski artikli koji se mogu koristiti umesto traženog i tako dalje. Ovakvi alati obično nisu neophodni kada se radi sa malim brojem dokumenata, a kada on poraste uglavnom se prave po zahtevu korisnika kako bi sadržali sve informacije koje su mu potrebne da donese ispravnu odluku. S obzirom da omogućavaju automatizovanu manipulaciju velikim brojem dokumenata, oni su tehnički izuzetno kompleksne ali se sklapaju od gotovih elemenata tako da trošak njihovog pravljenja nije velik i višestruko se isplati.

Izgled forme za obradu trebovanja (klik za detaljan opis)

Za manje zahtevne sisteme postoji jednostavnije rešenje: svaki dokument prilikom kreiranja može da "povuče" količine iz prethodnog. Prilikom unosa stavki na dokument, postoji specijalizovan alat koji ume da prikaže dokumente na kojima postoji preostala nerealizovana količina, i da omogući korisniku da izabere šta od toga želi da prebaci u svoj dokument - na primer, prilikom kreiranja prijemnice da izabere na koje stavke kojih porudžbenica se ona odnosi. Takođe, ako su dokumenti identični, moguće je kopiranje: ako je stigla kompletna poručena količina, porudžbenicu celu iskopiramo u prijemnicu.

To što korisnik vidi jednostavne podatke znači da se teži deo posla prebacuje sistemu, i ovde je sistem taj koji treba da analizira veze između dokumenata i da da ogovor na pitanje dokle se stiglo. Ovo je u suprotnosti sa uobičajenom filozofijom poslovnih aplikacija, gde se korisnik tera da unese podatke na određeni način i pripremi ih za aplikaciju. U Cyclone aplikaciji je napravljena vrlo složena logika koja ovo radi - štaviše, u teoriji grafova nije postojao (ili mi nismo uspeli da pronađemo) sličan problem pa je razvijen poseban algoritam. Komponenta koja analizira graf povezanih dokumenata ume da dođe do zaključka kako su se količine kretale kroz dokumente i da poveže krajnje tačke sa početnima tako da zna gde je koja količina završila. U navedenom primeru ovo znači da, kada stigne poručena roba, zna se tačno za koga je stigla. Takođe, autor dokumenta vidi šta se dešava: za trebovanje se vidi koja količina je poručena, koja je stigla a koja čeka na obradu. Za ulaznu porudžbinu (porudžbinu klijenta) se vidi koliko je isporučeno a koliko fakturisano, a ako postoji i proizvodnja onda i koliko je otišlo u proizvodnju. Pritom aplikacija poštuje prioritete dokumenata i radi po principima fer-pleja: ako je određena količina poručena za nekoga ko ima niži prioritet, on je taj koji će je i dobiti. Naravno, moguće je da korisnik koji ima pravo odlučivanja promeni mišljenje i pristiglu robu dodeli nekom drugom. Sistem će se prilagoditi i prerasporediti preostale količine kako bi nadalje sve funkcionisalo kako treba.