SBE Tehnobar

SBE treba da bude poslovni prikaz budućeg rada, a ne tehnička specifikacija.  

Kroz nekoliko reprezentativnih scenarija klijent treba da razumije kako će TehnoBar raditi nakon implementacije, dok SBE ostaje referentna osnova za kontrolu scope-a. 

• Jednostavno predstavljanje budućeg načina rada; 
• Potvrda zajedničkog razumijevanja ponuđenog rješenja; 

• Ulazna osnova za analizu i dizajn; 

• kontrolna osnova za identifikovanje odstupanja i Change Request zahtjeva. 
  
  

1. Kako treba koristiti SBE 

• ko započinje proces; 

• koji je poslovni događaj; 

• kako proces prolazi kroz Odoo; 

• gdje su kontrole i odgovornosti; 

• koji dokumenti i podaci nastaju; 

• šta se smatra očekivanim rezultatom; 

• šta nije dio scenarija. 

Svaki scenario dobija identifikacionu oznaku, na primjer: 

• SBE-SAL-01 Prodaja robe iz centralnog skladišta 

• SBE-WMS-01 Prijem robe od dobavljača 

• SBE-PUR-01 Nabavka robe prema potrebi 

• SBE-ACC-01 Fakturisanje i naplata kupca 

• SBE-ECOM-01 Online narudžba 

• SBE-HR-01 Obračun zarade 

• SBE-EXP-01 Putni nalog i trošak 

• SBE-AST-01 Nabavka i amortizacija osnovnog sredstva 

2. Krovni “end-to-end" scenario 

SBE-E2E-01: Od potrebe kupca do finansijskog evidentiranja 

Učesnici: 

• kupac; 

• prodavac; 

• skladištar; 

• računovodstvo; 

• rukovodilac prodaje, kada je potrebno odobrenje komercijalnih uslova. 

Budući tok rada 

Očekivani rezultat - jedinstven i sljediv tok:

Kupac → Ponuda → Prodajni nalog → Rezervacija → Isporuka → Faktura → Uplata 

Okvir ponuđenog scope-a 

• ponude i prodajni nalozi; 

• cjenovnici, rabati i komercijalni uslovi; 

• prikaz i rezervacija zaliha; 

• isporuka robe; 

• izlazno fakturisanje; 

• praćenje stanja kupaca; 

• standardni prodajni i finansijski izvještaji. 

Nije definisano ponudom 

• posebno razvijeni višestepeni approval proces za rabate; 

• automatsko određivanje cijene prema eksternim servisima; 

• integracija sa eksternim CRM-om; 

• mobilna aplikacija izrađena posebno za TehnoBar; 

• posebni algoritmi za predikciju prodaje. 

Ove stavke ne treba unaprijed proglasiti CR-om samo zato što su pomenute.  CR nastaje tek kada ih klijent zatraži kao obaveznu funkcionalnost, a one nijesu dio prihvaćenog baseline-a. 

3. Prodajni scenariji 

SBE-SAL-01: Standardna ponuda i prodaja 

Poslovna situacija: Kupac traži cijenu i rok isporuke za više artikala. 

Tok: 

1. Prodavac pronalazi kupca ili kreira novi kontakt. 

2. Dodaje proizvode, količine i jedinice mjere. 

3. Sistem primjenjuje odgovarajući cjenovnik. 

4. Prodavac unosi rabat, rok važenja i planirani datum isporuke. 

5. Ponuda se šalje kupcu. 

6. Aktivnost za praćenje ponude dodjeljuje se odgovornom prodavcu. 

7. Nakon potvrde kupca, ponuda se konvertuje u prodajni nalog. 

8. Sistem inicira rezervaciju i isporuku robe. 

Kontrolne tačke 

• ispravan kupac; 

• odgovarajući cjenovnik; 

• raspoloživost robe; 

• komercijalni uslovi; 

• planirani datum isporuke. 

Potencijalno odstupanje koje nije automatski CR 

