Carpio ERP

Integracija svih segmenata poslovanja

Carpio sustav je u potpunosti integriran. To znači da nisu samo integrirani moduli unutar računovodstvenog programa, nego su integrirani i građevinski, upravljački, CRM i podisistem serijske proizvodnje. Dakle, kad odgovorna osoba na gradilištu (u građevisnkom podsistemu) napiše zahtjev za nabavom, taj je isti zahtjev vidljiv i u CRM modulu u kojem se vodi nabava. Referent nabave će klikom miša ovjeriti zahtjev kao zaprimljen (što će se vidjeti na zahtjevu u građevinskom modulu, gdje je vidljivo kojeg datuma i s kojim brojem je zahtjev odobren). Referent nabave će zatim klikom miša izgenerirati narudžbu. Dogovorit će cijene sa dobavljačem i upisati ih u narudžbu (u dizajneru izvještaja će biti određeno hoće li se te cijene u stvarnosti i ispisivati) zajedno sa dogovorenim datumom isporuke, te klikom miša ovjeriti narudžbenicu, izlistati je i poslati dobavljaču. Ovu akciju će djelatnik na gradilištu vidjeti na zahtjevu, gdje će za svaku zahtjevanu količinu biti upisano koja je količina kojom narudžbom naručena (ukoliko je bilo više narudžbi) i kada je dogovoren rok isporuke. Kad dobavljač isporuči materijal, skladištar na gradilištu (ili odgovorna osoba) neće morati upisivati količine, već će klikom miša dohvatiti količine iz narudžbe (zajedno sa dogovorenim cijenama), te prekontrolirati je li što je naručeno ujedno i isporučeno i po potrebi ispraviti količine. Klikom miša proknjižit će primku na skladišne kartice. Pri tome će sustav automatski numerirati vrstu transakcije koja je određena za to gradilište. Proknjižena primka je odmah i vidljiva u podsistemu računovodstva u modulu materijalne evidencije. Računovođa će klikom miša prenijeti financijske podatke primke u dnevnik glavne knjige. Obzirom da je vrsta transakcije asocirana s shemom knjiženja, financijski podaci primke će u dnevnik glavne knjige stići predkontirani. Sistem će također prenijeti i oznaku gradilišta (nosioca troška) čime su stvoreni svi preduvjeti da se preneseni podatak pojavi u bilanci gradilišta. Prije samog rasknjižavanja podataka na kartice glavne knjige, knjigovođa će u dnevniku te podatke moći još pregledati, dokontirati, izmijeniti ili na drugi način intervenirati. Klikom miša knjigovođa će podatke proknjižiti na kartice i na taj način uvesti u bilancu tvrtke i bilancu nosioca troška.

Na sličan način su integrirani i ostali dijelovi različitih podsistema. Otpremnica naisana u sustavu za serijsku proizvodnju se klikom miša učitava u izlaznu fakturu, a koja se zatim klikom miša dohvaća u knjigu IRA u saldakontiju, čime je ujedno i na analitičkim karticama i u sustavu PDVa (po potrebi se ovdje može i intervenirati). Klikom miša se izlazni račun, pretkontiran prebacuje u dnevnik glavne knjige. Građevinski modul je integriran i sa plaćama radi kreiranja radnih lista.

No, najvažnije u čitavoj toj integraciji jest činjenica da sustav ne prisiljava korisnika da svi segmenti budu integrirani. Korisnik može sam odrediti nivo integracije pojedinih podsustav, te čak unutar jednom modula može raditi djelomičnu integraciju. Na primjer, može odlučiti da povlačenjem podataka integrira kupce, a da za dobavljače ne postoji integracija. Korisnik će sam odrediti tempo kojim će integrirati svoje poslovanje. Svi moduli će jednako dobro raditi ukoliko ne budu integrirani. Sustav zapravo uopće ne razlikuje upisani podatak ručno od podatka koji je dohvaćen (samo što je ovaj posljednji točniji). U svakom slučaju, odabere li integraciju, korisnik će na svakom koraku moći intervenirati u dohvaćeni podatak, ukoliko za to ima ovlasti.

