Ovo je kao da si pitao "koje su konkretne razlike između Mercedesa i BMW-a".
Možda će da se nađe neko pa da nabraja ...

Postaviću onda konkretnija pitanja.

Da li Controlling modul u okviru SAP-a može u potpunosti da zameni kvalitetno BI rešenje?

Generalno uzevši - može. I jedno i drugo se svodi na pripremu i prezentaciju podataka koji su potrebni menadžmentu da bi donosio kvaitetne poslovne odluke.

Ukoliko kompanija želi da izvrši prelazak sa Navision-a na SAP, zbog različite strukture tabela migracija podataka je dosta otežana?

Prilično je komplikovan svaki prelaz sa jednog na drugi sistem.

U SAPu postoji poseban mehanizam LSMW - Legacy System Migration Workbench

Nakon kastomizacije SAP sistema, posao se sastoji od prenosa sledećih grupa podataka:

1. Meta podataci. Ukoliko postoji potreba. Često se može uneti ručno. Ovaj skup podataka nije masovan
2. Matičnih podaci (Master data) Prilično pipav posao, od krucijalne važnosti za ceo sistem.
3. Stanja (finansijsko stanje na kontima GK, stanje robe / materijala u magacinima i slično)
4. Otvorene stavke - kupaca, dobavljača

Meni je ovo, tj. Data Migration bila specijalnost, u vreme kad sam se bavio SAP sistemina (2005 - 2009)

Hvala ti puno na odgovorima.

Da li postoje suštinske razlike između Microsoft Dynamics Sure Step metodologije i SAP-ove ASAP metodologije?

možda bolje rečeno između Toyote i kamiona :).

Ovde ne znam da ti odgovorim tačno, jer ne poznajem detaljno Sure Step. Doduše, ni ASAP nešto preterano. Potraži na netu kako idu step by step.

Ali, mogu ti reći kako se radi u realnosti. I za SAP i za MD.

- Intervju, tj. razgovor sa korisnicima. Po meni, prvi i najvažniji korak. Intervju mora da radi neko ko detaljno poznaje kako poslovne procese, tako i informacioni sistem. Neko sa mnooooogo iskustva.
- Izrada projekta. Zatim prezentacija projekta korisnicima. Nakon eventualnih korekcija, ide potpisivanje-verifikacija projekta.
- Kastomizacija SAP sistema, po projektu.
- Verifikacija urađenog kroz Integracioni test, koji podrazumeva unos podataka, knjiženje, i informisanje - preglede. Dakle, integracioni test treaba da pokrije sve poslovne procese, od početka do kraja. Korisnik potpisuje da je kroz integracioni test pokazano da je sve urađeno shodno projektu.
- Data migration, tj. unos podataka, i Go-live.
- Početna podrška u realnoj eksploataciji.

Ne dao ti Bog da se neki od "faktora" u firmi seti da mu nešto fali posle potpisanog Integracionog testa. Onda to košta ko Svetog Petra Kajgana.

Ko vrši integracioni test, implementacioni partner ili sama kompanija? Taj test podrazumeva manuelno proveravanje svih funkcionalnosti u SAP-u ili se manuelno proveravaju samo najbitnije funkcionalnosti a ostatak se automatizuje kroz odgovarajući softver?

Test rade zajedno implementacioni partner, koji pokazuje kako sve radi, i kompanija naručilac. Poneku obradu dokumenta mogu da urade i zaposleni u kompaniji, ali realno, da bi to uradili, prvo treba neka obuka.

Test podrazumeva proveru SVIH funkcionalnosti. Ali pre svega se misli na funkcionalnost kastomizacije. Dakle, SVAKI poslovni proces koji je obuhvaćen implenetacijom treba da se pokaže i dokaže. Od unosa počenih dokumenata, preko knjiženja, do izveštavanja.

Šta podrazumeva formiranje određenog competence centra unutar firme, koji će nakon završene implementacije biti zadužen za održavanje sistema i za podršku krajnjim korisnicima sistema?

Da li to podrazumeva osobu koje će vršiti sva neophodna podešavanja i izmene parametara sistema, dodeljivanje privilegija korisnicima, komunikaciju sa SAP-om u slučaju neophodnih dorada sistema, ili čitav tim?

Poznato mi je kakav je pristup kod Navision-a, koji ne zahteva ključne korisnike već je često u pitanju one man show. U NAV-u je moguće vršiti veliki broj korekcija i podešavanja sistema, ali značajnije izmene sistema se ne mogu izvršiti lokalno već se za takve izmene mora angažovati implementacioni partner.

Vidi, zavisi koliki je sistem, pa prema tome, toliki treba da bude i competence centar. Iskreno govoreći ranije nisam čuo za "ovaj reč", ali kapiram.

U velikoj naftnoj kompaniji u kojoj sam radio, bilo je 100+ korisnika. FI, CO, MM, SD, i još koješta. Mnogo hardvera, kako radnih stanica tako i servera.
Bilo je tu ljudi za održavanje mreže, radnih stanica, servera, storidža, Oracle baze, admnistracija UNIX-a, pa onda pojedinačnih konsultanata / ključnih korisnika za svaki modul posebno. Pa onda i administracija SAP sistema u celini. I još koješta: backup, ostali hardver u firmi, ostali softver u firmi, WIN administracija radnih stanica ...

