Human Resource Information Systems

Chapter 3
HR Processes, Requirements and Data Modeling

Bachelors Program in Human Resource Management
Human Resource Information Systems   •   Bachelor

HR Processes, Requirements and Data Modeling

Introduction

Human Resource Information Systems (HRIS) create value only when technology reflects how work is actually performed. An HRIS is not simply a database or an electronic filing cabinet. It is an organizational information system that connects people, policies, processes, data, controls, and technology. Poorly understood HR processes produce poorly designed systems: approvals are unclear, data are duplicated, responsibilities overlap, and reports cannot be trusted.

This chapter explains how HR professionals analyze processes, translate organizational needs into system requirements, model employee-related data, document workflows, and establish data governance. The central principle is that HRIS design should begin with business purpose and process evidence, not with a software feature list.

Learning Objectives

By the end of this chapter, you should be able to:

  1. Map major HR processes and identify process owners, activities, inputs, outputs, controls, and performance measures.
  2. Distinguish functional requirements from non-functional requirements.
  3. Model employee data using entities, attributes, relationships, identifiers, and business rules.
  4. Represent HR workflows, approvals, exceptions, and segregation of duties.
  5. Establish data definitions, ownership, quality standards, and master-data principles.
  6. Evaluate ethical, legal, operational, and implementation risks in HRIS design.

1. HRIS as a Process and Information System

An HRIS supports the acquisition, maintenance, use, protection, and disposal of information about workers and work. Typical capabilities include recruitment, onboarding, organizational management, time and attendance, payroll interfaces, learning, performance management, compensation, absence management, reporting, and employee self-service.

These capabilities are interdependent. A change in organizational structure affects reporting lines, approval routing, security access, workforce analytics, and sometimes payroll. A change in an employee's employment status may affect benefits, leave eligibility, access rights, and statutory reporting. Consequently, HRIS analysis must consider the entire process landscape rather than isolated modules.

A process is a structured set of related activities that transforms inputs into outputs for a customer or stakeholder. In HR, the customer may be an employee, manager, candidate, payroll team, regulator, or senior executive. Processes can be:

  • Core HR processes: maintaining worker and organizational records.
  • Talent processes: recruiting, onboarding, learning, performance, succession, and career development.
  • Workforce administration: time, attendance, leave, scheduling, and benefits.
  • Compliance and reporting: statutory returns, audit evidence, policy monitoring, and workforce reporting.
  • Support processes: HR service requests, document management, case management, and data correction.

A process view prevents a common design error: automating an inefficient process without first questioning its purpose, sequence, controls, and evidence requirements.

2. Mapping HR Processes

2.1 Process hierarchy

A useful process hierarchy moves from broad to specific:

LevelDescriptionHR example
Process domainMajor area of organizational workTalent acquisition
End-to-end processComplete outcome-oriented flowRecruit-to-hire
SubprocessDistinct stageScreen applicants
ActivityWork performed by a role or systemVerify qualification
TaskSpecific actionEnter qualification evidence

The end-to-end perspective is especially important. For example, recruitment does not end when a candidate accepts an offer. Information may need to flow into a person record, position assignment, payroll interface, identity management system, and onboarding workflow.

2.2 Process mapping methods

Several techniques are useful:

  • SIPOC: identifies Suppliers, Inputs, Process, Outputs, and Customers. It is suitable for establishing scope.
  • Swimlane maps: place activities in lanes for roles, departments, or systems. They reveal handoffs and accountability.
  • BPMN-style modeling: uses events, activities, gateways, and message flows to represent sequence, decisions, and exceptions.
  • Value-stream analysis: examines waiting time, rework, duplication, and activities that do not contribute to the desired outcome.
  • Service blueprints: connect employee-facing interactions with backstage HR and system activities.

A process map should show the current state before the desired future state is designed. Current-state mapping exposes informal workarounds, spreadsheets, email approvals, undocumented decisions, and duplicate data entry.