Otvorenost sustava

Postavljanje uvjeta (Query by example - QBE) omogućuje korisniku da prikaže samo određenje podatke, koji zadovoljavaju uvjet koji je sam postavio, tj. da se fokusira samo na neke podatke. Sustav omogućuje da se takvi podaci spreme pod željenim naziviom i kasnije upotrijebe jednim klikom miša, čime se otvaraju neograničene mogućnosti trenutne analize podataka.

Korisnik sam može odrediti nivo integracije pojedinih segmenata. Svaki podsistem može raditi sam za sebe, s time, da ukoliko nije povezan sa drugim podsustavom, korisnik samo ne vidi podatke iz tog drugog podsustava (ili ne može koristiti pojedinu funkciju koja se na tim podacima bazira), bez drugih posljedica.

Korisnik može uvoditi nove vrste transakcija u sustav. Transakcije su označene sa 3 slova ili brojke i omogućuju da se napravi analiza samo takvih transakcija u odnosu na druge. Na primjer: ukoliko korisnik želi analizirati (izlistati / prikazati / izdvojiti) ulazne račune za materijal u odnosu na druge račune, odredit će za njih novu vrstu transakcije (na pr UFM: M = materijal) za razliku od redovnih računa koji se standardno označavaju sa UFA. Ako pri tome želi dodatno razlikovati ulazne račune za usluge, uvest će novu vrstu UFU. Broj transakcija nije ograničen. Sustav jedinstveno numerira pojedinu transakciju. Transakcije postoje i u ostalim modulima, ne samo računovodstvenom. U računovodstvenom podsistemu su transakcije dodatno vezane u shemu knjiženja pa omogućuju automatsko pretkontiranje knjiženja.

Korisnik može proširiti bazu dodatnim poljima na već postojeću strukturu koju ne može narušiti. Tako smo mi, na primjer, u našoj bazi partnera koja, usput, sadrži sva polja kao na pr Outlook (15 polja + 25 za osobu), dodali polje BrojRadnika, te ga upotrebljavamo da bismo izlistali sve tvrtke koje imaju broj zaposlenih 50 - 100 djelatnika. Jedan naš korisnik je uveo polje BrojUgovorenihPoslova, jer pojedinom partneru daje veće popuste a prema izračunatoj tablici. Na nivou troškovnika mogli bismo definirati dodatno polje UdaljenostAsfaltneBaze da bismo automatski odabrali i primjenili normativ prijevoza (na 5, 10 ili 20 Km) u analizi pojedine stavke.

Sustav, dakako, funkcionira i bez ovakvih dodataka jer dolazi već unaprijed parametriziran za normalnu funkcionalnost, te ga korisnik može početi upotrebljavati odmah, a elemente otvorenosti naknadno, prema vlastitom hodogramu.

Proizvoljni upiti na bazu - Ad hoc upiti - QBE

Postavljanje proizvoljnih upita na bazu je alat s kojim se može uštedjeti puno vremena. Na primjer: nakon 9 mjeseci projekta želite provjeriti koji su sve djelatnici radili vikendom. Stoga ćete postaviti upit sistemu da prikaže samo zapise iz dnevnika građenja koji se odnose na subote i nedjelje. Ili ćete htjeti prikazati samo one datume u kojima je temperatura bila iznad 8 stupnjeva. U računovodstvu, na primjer, želite prikazati samo one ulazne račune čije je dospijeće u slijedeća dva tjedna, a veće su od 15.000 kn i imaju oznaku UFU, tj, radi se u računima za usluge.. U podsustavu za serijsku proizvodnju ćete možda htjeti saznati koji su sve radnici radili na operaciji Ušivanje ovratnika, a imali su prebačaj norme, jer biste takvog djelatnika htjeli postaviti da radi upravo tekući, važan radni nalog.