Dobro, jedna osoba može da obavlja par funkcija, ali ne možeš očekivati da jedna osoba radi sve. Jer, onaj ko se razume u UNIX i storidže, "malo manje" mari za otrpemnice, prijemnice i knjiženje računa. I obrnuto. U toj, naftnoj kompaniji bilo je nas desetak+, dakle, za sve opisane, i još dosta neopisanih funkcija.

E sada, ako je ukupno korisnika deset, onda naravno, competence centar nikako ne može da ima deset ljudi.

Hvala na odgovoru.

Jasno mi je da su posebne osobe zadužene za hardver, održavanje mreža, servera i storidža. Nejasan mi je pomalo ovaj deo koji se tiče konsultanata / ključnih korisnika po modulima. Videh negde da postoje termini super user, power user i key user, ali ima dosta različitih definicija.

Ključni korisnici za pojedinačne module su zapravo ljudi koji najviše rade u pojedinačnim modulima i koji najbolje poznaju poslovni proces?

Otprilike tako.
Svaka firma (korisnik SAP-a) je "živ organizam" koja se menja, raste, dopunjava. Poslovni procesi se menjaju, dodaju, nestaju. Zakoni koji regulišu poslovne procese se takođe menjaju. Uvek je potrebno da se nešto u infromacionom sistemu "čačne", doradi, promeni, doda ...
Neko to mora.

Ako je frima mala, onda se nađe neka malo pametnija žena iz knjigovodstva kojoj se objasne osnovne stvari oko administracije, i onda ona može da administrira / kastomizuje SAP setinge, naravno do neke granice. Onda je ona "key user" ili "power user" ili šta si ono već naveo.

Ako je firma malo veća / velika, onda, kao što smo već apsolvirali, bude tu neko iz "AOP-a" ili "ERC-a" ili Competence centra. Pošto je to njemu / njoj glavni posao onda najčešće ume i zna znatno više nego onaj gorepomenuti key user.

Poznavanje poslovnog procesa se podrazumeva, ali je neophodno i određeno znanje SAP administracije / kastomizacije i slično.

Ne baš skroz. Na primer, za proces unošenja prodajnog dokumenta najviše radi neki operater, referent ili kako god. Međutim, skoro sigurno neće biti on ključni korisnik, nego neko ko i zna proces i ima mogućnost da potvrdi da nešto radi kako treba i da može da anticipira potrebne izmene u trenutnom obavljanju posla.

Ovo je sa stanovišta implementacija NAV-a, ali moguće da različiti partneri različito rade.

Koji od osnovnih modula (FI, MM, LE, CO, SD, PP) je najkompleksniji za implementaciju?

Da li je to modul planiranje proizvodnje?

Ne postoji najkompleksniji modul. Sve zavisi od kompleksnosti vaših poslovnih procesa i znanja konsultanta koji implementira. A i kompleksni poslovni procesi su retko samo u jednom modulu.

Da li je tim proizvodnim modulom pokriveno apsolutno sve sto se tice samog procesa proizvodnje, od planiranja materijajlnih resursa, preko definisanja rasporeda proizvodnje do analize uskih grla?

Apsolutno sve niko ne može da pokrije. MRP je "modul" za planiranje i osnovni je deo ERP paketa a integrisan je sa većinom modula, za kompleksnije modele planiranja i analize sap ima poseban APO modul/sistem on nije sastavni deo ERP paketa.

Koliko je komplikovano vrsiti odredjene "fine" izmene u SAP-u u fazi eksploatacije? Da li je za primenu takvih izmena potrebno znanje ABAP programskog jezika?

<sub>[Ovu poruku je menjao Inicijator dana 07.02.2016. u 20:23 GMT+1]

[Ovu poruku je menjao Inicijator dana 07.02.2016. u 20:23 GMT+1]</sub>

Paa.. zavisi koliko je fina izmena. :) Baš ti dajem konkretne odgovore.
SAP je dosta parametrizovan i veliki broj izmena moguće je uraditi samo podešavanjem standardnih parametara. A pošto je i potpuno otvoren sve što nije moguće uraditi standardnim podešavanjem, moguće je doraditi, i tada je potrebno poznavanje ABAP.

Našao sam ovaj tekst na forumu: "Proces implementacije nikada ne prestaje – Mnoge firme proces implementacije ERP sistema tretiraju kao i svaki drugi projekat. Pretpostavljaju da kada jednom proces instalacije i integracije bude završen, ljudi iz internog tima se mogu vratiti svojim starim zaduženjima. Međutim, stvarnost je drugačija. Tim koji je radio na implementaciji je isuviše vredan. Oni bolje poznaju procese i procedure u proizvodnji od ljudi koji rade u proizvodnom pogonu i bolje poznaju prodajne procese od ljudi iz prodajnog odeljenja. Samo kreiranje raznih izveštaja u ERP sistemu će im dati dovoljno posla u jednom dužem periodu… Dakle, čim postavite svoje najbolje ljude u tim za implementaciju ERP sistema, odmah planirajte angažovanje njihovih zamena na starim radnim mestima, obzirom da će svi oni činiti vaš tim za održavanje ERP sistema kada se proces integracije završi."

Da li ovo važi za velike poslovne sisteme koji imaju više od 300 sap korisnika? Malo mi je čudno da je potreban toliki tim ljudi za svakodnevno održavanje sap-a, i da zaista ima potrebe da se za svaki modul odredi po jedna odgovorna osoba.

