Poslovođa je završio raspored.

Supervizor ga je pregledao i odobrio.

A zatim neko promeni jednu smenu direktno u istom planu.

Na ekranu i dalje može da piše Approved, ali poslovno više nije jasno šta je zapravo bilo odobreno.

To je razlog zbog kojeg planiranje zaposlenih nije samo pitanje raspoređivanja ljudi po danima i smenama. Plan mora da ima lifecycle u kojem status određuje šta se sa njim sme raditi, ko donosi odluku i šta predstavlja referentnu osnovu kada počne realizacija.

U OWMS modelu Draft, Submitted, Approved i Rejected nisu dekorativne oznake. Oni predstavljaju različita poslovna stanja kroz koja plan prolazi. Pasted text

Planiranje zaposlenih se često posmatra kroz njegov najvidljiviji rezultat: kalendar sa zaposlenima, smenama i satima.

Ali raspored je samo izlaz.

Iza njega postoji proces:

plan se priprema → proverava → šalje na odluku → odobrava ili odbija → koristi kao osnova za realizaciju → eventualno menja kontrolisanim putem.

U dokumentovanom OWMS modelu odluka o planu eksplicitno odgovara na pitanje da li je plan Draft, Submitted, Approved ili Rejected i ko je doneo odluku. Pasted text

Zato status nije samo podatak koji treba prikazati korisniku.

Status određuje koje poslovne akcije su u tom trenutku dozvoljene.

Draft može da se menja.

Submitted čeka odluku.

Approved postaje operativna referenca.

Rejected se vraća na korekciju.

Drugim rečima, lifecycle pretvara raspored iz običnog skupa unosa u kontrolisan poslovni objekat.

Pretpostavimo da je plan smena pripremljen za određeni objekat i period.

Poslovođa ga pregleda, validira i šalje supervizoru.

Supervizor ga odobri.

Ako poslovođa nakon toga može da otvori isti plan i bez ikakvog dodatnog koraka promeni zaposlenog, smenu ili broj sati, javlja se jednostavan problem:

šta tačno predstavlja odluka koju je supervizor prethodno odobrio?

Ako je sadržaj slobodno promenljiv, Approved postaje samo etiketa.

To ne znači da je plan zauvek nepromenljiv.

Operativa se menja.

Zaposleni može postati nedostupan. Može biti potrebna druga smena. Može nastati legitiman razlog za korekciju.

Ali razlika je u tome što se promena više ne tretira kao običan edit.

Postaje kontrolisana poslovna akcija.

Najjednostavnija implementacija mogla bi da ima polje:

Status = Approved

i nekoliko različitih vrednosti u dropdown-u.

To tehnički čuva status.

Ali ne čuva nužno lifecycle.

Lifecycle postoji tek kada stanje menja ponašanje sistema.

Ako Draft i Approved dozvoljavaju iste akcije, između njih poslovno gotovo da nema razlike.

U OWMS-u statusni lifecycle je zato vezan za dozvoljene akcije: sistem kontroliše ko sme da menja, šalje, odobrava ili vraća plan. Pasted text

To znači da stanje mora da bude povezano najmanje sa:

• pravom izmene;
• pravom slanja;
• pravom odlučivanja;
• dozvoljenim narednim statusom;
• pravilom naknadne promene;
• tragom odluke.

Tada status više nije UI detalj.

Postaje deo poslovnog pravila.

Kontrola ne počinje u trenutku kada supervizor klikne Approve.

Plan prvo mora da stigne do stanja u kojem je uopšte spreman za odluku.

U dokumentovanom OWMS toku planiranje uključuje period, ciljne sate, rok, zaposlene, odsustva i validaciju. Plan ne može da se pošalje na odobrenje pre sistemske provere. Pasted text

Zato prirodan tok izgleda ovako:

Draft — plan se još izrađuje i koriguje.

Submitted — autor plana tvrdi da je plan spreman za odluku.

Approved — nadležna osoba je prihvatila konkretnu verziju plana kao operativnu osnovu.

Rejected — plan nije prihvaćen i vraća se na korekciju.

Važna stvar je da svaka tranzicija mora da ima značenje.

Draft → Submitted nije promena teksta u koloni.

To je predaja odgovornosti.

Submitted → Approved nije samo potvrda.

To je odluka kojom konkretan plan dobija status baseline-a.

Submitted → Rejected mora da vrati proces u stanje u kojem je korekcija ponovo dozvoljena.

Pouzdan lifecycle zahteva nekoliko povezanih odluka.

1. Definisati stanja plana

Ne treba početi od dugmadi, već od poslovnih stanja kroz koja plan stvarno prolazi.

U ovom slučaju: Draft, Submitted, Approved, Rejected.

2. Definisati dozvoljene tranzicije

Ne sme svaki status da pređe direktno u svaki drugi.

Na primer, odobrenje ima smisla tek nakon što je plan prethodno predat.

3. Definisati dozvoljene akcije po stanju

Ključno pitanje nije samo „koji je status?“, već:

„Šta korisnik sada sme da uradi?“

4. Definisati ownership odluke

Poslovođa priprema i šalje plan, dok supervizor odlučuje o predatom planu. Case study eksplicitno razdvaja njihove odgovornosti. Pasted text

5. Definisati ponašanje nakon odobrenja

Approved plan više nije običan radni dokument.

Postaje referentna verzija prema kojoj se kasnije posmatra ono što je planirano i ono što se zaista dogodilo.

6. Projektovati izuzetke

Naknadna promena nije zabranjena — ali mora imati poseban kontrolisan tok.

To čuva potrebnu fleksibilnost bez gubitka značenja prethodne odluke.

