Ako sistem danas utvrdi da ugovor zaposlenog ističe za osam dana, vrlo je verovatno da će sutra utvrditi isto — samo će do isteka ostati sedam dana.

I prekosutra će uslov i dalje biti ispunjen.

Ali to ne znači da je svakog dana nastao novi poslovni događaj.

Upravo zato praćenje isteka ugovora zaposlenih nije samo pitanje čuvanja datuma i slanja emaila. Sistem mora da razume koji je zapis trenutno važeći, da li je događaj isteka već evidentiran i da li promena ugovora predstavlja nastavak postojećeg ili nastanak novog poslovnog konteksta.

U OWMS implementaciji taj problem je rešavan na nivou poslovnog događaja, a ne tek na nivou email poruke. Dokumentovani sistem koristi dnevnu evaluaciju rokova, događaje isteka, deduplikaciju i ciljano obaveštavanje.

Praćenje isteka ugovora zaposlenih je sistemski proces kojim se ne prati samo datum do kog ugovor važi, već i poslovno stanje koje taj datum proizvodi.

To znači da sistem mora da zna koji je ugovor važeći, koji datum je relevantan za automatizovanu obradu, kada zaposleni ulazi u period upozorenja, da li je za taj datum već nastao događaj i šta treba da se dogodi kada se ugovor produži ili status zaposlenog promeni.

Važna razlika je između: uslova — „ugovor ističe u narednih nekoliko dana“ i događaja — „za ovaj važeći ugovor evidentiran je događaj približavanja isteka“.

Uslov može biti tačan deset dana zaredom. Poslovni događaj ne treba zbog toga da nastane deset puta.

To je suština deduplikacije.

Zamislimo da zaposleni ima važeći datum isteka ugovora i da sistem jednom dnevno proverava ugovore koji su ušli u definisani period upozorenja.

Prvog dana uslov je ispunjen.

Sistem evidentira događaj.

Sledećeg dana scheduler ponovo vidi isti ugovor. Datum je i dalje blizu. Matematički uslov je ponovo tačan.

Ako implementacija odgovara samo na pitanje: „Da li je datum unutar perioda upozorenja?“ dobijaćemo novi događaj pri svakom izvršavanju.

U OWMS projektnoj dokumentaciji ovaj problem je eksplicitno tretiran kao zahtev za idempotentnom periodičnom obradom: bez jedinstvenog poslovnog ključa dnevna obrada bi ponovo generisala isti događaj i novo upozorenje. OWMS_Proaktivna_kontrola_HR_rok…

Zato je potrebno drugo pitanje: „Da li je za ovaj važeći zapis ovaj poslovni događaj već evidentiran?“

Tek kombinacija ta dva pitanja daje stabilno ponašanje.

Najlakše je problem posmatrati kao pitanje emaila:

„Ako smo juče poslali upozorenje, nemoj ponovo danas.“

Ali to rešava problem prekasno.

Email je samo jedan mogući kanal kojim se posledica poslovnog događaja isporučuje korisniku. Pre emaila sistem već mora da odluči da li poslovni događaj uopšte postoji.

Ako se duplikat sprečava tek u email sloju, sistem i dalje može da napravi više događaja, više internih notifikacija ili nekonzistentnu istoriju — samo možda neće poslati sve poruke.

Zato deduplikacija pripada poslovnom modelu.

U konkretnom OWMS pravilu, za istog zaposlenog i isti relevantni datum može postojati najviše jedan aktivan događaj isteka. OWMS_Proaktivna_kontrola_HR_rok…

Drugim rečima, potrebno je definisati identitet događaja, a ne samo identitet email poruke.

Pouzdan model može da se razloži na pet povezanih odluka:

1. Odrediti važeći zapis. Automatizacija ne sme nasumično da koristi bilo koji istorijski datum ugovora. Mora postojati jasno pravilo koji podatak trenutno predstavlja važeće poslovno stanje.
2. Definisati identitet poslovnog događaja. U OWMS slučaju identitet povezuje tip događaja, zaposlenog i relevantni datum. Dnevno izvršavanje tada može da proveri da li događaj već postoji, umesto da ga automatski kreira ponovo.
3. Odvojiti događaj od isporuke. Nastanak događaja i slanje notifikacije nisu ista odgovornost. Evaluacija treba da potvrdi i sačuva poslovni događaj, dok poseban tok određuje primaoce i upravlja isporukom.
4. Definisati lifecycle događaja. Produženje ugovora, prelazak zaposlenog na stalno, deaktivacija ili drugi relevantan događaj moraju da utiču na prethodno otvorene događaje i notifikacije. Stari poslovni kontekst ne sme da ostane operativno važeći samo zato što zapis već postoji.
5. Uvesti audit i monitoring. Potrebno je razlikovati šta je sistem utvrdio od toga šta je kasnije uspešno isporučeno određenom primaocu.