2.3 Process mapping procedure

A disciplined mapping exercise normally follows these steps:

  1. Define the process boundary, trigger, outcome, and customers.
  2. Identify participants, systems, policies, documents, and data stores.
  3. Record activities in actual sequence, including parallel activities.
  4. Identify decisions, approval points, exceptions, and rework loops.
  5. Mark inputs, outputs, handoffs, and control evidence.
  6. Validate the map with people who perform the work, not only managers.
  7. Measure delays, error rates, workload, and service performance.
  8. Design the future state and identify requirements.

2.4 Example: employee address change

A simple address-change process may involve an employee submitting a request, the system validating mandatory fields, HR reviewing supporting evidence where required, updating the authoritative record, sending an acknowledgement, and transmitting the change to dependent systems. The map should answer: Who may initiate the change? Is approval required? What evidence is acceptable? Which address types exist? When does the change become effective? How are previous values retained? Which systems receive the update?

The process is not adequately modeled by the sentence “employee updates address.” That description omits controls, data definitions, exceptions, and downstream consequences.

3. From Stakeholder Needs to Requirements

A requirement is a documented, testable statement of a needed capability, condition, or constraint. Requirements should be traceable to a stakeholder need, process problem, policy, risk, or legal obligation.

3.1 Stakeholder analysis

HRIS stakeholders include employees, candidates, line managers, HR specialists, payroll personnel, finance, information technology, data-protection officers, auditors, executives, regulators, and software suppliers. They may have conflicting priorities. Employees may want convenience, HR may require control, managers may want rapid approvals, and privacy officers may require data minimization.

Stakeholder interviews should be supplemented by observation, document review, workshops, system logs, policy analysis, and data-quality profiling. Asking only what users want often reproduces existing assumptions. Better questions include:

  • What event starts the process?
  • What decision must be made?
  • What information is required at that decision?
  • What can go wrong?
  • Who is accountable for correction?
  • What evidence must be retained?
  • What happens when the normal path fails?

3.2 Functional requirements

Functional requirements describe what the HRIS must do. Examples include:

  • create a worker record after approved hiring;
  • route a leave request to the appropriate manager;
  • prevent approval by an unauthorized role;
  • calculate entitlement according to configured policy rules;
  • maintain effective dates for organizational assignments;
  • produce a headcount report by legal entity and department;
  • record an audit event when sensitive data are changed;
  • exchange approved worker data with payroll.

A strong requirement identifies an actor, action, object, condition, and expected result. For example: “When an employee submits a leave request, the system shall validate required dates, calculate the requested duration according to the assigned work schedule, and route the request to the employee’s current manager.”

3.3 Non-functional requirements

Non-functional requirements define qualities and constraints rather than business functions. Important categories include:

CategoryHRIS concernExample requirement
SecurityConfidentiality and accessSensitive compensation data shall be limited by role and organizational scope.
PrivacyLawful and proportionate processingThe system shall collect only data necessary for stated HR purposes.
AvailabilityService continuityEmployee self-service shall be available during defined service hours.
PerformanceResponse and processing timeStandard employee searches shall return within the agreed service target under normal load.
UsabilityEase and accessibilityCommon transactions shall be understandable to users with varied digital ability.
InteroperabilityExchange with other systemsApproved worker changes shall be transmitted using an agreed interface format.
MaintainabilityConfiguration and supportPolicy changes shall be configurable without rewriting core software where feasible.
AuditabilityEvidence and traceabilityChanges to sensitive fields shall record actor, timestamp, old value, and new value.
ScalabilityGrowthThe system shall support forecast workforce and transaction volumes.

Non-functional requirements should be measurable wherever possible. “The system must be fast” is weak; a defined response target, workload, and measurement method is stronger. Requirements must also distinguish mandatory constraints from preferences.

3.4 Prioritization and traceability