U kreiranju ovakvih upita korisniku pomaže ugrađeni čarobnjak, a sustav omogućuje spremanje ovakvih upita za kasniju upotrebu putem samo jednog klika miša. Na taj način moguće je da sofisticirane upite koje su napravili informatički napredniji korisnici, upotrebljavaju jednostavno i svi drugi sudionici sustava.

Sustav animacija - lagano uvođenje

Iskustvo pokazuje da se 90% zastoja događa u prvih 6 mjeseci upotrebe novog informacijskog sustava, a da je pri tome 70% zastoja relativno jednostavno, u smislu da je korisnik zašao u neku opciju iz koje ne zna izaći, ili nezna kako izvršiti određenu radnju. Radi se, dakako, o zastojima čiji je uzrok nepoznavanje sustava, jer jednom kad se sustav uvede, tada rijetko postoji potreba za tehničkom pomoći. Osim sustava školovanja, priručnika, postupnika u elektronskom obliku i pomoći naše tehničke službe, Carpio je za potrebe korisnika napravio video animacije koje mu pomažu da neograničeno mnogo puta pogleda kako se pojedina funkcija obavlja. Svaka animacija traje 7 - 8 minuta, i u njoj sustav prikazuje slijed akcija potrebnih da se neka radnja obavi, komentira izglede ekrana, umjesto korisnika upravlja mišem i pokazuje mu gdje treba kliknuti, tj vodi ga na način da što lakše i brže nauči kako obaviti akciju. U biblioteci koju isporučujemo sa sustavom, trenutno postoji oko 30tak animacija, a taj se broj proširuje novima na temelju naših opažanja gdje bi animacija najviše pomogla. Za pokretanje animacije potrebno je da na vašem PC postoji instalirana Java (TM), što je praktički na svakom računalu. Pogledajte primjer animacije koji pojašnjava kako proširiti ekran za prikazivanje animacije, kliknite ovdje.

Evidencija u svim segmentima

Osim računovodstvenih podataka, koje evidentira svaki informacijski sustav, te tehnološko operativnih podataka (tipa knjige građenja, dnevnika rada, popratnog kartona, operacijskog lista, itd.), u svakodnevnici jednog gradilišta ili proizvodnog radnog naloga postoji niz drugih podataka koji su vitalni za ispravno, pravovremeno i uspješno završenje radova. To su dopisi, faksovi, elektronska pošta, sastanci, telefonski pozivi, zadaci, interni radni nalozi, vremenski rokovi i sl. koje sustav prije svega evidentira i jedinstveno numerira, čime je prije svega postoji trag da su nastali. Ukoliko na temelju ovakvih podataka treba učiniti neku akciju, tada je u sistemu zabilježeno i tko to treba učiniti i do kada. Ako rok gotovosti istekne, sustav tada cvrenom zastavom upozorava izvršioca na tu činjenicu, a po potrebi i nadređenog ili djelatnika u istom nivou odgovornosti. Svi takvi podaci, koji se u našem sustavu vode u podsustavu za CRM i Management, evidentiraju se tako da ih se može analizirati iz nekoliko različitih uglova. Prije svega evidentiraju se u odnosu partnera na kojeg se odnose (bez obzira da li je netko slao tom partneru elektronsku poštu, ili je parner poslao eletronsku poštu nekom našem djelatniku). Ovo omogućuje da se na jednom mjestu prikažu svi događaji koje se tiču odabranog partnera, tj da se na jednom mjestu vidi kompletna komunikacija i druga dokumentacija koja se odnosi na njega. S druge strane podaci se evidentiraju u odnosu na osobu koja ih je uvela u sustav, te postoji kronološka evidencija što je sve pojedinac radio u sistemu. S treće strane vodi se evidencija u odnosu na osobu koja bi po tom zapisu trebala reagirati, pa pojedinac uvijek može vidjeti što sve ima za napraviti. S četvrte strane, sustav evidentira ove događaje u odnosu na gradilište, ili projekt ili proizvodni radni nalog na koji se odnosi, što omogućuje da se na jednom mjestu vidi sva dokumentacija i komunikacija koju bilo tko u tvrtki radi a tiče se odabranog gradilišta ili proizvodnog radnog naloga. Na taj način voditelji gradilišta automatski imaju evidenciju o tome tko je što radio, trebao raditi ili primio poruku a tiče se gradilišta pod njegovom kontrolom. Obzirom da se i dijelovi računovodstvenih podataka (ulazni i izlazni računi i plaćanja) vide u građevinskom modulu, voditelj građenja ima potpunu dokumentaciju o događajima koji mogu utjecati na njegovo gradilište.