Klijent želi drugačiji izgled štampane ponude. To može biti konfiguracija ili manja adaptacija unutar predviđenog obima, zavisno od složenosti. 

Tipičan CR (change request) - zahtjev za promjenama projektnog okvira

Klijent traži: 

• poseban konfigurator proizvoda; 

• složeni approval prema procentu marže; 

• automatski obračun bonusa prodavca; 

• novu aplikaciju za terensku prodaju. 

SBE-SAL-02: Prodaja artikala u različitim pakovanjima 

Tok: 

1. Za artikal se definišu osnovna jedinica mjere i podržana pakovanja. 

2. Prodavac bira artikal i odgovarajuće pakovanje. 

3. Sistem prikazuje količinu u skladu sa konfiguracijom. 

4. Skladište priprema odgovarajuću količinu. 

5. Isporuka i fakturisanje prate potvrđenu prodajnu količinu. 

Važna presales napomena 

Ponuda navodi pakovanja, jedinice mjere i logističke jedinice, ali ne definiše sve posebne kombinacije pakovanja koje TehnoBar koristi. 

Zbog toga u fazi analize treba potvrditi reprezentativne primjere: 

• komad; 

• paket; 

• kutija; 

• različito prodajno i nabavno pakovanje; 

• mogućnost ili zabrana otvaranja pakovanja. 

Ako se proces može ostvariti standardnom konfiguracijom, nije CR. Ako je potreban poseban algoritam konverzije ili novi način rezervacije, može postati CR. 

4. Skladišni scenariji 

SBE-WMS-01: Prijem robe od dobavljača 

Tok: 

1. Skladištar otvara očekivani prijem. 

2. Provjerava dobavljača, artikle i očekivane količine. 

3. Unosi stvarno primljene količine. 

4. Evidentira eventualne razlike. 

5. Robu smješta na odgovarajuće lokacije. 

6. Potvrđuje prijem. 

7. Sistem ažurira stanje zaliha. 

8. Računovodstvo kasnije povezuje ulazni račun sa nabavkom i prijemom. 

Rezultat 

• ažurno stanje robe; 

• sljedivost prijema; 

• pregled naručene, primljene i preostale količine; 

• osnova za kontrolu ulaznog računa. 

SBE-WMS-02: Interni transfer robe 

Tok: 

1. Korisnik kreira interni transfer. 

2. Definiše izvornu i ciljnu lokaciju. 

3. Skladištar priprema robu. 

4. Transfer se potvrđuje. 

5. Sistem ažurira količine po lokacijama. 

6. Korisnici mogu vidjeti gdje se roba fizički nalazi. 

CR granica 

Standardni transfer između Odoo lokacija je baseline. 

Poseban CR može biti: 

• razvoj posebne mobilne aplikacije; 

• integracija sa nezavisnim WMS sistemom; 

• automatsko upravljanje transporterima i rutama; 

• specifična optimizacija redosljeda komisioniranja. 

SBE-WMS-03: Inventura i korekcija zaliha 

1. Kreira se inventurna lista za lokaciju ili grupu artikala. 

2. Korisnici evidentiraju prebrojane količine. 

3. Sistem prikazuje razliku između evidencije i stvarnog stanja. 

4. Ovlašćeno lice provjerava razlike. 

5. Potvrđuje se korekcija. 

6. Sistem evidentira novo stanje i trag izmjene. 

Presales ograničenje: 

Ponuda obuhvata inventuru i korekcije zaliha, ali ne definiše napredne ciklične inventure, wave counting ili posebne procedure odobravanja inventurnih razlika. 

5. Nabavni scenariji 

SBE-PUR-01: Nabavka prema potrebama prodaje i zaliha 

Poslovna situacija: Prodaja ili skladište identifikuju potrebu za nabavkom artikala. 

Tok: 

1. Korisnik kreira RFQ prema dobavljaču. 

2. Dodaje potrebne artikle i količine. 

3. Sistem koristi definisane podatke o dobavljaču. 

4. RFQ se šalje dobavljaču e-mailom. 

5. Nakon potvrde uslova, RFQ postaje narudžbenica. 