Requirements can be prioritized using categories such as mandatory, important, useful, and deferred. A traceability matrix links each requirement to its source, process, design component, test case, and acceptance decision. Traceability is particularly valuable when requirements arise from employment law, collective agreements, financial controls, or privacy obligations.

A requirement is testable when an independent reviewer can determine whether it has been met. Acceptance criteria might specify valid and invalid inputs, authorization rules, expected notifications, audit evidence, and treatment of exceptions.

4. Employee Data Modeling

4.1 Data modeling concepts

A data model describes the structure, meaning, and relationships of data. Common concepts include:

  • Entity: a distinguishable object about which information is stored, such as Person, Position, Assignment, or Leave Request.
  • Attribute: a property of an entity, such as date of birth or employment status.
  • Relationship: an association between entities.
  • Identifier: an attribute or combination that uniquely identifies a record.
  • Cardinality: the number of records that may participate in a relationship.
  • Constraint: a rule restricting permitted data or relationships.
  • Reference data: controlled values used to classify records, such as country or employment status.
  • Transaction data: records of events, such as a promotion or leave request.
  • Master data: relatively stable, shared data used across processes, such as person, organization, position, and location.

An important design distinction is between a person and an employment relationship. One person may have multiple assignments, contracts, or periods of employment. If the design assumes one person equals one job, it may fail for concurrent employment, rehire, secondment, contingent work, or international transfers.

4.2 Conceptual HR data model

A conceptual model might contain the following entities:

EntityPurposeTypical relationships
PersonRepresents an individualMay have one or more worker or candidate roles
WorkerRepresents a person engaged by the organizationBelongs to one or more assignments over time
Employment AssignmentDefines employment terms and organizational placementLinks worker, position, department, manager, and legal entity
PositionDefines an organizational role or authorized postMay be occupied by one or more workers over time, subject to policy
Organization UnitRepresents department or business structureHas parent-child relationships
LocationDefines work location or jurisdictionMay affect policy, taxation, and reporting
JobDescribes occupational content or job familyMay be associated with multiple positions
Compensation RecordStores pay-related termsBelongs to an assignment and has effective dates
Leave RequestRecords a request and decisionBelongs to a worker and leave type
DocumentStores or references evidenceHas owner, classification, retention, and access rules

A simplified relationship statement is: one Person may have many Employment Assignments; each Assignment refers to one Position at a given effective period; each Position belongs to one Organization Unit; an Organization Unit may contain many Positions. Actual designs vary by organizational and legal context.

4.3 Keys, normalization, and history

A primary key uniquely identifies a record within an entity. A foreign key references another entity. Natural identifiers, such as national identification numbers, may be unsuitable as system keys because they can be sensitive, unavailable, duplicated across jurisdictions, or changed under exceptional circumstances. A stable internal identifier is often preferable, with carefully governed external identifiers stored separately.

Normalization reduces unnecessary duplication and update anomalies. For example, storing a department name repeatedly in every employee row makes corrections difficult. A separate Organization Unit entity can store the department once, while assignments reference it. However, reporting systems may deliberately use denormalized structures for performance or analytical convenience. The choice should be explicit and controlled.

HR data are temporal. A current value alone cannot answer historical questions such as “Who was the employee’s manager on 1 March?” Effective dating commonly uses start and end dates or a start date plus a rule for the next record. Temporal rules must address overlapping records, gaps, future changes, corrections, and retroactive events.

4.4 Business rules

Business rules translate policy into enforceable data and process conditions. Examples include:

  • an assignment must reference an active legal entity;
  • an end date cannot precede a start date;
  • a worker cannot have two primary assignments overlapping unless policy permits it;
  • a leave request must use an active leave type;
  • a manager approval must be performed by an authorized person;
  • a terminated worker may have restricted self-service access but must remain available for retention and reporting obligations.