Da. Po završetku implementacije, ne bi trebalo da se stane. Poslovni procesi se menjaju i potrebno je te promene ispratiti u ERP a za to je potrebno imati osobe koji znaju end to end te procese i kako su oni mapirani u vašem SAP.
Sa druge strane korisnici će sigurno imati problema u svakodnevnom radu pa je potrebno onda kontakt osoba koja će sve te probleme rešavati. Problemi od logovanja, preko toga da se neki dokumenti neće proknjižiti, do toga da su uradili pogrešno i da sada sve treba dovesti na tačno stanje.

Po meni rešavanje tekućih problema je manje više šablon za koji mogu da se obuče ljudi iz IT ili osnuje posebno odeljenje za to. Dok praćenje procesa može da prati neko sa starog radnog mesta koji i sam učestvuje u njima, samo sa novim zaduženjima. Ali ukoliko takva osoba treba i da menja sistem onda ne znam koliko je to moguće uraditi a da ona ostane na tom starom radnom mestu.

Tako da podela ko će šta da radi i koliko ljudi svakako zavisi od obima posla, i samih ljudi. Kod nas je to obično po jedan čovek po modulu koji radi sve i održavanje i unapređenje.
Uvek možete da razmislite da deo posla prepustite nekoj konsultantskoj kući :)

Kakva je trenutno situacija sa Sap-om u regionu? Da li je tržište već dosta zasićeno konsultantima i firmama koji se bave implementacijom Sap-a?

Šta tačno podrazumevaš pod situacijom sa SAP-om?
Iako konsultanata ima mnogo više nego pre recimo 5 godina, mislim da tržište nije prezasićeno i da još uvek nemamo dovoljno konsultanata, bar ne kvalitetnih. I konsultantskih firmi ima sve više i više, ali ni to ne vidim kao prezasićenje.
Po meni veći problem je to što naše firme slabo vrednuju IT i njegov značaj u njihovom poslovanju. Budžeti za IT su jako mali, što onda utiče da se više gleda cena nego kvalitet. A sve se to preliva i na SAP.

Mislio sam da je sada u odnosu na raniji period u regionu prisutno mnogo vise firmi i konsultanata koji se bave implementacijom sap-a (ne ulazeci u kvalitet njihovog rada), ali da je u regionu preostalo malo kompanija koje su u mogucnosti da sebi priuste implementaciju sap-a.

Ukoliko se kompanija odluči za implementaciju sap-a, koliki su izdaci neophodni za novu hardversku infrastrukturu koju sap zahteva?

Nema ovde generalnog odgovora. Ne zahteva SAP, sam po sebi, mnogo. Sve zavisi koliko će korisnika biti, kolika baza i slično.

Da li HANA dolazi kao sastavni deo sap implementacije, ili je na korisnicima da odluče da li žele da je implementiraju?

HANA je neka vrsta hibridnog rešenja? Sistem za upravljanje relacionim bazama podataka i za analizu podataka u realnom vremenu?

Zavisi šta su vam prodali, u standardnom ERP paketu koliko ja znam ne dolazi, ali standard se menja i nisam siguran da li je tako i sada.
HANA je nešto što je budućnost SAP i SAP trenutno ima jako veliku kampanju u kome gura HANA na sve moguće načine. Prošla godine mu je upravo ovaj segment (cloud) omogućio da ostvare najveći profit u istoriji kompanije.

HANA je cela platforma na koju SAP polako prelazi. To je prvenstveno in-memory baza, vrlo visokih performansi, optimizovana za big data, oko koje je SAP napravio/pravi celu platformu i polako prebacuje sva svoja rešenja na nju. BW, CRM, ERP, .. je već prebacio, verovatno još što šta.

I da HANA nije relaciona baza, a u zavisnosti od implementacije omogućava analitičke i transakcione obrade nad istom bazom u isto vreme.

Da li ima kompanija u Srbiji koje vec koriste Hanu?

Mislim da su Telekomu prodali ali ne znam da li su i implementirali. Za druge ne znam, moguće je da NIS, Stada pokušavaju nešto in house.

Ali po meni veliki je rizik sada implementirati HANA zato što globalno ima jako malo iskusnih konsultanata.

Da li je standardna prica da konsultanti prilikom pregovora o implementaciji zastupaju stav da je najbolje da se nikakve dorade ne rade u okviru standardnih sap modula, i da je bolji pristup da kompanija prilagodi svoje poslovanje sap-ovom nacinu rada?

To je uobičajeni stav za bilo koji "veliki/kompleksan" softver, a kada dobiješ ponudu na 10+ čovek dana za prilagođavanje najmanje sitnice biće ti jasno i zašto.

Standard je jako širok pojma koji se dosta zloupotrebljava.
Implementaciju treba uzeti kao dobar trenutak kada firma treba da ozbiljno razmisli o svojim poslovnim procesima. Inisistiranje da se ERP prilagodi vašim procesima nekad ima smisla, nekad nema, ali uvek morate da budete svesni rizika koji takav stav može imati na projekat (bužet, rokovi, uspeh/neuspeh).

Prelazak na novi ERP se uvek vrsi 1.1. tekuce godine?

Tekuće sigurno ne :)