6. Definiše se očekivani datum prijema. 

7. Skladište vidi očekivanu robu. 

8. Nakon dolaska robe potvrđuje se prijem. 

9. Računovodstvo unosi dobavljački račun. 

10. Sistem povezuje nabavku, prijem i finansijski dokument. 

U okviru baseline-a obuhvaćeno: 

• više dobavljača po artiklu; 

• dobavljački uslovi; 

• RFQ i PO; 

• planiranje prijema; 

• povezivanje sa skladištem i računovodstvom; 

• standardna analitika nabavke. 

Tipičan CR 

• portal za dobavljače; 

• elektronsko nadmetanje dobavljača; 

• automatsko poređenje eksternih cjenovnika; 

• EDI integracija; 

• poseban tender workflow; 

• algoritam optimizovane nabavke koji nije standardna reorder logika. 

SBE-PUR-02: Automatska dopuna minimalnih zaliha 

Tok: 

1. Za artikal se definišu min-max pravila. 

2. Sistem prati raspoloživu i očekivanu količinu. 

3. Kada se dostigne prag, generiše se potreba za dopunom. 

4. Odgovorno lice pregleda prijedlog. 

5. Kreira se ili potvrđuje RFQ. 

6. Dalji proces ide kroz standardnu nabavku i prijem. 

Ograničenje 

Standardne reorder rules jesu dio ponude. Napredno sezonsko predviđanje, AI forecast ili složena optimizacija zaliha nijesu eksplicitno obuhvaćeni. 

6. Računovodstveni scenariji 

SBE-ACC-01: Izlazna faktura i naplata 

Tok: 

1. Faktura nastaje na osnovu potvrđene prodaje i poslovnog pravila. 

2. Računovodstvo provjerava podatke. 

3. Faktura se potvrđuje. 

4. Sistem kreira odgovarajuća knjiženja. 

5. Uplata se unosi ili uvozi kroz bankovni izvod. 

6. Uplata se povezuje sa fakturom. 

7. Otvorena stavka se zatvara ili ostaje djelimično otvorena. 

8. Finansijski izvještaji se automatski ažuriraju. 

SBE-ACC-02: Dobavljački račun 

1. Računovodstvo unosi dobavljački račun. 

2. Povezuje ga sa dobavljačem i relevantnom nabavkom. 

3. Provjerava poreze, iznose i rok plaćanja. 

4. Potvrđuje dokument. 

5. Sistem generiše knjiženje. 

6. Obaveza se prati do plaćanja. 

7. Nakon plaćanja zatvara se otvorena stavka. 

SBE-ACC-03: Bankovni izvod i automatsko rasknjižavanje 

1. Bankovne transakcije se unose ili uvoze. 

2. Sistem predlaže povezivanje sa fakturama i partnerima. 

3. Računovođa potvrđuje ili koriguje prijedlog. 

4. Transakcije se knjiže i usaglašavaju. 

5. Otvorene stavke se ažuriraju. 

CR granica: 

• Standardni uvoz i modeli rasknjižavanja pripadaju ponudi. 
• Integracija sa određenom bankom preko API-ja nije navedena kao ugovorena integracija. Ako se zahtijeva direktna automatska bankarska integracija, to mora biti posebno analizirano i ugovoreno. 

7. eCommerce scenario 

SBE-ECOM-01: Online narudžba kupca 

Poslovna situacija: Kupac posjećuje TehnoBar web prodavnicu, bira proizvode i kreira narudžbu. 

Tok: 

1. Kupac pregleda proizvode i kategorije. 

2. Bira varijantu, količinu i dodaje proizvod u korpu. 

3. Sistem prikazuje odgovarajuću cijenu. 

4. Kupac prolazi checkout. 

5. Bira način dostave i ponuđeni način plaćanja. 

6. Kreira se online narudžba. 

7. Roba se rezerviše u skladištu. 

8. Interni korisnik obrađuje narudžbu. 

9. Roba se isporučuje. 

10. Prodaja i performanse prate se kroz izvještaje. 