Rules should distinguish validation from approval. A valid request may still be rejected by an authorized decision-maker. Likewise, a technically possible action may be prohibited by policy.

5. Workflow and Control Modeling

A workflow specifies how work moves among people and systems. It includes a trigger, states, transitions, actors, conditions, notifications, deadlines, and exception paths.

For example, a promotion workflow may begin with a manager proposal, proceed to HR validation and budget review, require one or more approvals, create an effective-dated compensation and assignment change, notify relevant parties, and transmit the approved result to payroll. A workflow model should show what happens when an approver is absent, a budget is rejected, required evidence is missing, or the effective date is retrospective.

5.1 Controls and segregation of duties

Controls reduce the risk of error, fraud, unauthorized disclosure, and non-compliance. Preventive controls block invalid actions; detective controls identify problems after occurrence; corrective controls restore accurate conditions.

Segregation of duties is particularly important for sensitive HR transactions. For example, the person who enters a compensation change should not automatically be the sole person who approves it and releases it to payroll. Access should follow least privilege: users receive only the permissions needed for their responsibilities.

Role-based access is useful, but HR data often require additional restrictions by legal entity, country, department, worker population, or field. A manager may see direct-report information but not unrelated compensation data. Highly sensitive fields may require attribute-level controls, masking, encryption, or separate storage.

6. Data Definitions, Ownership, and Quality

6.1 Data dictionary

A data dictionary gives each important data element a shared meaning. A useful entry includes:

ElementDefinitionFormatPermitted valuesOwnerQuality rule
Worker identifierUnique internal identifier for a workerAlphanumericUnique, non-reusedHR data ownerPresent for every active worker
Employment statusCurrent status of an employment relationshipCoded valueActive, leave, suspended, terminatedHR policy ownerMust have effective date
Organization unitApproved structural unit to which an assignment belongsReference codeActive organization codesOrganization ownerMust exist in master list
Manager identifierAuthorized manager for an assignmentWorker identifierActive eligible workerHR operationsMust satisfy reporting rule

Definitions should avoid vague terms. “Employee number” may mean payroll number, badge number, or internal worker ID. The organization must specify which identifier is intended, where it is generated, and whether it can change.

6.2 Ownership and stewardship

Ownership is accountability for meaning, policy, access, and acceptable use. Stewardship is operational responsibility for maintaining accuracy, resolving defects, and applying standards. IT may operate the database, but HR or the relevant business function normally owns the meaning of employment data.

A responsibility matrix can assign roles such as:

  • Data owner: approves definitions, access principles, and quality thresholds.
  • Data steward: manages daily standards, correction queues, and issue resolution.
  • Process owner: accountable for end-to-end process performance.
  • System owner: accountable for technical operation and controls.
  • Data subject: the person to whom personal data relate.
  • Custodian: administers storage, backup, and technical safeguards.

6.3 Data-quality dimensions

Common quality dimensions are accuracy, completeness, consistency, timeliness, validity, uniqueness, and integrity. A quality measure should specify a population, rule, calculation, and review period. For example, a completeness rate can be expressed as:

Completeness rate = (records with a non-missing required value ÷ records expected to have that value) × 100%

The numerator counts records satisfying the rule; the denominator is the relevant population. The measure is meaningful only when “required,” “missing,” and the population are defined. A field may be complete but inaccurate, so completeness alone does not establish overall quality.

Data profiling can identify duplicate workers, invalid organization codes, impossible dates, orphaned assignments, inconsistent status values, and records lacking owners. Quality improvement should address root causes, such as unclear definitions or poorly designed forms, rather than relying only on periodic cleansing.

7. Master-Data Principles

Master data are shared reference objects used across multiple processes and systems. In HR, common master domains include person, worker, organization, position, job, location, legal entity, and employment status.