Ne mora 01.01. ali klijenti uglavnom žele da u novu godinu uđu sa novim softverom. Skroz je legitimno da to bude 01.04 ili 23.08. Razlika je samo u malo većoj petljanciji za pripremu izveštaja za državu.

Da li na osnovu vaseg i iskustva vasih poznanika mozete da kazete da se dugorocno ulaganje napora i vremena zarad sticanja sveobuhvatnog znanja o erp sistemima (bilo da je u pitanju sap ili bilo koji drugi) na kraju isplati? U prilici sam da vidim kako to funkcionise, i kada pogledam koliko je energije potrebno uloziti i kako danasnje kompanije funkcionisu, pitam se da li je mozda pametnije energiju i vreme posvetiti necem drugom. Kod nas (u Srbiji) je to i dalje rudarski posao

Isplati se

... bilo čemu se isplati. Dugoročno uloži napor i vreme da izučiš stolarski ili bilo koji drugi zanat - isplatiće se.

Moj neki utisak je da se može doći do jako dobre zarade, ali da to sa druge strane podrazumeva da prihvataš mnogo toga.

Pošto je poslovanje dinamično, a kompanijama i te kako nedostaje standardizacija poslovnih procesa, izaći na kraj sa svim peripetijama koje se jave u toku dana zahteva ogromno trošenje živaca.

Mala bara puno krokodila.

Želim ti puno sreće u ostvarivanju te jako dobre zarade.

Sta sve od izmena u sapu mogu da rade same kompanije nakon implementacije, bez angazovanja zvanicnih sap partnera?

_{[Ovu poruku je menjao Inicijator dana 31.05.2016. u 16:17 GMT+1]}

Ima SAP Business One ali mislim da on nije lokalizovan za Srbiju. Sa vremena na vreme pričao sam sa ljudima koji su mi govorili kako su ga implemetirali u srpskim firmama, ali ja to nikad nisam video. U svakom slučaju to je poseban stack i ima malo toga zajedničkog sa glavnom ECC komponentom, namenjen je malim i srednjim firmama.

Drugi vid na koji SAP pokušava da smanji cenu posedovanja, istog je preko paketa: All in One, SAP by Design.. sve se svodi da u njima prodaje vec iskonfigurisane procese pa je dovoljno samo promeniti "par" organizacionih podataka i može vrlo brzo da se krene sa produktivnim radom. On ovu priču prodaje takođe kao namenjenu malim i srednjim preduzećima koje nemaju kompleksne procese.

Sad vidim da si promenio pitanje.. pa da odgovorim i na njega.

Ukoliko imaju dovoljno znanja mogu sve da menjaju.
Sistem je potpuno otvoren i nema ograničenja ko šta može da menja.

Ne postoje ogranicenja u zavisnosti od tipa sap licence?

Kao sto je kod Navision-a (tipa da mozes da vrsis modifikacije samo na tabelama u odredjenom opsegu, a za ostale izmene moras slati zahtev kompaniji koja je partner MS-a).

Nema nikakvih ograničenja.
Kad pričamo o izmenama u SAP ima 2 načina promenom podešavanja i promena koda. Kako to radi implementator tokom procesa implementacije tako to isto može nakon toga da radi i sam klijent. Još od implementatora bi trebalo da dobije detaljno dokumentovano šta je sve implementator promenio.

Sav kod je vidiljiv, i dostupan. Jedino "ograničenje" je ukoliko se menja SAPov standardni kod, tada se ta izmena mora prijaviti na njihovom portalu. Ali ta prijava je samo na nivou koji objekat je menjan kako bi to bilo izbačeno iz održavanja. Tako da kad bi se klijent posle toga žalio kako mu nešto vezano za to ne radi, oni samo kažu to ste vi menjali i ne spada više u okvir garancije.

nije baš tako u Navisionu. Prvo imaš nešto što možeš da radiš sa uobičajenom korisničkom licencom (na primer da dodaješ polja na tabelama ili da praviš reporte), a za neke druge stvari ti treba developer granula (da pišeš kod u tabelama ili da praviš codeunite npr).
što se tiče objekata, postoji opseg standardnih objekata, a objekti van standardnih se kupuju od MS-a (i tu imaju razlike, da li su objekti na rangu koji je deo nečijeg add-ona, pa se faktički kupuje ceo add-on koji ima neku jasnu i prepoznatljivu funkciju; ili se menjaju objekti na rangu kom svako ima pristup i može da ih menja i razlikuju se od baze do baze)


sad kad pročitam svoj odgovor, to i nije toliko različito od onoga što si napisao :)

Znam da kod najnovije verzije Navision-a postoji tip icenciranja koji omogucuje da se konstantno skidaju zakrpe koje MS objavljuje (kao sto funckionise windows update).

Po meni, ako prica krene da se razvija dalje u tom smeru onda previse samostalnog petljanja sa kodom moze da ometa to redovno azuriranje.

_{[Ovu poruku je menjao Inicijator dana 03.06.2016. u 13:23 GMT+1]}