Jedna od najvažnijih razlika u ovom modelu jeste razlika između plana i realizacije.

Odobren plan odgovara na pitanje:

„Šta smo odlučili da treba da se dogodi?“

Realizacija odgovara na drugo:

„Šta se zaista dogodilo?“

Ta dva podatka treba da budu povezana, ali ne smeju biti ista stvar.

Case study eksplicitno navodi da realizacija mora da beleži stvarno stanje čak i kada odstupa od plana, dok plan ostaje referenca za poređenje i analizu. Pasted text

To je razlog zbog kojeg odobren plan mora da ostane baseline.

Ako se plan retroaktivno prepiše stvarnim stanjem, organizacija gubi odgovor na pitanje:

„Šta smo prvobitno odobrili?“

Tada više nije moguće pouzdano razlikovati plan od odstupanja.

U OWMS-u je planiranje implementirano kao širi kontrolisani ciklus koji povezuje period, ciljne sate, rok, odsustva, plan, approval, realizaciju i izveštavanje. Sistem je razvijen za distribuirano maloprodajno okruženje u kojem lokalni poslovođa priprema plan, a supervizorski nivo postavlja okvir, prati napredak i odlučuje o planovima.

Konkretan approval workflow izgleda tako da poslovođa najpre validira plan i šalje ga, nakon čega supervizor može da ga odobri ili odbije. Ako je odbijen, plan se koriguje i ponovo šalje.

Kada je plan odobren, direktna tiha izmena baseline-a nije dozvoljena. Naknadna promena prolazi kroz poseban zahtev koji sadrži konkretan predmet promene i obrazloženje.

Odobren plan zatim predstavlja osnovu za dnevnu realizaciju.

Na taj način ista sistemska celina zna:

šta je pripremljeno,

šta je predato,

šta je odobreno,

šta je naknadno promenjeno,

i šta se zaista dogodilo.

To je razlika između digitalnog rasporeda i kontrolisanog operativnog procesa.

Rejected nije greška sistema.

To je legitimna poslovna odluka.

Plan može biti tehnički popunjen, a ipak neprihvatljiv za operativnu primenu.

Ako odbijanje postoji samo kao poruka van sistema, nastaje problem: plan možda ostaje u stanju koje izgleda kao aktivno, dok razlog zbog kojeg nije prihvaćen živi u drugom kanalu.

U kontrolisanom lifecycle-u odbijanje menja stanje plana i vraća odgovornost autoru plana.

Poslovođa zna da je potrebna korekcija.

Supervizor ima trag odluke.

Sistem zna da plan još nije validna operativna baseline.

Case study upravo razlikuje validaciju, slanje, odobravanje, odbijanje i ponovno slanje kao zasebne implementirane sposobnosti.

Kontrolisan lifecycle namerno smanjuje deo ad-hoc fleksibilnosti.

Dok je plan u Draft stanju, izmene treba da budu lake.

Kada je plan odobren, ista sloboda više nije poželjna, jer bi poništila smisao odobrenja.

To je svestan trade-off. Sama dokumentacija ga eksplicitno navodi: statusni lifecycle donosi kontrolu dozvoljenih akcija, ali smanjuje slobodu proizvoljne izmene nakon odobrenja. Pasted text

To ipak ne znači da su izmene odobrenog plana apsolutno zabranjene.

Naprotiv, case study potvrđuje poseban put za naknadnu promenu. Zato ne bi bilo tačno tvrditi da Approved znači „nikada se više ništa ne može promeniti“.

Druga granica odnosi se na rezultat implementacije.

Dokumentacija ne sadrži pouzdanu početnu metriku vremena planiranja, broja grešaka ili troška koordinacije, pa članak ne treba da tvrdi procenat uštede, smanjenje grešaka ili povećanje produktivnosti.

Prva pogrešna pretpostavka je da su Draft, Submitted, Approved i Rejected samo vrednosti koje treba prikazati korisniku.

Ako status ne menja dozvoljene akcije, on ne predstavlja pravi lifecycle.

Druga je da je Approved plan nepromenljiv zauvek.

Nije. Operativne promene su realne, ali promena mora da prođe kroz kontrolisan put kako bi prethodna odluka ostala dokaziva.

Treća je da plan treba menjati tako da uvek odgovara realizaciji.

Time se briše istorijska razlika između onoga što je bilo planirano i onoga što se stvarno dogodilo.

Četvrta je da approval može da postoji van samog sistema, na primer samo kroz email ili poruku.

Takva poruka može preneti odluku, ali sama po sebi ne zaključava plan, ne definiše naredne dozvoljene akcije i ne obezbeđuje jednoznačno stanje celog procesa.

Planiranje zaposlenih nije završeno kada su smene upisane u kalendar.

Da bi plan postao pouzdana operativna osnova, sistem mora da zna u kom se stanju nalazi, ko trenutno ima pravo na akciju, koja tranzicija je dozvoljena i šta se dešava nakon odluke.

Zato Draft, Submitted, Approved i Rejected nisu dekorativni statusi.

Oni predstavljaju lifecycle poslovne odluke.

A Approved plan dobija pravo značenje tek kada ostane sačuvan kao baseline prema kojoj se mogu posmatrati naknadne promene i stvarna realizacija.

U tome je razlika između aplikacije koja prikazuje raspored i sistema koji upravlja procesom planiranja.

---

Detaljniji primer implementiranog ciklusa možete pogledati u povezanoj studiji slučaja:

Studija pokazuje kako su u jednom sistemu povezani period, targeti, odsustva, planiranje, validacija, approval, kontrolisane promene i stvarna realizacija.