Posebno važna scope napomena 

Ponuda obuhvata osnovni eCommerce tok, proizvode, varijante, kategorije, cijene, checkout, načine plaćanja i dostave, obradu narudžbi, rezervaciju i analitiku. 

Ponuda sama po sebi ne potvrđuje: 

• integraciju sa konkretnim payment gateway-om; 

• integraciju sa kurirskom službom; 

• loyalty program; 

• kompleksne akcije i promocije; 

• marketplace integracije; 

• napredni product recommendation engine; 

• posebno dizajniran frontend izvan dogovorenog obima. 

Ovo je područje u kojem se najlakše pojavljuju pretpostavke klijenta. Zato eCommerce SBE mora sadržati slike ili jednostavne wireframe prikaze ključnih koraka, a uz svaki korak treba navesti šta je standard, šta je konfiguracija i šta ostaje otvoreno za potvrdu. 

8. Zaposleni i obračun zarada 

SBE-HR-01: Od evidencije zaposlenog do obračuna zarade 

1. HR ili administracija kreira karton zaposlenog. 

2. Definišu se organizaciona jedinica, radno mjesto i nadređeni. 

3. Evidentira se ugovor i datum isteka. 

4. Unose se podaci potrebni za obračun. 

5. Pokreće se obračun zarada za period. 

6. Sistem obračunava zaradu prema podešenim pravilima. 

7. Odgovorno lice kontroliše rezultat. 

8. Generišu se obračunski listići. 

9. Obračun se knjiži u računovodstvo. 

10. Generišu se ugovoreni izvještaji i obrasci. 

CR granica 

Lokalni obračun i navedeni izvještaji pripadaju ponuđenom rješenju. 

Poseban CR može biti: 

• integracija sa eksternim sistemom evidencije prisustva; 

• poseban sistem bonusa i stimulacija; 

• razvoj dodatnih izvještaja koji nijesu dio lokalizacije; 

• employee self-service funkcionalnosti izvan standardnog obima. 

9. Troškovi i putni nalozi 

SBE-EXP-01: Evidentiranje i odobravanje troška 

1. Zaposleni ili ovlašćeno lice unosi trošak. 

2. Dodaje račun ili drugu dokumentaciju. 

3. Trošak se šalje na odobravanje. 

4. Odgovorna osoba odobrava ili vraća trošak. 

5. Odobreni trošak se knjiži. 

6. Evidentira se obaveza refundacije zaposlenom. 

7. Trošak se analizira po zaposlenom i odjelu. 

SBE-EXP-02: Putni nalog 

1. Kreira se putni nalog. 

2. Definišu se zaposleni, relacija, period i razlog putovanja. 

3. Unose se dnevnice, kilometraža i ostali troškovi. 

4. Prilaže se dokumentacija. 

5. Nalog prolazi odobravanje. 

6. Sistem obračunava iznos prema podešenim lokalnim pravilima. 

7. Trošak se knjiži i refundira. 

10. Osnovna sredstva 

SBE-AST-01: Nabavka i amortizacija sredstva 

Tok: 

1. Dobavljački račun sadrži nabavku osnovnog sredstva. 

2. Iz stavke računa kreira se kartica sredstva. 

3. Dodjeljuje se kategorija i model amortizacije. 

4. Sistem generiše plan amortizacije. 

5. Periodično se automatski knjiži amortizacija. 

6. Korisnik prati nabavnu, otpisanu i sadašnju vrijednost. 

7. Kod prodaje ili rashodovanja zatvara se kartica sredstva. 

11. Migracioni scenario 

SBE-MIG-01: Preuzimanje izlaznih faktura za istorijski pregled 

Ponuda predviđa migraciju izlaznih faktura bez knjiženja, radi pregleda istorijskih podataka. 

Budući način upotrebe 

1. Korisnik otvara karton kupca. 

2. Pored novih Odoo transakcija može pregledati prenesene istorijske fakture. 

3. Istorijske fakture služe za informativni pregled. 