To nije odlika nove verzije, uvek su mogli da se skidaju buildovi i hotfixovi sa partner/customersource. Problem je , naravno, lokalizacija, customizacija i ostalo što onemogućava da se build samo uveze. Ono što je novo je da se sada apdejti izbacuju na mesečnom nivou, verzije izlaze mnogo češće i generalno se sve ubrzalo.
Od kako je ovaj "naš" na čelu razvoja NAV-a koji je došao iz drugog sveta, priča je da se sve više okreću cloudu i ide se ina to da se ne dira standardni kod, nego da se kroz neke ekstenzije koji bi se u idealnom svetu za X godina skidale sa Dynamics APP Store uvode potrebne modifikacije i dorade. Ideja je da nema ni malo izmena standaradnog koda (na produkciji), nego da se odradi development kod provajdera, zapakuje se u ekstenziju i instalira se kod klijenta. I kada ne treba više- skine se ekstenzija i ćao đaci.
Ekstenzije su u opticaciju tek od trenutne verzije (2016) i trenutno smo daleko od toga, ali g. Perišić se ne šali i brzo menja NAV svet.

Meni je logicnije da se proces modifikacije i dorade u potpunosti prepusti provajderu, kao nekome ko ima pristup bazi znanja. Nekako mi deluje kao sizifov posao da firme koje koriste Navision imaju svoje ljude koji ce raditi na doradama. Ukoliko sistem nije ustrojen na nacin da se modifikacije mogu vrsiti kroz promene parametara i fina podesavanja, vec je neophodno izvoditi raznorazne peripetije, onda je na provajderu da pronadje najbolji nacin da taj deo preuzme i optimizuje.

Jel sme neko da napise kolika je cena odzavanja tih sistema, obicno izrazeno kao inzenjer-dan? I kolika je cena modula i licenci?
Za SAP sam cuo, ne znam za NAV

^ Odgovorio sam ti preko PP.

Na koji nacin eksterni revizori analiziraju podatke i zapise ERP sistema kako bi otkrili eventualne zloupotrebe?

Sta sve proveravaju?

Cena održavanja je stvar dogovora implementatora i korisnika. Ono što MS zahteva je da se svake godine plaća 16% vrednosti licence.
NAV se ranije prodavao po modulima, sada postoje generalno dve vrste licenci Starter Pack i Extended Pack. Ovo su neke cene koje sam našao na netu (za tačan cenovnik treba customer login na partnersource portalu, pa kontam da taj podatak nije baš javan. ) :

Starter Pack: $5,000 for THREE concurrent users (required)*
Additional Full Users: $3,000 each
Additional Limited Users: $600 each (useri koji su ograničeni brojem tabela u koje smeju da upisuju u jednoj transakciji)

Cena zavisi i od zemlje do zemlje, tako da ovo možda nije cena koja važi i u Srbiji.

Dodatno se plaća ako se koristi neki nestandardni modul, tzv add-on (na primer, payroll, retail, ... ).
Bitno je i znati da NAV broji concurent usere.

Cene u Srbiji su niže od ovih, ali kao što High Spirit reče, to nije baš javna informacija. Pozvati nekog od partnera i tražiti ponudu.

Kod sap-a se ne gleda broj 'concurrent' korisnika aplikacije vec je jedan zaposleni jedna licenca.

Da li u sap-u postoje opcije da se kupe ogranicene korisnicke licence (recimo licenca koja omogucava korisniku samo da vrsi uvid u podatke ERP-a, bez mogucnosti unosa i izmene podataka) ili su sve licence full user-i?

Postoje više različitih tipova ograničenih licenci samo količina koju korisnik može da kupi zavisi od broja full licenci.

Detalje ne znam, niti želim da ih znam, pošto SAP, a i svi ostali u IT, uslove za licence pišu nedefinisano kako bi imali mogućnost da svakom razrežu kako im se prohte. Uvek daju neki cenovnik sličan ovome što je naveden ovde koji je dranje, koji se onda pravilinim tumačenjem uslova licenciranja može znatno smanjiti.

... i onda slično kao na prezentacijama gde se prodaju time-sharing apartmani, posteljina i šerpe, implementator ponudi "spacijalni popust", jer ga je "upravo pozvao generalni direktor", i "sada, samo sada, ako odmah potpišete ugovor dobićete punih 15% popusta, i još 5% od njega lično, jer on ima pravo da dobrim kupcima obodri specijalni popust", što sve zajedno čini "neverovatnih 20% popusta, šte je, moraćete priznati, prilika koja se dobija samo jednom"

I tako te oderu do gole kože, uz ugovor da te deru i mnogo narednih godina, a ti misliš da si prošao neznamnija koliko povoljno.

Za NAV nema nekih specijalnih mogućnosti tumačenja (cigo hvali svoga konja :D). Dosta je jasno kada se može koristiti full, kada limited (čak ima i spisak tabela u koje se može insertovati, ako implementator ponudi limited gde ne može da ide limited - korisniku će se javiti greška), a kada device licenca.
Meni se čini da je veći problem što se nekad cena licence predstavlja nefer niskom (tako što se uključe limited umesto full i slično) i tako dobija niža cena i konkurentnija ponuda, nego da se napumpava.

Ja ne razumem ni Office licenciranje, a mogu tek da zamislim kako je za njihov ERP. Skoro nam je u firmu došao neki lik koji je kroz razne pakete i ko zna šta ne još uspe da nam značajno smanji koliko smo plaćali MS za office.
Ali u svakom slučaju možda je do mene, kad god dođe tema licenciranja meni postane muka i nestanem.

I u SAPu sve te kontrole postoje. Ima poseban program, isti svima, koji se na kraju godine pokreće i obračunava licence i održavanje, ali nekako svako plaća drugačije.