Sustav, dakle, evidentira ne samo računovodstvene i tehnološke podatke vezane uz pojedino gradilište, nego i sve ostale događaje koji se odnose na gradilište, što daje jednu sasvim novu dimenziju u upravljanju građenjem.

Definiranje vlastitih transakcija

Naš sustav razlikuje različite vrste transakcija, te svaku od njih jedinstveno numerira. Što su transakcije? Transakcije su različiti poslovni događaji, koje želimo na neki način analizirati. Na primjer, u poslovanju tvrtke postoje 2 vrste faktura: ulazne i izlazne. Ova dva poslovna događaja su vrlo različita, i svakako ih želimo analizirati odvojeno, u smislu da želimo znati koliki dio iznosa otpada na PDV, koje se sve fakture odnose na pojedino gradilište ili proizvodni radni nalog, i slično. Stoga ih i označavamo različitim oznakama (UFA ili URA i IFA ili IRA), a u našem sustavu ih zovemo transakcijama. Što, međutim, učiniti ako bismo htjeli odvojeno analizirati ulazne račune za materijal od ulaznih računa za usluge (podizvođači). Sustav nam dopušta da kreiramo nove vrste transakcija, pa tako bismo mogli ulazne račune za materijal označavati sa UFM, a ulazne račune podizvođača sa UFP. Sve ostale, koje nisu niti jedno niti drugo (na primjer telefonski računi uprave) mogli bismo označavati sa standardnim UFA. To bi nam omogućilo da analiziramo ukupne ulazne račune za materijal, bez obzira na koje se gradilište odnosile i bez obzira od kojeg dobavljača dolazile. Sustav bi jedinstveno numerirao UFM-1, UFM-2, ... itd, ali isto tako UFP-1, UFP-2.

Broj vrsta transakcija nije ograničen. Sustav dopušta da se i dokumenti iz drugih dijelova sustava označavaju različitim transakcijama (platni promet, blagajna, skladišno materijalno poslovanje), čak štoviše pojedine količine na primkama i izdatnicama mogu biti označene različitim vrstama transakcija, a u svrhu njihovog analiziranja. I dokumenti izvan računovodstva (na pr, zahtjevi za nabavom, narudžbenice, ponude itd) mogu na taj način biti označeni i analizirani. U računovodstvenim oznakama transakcija postoji dodantna pogodnost da se pojedina transakcija asocira sa određenom shemom knjiženja, pa se postiže mogućnost da sistem automatski pretkontira odabranu vrstu transakcije (i konto i protukonto). Prilikom otvaranja gradilišta, moguće je predeterminirati koje vrste transakcija se koriste na tom gradilištu, što prije svega, isključuje mogućnost da skladištar upiše pogrešnu vrstu dokumenta, a zatim da se horizont vidljivosti skladištara svede samo na onih nekoliko vrsta dokumenata s kojima on radi. Radeći svakodnevni posao, skladištar nije niti svjestan da je napravio velik dio posla za onoga tko u lancu dolazi iza njega.

Sustav, dakako, ne prisiljava korisnika da upotrebljava ovu mogućnost, nego se isporučuje sa svim zakonskim osnovnim dokumentim, te se u tom smislu ponaša kao i svaki drugi informacijski sustav. Da li će, i kada, biti uvedena dodatna vrsta transakcije, u svrhu daljnje analize, ovisi isključivo o samom korisniku.