Effective master-data management requires:

  1. A system of record: a designated authoritative source for each data domain.
  2. A single meaning: common definitions across HR, payroll, finance, and analytics.
  3. Controlled identifiers: stable, unique, and governed codes.
  4. Lifecycle management: creation, approval, change, suspension, archival, and retirement.
  5. Effective dating: history and future changes where business needs require them.
  6. Synchronization rules: defined interfaces, frequency, direction, and error handling.
  7. Ownership: accountable business owners and operational stewards.
  8. Quality monitoring: thresholds, dashboards, issue queues, and escalation.

“Single source of truth” does not necessarily mean one physical database. It means that a recognized authoritative source exists for a particular meaning and that other systems consume or reconcile data according to explicit rules. A payroll system may be authoritative for paid results while the HRIS is authoritative for approved employment assignments.

8. Implementation, Integration, and Change

Requirements and models must be translated into configuration, interfaces, migration rules, security roles, reports, and test scenarios. Data migration is not merely a technical extraction and loading exercise. It requires mapping old values to approved definitions, identifying duplicates, validating historical records, assigning ownership, and deciding what should not be migrated.

Integration designs should specify source, target, data elements, transformation rules, timing, error handling, reconciliation, and security. Interfaces may be batch, event-based, or application programming interface driven. Regardless of method, the organization needs monitoring and a clear process for rejected or duplicated messages.

Testing should include unit, integration, security, usability, performance, migration, regression, and user acceptance testing. Test cases should reflect normal and exceptional HR events, including rehire, transfer, retroactive correction, overlapping assignments, manager absence, termination, and changes in legal entity.

Change management is essential because HRIS implementation changes authority, work habits, and accountability. Training should explain not only which buttons to press but why data definitions, approvals, and quality rules matter.

9. Ethical, Legal, and Governance Issues

HRIS processes personal and often sensitive information. Ethical design requires respect for privacy, fairness, transparency, proportionality, and human dignity. Relevant legal obligations vary by jurisdiction but commonly concern lawful processing, purpose limitation, data minimization, accuracy, retention, access rights, security, cross-border transfer, and breach response.

Important governance questions include:

  • Is the data collection necessary for a defined purpose?
  • Who can access it, and why?
  • Are employees informed in understandable language?
  • How are corrections and disputes handled?
  • How long should records be retained?
  • Are automated recommendations explainable and reviewable?
  • Could a data field or rule produce discriminatory effects?

Artificial intelligence may assist with classification, workforce analytics, candidate matching, or service routing, but it does not remove accountability. HR professionals should examine training data, proxy discrimination, explainability, human review, security, and the consequences of error. Automated outputs should not be treated as objective merely because they are statistical.

10. Illustrative Case: Northstar Services HRIS Renewal

Background

Northstar Services, a fictional organization with 2,400 employees in three countries, uses separate spreadsheets for organization structures, email for approvals, and a legacy HR system for basic employee records. Payroll is outsourced. Managers report that headcount reports differ among HR, finance, and payroll.

Problem

An internal review finds duplicate worker records, inconsistent department names, missing manager assignments, and late notification of transfers. Employees submit address and bank changes through several channels. No common data dictionary exists, and access to spreadsheets is broader than necessary.

Analysis

A project team maps the hire-to-pay, transfer, leave, and employee-data-change processes. Swimlanes reveal that the same worker information is entered by HR, payroll, and IT. Interviews show that “active employee” has different meanings in the three functions. The team identifies the HRIS as the authoritative source for approved employment assignments, while payroll remains authoritative for payroll payment results.

Approach

The team establishes a Person entity separate from Employment Assignment, creates controlled organization and employment-status reference data, and introduces effective dates. A manager submits a transfer request; HR validates the position and legal entity; finance confirms budget where required; an authorized approver approves; the HRIS records the assignment change; and an integration sends the approved result to payroll and identity management.

A data dictionary defines each field, its owner, permitted values, and quality rule. A role matrix limits managers to appropriate populations. Sensitive changes require audit logging and, where appropriate, secondary approval. Data cleansing is performed before migration, and rejected interface messages are monitored daily.