Ja sam jednom pokušavao da skontam za SQL i bio sam vrlo zadovoljan što to ne moram stvarno da znam. Mada, uskoro nam dolazi i sve to uvećano za faktor Azure

Da li po vama postoje neki "preduslovi" u pogledu strukture kompanije da bi nakon implementacije SAP-a kompanija uspela da ostvari njegovu punu vrednost?

Ima li slucajeva da je SAP implementiran u kompanijama sa manjim brojem zaposlenih (60-ak korisnika ERP sistema)? I da li je iskustvo pokazalo da kompanije srednje velicine mogu da se nose sa kompleksnoscu SAP-a?

_{[Ovu poruku je menjao Inicijator dana 30.06.2016. u 13:35 GMT+1]}

Nema preduslova. Jedini preduslov su dobri konsultanti i dobar menadžment koji je spreman da aktivno učestvuje u implementaciji. Dobri konsultantni će prilagoditi sap firmi, a dobar menadžment firmu sap-u.
Uzged, pitanje, šta je to puna vrednost SAP?

Veličina kompanije nema veze sa izborom erp-a, već samo šta neko želi da radi sa njim. A valjda i sama ta "kompleksnost" sap-a ili bilo kog drugog erp-a bi trebalo da im omogući da mogu da radi u svim uslovima.
Inače znam da je firma za 3 korisnika implementirala sap (Austrija).

Pod punom vrednoscu smatram da nakon implementacije SAP-a kompanija u svakodnevnom poslovanju koristi najveci broj raspolozivih funkcionalnosti sistema, a da nije slucaj da su implementirane mnoge funkcionalnosti koje u teoriji lepo zvuce, ali koje korisnici sistema ne koriste uopste vec te aktivnosti rade pesaka van ERP-a (pored toga sto imaju sva neophodna upustva, ali se jednostavno kroz rad u praksi pokaze da to bas i ne moze u realnom radu da funkcionise, kao sto su konsultanti obecavali i demonstrirali na jednostavnim modelima pre prodaje).

_{[Ovu poruku je menjao Inicijator dana 04.07.2016. u 14:25 GMT+1]}

Citat preuzet na drugom sajtu: "Imamo SAP (ne i MRP modul) ali su inputi katastrofa. Prodaja priča bajke jer jure svoje brojeve zarad svojih nekih bonusa i ko zna čega, isforsiraju te da proizvedeš toliko i toliko hiljada hektolitara (što povlači za sobom planiranje isporuka neophodnih materijala tipa flaša, čep, etiketa, folije itd), od čega ti pola ostane u FG skladištima i čeka rok trajanja i sad nemaš prostora ni lego kocku da staviš u magacine.

I da imamo MRP -- čemu bi služio kada ti plan proizvodnje menjaš 5 puta na dan jer reaguješ na raspršivanje fantazija Sales odseka i smanjuješ hektolitre, izbacuješ jedan proizvod, guraš drugi, itd? Znači, ljudski faktor opet figurira kao ključan element (ne)operativnosti.
Radim MRP i planiranja mora da ima: oslanjam se na Excel i na plan proizvodnje koji radi kolega prekoputa mene, a SAP mi služi isključivo za pregled zaliha i slanje narudžbenica jer je zaista beskoristan u ovakvim uslovima poslovanja (prevashodno mislim na Srbiju, ne na firmu).

Dobavljači nas redovno napušavaju zbog šizofrenih zahteva ali, kažem, to je sve zbog katastrofalnih Sales inputa sa kojima radimo. Kad si u logistici, svima si kriv za sve--čak i onima koji ti prouzrukuju 90% problema: prodaji i marketingu."

Ja sam lično takođe čuo komentare od osoba koje su radile u stranim kompanijama da nisu bile zadovoljne MRP sistemom, pa su planove pravili ručno sami.

Slažete li se sa time da je malo kompanija u Srbiji koje su na dobar način implementirali logiku ERP-ovog načina planiranja zaliha u svoje poslovanje i da se u potpunosti oslanjaju na njega (svo planiranje vrše u njemu, nema hiljadu excel fajlova kao ispomoć)?

Ne slažem se.

O ovome bih mogao jako mnogo da pišem.
Ali da sumiram konstatacija je jako je paušalna i ima mnogo više veze sa tim kako naši ljudi doživljavaju i odnose se prema ERP nego sa bilo čim drugim.

I za kraj, po meni, excel je neophodan i nezamenljiv alat, činjenica da ga neko koristi i pored ERP ne dokazuje apsolutno ništa.

Konstatacija koju sam izneo se generalno odnosi na uslove poslovanja kompanija u Srbiji. Problem nije u ERP sistemima (koji zahtevaju određeni nivo discipline u čitavom lancu kako bi na duži rok moglo da se izvrši anticipiranje potražnje). Ukoliko se disciplina ne nametne svim karikama u lancu, ukoliko se dozvoljava previše izuzetaka, ERP sistem je onda nemoćan.

Da li je neko upoznat u kojim sve drzavnim sistemima / institucijama se koristi SAP? Za privatne kompanije mi je poznato, ali za državni sektor ne.

Ovo je ono za šta ja znam:
Grad Beograd, Neki mali deo u trezoru,
EPS, Pošta, Telekom, RTS,
Takođe mislim da je SAP ovde pravio public sector hub, ali ne znam dokle je to otišlo.