Sofisticirani sustav zaštite

U ovakvom integriranom sustavu, gdje se puno događaja odvija istovremeno i puno sudionika radi svoj svakodnevni posao, od presudne je važnosti da pojedini sudionik vidi samo one dijelove sistema sa kojima radi. Time se kompleksan sustav svodi na jednostavan, jer pojedinac radi samo sa nekoliko ekrana u kojima obavlja svoj posao, a nije niti svjestan da postoje drugi. Ugrađeni sustav dozvole pristupa omogućuje da se na nivou svakog ekrana precizno odredi koje opcije pojedinac vidi, koje gumbe ili koja upisna polja vidi a koja ne. Time se postiže, da dva različita sudionika vide različite stvari kad uđu u isti ekran, tj. da na istom podatku rade, ali sa različitim ovlastima. U slijedećem primjeru je vidljiv ekran detalja troškovničke stavke kad u njega uđe korisnik sa ovlastima kalkulanta i kad uđe korisnik sa ovlastima upisivača teksta.

Upisivač teksta prije svega ne vidi sve mape (kao na pr kalkulativne elemente, analizu itd) a osim toga u mapi "Općenito" ne vidi jedinične cijene niti ukupni iznos, te tako nikako ne može pokvariti rad kalkulanta. Drugim riječima, bez straha možemo dozvoliti i jednom i drugom da rade na istom podatku, a da nikako ne dođe do sudara, jer upisivač naprosto nije svjestan da uopće postoj polja jedinične cijene ili mapa Analize. Isto je primjenjivo za opcije menua, kao i pojedine procedure.

Sustav ovo postiže zahvaljujući prijamnom imenu i lozinki. Administrator sistema (a administrator je jedan od sudionika), otvara novog sudionika tako što mu dodijeli pristupno ime i ovlasti. Sustav mu pridjeli jedinstveni broj (koji nije moguće mijenjati) i koji se koristi kao potpisna šifra za sudionika. Novi korisnik sam sebi određuje pristupnu lozinku, te je niti administrator sistema, niti bilo tko iz naše tvrtke može pročitati jer se radi o principu javnog i privatnog ključa. Posebnim administratorskim alatom, administrator pridijeljuje prava sudionika na pojedinom ekranu, kreira grupe korisnika sa istim pravima, a po potrebi pojedincima može pridijeliti i ovlasti izvan grupe.

Dodatna polja - proširivanje baze

U svakom informacijskom sustavu dođe trenutak kad je potrebno proširiti bazu sa nekakvim dodatnim podatkom, koji nije bio interesantan u momentu izrade programske podrške, ili je potrebno proširiti funkcionalnost informacijskog sustava sa dodatnim elementima, ili je naprosto potrebno evidentirati neke dodatne podatke. Našoj je tvrtki interesantan podatak o broju zaposlenih, u smislu da smo imali potrebe izdvojiti tvrtke sa više od 50 i manje od 400 uposlenih, jer smo im željeli poslati posebnu ponudu. Taj podatak nije interesantan svakome, pa nije bilo potrebe s njime opterećivati bazu partnera. Svi ipak trebamo neke osnovne podatke o partneru, kao na pr. naziv tvrtke, adresu, matični broj itd. Takvih, "fiksno ugrađenih" podataka u bazi partnera ima 15 (ima dodatnih 25 za pojedinca iz tvrtke, čime su pokriveni svi elementi koji se nalaze, na pr u Outlooku(TM)). Na takvu fiksnu strukturu mi smo dodali polje BrojUposlenih koji smo onda upotrijebili za izdvajanje željene grupe tvrtki. Neka druga tvrtka bi imala drukčije potrebe za dodatnim podacima koje bi željela evidentirati uz pojedinog partnera. No ono što je važno, jest činjenica, da smo na "noseću", fiksnu strukturu dodali jedno ili više dodatnih polja, a čime nikako nismo mogli narušiti osnovnu funkcionalnost baze partnera.