Outcome

After implementation, reports use common organization codes, transfer changes have visible effective dates, and HR can identify the owner of data defects. The organization does not eliminate all errors, but it reduces duplicate entry and makes errors detectable and assignable.

Learning points

  1. Process mapping exposed the causes of inconsistent reporting.
  2. Data ownership was a governance decision, not merely a software setting.
  3. Separating Person from Employment Assignment supported multiple employment situations.
  4. Effective dating preserved historical and future organizational information.
  5. A system of record must be defined by data meaning and accountability.

Challenges and Limitations

HRIS models cannot represent every organizational nuance without becoming excessively complex. Policies may be ambiguous, local laws may conflict with global standards, and organizational structures may change faster than system governance. Overly rigid workflows can encourage workarounds, while overly flexible configuration can weaken control. Data-quality measures can also create false confidence when definitions are incomplete or when quality is measured only at field level.

Organizations should therefore review models periodically, involve diverse users, document assumptions, test exceptional cases, and distinguish system limitations from policy choices. A well-designed HRIS supports professional judgment; it does not replace it.

Best-Practice Checklist

  • Begin with outcomes and end-to-end processes.
  • Map current and future states separately.
  • Make requirements specific, testable, and traceable.
  • Separate person, worker, assignment, position, and organization concepts where appropriate.
  • Use stable identifiers and controlled reference data.
  • Apply effective dating to information that changes over time.
  • Assign business ownership and operational stewardship.
  • Define quality dimensions and measurable rules.
  • Design authorization, audit, privacy, retention, and segregation-of-duties controls early.
  • Treat integration, migration, testing, and change management as part of HRIS design.
  • Govern AI-supported HR decisions through transparency, human oversight, and bias assessment.

Chapter Summary

HRIS design begins with an accurate understanding of HR processes. Process maps identify actors, activities, handoffs, decisions, inputs, outputs, exceptions, and controls. Functional requirements state what the system must do, while non-functional requirements specify qualities such as security, privacy, performance, usability, auditability, and interoperability. Both types must be measurable and traceable.

Data modeling provides a shared representation of people, workers, assignments, positions, organizations, transactions, and documents. Separating Person from Employment Assignment and using identifiers, relationships, constraints, and effective dates improves accuracy and historical analysis. Workflow modeling clarifies responsibilities, approvals, exceptions, and segregation of duties.

Data governance gives information consistent meaning and accountability. Data dictionaries, ownership, stewardship, quality standards, systems of record, controlled reference data, and lifecycle management are essential master-data principles. Ethical and legal design requires privacy, proportionality, security, transparency, and human oversight, especially when AI is used. The professional HRIS practitioner therefore combines process analysis, requirements engineering, data management, governance, and organizational judgment.

Key Terms

Business rule: A policy or operational condition that governs data or process behavior.

Cardinality: The permitted number of records participating in a relationship.

Data dictionary: A controlled description of data elements, meanings, formats, owners, and quality rules.

Data owner: The person or function accountable for the meaning, use, and governance of a data domain.

Data steward: The role responsible for operational data maintenance and quality management.

Entity: A distinguishable object about which information is stored.

Effective dating: Recording when a data value or relationship becomes and ceases to apply.

Functional requirement: A statement of what an information system must do.

Master data: Shared, relatively stable data used across multiple processes and systems.

Non-functional requirement: A quality, constraint, or performance condition imposed on a system.

Normalization: Structuring data to reduce unnecessary duplication and update anomalies.

Process map: A visual or textual representation of activities, roles, decisions, and flows.

Reference data: Controlled values used to classify or validate records.

Segregation of duties: Distribution of responsibilities to reduce unauthorized or fraudulent activity.

System of record: The authoritative source for a defined data meaning or domain.

Traceability: The ability to connect a requirement to its source, design, test, and acceptance evidence.

