Suport de seminar
© 2026 Sorin Burlacu
© 2026 Academia de Studii Economice București
Departamentul de Administrație și Management Public
Facultatea de Administrație și Management Public
Toate drepturile rezervate. Niciun fragment al acestei lucrări nu poate fi reprodus sau transmis sub orice formă fără permisiunea scrisă a autorului, cu excepția citatelor scurte folosite în recenzii și articole academice.
Lucrarea reprezintă suport didactic pentru disciplina Sisteme digitale pentru resursele umane (cod 25.0253IF3.2-0004), parte din programul de licență Resurse umane (an 3, sem. 2), ASE București.
ISBN 978-606-XXX-XXX-X
Tipărită în format digital · Anul universitar 2025–2026
amp.ase.ro/sdru/carte
Studenților în resurse umane
care înțeleg că instrumentele digitale
nu înlocuiesc judecata profesională
și că alegerile bune ale unei firme
preced întotdeauna sistemul ei bun.
Trei părți, opt capitole — un drum complet de la oameni la sisteme.
„Un sistem informatic de resurse umane nu este o cutie cu funcționalități — este traducerea în cod a felului în care firma își înțelege oamenii."
Termenul SIRU (Sistem Informatic de Resurse Umane), echivalent al e-HR (electronic Human Resources), desemnează familia de aplicații și fluxuri digitale care suportă procesele de gestiune a personalului — de la recrutare și încadrare, prin pontaj, salarizare și evaluare, până la dezvoltarea carierei și separarea profesională. Pentru o firmă privată mică-medie din 2026, un SIRU funcțional este o presupunere de bază — fără el, profesia de specialist RU nu mai este exersabilă la scară.
Distincția față de instrumentele de productivitate generală (Excel, e-mail, drive partajat) este esențială. Un SIRU autentic are single source of truth pentru fiecare informație despre angajat, audit trail pentru fiecare modificare, control de acces granular și capacitate de raportare structurată. Cinci Excel-uri partajate, oricât de bine întreținute, nu sunt un SIRU — sunt o problemă de migrare.
Istoria digitalizării RU se citește în trei valuri suprapuse. Generația întâi (anii 1990–2005) — sisteme client-server izolate, instalate local, axate pe salarizare și evidență. Generația a doua (2005–2018) — web-based, modular, cu introducerea autoservirii angajatului (employee self-service) și a integrării cu sisteme externe. Generația a treia (din 2018) — cloud-native, mobile-first, integrată cu CRM, ERP, platforme de învățare și instrumente analitice; aici intervin și componentele de inteligență artificială pentru screening de CV-uri, predicția fluctuației și recomandări de dezvoltare.
Un SIRU integrat conține, în mod tipic, șapte module funcționale legate prin date comune: evidența personalului (contracte, dosare, vechime), pontaj și concedii, salarizare, recrutare și onboarding, evaluare și performanță, formare și dezvoltare, raportare și analiză. La acestea se adaugă tot mai des un modul de experiență angajat (Employee Experience), care urmărește satisfacția, NPS-ul intern și semnalele timpurii de plecare.
Echilibrul dintre integrare profundă (toate modulele în aceeași aplicație) și integrare prin API (module specializate care comunică) este una dintre alegerile arhitecturale fundamentale. Soluțiile monolitice (cum sunt suitele SAP SuccessFactors sau Workday) oferă consistență; soluțiile best-of-breed (un sistem dedicat pentru recrutare, altul pentru învățare, altul pentru evidență) oferă flexibilitate, dar cer disciplina integrării.
Orice SIRU folosit în România, indiferent că e produs local sau internațional, trebuie să se conformeze cu: Codul muncii (Legea 53/2003), REVISAL (HG 905/2017 pentru sectorul public, HG 500/2011 pentru restul), legislația de protecție a datelor (GDPR + Legea 190/2018), și — pentru firmele care lucrează cu fonduri europene sau publice — un set de cerințe suplimentare de raportare.
Această conformitate locală este una dintre cauzele principale pentru care suitele globale au întotdeauna un strat de „localizare" românească: calculul de salariu cu sporurile și impozitele specifice, integrarea cu Declarația 112 ANAF, formatul fișei de pontaj, particularitățile concediilor de odihnă și ale concediilor medicale.
Înțelegerea celor trei generații te ajută să citești corect ce primești pe piață. O firmă care propune astăzi o soluție „client-server cu instalare locală" propune o tehnologie de acum 25 de ani. O firmă care propune „cloud-only fără export de date" propune un vendor lock-in costisitor. Calibrarea profesională a opțiunilor cere context istoric — altfel, fiecare furnizor pare egal de credibil.
„Modelul de date este harta firmei. Câmpurile pe care le definești spun, peste cinci ani, ce te-ai gândit că merită urmărit despre oameni."
O bază de date pentru un sistem de resurse umane este, înainte de a fi un produs tehnic, o decizie organizațională. Câmpurile pe care le definești — și mai ales cele pe care nu le definești — configurează ce poate firma să întrebe ulterior despre oamenii ei. Un SIRU fără câmp pentru „motivul plecării" nu va putea răspunde niciodată întrebării „de ce pierdem talente"; unul fără câmp pentru „salariul așteptat la angajare" nu va putea evalua niciodată precizia ofertelor inițiale.
Cele mai multe SIRU contemporane folosesc baze de date relaționale (PostgreSQL, MySQL, SQL Server) — structurate în tabele, cu relații explicite între entități. Modelul relațional are virtutea esențială că integritatea referențială (un contract trebuie să aibă un angajat valid, o evaluare trebuie să aibă un evaluator valid) este garantată la nivelul bazei de date, nu lăsată pe seama codului aplicației.
Modelul tipic include: persoană (angajat, candidat, fost angajat), contract, departament, funcție/post, evenimente de carieră (angajare, promovare, transfer, plecare), perioade de absență, tranzacții de salarizare, evaluări, certificări/formări. Relațiile dintre acestea — cardinalitatea (unu-la-mulți, mulți-la-mulți), opționalitatea (obligatoriu vs. opțional) — constituie scheletul modelului.
Principiul normalizării (în special forma normală a treia — 3FN) cere ca fiecare informație să fie stocată într-un singur loc. Salariul actual al unui angajat este în tabelul de contracte sau în tabelul de plăți — nu în ambele. Numărul de telefon este în tabelul de date personale — nu și pe fișa de pontaj. Această disciplină pare excesivă până când, peste 18 luni, descoperi că ai 4 surse care „știu" salariul aceluiași om și niciuna nu e de acord cu celelalte.
Excepțiile de la normalizare se numesc denormalizări controlate și se fac pentru performanță, dar întotdeauna documentate: „salariul anterior se păstrează și pe linia de salariu, ca să nu trebuiască să recompunem istoria la fiecare raport — recalculul autoritativ rămâne din contracte".
O distincție utilă pentru raportare: datele dimensionale descriu „cine, unde, ce" — angajatul, departamentul, funcția; datele tranzacționale descriu „ce s-a întâmplat" — o promovare la o dată, o plată cu o sumă, o evaluare cu un scor. Dashboard-urile bune separă cele două.
Orice modificare a unei date despre o persoană (schimbare de salariu, modificare de funcție, ștergerea unui contract) trebuie să producă o intrare într-un audit log: cine a modificat, când, de la ce valoare la ce valoare, sub ce justificare. Aceasta nu este paranoia administrativă — este apărarea ta în orice procedură cu ITM, ANSPDCP sau în orice litigiu de muncă.
Audit log-ul are o regulă esențială: append-only. Nu se modifică niciodată retroactiv. Dacă cineva încearcă să-l modifice, sistemul trebuie să detecteze și să raporteze. Implementarea poate fi simplă (tabel separat cu trigger pe modificări) sau sofisticată (blockchain intern, semnătură criptografică), dar principiul rămâne.
Bazele NoSQL (MongoDB, Cassandra) sunt utile pentru cazuri specifice — log-uri de aplicație, date semi-structurate, scale extrem de mare. Pentru un sistem central de evidență RU al unei firme cu sub 5.000 de angajați, modelul relațional rămâne, în 2026, alegerea profesional defensabilă. Tentația „să folosim NoSQL pentru că e modern" este eroarea clasică de cargo cult: tehnologia bună pentru altcineva nu este automat tehnologia bună pentru tine.
„Granița dintre RU, CRM și ERP nu este desenată de natura proceselor — este desenată de software-ul pe care firma a ales să-l cumpere prima dată."
Două categorii majore de sisteme integrate ating frecvent zona resurselor umane — CRM (Customer Relationship Management) și ERP (Enterprise Resource Planning). În forma lor pură, CRM-ul gestionează relația cu clienții, iar ERP-ul integrează contabilitatea, financiarul, lanțul de aprovizionare și producția. În practică, ambele dezvoltă module care fie ating RU, fie pretind că o pot înlocui.
Înțelegerea acestei suprapuneri este crucială pentru orice specialist RU care va trebui, în carieră, să negocieze granițele de responsabilitate între departamentul de RU, cel de vânzări, cel financiar și cel de IT. Un specialist RU care nu știe ce face Salesforce sau ce face SAP S/4HANA va lua decizii proaste în comitetul de selecție de softuri.
În agențiile de recrutare, granița dintre „candidat" și „client" se șterge. Sistemele CRM (Salesforce, HubSpot, Bullhorn) gestionează ambele relații — companii-client care plasează cereri și candidați care caută posturi. Funcționalitățile esențiale: pipeline-uri (etape ale procesului), tagging și segmentare, comunicări multi-canal (e-mail, SMS, LinkedIn), istoric complet al interacțiunilor.
ERP-urile mari (SAP S/4HANA, Oracle ERP Cloud, Microsoft Dynamics 365) includ aproape întotdeauna un modul de HCM (Human Capital Management). Avantajul: integrarea cu contabilitatea este nativă — salariile, contribuțiile, costurile de personal trec automat în registrele contabile. Dezavantajul: modulele HCM ale ERP-urilor mari sunt frecvent mai puțin sofisticate decât suitele specializate (SAP SuccessFactors, Workday, Personio), tocmai pentru că HCM nu este focusul principal al ERP-ului.
Pentru o firmă cu 50–500 de angajați, decizia tipică este: ERP cu HCM integrat dacă procesele financiare domină și RU este relativ simplu, sau specialist HRIS separat, integrat cu ERP-ul prin API dacă procesele de RU sunt sofisticate (recrutare la volum, evaluări complexe, formare structurată).
Promisiunea „toate sistemele vorbesc între ele" este aproape întotdeauna mai dificilă decât pare. Câmpuri cu același nume au înțelesuri diferite în CRM vs. ERP vs. HRIS. Datele de referință (departamente, funcții) trebuie sincronizate sau acceptate ca având surse de adevăr diferite. Calendarele de export-import devin proiecte în sine.
Un CRM enterprise (Salesforce) pornește de la 80–150 EUR/utilizator/lună pentru o configurație serioasă. Un HRIS cloud comercial (Personio, BambooHR) pornește de la 6–12 EUR/angajat/lună. Un ERP enterprise (SAP S/4HANA) începe la 200.000–500.000 EUR/an pentru o filială medie, plus implementare comparabilă. Soluțiile open-source (SuiteCRM, OrangeHRM, Odoo) au licență zero, dar implementare și mentenanță reală — bugetul nu dispare, doar se mută în „salarii de consultanți" și „rebrand-uri ale costului".
Regula empirică pentru o firmă privată mică-medie românească din 2026: costul total al sistemului pe 5 ani tinde să fie de 8–15× costul licenței anuale, după ce adaugi implementare, customizare, formare, integrări, mentenanță și migrări.
Marele vis al integratorilor este „un singur sistem care face și CRM, și ERP, și HRIS". Există — Microsoft Dynamics 365, Oracle Fusion. Realitatea: în firmele care le adoptă, fiecare modul rămâne moderat de competitiv, niciunul nu e excelent, iar costul total este comparabil cu trei sisteme separate de top.
„Cloud-ul nu este un loc — este un model contractual. Open source-ul nu este gratuit — este alt fel de a plăti."
Două dintre cele mai supraestimate cuvinte din vocabularul IT contemporan sunt „cloud" și „open source". Ambele sunt utile, ambele au limite, și ambele sunt frecvent prezentate ca panacee de către integratori care au interes să le promoveze. Specialistul RU din 2026 trebuie să poată distinge între promisiune și realitate — pentru că deciziile de a folosi sau nu cloud, de a alege open-source sau comercial, configurează costuri și riscuri pe orizont de 5–10 ani.
Trei niveluri de abstractizare definesc piața cloud. SaaS (Software as a Service) — folosești aplicația, furnizorul gestionează totul: Personio, Salesforce, Workday. PaaS (Platform as a Service) — îți dezvolți aplicația proprie pe o platformă: Heroku, Azure App Service. IaaS (Infrastructure as a Service) — închiriezi servere virtuale, restul faci tu: AWS EC2, Azure VMs.
Pentru o firmă privată care vrea SIRU, alegerea tipică este SaaS — costuri predictibile, întreținere zero, scalare automată. Pentru un proiect open-source self-hosted, te muți la IaaS (cu un OrangeHRM pe un EC2) sau on-premise (pe serverul firmei). PaaS este nișa intermediarului între dezvoltatori serioși.
Cloud public: serverele sunt împărtășite între mulți clienți (AWS, Azure, GCP). Cost mic, scalabilitate mare, control limitat. Cloud privat: infrastructura este dedicată unei singure organizații (poate fi tot la AWS, dar izolată). Cost mai mare, control mai bun. Hibrid: combinație — datele sensibile pe cloud privat, restul pe public.
Pentru date de personal din UE, regiunea fizică a cloud-ului contează: regiunile UE (Frankfurt, Dublin, Amsterdam, Paris) sunt acceptabile fără complicații suplimentare; regiunile non-UE necesită clauze contractuale standard (SCC) și posibil DPIA dedicat. Câțiva furnizori — OVHcloud, Hetzner, Scaleway — sunt 100% UE și uneori se aleg din considerente de suveranitate digitală.
Trei platforme open-source dominante în 2026: OrangeHRM (PHP/MySQL, foarte popular în firme mici-medii), iceHRM (PHP, simplu și ușor de configurat), Odoo HR (Python, parte a unui ERP complet). Toate trei au și versiuni comerciale cu funcții suplimentare („open core" model).
„Open source-ul este gratuit" este adevărat doar pentru licență. Costul real al unei implementări open-source într-o firmă cu 200 de angajați include: hosting (200–500 EUR/lună pentru o instanță decentă), implementare inițială (15.000–40.000 EUR pentru configurare, migrare date, customizări), mentenanță anuală (6.000–18.000 EUR pentru un consultant care răspunde la probleme și aplică update-uri), integrări (variabil, dar nu sub 5.000 EUR per sistem integrat). Total 5 ani: 60.000–150.000 EUR.
Aceeași firmă pe SaaS comercial: 6 EUR/angajat/lună × 200 × 60 luni = 72.000 EUR. Diferența nu este în costul total, ci în previzibilitatea lui și în cine poartă riscurile.
Open-source-ul are sens când firma are competențe IT interne reale, când customizările specifice sunt esențiale și când suveranitatea datelor este o prioritate strategică. Open-source-ul nu are sens când singurul argument este „să economisim pe licență" — economia se evaporă la prima problemă urgentă fără suport.
„Un sistem informatic prost proiectat costă mai mult decât unul scump cumpărat — pentru că la prost proiectat plătești de două ori: o dată ca să-l construiești, a doua oară ca să-l înlocuiești."
Proiectarea unui SIRU pentru o firmă privată mică-medie este actul profesional cel mai semnificativ pe care îl va întâlni un consultant junior IT-HR în primii săi ani de carieră. Decizii luate în primele patru săptămâni — arhitectură, model de date, plan de implementare, criterii de succes — configurează cinci ani de funcționare. Refacerea lor ulterioară este de zece ori mai scumpă decât gândirea atentă la început.
Literatura academică distinge cinci etape: diagnoza (cum este astăzi), analiza cerințelor (cum trebuie să devină), proiectarea (arhitectură, model de date, fluxuri), implementarea (configurare, migrare, formare), operarea și mentenanța. Fiecare etapă produce livrabile documentate, iar trecerea la următoarea fără închiderea celei anterioare este sursa principală de eșec.
În practica firmelor mici-medii, aceste etape se comprimă: o diagnoză exhaustivă de două luni nu este realistă pentru o firmă de 80 de oameni. Versiunea pragmatică: diagnoză focalizată în 1–2 săptămâni, cerințe documentate în 1 săptămână, proiectare aprobată în 2 săptămâni, implementare în 8–16 săptămâni. Operarea și mentenanța sunt continui.
(1) Single source of truth — fiecare informație are exact un loc autoritativ. (2) Audit trail complet — orice modificare este logată, niciodată ștearsă retroactiv. (3) Control de acces granular — nu „toată lumea vede tot, sau nimeni nu vede nimic", ci permisiuni pe categorii de date și pe operațiuni. (4) Export structurat — datele firmei pot fi exportate într-un format folosibil oricând, fără ajutorul furnizorului. Acest ultim principiu este cel mai des sacrificat — și cel mai costisitor când lipsește.
Cel mai important moment al unei implementări nu este lansarea — este săptămâna de paralel run, în care sistemul nou rulează simultan cu cel vechi (Excel, sistem anterior) pe aceleași date. Discrepanțele descoperite în această săptămână previn catastrofele post-cutover. Sărirea peste paralel run pentru a economisi două săptămâni este eroarea care produce 80% din implementările eșuate.
Un proiect SIRU fără criterii de succes măsurabile este garantat să se termine în dispute despre „ce era inclus". Criteriile SMART (Specific, Measurable, Achievable, Relevant, Time-bound) protejează ambele părți. Exemple bune: „90% din contracte digitalizate cu zero erori în luna 1 post-cutover", „timpul mediu de generare a unui stat de salariu scade de la 4 zile la 1 zi în luna 3", „rata erorilor de pontaj scade sub 0,5% în luna 6".
Criterii proaste: „sistemul funcționează", „angajații sunt mulțumiți", „avem rapoarte mai bune". Acestea se interpretează diferit de fiecare parte și conduc la conflicte la final.
Proiectarea tehnică este 40% din succesul SIRU; restul de 60% este organizațional: sponsor real în conducere (nu doar nominal), responsabili de fluxuri identificați pe partea de business, buget pentru formarea utilizatorilor (de regulă 15–20% din costul proiectului), plan de schimb organizațional care anticipează rezistența. Niciun sistem bine proiectat nu rezistă unei organizații care nu vrea să se schimbe.
„Intranetul de resurse umane este oglinda firmei. Ce găsesc oamenii acolo le spune ce înseamnă, pentru voi, să fii angajat."
Un sistem de management de conținut (CMS — Content Management System) este aplicația care permite unei firme să publice, organizeze și controleze conținutul digital — pagini, documente, anunțuri, ghiduri, formulare — fără ca fiecare modificare să necesite intervenția unui programator. În contextul resurselor umane, CMS-ul este, tipic, baza intranet-ului firmei: ghidul angajatului, manualele de procedură, anunțurile interne, documentele de onboarding, formularele pentru solicitări.
O firmă cu 200 de angajați produce, în mod tipic, peste 400 de documente interne pe an: politici noi, anunțuri, ghiduri, FAQ-uri, formulare. Fără un CMS, aceste documente trăiesc pe shared drives haotice, în atașamente de e-mail nesigure, sau pe SharePoint-uri abandonate. Cu un CMS bine configurat, fiecare document are: versiune, autor identificabil, data ultimei revizii, permisiuni de acces, istoric de modificări, posibilitate de căutare.
Pentru RU specific, CMS-ul este și locul unde se publică politici care produc obligații — politica de confidențialitate internă, regulamentul de ordine interioară, procedura de raportare a abuzurilor. Aceste documente au valoare juridică doar dacă pot fi dovedite ca publicate și accesate la un moment dat.
CMS-uri open-source generale — WordPress, Drupal, Joomla. Foarte populare, comunitate largă, multe teme și plugin-uri. Costuri reduse pentru configurare de bază, dar securitatea cere disciplină (actualizări frecvente). CMS-uri orientate enterprise — SharePoint (Microsoft 365), Confluence (Atlassian), Notion. Integrare nativă cu ecosistemele Microsoft/Google. CMS-uri specializate pe intranet — Happeo, Simpplr, Workvivo. Funcționalități țintite (anunțuri, comunități, sondaje interne).
Pentru o firmă privată mică-medie, alegerea tipică în 2026 este: SharePoint dacă deja folosesc Microsoft 365 (costul marginal este zero), Confluence dacă au cultură tech sau folosesc deja produse Atlassian, WordPress dacă vor flexibilitate maximă cu costuri minime, sau Happeo/Simpplr dacă vor un intranet „out of the box" cu funcții moderne.
Punctul cheie al integrării este single sign-on (SSO): angajatul se autentifică o singură dată și accesează atât SIRU-ul, cât și intranet-ul, fără să reintroducă credențiale. Tehnic, asta se face prin SAML 2.0 sau OAuth 2.0/OIDC. Lipsa SSO produce frecvent „shadow IT" — oameni care își notează parolele în Excel, ceea ce este precis ce nu vrei.
Nu toate documentele de RU sunt publice intern. Anunțul de bonusuri trimestriale este pentru toți. Manualul de evaluare confidențială pentru manageri este doar pentru manageri. Politica salarială detaliată este doar pentru conducere și echipa de RU. CMS-ul trebuie să suporte permisiuni granulare — pe document, pe folder, pe categorie de utilizatori — și să aplice corect aceste permisiuni la căutare (un document invizibil nu trebuie să apară nici în rezultatele de căutare).
Un test rapid pentru orice CMS: încarcă un document marcat „confidential — managers only", autentifică-te cu un cont de angajat de bază, caută cuvinte-cheie din document. Dacă apare în rezultate, sistemul nu este sigur — indiferent ce promite documentația.
Conținutul intranet-ului are ciclu de viață: creare, revizuire (de regulă peer-review), publicare, actualizare periodică, arhivare. Documente care nu sunt revizuite cel puțin anual devin toxice — angajații le citesc, presupun că sunt în vigoare, iar realitatea poate fi alta. O regulă simplă și defensabilă: orice document de politică internă afișează data ultimei revizii, iar dacă trec >18 luni de la revizie, sistemul îl marchează automat „necesită actualizare".
„Cel mai sigur sistem informatic este cel pe care nimeni nu-l folosește. Cel folosit are întotdeauna riscuri — iar gestiunea lor responsabilă este profesia mea."
Datele de personal sunt printre cele mai sensibile categorii pe care le procesează o firmă: nume complete, CNP-uri, salarii, evaluări psihometrice, motive de plecare, certificate medicale, contracte cu clauze de neconcurență. Un incident de securitate la nivelul SIRU produce daune pe mai multe dimensiuni simultan: juridică (sancțiuni GDPR până la 4% din cifra de afaceri), reputațională (pierderea încrederii candidaților, retenție afectată), operațională (timpul echipei de management blocat în managementul incidentului), personală (pentru cei afectați — risc de fraudă, șantaj, hărțuire).
Securitatea informației se gândește pe trei dimensiuni: confidențialitatea (datele sunt văzute doar de cine trebuie), integritatea (datele nu sunt modificate neautorizat), disponibilitatea (datele sunt accesibile când este nevoie). Cele trei sunt frecvent în tensiune — un sistem perfect confidențial este inutil dacă nu poate fi accesat când este nevoie; un sistem perfect disponibil este vulnerabil dacă lipsește confidențialitatea.
(1) Multi-factor authentication (MFA) pe toate conturile cu acces la date personale — fără excepții, fără „mai târziu". (2) Procedura de offboarding cu checklist obligatoriu: cont dezactivat în 24h, accesele revocate, datele backupate. (3) Patching la zi — actualizările de securitate aplicate în max. 30 zile de la publicare; pentru vulnerabilități critice, 7 zile. (4) Backup-uri verificate — nu doar existente, ci testate periodic prin restore real. (5) Logging și monitoring — log-urile colectate central, alerte configurate pentru evenimente suspecte (autentificări atipice, descărcări masive de date, modificări de privilegii).
Fiecare angajat trebuie să aibă exact accesul necesar pentru job, niciodată mai mult. Un specialist de recrutare nu are nevoie de acces la salariile întregii firme. Un contabil nu are nevoie de acces la evaluările psihometrice ale candidaților. Periodic (la minim 6 luni), accesele se revizuiesc — o practică numită access recertification. Conturile de serviciu (folosite de aplicații sau de administratori care au plecat) sunt sursa principală de incidente — inventarul lor exhaustiv este obligatoriu.
Sub GDPR (art. 33), orice incident de securitate care implică date personale trebuie notificat autorității de supraveghere (ANSPDCP în România) în maxim 72 de ore de la momentul cunoașterii. Termenul curge de la cunoaștere, nu de la confirmare completă — notificările parțiale cu informații completate ulterior sunt acceptate; notificările cu întârziere justificată prin „voiam să fim siguri" nu sunt.
Sub art. 34 GDPR, dacă incidentul prezintă risc înalt pentru drepturile persoanelor vizate, ele trebuie notificate direct, fără întârzieri nejustificate. Stratificarea comunicării după gradul real de impact (cei mai expuși primesc notificare personalizată, ceilalți primesc notificare informativă, plus anunț public final) este buna practică europeană.
Dacă incidentul se materializează, probele digitale (log-uri, copii ale sistemului afectat) trebuie să mențină un lanț de probe (chain of custody) care permite folosirea lor în orice procedură ulterioară. Asta înseamnă: nu modifici nimic pe sistemul afectat, chemi forensics extern cu chain of custody documentat, înregistrezi fiecare acces la probe. „M-am uitat puțin singur în log-uri" la 23:00 noaptea poate fi suficient ca să compromită probele.
„Datele despre oameni sunt o încredințare, nu un activ. Fiecare câmp pe care îl colectezi este o promisiune că vei face cu el doar ce ai spus."
Capitolul final închide suportul de seminar cu trei teme care, deși par eterogene, sunt legate prin firul comun al responsabilității — față de oamenii ai căror date le prelucrezi, față de cadrul juridic care guvernează această prelucrare, și față de mediul natural pe care infrastructura digitală îl afectează material. Toate trei sunt teme pe care specialistul RU contemporan nu și le mai poate permite să le delege.
Conformitatea juridică (GDPR) este podeaua eticii, nu tavanul. „Am respectat ce cere legea" nu este același lucru cu „am acționat etic". Etic înseamnă: minimizare reală (colectezi doar ce ai nevoie, nu tot ce ai putea), transparență dincolo de obligatorie (oamenii știu ce faci cu datele lor, nu doar formal printr-un text de 12 pagini), scop limitat (datele colectate pentru recrutare nu se folosesc pentru cercetări de marketing intern), recunoașterea greșelilor când apar, în loc de transfer de vină pe angajați individuali.
GDPR-ul oferă persoanelor vizate (angajați, candidați, foști angajați) un set de drepturi esențiale, care se aplică inclusiv în relația cu SIRU-ul firmei. Dreptul de acces (art. 15) — orice persoană poate cere o copie a datelor pe care firma le deține despre ea. Dreptul de rectificare (art. 16) — corectarea datelor inexacte. Dreptul de ștergere (art. 17, „dreptul de a fi uitat") — în anumite condiții, datele trebuie șterse. Dreptul de portabilitate (art. 20) — exportul datelor într-un format folosibil. Dreptul de a obiecta (art. 21) la prelucrări specifice. Drepturi legate de decizia automatizată (art. 22) — niciun candidat nu poate fi respins exclusiv de un algoritm fără posibilitatea unui review uman.
Un SIRU profesional are aceste drepturi implementate ca funcționalități, nu ca proceduri manuale: butonul „exportă-mi datele" pentru angajat, butonul „șterge contul candidatului" pentru recrutor, log-ul de modificări vizibil persoanei vizate la cerere.
Infrastructura digitală nu este „dematerializată" — este materializată altundeva. Un SIRU SaaS pe AWS rulează pe servere fizice consumatoare de energie și apă (pentru răcire); un SIRU on-premise rulează pe un server în firmă, cu același tip de consum. La nivel global, IT-ul consumă în jur de 4–5% din electricitatea mondială și produce 2–4% din emisiile de CO₂ — comparabil cu industria aviației.
Pentru o firmă privată mică-medie din 2026, deciziile de SIRU care au impact real asupra mediului sunt: alegerea unei regiuni cloud cu energie predominant regenerabilă (multe regiuni europene se aliniază tot mai mult cu acest standard), politica de retenție a datelor (datele păstrate fără rost ocupă spațiu de stocare cu impact energetic), frecvența backupurilor și retenția lor (un backup zilnic pentru date care se schimbă rar este risipă; unul pentru date critice este necesar), e-mail-urile cu atașamente mari care se înmulțesc viral.
Capitolul închide acest suport de seminar cu o observație necesară: tehnologia se schimbă rapid, dar principiile rămân. Drepturile angajaților, transparența procedurilor, răspunderea profesională a specialistului de RU și grija pentru impactul deciziilor — toate acestea nu depind de instrumente. Depind de oameni. SIRU-ul este, în 2026 și mai departe, mijloc, nu scop.
Termeni tehnici și juridici uzuali în sistemele digitale pentru resursele umane
Surse academice, cadru legal aplicabil și webografie esențială
Lista completă a surselor și webografia extinsă sunt disponibile în fișa oficială a disciplinei, accesibilă pe platforma instituțională.
„Sistemul informatic de resurse umane nu este o opțiune tehnică — este coloana vertebrală a unei profesii care, în 2026, lucrează cu date, fluxuri și decizii cuantificabile. De la oameni, la sisteme."
Sorin Burlacu