Ja sam pored tog podatka za upravu za trezor u okviru Ministarstva finansija pronašao još za MUP (ne znam da li samo deo koji se tiče poslova javnih nabavki).

Postoji li u SAP-u ili NAV-u opcija da se omogući beleženje preciznog vremena svake transakcije (vreme otvaranja porudžbenice, vreme knjiženja...)?

Ukoliko u samom ERP sistemu ne postoji takva opcija, postoji li neki softver koji se može integrisati sa ERP sistemom koji će meriti precizno trajanje svake aktivnosti?

https://www.youtube.com/watch?v=xN9bSyvt-xg

Sećam se da je ranije bilo sličnih komentara, ali me je iznenadilo da ovo kaže baš on i to u 2017. godini

Šta te ovde čudi hoće čovek da uvede neko svoje "bolje" rešenje od koga će da uzme masnu proviziju. A onda će neko ko bude došao posle njega da pljuje to njegovo rešenje i da uvede novo.
Na stranu šta ja mislim o Prointeru/Energosoftu i njihovom gazdi (ništa dobro) što je tema Insajdera, ali istorija implementacije SAP u EPS je jako duga i dosta različitih implementatora se tu izređalo i glavni problem nije u SAP.

Kako god, to je trenutno glavno zanimanje svih novo postavljenih direktora, implementacija informacionih sistema.

Sećam se kako je u Infostanu neki direktor ili šta već namerno poslao pola beograda pogrešne račune i to opravdao kako je IS koji je njegov prethodih uveo loš IS (potrošeno je bilo više miliona evra) i posle toga dobio saglasnost da uvede novi. Znam da mu je prva tema kako je postavljen na funkciju bila sagledavanje IS i kad nije dobio saglasnost da išta menja uradio je to što je uradio. Sve se to desilo u prvih par meseci njegovog mandata. Mislim da se posle toga opet promenili ali tad je bila donesena odluka na nivou grada, a tu je tek bio fijasko, i tako u nedogled.

Jedino što mogu da razumem jeste kada kaže da je šteta što se prelazi na novi sistem iako su prethodnih godina uložena velika sredstva u razvoj i održavanje postojećeg sistema. Ako je stari sistem ispunjavao sve zahteve onda nije bilo ni potrebno krenuti sa novim sistemom.

Ali ne znam koliko je to njihovo postojeće rešenje zadovoljavajuće, mnoge domaće firme su se nakačile na grbaču javnih preduzeća.

I dan danas može da se čuje da neko izgovori da je najveći problem SAP-a to što je rađen po zapadnom sistemu poslovanja, te da je teško primeniti ga u Srbiji.

_{[Ovu poruku je menjao Inicijator dana 19.07.2017. u 21:49 GMT+1]}

Ako se misli na vreme u koje je nešto urađeno, onda to u NAVu standardno postoji. Postoji evidencija promena koja se podešava na nivou tabele/polja, tako da je moguće podesiti da se tačno vidi kada je otvorena neka porudžbina (i koji korisnik)
Ako se misli na trajanje transakcije, u NAVu takva opcija standardno ne postoji, ali nije neka mudrost to doraditi da se beleži trajanje transakcije npr od momenta kada korisnik stisne dugme Knjiži do momenta kada se transakcija završi.

Jednom se to pitanje poteglo, da li se može na određeni način (merenjem vremena rada na nekom nalogu) doći do nekih ocena zaposlenih, nekih merljivih kriterijuma na osnovu kojih bi mogli da se prate / da se definiše neki standard.

Međutim, to po meni ne vodi nigde i ne može da se uzme kao relevantan podatak. Od samog otvaranja nekog dokumenta do knjiženja može proći dosta vremena, a za to nikako ne mora biti odgovorna osoba koja obrađuje sam nalog. Ne bi to vodilo ničemu, ne znam da li bi takav podatak bio bilo kome od koristi.

Vidiš nisam razmišljao o tome, ali ta druga opcija je možda i korisnija, da se beleži koliko dugo traje samo knjiženje nekog dokumenta kako bi se videlo da li postoje neki ekstremi.

Kada je u pitanju izveštavanje, SAP ako se ne varam koristi Crystal Reports, a u specifikaciji tehničkih zahteva za Navision stoji da je za pokretanje izveštaja na računarima korisnika potrebno instalirati

* Microsoft Report Viewer 2015 to run reports that use RDLC
report layouts.

* SQL Server Report Builder 3.0 for Microsoft SQL Server 2014 or
Microsoft SQL Server 2012 SP1 to edit RDLC report layouts,

* Microsoft Word 2013 or later to edit the layouts.

Dok za izradu izveštaja stoji da je potrebno instalirati

*Microsoft Report Viewer 2015 to run reports that use RDLC
report layouts.

*Microsoft Visual Studio or SQL Server Report Builder for
creating and editing RDLC report layouts.

*Word 2013 or later to create Word report layouts

Da li se nešto gubi ako se koristi SQL Server Report Builder a ne Visual Studio?