Workflow: A defined sequence of activities, decisions, actors, and transitions.

Data quality: The degree to which data are fit for intended use, including accuracy, completeness, validity, and timeliness.

Review Questions

Short Answer Questions

  1. What is the difference between a functional and a non-functional requirement?
  2. Why should Person and Employment Assignment often be modeled as separate entities?
  3. What information should a data dictionary entry contain?
  4. Define a system of record in the context of HRIS.
  5. Why is effective dating important in HR data modeling?

Long Answer Questions

  1. Explain how an HR team can map a current-state process and transform the findings into an improved future-state workflow.
  2. Discuss the role of data owners and data stewards in maintaining HRIS data quality.
  3. Compare SIPOC, swimlane mapping, and value-stream analysis as HR process-analysis techniques.
  4. Explain how normalization, identifiers, relationships, and constraints contribute to a reliable employee data model.
  5. Discuss the ethical and governance requirements for using AI in HR information systems.

Analytical / Application Questions

  1. An organization stores department names directly in every employee record. Analyze the likely data-quality problems and propose a revised model.
  2. A manager can submit, approve, and transmit a compensation change to payroll without review. Identify the control weaknesses and design a safer workflow.
  3. HR, finance, and payroll report different headcounts because each uses a different definition of “active employee.” Design a requirements and governance approach to resolve the disagreement.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a functional requirement in an HRIS?

A. The system shall encrypt sensitive data at rest.

B. The system shall route an approved leave request to the employee’s manager.

C. The system shall be available during specified service hours.

D. The system shall support future workforce growth.

Correct Answer: B. The system shall route an approved leave request to the employee’s manager.

Question 2

What is the principal purpose of a data dictionary?

A. To replace all system testing

B. To provide shared definitions and quality rules for data elements

C. To authorize every employee transaction

D. To calculate payroll automatically

Correct Answer: B. To provide shared definitions and quality rules for data elements

Question 3

Why is Person commonly modeled separately from Employment Assignment?

A. A person may have multiple assignments or employment periods

B. Assignments never require dates

C. Person records are always public

D. It eliminates the need for identifiers

Correct Answer: A. A person may have multiple assignments or employment periods

Question 4

Which control most directly supports segregation of duties?

A. Allowing one user to enter and release a compensation change

B. Allowing every manager to view all employee records

C. Requiring independent approval before a compensation change is sent to payroll

D. Removing audit logs to improve performance

Correct Answer: C. Requiring independent approval before a compensation change is sent to payroll

Question 5

Which is an example of master data?

A. A single employee’s submitted leave request

B. An approved organization-unit code used across HR and finance

C. A temporary system error message

D. A one-time password reset

Correct Answer: B. An approved organization-unit code used across HR and finance

Question 6

If 960 of 1,000 expected records contain a required value, what is the completeness rate?

A. 9.6%

B. 40%

C. 96%

D. 99.6%

Correct Answer: C. 96%

Question 7

What does effective dating enable an HRIS to represent?

A. Only the current value of a field

B. Historical and future validity of changing values

C. Unlimited access to confidential data

D. Automatic elimination of duplicate people

Correct Answer: B. Historical and future validity of changing values

Question 8

Which role is primarily accountable for operationally resolving data-quality issues?

A. Data steward

B. Candidate

C. External auditor only

D. Unauthorised system user

Correct Answer: A. Data steward

Question 9

Which process-mapping method most clearly shows activities assigned to different roles or systems?

A. Swimlane mapping

B. A password policy

C. A retention schedule

D. A data dictionary

Correct Answer: A. Swimlane mapping

Question 10

Which principle is most relevant when an HRIS collects only information necessary for a defined purpose?

A. Data minimization

B. Denormalization

C. Unlimited retention

D. Unrestricted access

Correct Answer: A. Data minimization

Human Resource Information Systems
Chapter 3 of 14