4. One ne generišu nova računovodstvena knjiženja u Odoo sistemu. 

5. Novi poslovni period vodi se kroz aktivne Odoo procese. 

Baseline ograničenje: 

Migracija istorijskih faktura ne podrazumijeva automatski: 

• migraciju kompletnog glavnog dnevnika; 

• migraciju svih otvorenih stavki; 

• rekonstrukciju knjiženja; 

• migraciju svih priloga; 

• migraciju svake istorijske izmjene dokumenta; 

• čišćenje i rekonstrukciju neispravnih podataka. 

Svako proširenje migracionog obuhvata mora biti posebno evidentirano. 

12. Kako SBE povezati sa osam delivery faza 

13. Ključna klasifikacija: defect, clarification, GAP ili CR 

Ovo treba eksplicitno uključiti u SBE ili Project Control proceduru. 

Najvažnije pravilo:  Nije svaki GAP CR. 

CR nastaje kada: 

1. Zahtjev nije dio ugovorene specifikacije ni prihvaćenog SBE baseline-a; 

2. Zahtijeva dodatni rad, trošak ili pomjeranje roka; 

3. Klijent želi da postane obavezni dio isporuke; 

4. Izvršena je analiza uticaja; 

5. Promjena je formalno odobrena. 

14. Predloženi obrazac jednog SBE scenarija 

- SBE-SAL-01 Standardna prodaja robe 

Poslovni cilj:  Omogućiti prodavcu da od upita kupca formira ponudu, provjeri raspoloživost, potvrdi prodaju i inicira isporuku i fakturisanje. 

Učesnici:  Prodavac, skladištar, računovodstvo. 

Preduslovi: 

• kupac je evidentiran; 

• proizvodi i cijene su definisani; 

• stanje zaliha je inicijalizovano; 

• korisničke uloge su podešene. 

Glavni scenario 

• Numerisani koraci 1–10. 
• Alternativni scenario 

Na primjer: roba nije raspoloživa, pa prodavac vidi očekivanu količinu ili se inicira nabavka. 

Poslovne kontrole 

• kontrola cijene; 

• kontrola raspoloživosti; 

• kontrola prava potvrde; 

• sljedivost dokumenta. 

Rezultat 

Kreiran prodajni nalog, rezervacija, isporuka i osnova za fakturu. 

U okviru baseline-a obuhvaćeno:

• Lista ugovorenih funkcija. 
• Van baseline-a 
• Lista funkcija koje se ne podrazumijevaju. 
• Otvorena pitanja 
• Samo pitanja koja zahtijevaju potvrdu tokom Discovery faze. 
• Kriterijum prihvatanja 

Scenario se smatra prihvaćenim kada ovlašćeni korisnik može samostalno izvršiti tok sa reprezentativnim podacima i dobiti očekivani rezultat. 

15. Preporučeni SBE paket za presales 

To je dovoljno da klijent razumije budući sistem, ali i dovoljno kontrolisano da SBE ostane upotrebljiv tokom implementacije. 

16. Kritična ugovorna formulacija 

U ponudu, ugovor ili Project Charter preporuka je dodati sljedeću odredbu: 

Prihvaćeni SBE scenariji predstavljaju poslovnu interpretaciju ugovorenog funkcionalnog obuhvata i koriste se kao referentna osnova tokom analize, dizajna, konfiguracije, testiranja i korisničkog prihvatanja rješenja. Zahtjevi koji uvode novi poslovni scenario, novu funkcionalnost, dodatnu integraciju ili značajno mijenjaju prihvaćeni tok rada podliježu procjeni uticaja i proceduri upravljanja promjenama. Dodatno pojašnjenje ili detaljizacija postojećeg scenarija ne smatra se automatski Change Request zahtjevom. 

Ova posljednja rečenica je važna da SBE ne postane instrument kojim bi se svaka sitna nejasnoća naplaćivala kao promjena. Istovremeno štiti projekat od situacije u kojoj klijent tokom UAT-a uvodi novi proces i predstavlja ga kao „podrazumijevanu funkcionalnost“.