Što se tiče merenja peformansi zaposlenih kroz ERP ja sam se susretao nekoliko puta, ali je uvek bilo vezano za magacionere. Na primer, ideja je bila da se meri kada je na nekom handheld uređaju korisnik krenuo u akciju (to je u suštini ili prijem ili isporuka), onda bi se gledalo u koji regal (visina & udaljenost) je spustio robu i koliko je ta roba teška i koliko je vremena prošlo od prvog koraka u procesu. Sa tako prikupljenim informacijama bi se onda uticalo na platu. Nije se išlo dalje od ideje, jer ima previše promenljivih koje mogu da utiču.
Za logistiku negde koriste broj kreiranih prodajnih dokumenata & broj redova dokumenata, ali to samo kao neku okvirnu informaciju jer naravno da ima milion stvari koji na to mogu da utiču.

Što se tiče reportinga, ovo što si naveo se uglavnom odnosi na ispis dokumenata. U tom kontekstu, za krajnjeg korisnika sigurno nije neophodno da ima sql report builder niti word. Što se tiče pravljenja izveštaja, lakše je raditi sa VS, ali je OK i sa SQL Report Builderom. Što se izveštavanja tiče, pored solidnog broja standardnih "papirnih" izveštaja, besplatno se može koristiti JET Express (ako postoji Excel naravno).

Izem ti firmu koja magacioneru meri korake i koriguje platu od 25.000 :D

I meni se to ne dopada ali tako nešto je moguće normirati.

Da li je Crystal Reports kompatibilan jedino sa SAP-om ili se može integrisati i sa drugim ERP rešenjima?

Deluje da može sa bilo kojim koji koristi neki od navedenih db


https://en.wikipedia.org/wiki/...Reports#Supported_data_sources

edit: a zaboravio sam i jednu stvar vezano za izveštavanje u NAVu, a to je Power BI i MS-ovo veliko ulaganje u ovaj alat.

Moze li neko da pojasni koncept regulacija u NAV-u?

Znam da je u pitanju obrada koja se periodično pokreće, ali koji je zapravo efekat same obrade, i zbog čega su regulacije neophodne?

Radi tacnog troska zaliha ( ako je pitanje vezano za regulaciju zaliha). Zamisli da ti je artikal usao na zalihe sa fakturnom cenom od 10 rsd. Artikal je prodat i trosak prodate robe je 10. Dobavljac za transport nije azuran i fakturu za prevoz je poslao nakon 14 dana. Proknjizena je ulazna faktura, troskovi su vezani za nabavka i sada su ukupni troskovi (fakturna vrednost +ztn) 12. E sad, regulacija taj dodatni trosak prebacuje i na stavku prodaje, tako da i trosak prodate robe bude 12.
Ovo je naravno najprostiji slucaj, ali se nadam da sam uspeo pojasniti svrhu.
To se moze raditi u momentu knjizenja, ali je praksa da se pusta kao posebna obrada ( cesto i nocu) jer je dosta zahtevna

Da, na te regulacije sam mislio, hvala puno na objašnjenju. Regulacije su znači neophodne da bismo na određeni dan imali realnu sliku, tako što bi se integrisale sve povezane stavke, prošlo kroz sve prethodne poslovne promene koje su se dogodile i izvršilo ažuriranje stavki radi dobijanja ažurnog stanja.

E baš to. Apsolutno su neophodne (ako postoje robne transakcije), samo postoji podešavanje da se to radi prilikom svakog knjiženja (da se ne pokreće posebna obrada), ali to koristi možda 5% klijenata.
Podjednako su bitne i kod prosečnog i kod FIFO metoda obračuna troška (samo što kod prosečnog ta obrada traje duže).

Pozdrav svima!
Imam jedno pitanje, a vidim da ovde ima ljudi koji su u oblasti MSC Dynamics NAV, pa se nadam da mogu dobiti objektivne info...
Da li se u BG traze NAV finansijski konsultanti, I da li znate kako se krecu plate za te poslove?
Hvala!

Traže se konstantno. Iako možda nema uvek formalno otvorenog konkursa, za NAV konsultanta uvek postoji tražnja.

E sad, plate se kreću dobro, ali zavisi od mnogo faktora - iskustva, znanja, koliko zaposleni traži i slično. Nema tu baš neke egzaktne cifre koja se mogu reći (plus ja radim kod jednog implementatora, pa mi ne deluje fer da iznosim cifre)

_{[Ovu poruku je menjao High Spirit dana 06.03.2018. u 10:16 GMT+1]}

Hvala u svakom slucaju, nije znaci zalud poslati pokoji CV :-)
Mozes li mi reci jos nesto: da li napr. tvoja kompanija koristi neku formu testiranja?

I da i ne. Evo na primer sad upravo primamo neke juniore konsultante (bez iskustva) i jedna od stvari koju radimo je da im se obezbedi osnovna literatura, da im se da neki baš jednostavan zadatak i onda im se omogući pristup NAVu u kom oni to nešto treba da urade. Da se razumemo, ovo ne dobiju svi koji dođu na razgovor, nego samo neki "uži" krug.
Za osobe sa iskustvom takve forme testiranja nema.
Takođe, nemamo neke standardizovane testove koje bi , šta znam, pokazale psihološke karakteristike, IQ ili nešto slično.

Da, ja sam i pitala vezano za testiranje u smislu znanja struke, s obzirom da nema cise zvanicne certifikacije...
Hvala!

Da se razumemo, to su testovi koji više pokazuju nečiju volju da uči i da se iscima nego što pokazuju šta i koliko neko zna. Prethodno iskustvo se može proveriti tokom razgovora.