'/%3E%3C/svg%3E){kind=small}
'/%3E%3C/svg%3E){kind=small}
Početna / Studija slučaja / Praćenje isteka ugovora zaposlenih
Od HR evidencije do proaktivne kontrole rokova
Kako je CoreLayer projektovao i implementirao OWMS modul za ugovore, sanitarne knjižice, uloge, događaje, audit i pravovremena obaveštenja.
Industrija: Maloprodaja
Rešenje:OWMS modul za HR evidenciju i kontrolu rokova
Obim: Mreža sa više od 20 prodajnih objekata
Fokus: Ugovori, sanitarne knjižice, odgovornost, obaveštenja i audit
Datum isteka ugovora izgleda kao jednostavan podatak.
Ali kada zaposleni rade u više objekata, a različite uloge imaju različite odgovornosti, taj datum mora da odgovori na mnogo više pitanja:
- koji je ugovor trenutno važeći;
- ko sme da promeni podatak;
- kada sistem treba da reaguje;
- ko treba da dobije obaveštenje;
- kako se sprečava dupliranje upozorenja;
- šta se dešava kada je ugovor produžen;
- šta se dešava kada zaposleni promeni objekat ili postane neaktivan;
- kako ostaje dokaz o promeni i isporuci.
Zato praćenje isteka ugovora zaposlenih nije samo problem podsetnika. To je problem podataka, poslovnih pravila, odgovornosti i pouzdane sistemske obrade.
Poslovni kontekst
Za maloprodajnu organizaciju sa distribuiranim zaposlenima projektovan je i implementiran OWMS modul koji povezuje četiri oblasti:
- tip radnog angažovanja i ugovore na određeno;
- referentnu evidenciju radnog staža;
- važenje i istoriju sanitarnih knjižica;
- automatsko prepoznavanje rokova i ciljano obaveštavanje.
Centralne uloge imaju širi pregled zaposlenih. Menadžer prodajnog objekta radi samo sa zaposlenima iz objekata kojima upravlja. Sistem zato ne može da koristi samo korisničku rolu. Mora da razume i organizacionu pripadnost zaposlenog i domet odgovornosti prijavljenog korisnika.
Ključni izazovi
Jedan važeći podatak i proverljiva istorija
Za automatsku obradu mora da postoji jedan aktivni datum isteka ugovora i jedna važeća overa sanitarne knjižice.
Prethodne vrednosti ne treba brisati. One ostaju deo istorije ili audit traga, ali više ne smeju da pokreću nova upozorenja.
Dnevna provera bez dupliranih upozorenja
Ako se ugovor proverava svakog dana, isti zapis može više dana zaredom da bude unutar perioda za upozorenje.
Bez idempotency pravila sistem bi svakog dana kreirao novi događaj i novo obaveštenje.
Implementirano rešenje zato dozvoljava najviše jedan aktivan događaj za istog zaposlenog, isti tip događaja i isti relevantni datum.
Različite uloge i različit domet podataka
HR i finansijske uloge obrađuju ugovorne podatke na centralnom nivou. Lokalni menadžer unosi podatke o sanitarnoj knjižici samo za zaposlene iz svojih objekata.
Isto pravilo važi i za obaveštenja: centralne uloge dobijaju širi pregled, dok lokalni primalac dobija samo događaje iz svog organizacionog domena.
Promena poslovnog konteksta
Novi datum ugovora čini prethodni događaj zastarelim. Nova overa menja važeći sanitarni rok. Promena objekta menja lokalnog primaoca. Deaktivacija zaposlenog prekida dalju obradu.
Ove situacije nisu izuzeci van sistema. One su deo normalnog poslovnog životnog ciklusa i moraju biti projektovane unapred.
CoreLayer pristup
Od korisničke priče do tehničke odluke
Poslovna potreba je prvo razložena na korisničke priče i use case-ove. Zatim su definisani testabilni funkcionalni zahtevi, zajednički rečnik, konceptualni domain model i Business Event Model.
Tek nakon zaključavanja poslovnih pravila projektovani su, a zatim implementirani moduli, agregati, application servisi, API granice, model podataka i background obrada.
Dokumentovani traceability lanac obuhvata:
- 11 korisničkih priča;
- 8 use case-ova;
- 123 funkcionalna zahteva;
- 9 ključnih pojmova u rečniku zahteva;
- 16 konceptualnih domen pojmova;
- 17 business invarianti;
- 7 automatskih poslovnih događaja.
Brojevi pokazuju dubinu i sledljivost analize i solution design-a. Sve sposobnosti opisane u dizajnu implementirane su u produkciji i koriste se u svakodnevnom radu klijenta.
Događaj kao osnova proaktivne kontrole
Sistem ne šalje obaveštenje samo zato što postoji datum.
Pozadinska obrada proverava da li je zaposleni aktivan, da li postoji važeći zapis i da li je datum u definisanom vremenskom prozoru.
Kada su uslovi ispunjeni, nastaje poslovni događaj. Tek tada sistem određuje primaoce i pokreće aplikativni i email kanal.
Reuse postojećeg OWMS sistema
Novi modul je implementiran kao proširenje postojećeg OWMS-a.
Postojeći zaposleni, prodajni objekti, korisnički identiteti, uloge, notifikacije, email infrastruktura i audit ostaju zajedničke sistemske osnove.
Dodaju se samo podaci i ponašanja specifični za radni angažman, ugovore, radni staž, sanitarne knjižice i događaje isteka.
To smanjuje rizik paralelnih izvora istine i nepotrebnog prepisivanja već postojećih sposobnosti.
Implementirane sposobnosti
|
Oblast |
Implementirana sposobnost |
|---|---|
|
Radni angažman |
Kontrolisan izbor tipa angažovanja i aktivnog ugovornog podatka |
|
Ugovori |
Dnevna evaluacija rokova i događaj kada ugovor uđe u definisan period |
|
Sanitarne knjižice |
Važeća overa, istorija i rano upozorenje |
|
Organizacija |
Centralni i lokalni domet prema ulozi i nadležnom objektu |
|
Notifikacije |
Aplikativni i email kanal sa statusom isporuke |
|
Integritet |
Deduplikacija, invalidacija i promena primaoca |
|
Sledljivost |
Audit korisničkih promena, obrada i isporuka |
|
Operacije |
Monitoring statusa pozadinskih poslova i događaja |
Šta je rešenje promenilo
Implementirano rešenje uvodi zajednički sistemski jezik za važeći podatak, događaj, odgovornost, primaoca, kanal i status obrade.
Razvojni tim je dobio jasne granice modula i implementacioni redosled. Poslovni tim koristi proverljivu vezu između poslovnog podatka, pravila, događaja, odgovornosti i obaveštenja.
Najvažnija promena nije novi ekran. To je prelazak sa pasivne evidencije datuma na model u kome rok pokreće kontrolisan i sledljiv operativni tok.
Važna granica ove studije
Ova studija prikazuje zahtevni, domenski, sistemski i detaljni dizajn, kao i produkcionu implementaciju rešenja koje se koristi svakodnevno.
Produkcijska implementacija i svakodnevna upotreba jesu potvrđene. Studija ne navodi neizmerene rezultate kao što su procenat uštede vremena, smanjenje grešaka, stopa isporuke ili finansijski efekat.
Takve kvantifikovane tvrdnje zahtevaju početne i završne pokazatelje ili potvrđene metrike klijenta.
Ključne lekcije
1. Datum nije kontrola dok nema važeće stanje, odgovornost i posledicu.
2. Organizacioni domet mora biti deo autorizacije, a ne naknadni filter.
3. Periodični poslovi moraju biti idempotentni kako upozorenje ne bi postalo spam.
4. Promena zaposlenog, ugovora ili objekta mora da promeni i otvorene događaje ili primaoce.
5. Audit, poslovna istorija, događaj i kanal isporuke nisu isti zapis i ne treba ih mešati.
6.Dobro projektovano proširenje koristi postojeće sistemske sposobnosti umesto paralelnog rewrite-a.
Zaključak
Praćenje isteka ugovora zaposlenih postaje pouzdano tek kada sistem poveže HR podatak, poslovno pravilo, organizacionu odgovornost, događaj, obaveštenje i audit trag.
CoreLayer je za OWMS definisao i implementirao takav model. Rešenje radi u produkciji i deo je svakodnevnog rada klijenta.
Projekat
Praćenje isteka ugovora zaposlenih
CoreLayer Solutions
Gradimo sisteme koji povezuju podatke, procese i odluke u realnom poslovnom okruženju.
Adresa
Bratstva i jedinstva 30, 14210 Ub
Telefon
+381601349282
upiti@corelayersolutions.org