No, ono što je još važnije jest činjenica da pojedino polje ima svoj horizont vidljivosti. Uzmimo slijedeći primjer:

Baza partnera je naslonjena na bazu gradova (preko poštanskog broja, dakako), a na sličan način su gradovi smješteni u regije (županije?). Kad korisnik piše neku komercijalnu ponudu, tada je on naslovi na određenog partnera. Na temelju toga, sustav odmah zna u kojem je gradu taj partner, a na temelju toga i u koju regiju ta ponuda ide. Ako je logika nuđenja takva da se za različite regije odobrava različiti rabat, tada je evidentno baza regija ta koju bi trebalo proširiti poljem koje se zove Rabat. Time bismo dobili mogućnost da za Zagrebačku regiju upišemo jedan postotak (na pr 10%), a za Dalmatinsku drugi (na pr. 15%). Iznos rabata bismo izračunavali za svaku ponudu, pa je evidentno da bismo otvorili dodatno polje IznosRabata uz bazu ponuda (u ovom konkretnom slučaju iznos i postotak rabata je već ugrađen u bazu ponuda, a ovdje ovakav slučaj uzimamo samo radi lakšeg objašnjenja).

Dodatno polje Rabat (definirano na nivou regije) ima svoj horizont vidljivosti, i taj se podatak vidi na nivou ponude. Kada ponudu naslovimo na tvrku iz Zagreba, u ovom polju će biti broj 10, a kada ponudu naslovimo na tvrtku iz Splita, u tom polju bit će broj 15. Kako ovo možemo upotrijebiti?

Svako dodatno polje može biti tekst (do 250 znakova), broj, padajuća lista ili formula, slično kao u Excelu (TM), s time da u formulama pojedina polja ne nazivamo kriptičnim imenima R4C5, nego u našem slučaju Rabat ili IznosRabata. U formulama možemo upotrijebiti bilo koje polje iz baze, te bilo koje dodatno polje, a osim običnih aritmetičkih funkcija, možemo upotrijebiti 50tak drugih (logičke funkcije, trigonometrijske, logaritmiranje, potenciranje, funkcije ispitivanje tipa AKO_JE x TADA...)

Ako bismo gornji primjer htjeli začiniti, mogli bismo na nivou tvrtke dodati polje u kojem bismo upisivali broj poslova koje je do sada partner ostvario s našom tvrtkom, a sa svrhom da odobrimo dodatni popust tvrtkama koje nam nose više poslova. Mogućnosti su praktički neograničene.

Dodatna polja je moguće definirati praktički u svim segmentima sustava. Tako na pr. u građevinskom modulu se mogu definiarti dodatna polja na nivou materijala, radnih sati, strojeva i normativa. No dodatna polja (formule) se mogu definirati i na nivou analize troškovničke stavke, u kojoj su vidljiva dodatna polja definirana na nivou gore spomenutih resursa, pa mogu biti upotrebljena za različite proračune. Štoviše, na nivou analize troškovničke stavke vidljiva su dodatna polja definirana na nivou troškovničke stavke, grupe radova ili troškovnika, a koja se također mogu upotrijebiti u izračunu analize. Pri tome treba napomenuti da sustav u svojoj baznoj funkcionalnosti ima ugrađeno proračun analize na temelju količina i jediničnih cijena odabranih resursa ili složenih podanaliza.

Za definiranje dodatnih polja nije potrebno informatičko znanje. Potrebno je samo odabrati u koji segment želimo dodati polje, te mu dati naziv i odrediti vrstu, te ga odmah možemo i upotrebljavati.

Sustav carpio ima svoju punu funkcionalnost bez da se definira i jedno dodatno polje. Definiranjem dodatnih polja nikako nije moguće narušiti baznu funkcionalnost sustava. Definiranjem dodatnih polja korisnik može ugraditi poznavanje svoje tehnologije u ponašanje sustava, a bez posebnog informatičkog znanja.