Tek kada su ova pravila jasna, automatizacija periodične provere postaje pouzdana. U suprotnom samo brže izvršavamo neprecizno poslovno pravilo.

Još jedna važna posledica ovog modela jeste razdvajanje evaluation i dispatch koraka.

Evaluation odgovara na pitanje: Da li se dogodila poslovno relevantna stvar?

Dispatch odgovara na drugo: Koga treba obavestiti i kakav je ishod isporuke?

U produkcionom OWMS toku ova dva koraka su namerno odvojena. Evaluacija utvrđuje i čuva poslovni događaj, dok dispatch naknadno određuje primaoce, kreira notifikacije, pokreće kanale i evidentira ishod. Takva granica omogućava retry i monitoring bez potrebe da se ponovo kreira isti poslovni događaj.

To je bitna razlika. Neuspešna email isporuka ne znači da poslovni događaj nije postojao.

Isto tako, ponovni pokušaj slanja ne treba da proizvodi novi događaj isteka ugovora.

U okviru OWMS-a CoreLayer je implementirao produkcioni modul za praćenje HR rokova koji klijent koristi u svakodnevnom radu.

Za periodičnu obradu ugovora definisano je pravilo da ponovna dnevna evaluacija ne sme da generiše novi aktivni događaj za isti poslovni slučaj.

Praktično, to znači da sistem ne pita samo „Da li se približava datum isteka?“ već i: „Da li ovaj događaj već postoji za trenutno važeći ugovor?“

Ako postoji, nova dnevna evaluacija ne proizvodi istu poslovnu činjenicu ponovo.

Ako se poslovni kontekst promeni — na primer ugovor dobije novi relevantni datum — sistem više ne posmatra situaciju kao jednostavno „isti email“, već kroz lifecycle važećeg zapisa i događaja.

Deduplikacija ne znači da sistem treba zauvek da spreči novo upozorenje za istog zaposlenog.

To bi bilo jednako pogrešno.

Ako zaposleni dobije novi ugovor sa novim relevantnim datumom isteka, novi datum predstavlja novi poslovni kontekst. Sistem zato mora da razlikuje stvarni duplikat od legitimno novog događaja.

Takođe, deduplikacija poslovnog događaja nije isto što i garancija email isporuke. Retry, status kanala i monitoring pripadaju posebnom delu obrade.

Prva pogrešna pretpostavka je da je dovoljno zapamtiti da je email već poslat. Time se kontroliše kanal, ali ne i identitet poslovnog događaja.

Druga je da je svaki sledeći događaj za istog zaposlenog duplikat. Nije — novi ugovor ili novi relevantni datum mogu predstavljati potpuno novi poslovni događaj.

Treća je da periodično izvršavanje samo po sebi rešava praćenje rokova. Scheduler samo ponavlja evaluaciju. Bez jasnog pravila o tome šta jedan događaj čini jedinstvenim, upravo ponavljanje izvršavanja postaje izvor duplikata.

Zato je kod ovakvih sistema važnije precizno definisati poslovni događaj nego odabrati tehnologiju koja će jednom dnevno pokrenuti proveru.

Praćenje isteka ugovora zaposlenih ne završava se datumom u profilu zaposlenog.

Ako se rok proverava svakog dana, sistem mora da razlikuje ponovljenu potvrdu istog uslova od nastanka novog poslovnog događaja.

Zato sprečavanje duplih upozorenja nije email pravilo. To je deo domenskog modela: važeći zapis, identitet događaja, lifecycle, odgovornost i isporuka moraju imati jasno definisane granice.

Tek tada dnevna automatizacija ne proizvodi novi „događaj“ svaki put kada vidi istu poslovnu činjenicu.

I upravo tu obična evidencija datuma postaje operativni sistem za upravljanje HR rokovima.

---

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