HR Process Digitalisation: A Complete Guide to People-Centric HR, HRMS, Automation and AI

1. What it means to digitalise HR processes

Digitalising HR processes means changing the way an activity passes between people: from a paper form or an Excel sheet to a flow with roles, statuses and data that other processes can reuse. Dematerialisation, digitalisation, automation and transformation are four related but distinct operations. They answer different questions, and confusing them leads to buying a tool for a problem that is organisational.

The distinction that follows is partly a working interpretation. Sources use these terms in partially overlapping ways and none defines automation in contrast to the other concepts: the separation between the four is the one we need in order to decide, not a standard.

Digitalisation, dematerialisation and automation

Wikipedia distinguishes digitisation, that is, the conversion of an analogue medium into a digital one (a scan), from digitalisation, the use of digital tools to improve a process, and from digital transformation, a broader strategic change. In Italian the first part of the scale has a name of its own: dematerialisation (dematerializzazione), which in the strict sense is the creation of a document in digital format in place of the paper one and, in the legal sense, the process in which acts and documents are formed, managed and preserved solely with IT tools, retaining validity for the parties and for third parties. Automation is the step missing from those definitions: a step of the process starts by itself when a condition occurs.

What digital transformation really changes

For Wikipedia, digital transformation is the adoption of digital technologies to launch or reshape products, services and operations, moving processes into digital form in search of value, innovation, experience and efficiency. In an HR office, when the leave request moves from an email to the manager into a flow, someone has to decide who approves if the manager is absent, which balance is authoritative, and what the colleague in the department sees. These are organisational decisions, which the software requires before launch: a project that postpones them faces them on the day the system goes into production.

Why replacing Excel is not enough

Replacing Excel with a program that reproduces the same screen, rows and columns included, moves the problem without solving it. Take a payroll office that receives twenty files from the sites, each with the columns in a different order: if the twenty files become twenty entries in a portal but each site keeps its own way of recording absences, the reconciliation work stays exactly the same. Excel is fine as long as there is one person who knows it and a single file that is authoritative. It stops working when the files are many, the data is duplicated and nobody can say who changed what.

The test we use is simple to check: after digitalisation, the same employee data must be entered only once and read by several processes, with a data owner and a trail of changes. If that does not happen, the process has stayed the way it was. A closer look at the move from paper to digital process is in the News item on how to digitalise HR processes.

What People-Centric HR means

EcosAgile uses as its working definition the one given in the webinar People-centric HR processes (in Italian), at minute 00:08: “processes whose central actor is the company's people and their data”. Two practical consequences follow. The first concerns design: you start from what the employee, the manager and HR must do, know or approve at each moment of the employment relationship, and only afterwards choose the tool. The second concerns data: if attendance, leave, projects, skills and organisation each read their own copy of the employee record, the overall view breaks apart, as the same webinar observes. The section People-Centric HR goes into detail on self-service, mobile and communication.

2. Which HR processes are worth digitalising

It is not worth digitalising everything at once. You start with the activities that repeat often, pass through many hands, produce costly errors or directly affect people's lives, and you link them straight away to the common employee record. The other processes follow, one at a time, on the same data. Priority is decided with a few explicit criteria, written down before discussing individual cases.

The table below is an EcosAgile working model, not a published standard. Each process receives a qualitative rating on four criteria: how often it repeats, how easy it is to make mistakes, how much it weighs on people if it goes wrong, and how much it costs to digitalise (effort). The intersection indicates the moment to start.

Example with fictitious data: a company of 300 people across three sites, with payroll outsourced to an external firm. Employee records are not the most visible process, but they end up in the first wave together with attendance and absences because every other process reads them. Expense reports start early if reimbursements still travel on paper. Talent waits, because an evaluation built on incomplete data mostly produces arguments about the data.

Two caveats on using the matrix. The ratings should be given together with the people who live the process every day (the payroll clerk, the site manager), because error risk is known from the errors that have already happened and cannot be guessed from a desk. And a process with high impact and high effort should not be discarded: it should be broken down. For onboarding, you can digitalise first just the step of the documents to be signed, leaving the rest for later.

Employee records and personnel data

This is the process that seems uninteresting and that determines the quality of all the others: who updates the address, where the contract is kept, which system is authoritative for the place of work. Pay transparency is the concrete case in which HR data (categories, levels, salaries) and payroll data must give the same numbers: the guide on integrating HR and payroll data for pay transparency covers it. To measure the work to be done, one test is enough: take five employees at random and compare the same fields in all the systems and files where they appear. The differences that emerge are the list of problems. The design of the shared employee record is in From fragmented processes to an integrated HR platform.

Onboarding and offboarding

They involve HR, the manager, IT and whoever manages company assets, in a sequence that must start when the person's status changes. The risk lies in the forgotten step, such as the account that stays active after the last working day. The flow is covered in Digital onboarding and workflow.

Attendance, leave and absences

These are the processes with the most events per day and the most immediate impact: an error in absences reaches the payslip and the employee sees it straight away. The detail is in the guide on digitalising attendance, working hours and absences.

Recruiting, talent and learning

They have less volume and more sensitivity. If artificial intelligence comes in, Regulation (EU) 2024/1689 (the AI Act) classifies as high-risk systems those used for hiring and selection and those used to evaluate performance and behaviour (Annex III, point 4): terms and obligations are in AI in HR processes. For recruiting there is the webinar recruiting and AI in personnel selection (in Italian); for evaluation and development, the webinar talent, evaluation and development (in Italian).

Expenses, business trips and company assets

They have precise tax rules and supporting documents to collect: the difficult part lies outside the software, in the rules to apply to each reimbursement. They are covered in the guide on digitalising expense reports and business trips. Assets assigned to people (phones, cars, equipment) follow the same pattern and link to onboarding and offboarding.

Documents, signature and preservation

Here the question concerns the legal value of the signature and the archive where the document ends up. The rules on electronic signature and preservation change and must be read in up-to-date sources: the reference is the webinar eIDAS 2, digital signature and preservation for HR (in Italian). The webinar Digitalisation of HR processes (in Italian) (recorded in 2024, 41 minutes) covers simple and advanced electronic signature, online payslips and document preservation.

Organisation, workforce and communication

The org chart, headcount planning and internal communications live on up-to-date data: if the employee record is correct, they are almost a by-product. The method is in the guide on org charts and workforce planning.

3. From fragmented processes to an integrated HR platform

An integrated HR platform prevents each process from living in a silo: employee record, roles, workflow and controls are shared, and data entered once serves several processes. You do not need a single piece of software covering every function to have one: you need carefully designed points of contact between the tools and, for each piece of data, one authoritative system with an owner.

HR suites and vertical software

Vertical applications arise from specific needs and often cannot be avoided: the webinar People-centric HR processes (in Italian) observes this, and also notes how the choice often falls on the maximum requirements of the single area, to the detriment of the process view. Our position, explained below: for processes that share employee data (employee record, attendance, absences, expenses, documents) a modular suite is preferable; vertical software is justified for a highly specialised process that the suite does not reach, provided it reads the employee record from the suite and does not keep its own.

The risk of the suite is checked with a test before purchase: you bring the oddest case the company really has (the split shift, the company that pays differently from the others) and have it run. The risk of the vertical product is checked by asking how the employee record arrives and where the data returns.

Single source of truth and employee record data

Single source of truth means that each piece of data has one place where it originates and is modified, and that the other systems read it instead of keeping a copy. For HR data this is the employee record. The webinar cited above shows it with capacity planning and staffing, which require project data, leave, time, costs, roles and skills in the same place.

Example with fictitious data: an employee changes site and manager from the first of the month. If all the processes read the same employee record, the change is made once and from there follow the absence calendar of the new team, the approver of expense reports, the position in the org chart, the change letter to be signed and the file for payroll. With five separate tools there are five changes, made by five people, and one may be forgotten until the next payslip.

A single data set requires visibility rules: Article 25 of the GDPR requires data protection by design and by default, that is, only the necessary data. The same employee record shows the manager the data of their team and the payroll office the data that payroll needs; access profiles are decided before the project (see Security, privacy and governance).

Workflow and automations

A workflow is the sequence of steps of a process, with the roles that carry them out and the statuses passed through: request, approval, recording, notification to the person concerned. Automation steps in on the simple-rule steps: the reminder to whoever has not approved, the handover to the deputy if the manager is absent, the update of the balance. Before automating it is better to simplify: approvals that nobody can justify are removed first, because automation would only make them faster.

Modularity and progressiveness

According to the webinar on people-centric processes, integration can also be reached gradually: you start with a few priorities, without one big change all at once. We share the idea, with one condition. Progressiveness works if some choices are made immediately and for all future modules: which module creates the employee record, which fields are mandatory, what sites, companies and cost centres are called, how people are identified. Otherwise you end up with three modules with three different lists of sites. These are choices to make before activating the first module (see the roadmap).

Integration with payroll, ERP and existing systems

Payroll is not replaced: the HR platform passes to the payroll software of the company, or of the firm that processes it, the data it needs (attendance, absences, changes to employee records) from structured files or APIs. The same applies to ERP, identity management and applications already in use: they are connected. What passes, in which direction, how often and who is accountable if a file arrives wrong is decided beforehand. The topic has a section of its own: Cloud HR, integrations and architecture. For the distinction between system levels see HRIS, HRMS and HCM: differences and when you need them.

4. People-Centric HR: designing around people

Designing HR around people means starting from who uses the process: the employee who asks, the manager who decides, the HR person who handles exceptions. For each process you establish what each person does alone, what they see, when they are notified and where they access it from, from joining to leaving. The HR office stops being the compulsory step for every request and takes care of the rules and of the cases that the rules do not cover.

The employee's and the manager's point of view

Many HR processes were born on the administration side: the payroll office needs a piece of data, so people are asked to fill in a form. Reversing the order means asking three questions. What should the employee be able to do, and from which device? What should the manager decide, and with what information in front of them? What is left for HR? The tool that supports this division is self-service: ESS (employee self-service) for the employee, MSS (manager self-service) for the manager. ESS lets employees view and update their own data, such as contact details and bank details, and handle routine tasks (leave requests, overtime, timesheets, expense reports) without going through HR.

A debatable position: if you have to choose where to put the most design care, put it on the manager. The employee makes a request every now and then; the manager handles many, between one meeting and the next. An awkward approval gets postponed, and a stalled request signals that self-service has shifted the work instead of removing it.

Requests and approvals

Before configuring a flow, four rules are written down: who approves (normally the direct manager, in some cases the project manager), who approves when the manager is absent, that nobody approves their own requests, and where the requester sees the status of the case.

Example with fictitious data: Marta asks for five days of leave in August. By email she writes to Luca, her manager, who replies after two days and forwards the go-ahead to HR, who updates the leave sheet: three steps, none visible to Marta. With a digital flow Luca approves from his phone and the status is visible to both without HR having to step in.

Notifications: few, with an action inside

A notification exists to make someone do something: approve, complete, read. If every event generates an alert, managers learn to ignore them. An alert that leads to the case to be closed works better, with a periodic summary for the rest. A personal document, such as the payslip, should not travel as an attachment: it is better to send an alert that points to the secure area, where you can see who opened it.

A single point of access

Employees should not have to know which system hosts which process. They find leave, payslips, expense reports, training and communications in the same place, with the same credentials from the computer and from the phone. Behind the scenes there may be more than one system, as long as the person does not have to know. A single point of access does, however, concentrate personal data, and what each person sees is part of the project. The GDPR requires data limited to what is necessary (Article 5(1)(c)) and protection by default (Article 25). Profiles and visibility are decided by role before launch, not after the first mistake.

The employee life cycle

The thread that holds the processes together is the life cycle of the employment relationship. Each phase has its own requests and actors, and the same personal data runs through all of them.

Insight from the expert: in the webinar People-centric HR processes (in Italian) (recorded in 2024, 22 minutes) the EcosAgile speaker presents, at minute 12:42, a case close to this section: a leave request must also involve in the flow the managers of the projects the person works on, and the same data must not be entered twice, once for payroll and once for projects. This is the position of the EcosAgile speaker, not a standard.

In EcosAgile: the Employee Self Service area is where employees manage their own profile and submit absence requests, from the web or from the app. The manager approves them from the Manager Self Service area, one at a time or in bulk; during their own absences they can name a substitute approver, and with the Project&Timesheet module the request is copied to the project managers. Notifications go through the portal, the ePeople app and email. The eTime, eWork and eExpense apps cover clock-ins, project activities and expense reports with a photo of the receipt. The available functions depend on authorisation profiles and on the contract.

5. HRIS, HRMS and HCM: differences and when you need them

HRIS, HRMS and HCM are acronyms that sources and vendors use in overlapping ways. To choose, you need to look at what the system must cover, in three levels: data and employee records, operational management of processes, development of human capital. The three acronyms can serve as labels for the three levels, as long as you know this is a working convention and you check the real coverage, not the name.

The Wikipedia page on the human resource management system presents HRMS, HRIS and HCM as alternative names for a category of software that integrates several systems for personnel data and processes. The page on human capital management refers to the entry on human resource management, where HCM is sometimes used as a synonym for HR and human capital is usually understood in a narrower sense, as people's knowledge; it does not say how HCM relates to HRIS. The three acronyms therefore overlap in use, with no shared definition separating them. The three levels are an EcosAgile working model, useful for asking vendors questions, not a standard.

What an HRIS is

According to the entry on human resource management, HRIS are systems that store HR data in electronic form, make it quickly retrievable and centralise it, so that it can also be analysed across several sites. An HRIS is enough when the problem is putting the data in order and requests are few. On its own it does not govern flows: without workflow it remains a well-kept archive.

What an HRMS is

The HRMS adds process management: requests, approvals, calendars, documents, data handovers to payroll. The same Wikipedia page includes employee self-service, which lets employees view and update their own data and handle routine tasks such as leave requests, attendance or expense reports, without going through HR. It is needed when processes involve managers and employees and email is no longer enough to keep track of who approved what. Level 2 uses the data of level 1 and does not create it: it only works if the employee record is in order.

What an HCM is

HCM is the least stable acronym. In the working interpretation we reserve it for the level that concerns skills, evaluation and development of people and headcount planning. A vendor that presents itself as HCM may not have those modules: ask where they are and what data they work on. For evaluation and development there is the webinar talent, evaluation and development (in Italian).

Complete suite or specialist modules

The level to start from depends on the state of the data. With employee records scattered across files and systems, you start from the first level and the most frequent processes of the second; the third comes later, because evaluating and planning on incomplete data gives debatable results. The comparison between suites and vertical software is in From fragmented processes to an integrated HR platform; the link between the org chart and the HRIS is in the News item org chart and HRIS integration (in Italian).

How to avoid organisational lock-in

Organisational lock-in exists when leaving a system costs more than staying, because the data cannot be taken away or because only one person knows how it is configured. It is prevented before signing, with these points.

• Data exportable in an open format, not only the current employee records but also history, documents and attachments: the export is tested before the contract.
• Documented APIs, included in the contract, that allow you to read and write the same data you see on screen.
• Data ownership and end of service: the controller is the company; the vendor is the processor, acts on documented instructions, uses a sub-processor only with the controller's written authorisation and, at the end of the service, deletes or returns the data (GDPR, Article 28).
• A written exit plan: in what format, in how much time, who to ask, with what proof that the export is complete.
• Internal knowledge: at least two people in the company can explain the configuration.
• Known exit costs: if exporting the data or using the APIs requires paid modules or services, you find out before signing.

6. Cloud HR, integrations and architecture

Cloud HR shifts the installation and maintenance of the software to the vendor and leaves the company with three decisions that no contract makes on its behalf: which data goes in, who can see it, and which systems it is exchanged with. The resulting architecture is a platform with the employee record at the centre and a few declared channels (API, files, single sign-on) towards payroll, ERP and analytics. It is better to fix the channels before choosing the vendor, not after.

Cloud or on-premise: what changes for IT and for HR

The comparison that follows is an EcosAgile working model: an explicit line of reasoning, not a measurement.

The two choices differ in who does what, more than in technology. Four points to put on the table together, IT and HR.

• Updates. In the cloud, versions arrive on the vendor's calendar, and the company must be able to repeat tests on its own flows (import, export, access) after each release. On-premise, IT decides the calendar; a postponed update remains a risk for the company.
• Responsibility. With a cloud vendor the company remains the controller of the data and the vendor normally becomes the processor: a written contract is needed (Article 28 GDPR) and the security measures of Article 32 apply to both. With on-premise, Article 32 does not disappear: the same work is done by the internal IT. For cloud services, the ISO/IEC 27017 standard offers guidelines on controls, aimed at customers and vendors.
• Integrations. On-premise, you are tempted to read the application's database directly. In the cloud you go through explicit channels (API, files, single sign-on): this is a useful constraint, because it forces you to document the links and makes them less exposed to updates.
• Running costs. On one side infrastructure, backups, patches and internal skills; on the other, the subscription fee and vendor management. A serious comparison covers several years, uses the company's own figures and counts the time of IT and HR, which is often not in the budget.

The working position is this: for an SME or a group without an infrastructure team dedicated to HR, the cloud is the starting point. On-premise is justified when an external constraint requires it, such as a group security policy or a contract, and whoever chooses it must write into the budget and the org chart who will run it.

How data is connected

Four decisions come before the channel, to be taken for each piece of data: which system it originates in, who corrects it, in which direction it travels, how often it is updated. The channel is chosen afterwards, and it is often determined by what the other system can do.

Payroll, ERP, HRIS and BI

Payroll remains the one the company already uses, its own or that of the payroll firm. The work lies in defining two flows: towards payroll, justified attendance and absences with the month's changes; in return, payslips, leave balances and cost items. Each flow has a file layout, a code that identifies the person in both systems and someone who reads the rejected records.

Example with fictitious data: at the start of the month the payroll firm sends a file with leave balances and the next day three rows turn out to be rejected because the employee number does not match the one in the employee record. The flow holds when someone has the task of reading the rejected records; punctuality of the file alone is not enough.

With ERP and other HRIS the decisive question is who is the master of the data. The ERP generally holds costs and cost centres, HR holds people and organisation, and the common key (employee number, tax code (codice fiscale) or another identifier) must be chosen only once. In a tender specification it is better to write what the system must do, not the label (HRIS, HRMS and HCM overlap). BI is a read-only channel: periodic extractions via API or file, with the KPI definitions written separately (see HR analytics and data for decisions).

Integration with the org chart is covered in more depth in org chart and HRIS integration (in Italian). The case in which HR data and payroll data must give the same numbers, pay transparency, is in the guide on integrating HR and payroll data for pay transparency. Access and security are in Security, privacy and governance of HR data.

In EcosAgile: the APIs use a dedicated user with EcosAgile credentials, without an API Key, and are enabled only for the fixed company IP addresses communicated in advance to support; the API Library shows the layout of each API, and the APIs can also be queried from BI tools. Flat files for automatic imports are deposited via SFTP, always from company IPs that have been communicated. Pay changes are imported from file or via API. For payroll, Time produces the file for the payroll firm and acquires the bulk payslip file to be split into individual payslips; leave balances and cost items arrive from imported files. Access is configured with Microsoft OpenID, to be enabled for the customer, or with LDAP or Active Directory, and with two-factor authentication. Calendars are synchronised with Outlook and Google Calendar through an iCal address, with updates that are not in real time.

7. HR analytics and data for decisions

HR data supports a decision when someone has established beforehand where each piece of data comes from, what it means and who is accountable for its correctness. An absence rate calculated differently by each site produces numbers that nobody defends in a meeting. The working sequence is this: sources, KPI definitions, owners, quality rules, and only then visualisation.

Dashboards and KPIs

Work on the dashboard starts from a table, before any chart. For each indicator you write the formula, the source, the owner and the reading frequency. The formulas are working definitions: each company adapts them, as long as it always uses the same one across all sites. They do not describe how the dashboards of any product calculate.

Nine indicators are enough to begin with: others are added when a decision calls for them.

Headcount and workforce data

Headcount seems the easiest KPI and gives different answers depending on who is answering. Do interns count? What about people on leave of absence? Does a person at 50% count as one or as half? Three decisions need to be written down once: who falls within the scope, on which date it is measured, whether you count by people or by FTE. For span of control and hierarchical levels, which belong to structural data, see the guide on org charts and workforce planning and the in-depth article on headcount and span of control KPIs (in Italian).

Example with fictitious data: a department has twelve people, three of them at 50%. Headcount is 12, FTE is 10.5 (nine full-time plus three halves). Whoever sizes the workload on the first number overestimates the unit's capacity and finds out at the end of the quarter.

Data quality and ownership

Each field has an owner, and it is the person who creates or corrects it at the source, not the person who reads it on the dashboard. The data dictionary puts definition, source system and owner in writing. It is worth adding the purpose as well: the GDPR requires data that is adequate, relevant and limited to what is necessary (Article 5(1)(c)) and protection by default (Article 25). Fields collected for future analysis do not qualify.

Example with fictitious data: four rows of a data dictionary, with hypothetical systems and roles.

Quality rules sit in the system that records the data: mandatory fields, closed lists in place of free text, validity dates. A check made downstream, on the exported file, often arrives too late.

Operational reporting and analytics

Operational reporting answers the people working today: requests awaiting approval, missing clock-ins, contracts about to expire. It must be exact to the single record and updated within the day. Analytics compares groups and periods in order to decide: it tolerates rounding, but demands definitions that do not change from one quarter to the next. A clear position: as long as operational reporting is done by copying data between sheets, every advanced analytics project, and predictive ones all the more so, starts on the wrong foundations. First you stop chasing lists by hand.

A single source of truth

For each piece of data there is one system of record, and the other systems read it. The opposite happens when each site calculates headcount in its own way and the figures of HR and management do not reconcile. For each field in the dictionary you state where it is written, who reads it and how often it is synchronised; if two systems can write the same field, one of the two must be made read-only. On the architecture of links with payroll and other systems see the section on cloud, integrations and architecture; on passing HR data to payroll, the guide on pay transparency. This section does not report market benchmarks: comparison values are built on the historical data of one's own organisation.

8. AI in HR processes

Artificial intelligence in HR processes pays off when it supports and creates problems when it decides: it answers recurring questions, writes drafts, reads documents, proposes matches or summaries that a person checks and is accountable for. The AI Act (Regulation (EU) 2024/1689) treats as high-risk the systems used to select people and manage the employment relationship, and after the Digital Omnibus the related obligations apply from 2 December 2027. Before that date, the prohibitions and the Italian labour rules already apply.

Where AI really helps

Use cases fall into five families, with very different risk profiles. The matrix separates them before anyone decides where to begin.

The matrix is an EcosAgile working model, not a legal classification. The ratings are qualitative and should be redone with the company's own processes.

Support, not decision

The principle we apply in every project is that AI proposes and a person decides, by name and surname, even where the law does not require it. Human oversight means that whoever checks has the time, the competence and the authority to change the outcome: a confirmation click on two hundred rows is not oversight.

For high-risk systems, Article 26 asks those who use them (the deployer), among other things, for these three commitments, useful as a reference for lighter cases too:

• human oversight entrusted to people with adequate competence, training, authority and support (paragraph 2);
• keeping logs under their own control for at least six months, unless otherwise provided (paragraph 6);
• prior information to the workers concerned and their representatives (paragraph 7).

Before applying these obligations to a specific case, check on the consolidated text of the Regulation that Article 26 and Annex III have not been amended after 28 October 2026.

What the rules say, and from when

Date the sources were checked: 28 October 2026. Texts predating July 2026 may still give 2 August 2026 for high risk: that date has been superseded. The Digital Omnibus on AI, Regulation (EU) 2026/1744 of 8 July 2026, published on 24 July 2026 and in force from 27 July 2026, amends the AI Act and moves the deadlines. The regulatory calendar was changed several times in 2026: read the text in force before applying it.

In Italy, Law no. 132 of 23 September 2025 requires, in Article 11, that AI at work be safe, reliable and transparent and respect dignity and data confidentiality; the employer informs the worker in the cases and ways set out in Article 1-bis of Legislative Decree 152/1997 and respects the ban on discrimination. Article 12 establishes an Observatory at the Ministry of Labour (Ministero del Lavoro); whether the implementing decree has been issued should be checked on the Ministry's website.

Article 1-bis, inserted by Legislative Decree 104/2022, provides in its original text for advance information (purposes, logic and functioning, categories of data, control measures) and the worker's right to access the data, with a written reply within 30 days. According to the comments by Brocardi and Agenda Digitale, after Decree-Law 48/2023 the obligation would apply to fully automated systems, excluding those protected by industrial and commercial secrecy; the comments are not uniform on the scope of the communication to trade union representatives. The text in force should be read on Normattiva (the Italian legislation portal) before writing an information notice.

How widespread AI is in businesses

According to ISTAT (the Italian National Institute of Statistics, Istituto nazionale di statistica; press release of 15 December 2025), in 2025 16.4% of Italian businesses with at least 10 employees used AI technologies, against 8.2% in 2024; large businesses are at 53.1%, SMEs at 15.7%. For Eurostat (11 December 2025) the EU average is 20.0% of businesses with at least 10 employees, up from 13.5% in 2024, according to the EU survey on ICT usage in enterprises (NACE Rev. 2 sections C-J, L-N and group 95.1). Among the uses indicated by ISTAT are marketing and sales (33.1%) and organisation of administrative processes (25.7%). The press release mentions neither human resources nor selection: these are context figures for HR, not a benchmark.

Articles, dates, scope of the rules and adoption percentages come from the sources cited at the bottom of the page. The matrix, the support-not-decision principle and the order of the use cases are EcosAgile's position.

For selection there is the webinar recruiting and AI in personnel selection (in Italian); for data, Security, privacy and governance of HR data.

In EcosAgile: the AI functions described in the manuals are there to support the user. A dedicated icon generates proposed texts, which the user supplements, for search profiles, training needs, role skills and assignment descriptions. In Recruiting the CV-Parser (optional module) fills in the fields from CVs, AI match proposes the pairing between candidate and position, and AI Insight offers a profile inferred from the CV, on anonymised content, as an indicative guide, without confirmation from the candidate and without any judgement on suitability; the AI functions of Recruiting are activated by subscribing to the AI services. In Expense the AI Foundation module extracts from the supporting document the value per VAT band and the route sections of the transits shown on the supporting documents; it is a separate module, with conditions defined in the contract.

9. Security, privacy and governance of HR data

Protecting HR data means deciding who can see what, how long it is kept, who processes it on the company's behalf and what happens when something goes wrong. The GDPR translates this into principles (minimisation, storage limitation, integrity and confidentiality, Article 5), obligations of design (Article 25), of contracts with vendors (Article 28), of security (Article 32) and of breach notification within 72 hours where feasible (Article 33, detail in the table). For employee data, Article 88 leaves room for specific national rules.

From principles to concrete choices

The work lies in translating the articles of Regulation (EU) 2016/679 into fields, permissions and deadlines that HR and IT can verify.

Roles, profiles, access and logs

There are three questions about access and they should be kept separate: which functions a person can use (the profile), the data of which companies or structures they can see (the scope), what they can modify and what they can only read. Mixing them produces profiles that multiply without anyone knowing any more why they exist. A manager sees the people they are responsible for; the system administrator does not need to read the content of cases. This is a working rule of ours, to be reviewed at every reorganisation.

Logs serve to reconstruct who did what, and they in turn must be managed. The Italian Data Protection Authority (Garante per la protezione dei dati personali), regarding email metadata, indicates that as a rule they are kept for a few days, roughly no more than 21, and that longer or generalised retention may amount to remote monitoring and require a trade union agreement or authorisation (Article 4 of the Workers' Statute). The document concerns email, not the logs of an HR system: the analogy is ours, and the log period is decided case by case with the adviser. For the information notice to workers on AI see AI in HR processes.

Vendors, breaches and certifications

The Article 28 contract fixes the things that matter on the day something goes wrong: documented instructions, Article 32 measures, assistance to the controller, deletion or return of data at the end of the service, audit. A sub-processor requires prior written authorisation.

ISO/IEC 27001:2022 defines the requirements for an information security management system. A certification concerns one vendor and a precise scope: you ask for the certificate and read what it covers and until when it is valid. The ISO/IEC 27017 standard is a guideline on security controls for cloud services, for customers and vendors: at the date of checking, the ISO page shows the 2026 edition in course of publication and the 2015 edition withdrawn. ISO/IEC 27018 concerns the protection of personal data in public clouds acting as processors, and its third edition appears to have been published in August 2025. These are reference standards for formulating questions, not proof that a vendor complies with them.

On data residency the question to ask is concrete: in which countries the data is held, where the backups are, where the sub-processors operate. The answer lies in the contract and should be established for each module, not assumed from the sales page.

Checklist for evaluating a vendor

• Deed of appointment as processor with subject matter, duration, purpose, types of data and documented instructions (Article 28)
• List of sub-processors and procedure for authorisation or objection
• Deletion or return of data at the end of the service and possibility of audit
• ISO/IEC 27001 certificate with scope, issuing body and expiry
• Status with respect to the ISO/IEC 27017 and 27018 guidelines, requested in writing
• Country of the data, of the backups and of the sub-processors, stated for each module
• Profiles and data scope configurable by the customer, by function and by company
• Access logs that the customer can consult and declared retention period
• Multi-factor authentication and single sign-on with the company directory
• Times and methods with which the vendor notifies the customer of a breach (Article 33)
• Restore tests and periodic checks of the effectiveness of the measures (Article 32)

For the case of structure data and the org chart there is an in-depth article on org chart security and governance (in Italian).

In EcosAgile: each user account has a level (2 Professional, 3 Manager, 4 User) that determines the breadth of the data accessible, and authorisation profiles enable individual functions if provided for in the contract; the profiles of levels 3 and 4 are assigned every night from the ESS and MSS groups, level 2 by hand by the customer's administrator. Row Security, distinct from the profile, decides which companies' data a user account sees; a manager sees and approves only the people they are responsible for. Information with a validity date is kept with its history. The Usage tab shows successful and failed logins, IPs and sessions; there is a Login Log with the reason for failure and a log of the actions of API calls. Passwords require at least 8 characters with upper case, lower case, a number and a special character; two-factor authentication is enabled per user account or in bulk; inactive user accounts are blocked automatically and unblocked by the administrator; access can go through Microsoft OpenID or LDAP/Active Directory (with LDAP the passwords stay in the customer's repository). EcosAgile states that it is ISO/IEC 27001 certified; for the issuing body, scope and expiry, ask the sales contact for the certificate.

10. How to build an HR digitalisation roadmap

An HR digitalisation roadmap starts from the processes that today waste time or generate errors, not from the list of a software's functions. They are chosen by value, risk and frequency, tried on a small scope with a clear owner, connected to existing data and systems, accompanied by training and measured. Only after a pilot with readable numbers is it extended to the following processes.

Six working phases

The six phases are an EcosAgile working model, not a published standard. They can overlap and sometimes you go back: from the pilot you discover that the process map was incomplete, and that is normal.

The baseline is taken in phase 1 or 2, before touching anything. After launch it is hard to reconstruct how things were before. Before the pilot (phase 3) you also fix the choices common to all future modules, listed in Modularity and progressiveness.

Value against complexity

Two axes are used to order the processes. Value combines frequency, minutes per execution, error risk and impact on people. Complexity counts the systems involved, the actors, the exceptions and the quality of the starting data. Placement depends on the company: the examples are indicative and should be redone with your own numbers.

The vertical processes (attendance, working hours and absences, expense reports and business trips) have an in-depth article of their own and are natural pilot candidates, because they are frequent and involve many people. Starting from one priority and proceeding step by step is also the thread of the webinar on people-centric HR processes (in Italian), which shows it with cases from consulting, retail, welfare, renewable energy and the dairy industry.

Who does what

A project stops when nobody knows who decides. This RACI table assigns, for each phase, who carries out (R), who is accountable for the result (A), who is consulted (C) and who is informed (I). It is an example to adapt: in a company with several companies, for instance, managers are more numerous and the sponsor role is split.

The maturity model from 0 to 4

This too is an EcosAgile working model, a grid of five levels for discussing where you are and where you need to get to.

How to use it: a self-assessment, carried out by HR and IT together. A level is assigned to each process, not to the whole company: absences may be at level 2 and recruiting at level 1. Next to the current level you write the level that is needed, which is not always the highest. It is a discussion tool and does not produce an index or a score. Level 4 presupposes the governance rules described in the section on AI in HR processes.

How long it takes

There is no duration that is valid for everyone. It depends on how many sources have to be unified and how clean they are, on how many companies, sites and collective agreements there are, on how many systems have to be integrated, on the availability of process owners and on how many people have to be trained. The calendar also matters: a pilot on attendance or payroll is not launched close to the month-end close. A serious estimate comes after phases 1 and 2, not before.

11. Digital onboarding and workflow

Digital onboarding manages a person's joining as a flow and not as a chain of emails: a list of tasks, each with an owner and a deadline, that starts when the person's status changes, notifies whoever has to act and keeps a record of what was done. HR, the manager, IT and the new hire each see their own part of the same process. The pattern, with different tasks, also applies to leaving and to internal moves.

What an onboarding process contains

The heart is the template: a model for each type of joiner (head-office employee, external contractor, fixed-term) that lists the tasks. Each task has a description, an owner, a deadline and an indication of visibility: the new hire should see the request to upload a document, not the computer order sent to IT. Deadlines are expressed in days relative to an event, usually the joining date, so that the same template serves someone who joins in January and someone who joins in June. Notifications alert whoever has to act and, for delays, HR. The process is divided into three stages.

• Pre-boarding, from acceptance of the offer to the day before: data and documents, signing of the contract and information notices, access and equipment to prepare.
• Day 1: working accounts, workstation ready, welcome from the manager and plan for the first weeks.
• Probation period: review meetings at set intervals, induction training, recorded feedback.

Example with fictitious data: template for a head-office employee. D is the joining day, D- and D+ indicate the days before and after.

Approval workflow

The workflow applies the same mechanism to decisions: a request, an approver, an outcome, a next step. Five decisions to take before configuring the flow:

1. which event starts the process: acceptance of the offer, signing of the contract, the hire date;
2. who is accountable for each task, indicated by role and not by name, because names change;
3. which deadlines are relative to the event and which are fixed;
4. who is notified, and when;
5. what happens if a deadline is missed: a reminder, a handover to HR, a block.

Requests and approvals seen from the employee's and manager's side are in the People-Centric HR section.

Offboarding

Offboarding has a pattern of its own: the timing is often imposed from outside: a notice period, a contract end date, sometimes an exit at short notice. Order and date matter: revocation of access on a defined day and at a defined hour, return of computer, phone, badge and car before the last day, final documents, handover to a colleague, exit interview.

What makes an onboarding digital

An onboarding is digital when you can answer three questions without writing to anyone: what is missing, from whom, for how long. With a chain of emails the answer sits in the mailbox of whoever forwarded the last message. The flow provides traceability, because every task has a status, an owner and a date, and reduces copies: identity documents and bank details that circulate as attachments are copies out of control, whereas the GDPR requires adequate measures against unlawful processing and against accidental loss and destruction (Article 5(1)(f)).

Documents to sign on joining

On joining there are many documents to sign: contract, assignment letters, information notices, equipment handover record. In the webinar on eIDAS 2 the EcosAgile speaker cites onboarding among the processes with the greatest documentary impact (from minute 09:59, “Digitalising HR processes”). On the choice of signature, according to the speaker Alberto Sturniolo (Regulatory Specialist, Tinexta InfoCert), no rule imposes a type of signature for HR documents, except for the acts of Article 1350 of the Italian Civil Code (codice civile), for which the qualified electronic signature is required. For information notices and equipment handover records a simple electronic signature may be enough; for employment contracts and employment letters he suggests the advanced or the qualified signature, specifying that this is a suggestion and not a prescription.

These are the opinions of an expert expressed in a webinar, not legal advice: the level of signature to use for each document should be agreed with your own adviser.

Insight from the expert: the webinar eIDAS 2 and digital signature (in Italian) (June 2026, 49 minutes) is with Alberto Sturniolo of Tinexta InfoCert: the choice of signature level is at minutes 08:04 and 43:19, while the processes with the greatest documentary impact are presented by the EcosAgile speaker from minute 09:59.

In EcosAgile: the On/Off Boarding functions manage joining, leaving and internal moves with task templates. Each task has a description, the days allowed to complete it, an indication of visibility for the new hire and an owner, who can be a named person, the direct manager or the new hire themselves; the deadline starts from a start event or is set by hand. The process starts on a person already registered in the employee record, even with a future date. The new hire finds the tasks on the Welcome page of self-service, the manager in the Manager Self Service area; notifications alert the manager and HR of deadlines and IT of new joiners and terminations. Termination in the employee record deactivates the user account. The signature procedure is started from the system; the manual describes the single, bulk and multiple scenarios (several documents to the same person). The functions are available if provided for in the contract.

12. How to measure the value of HR digitalisation

The value of HR digitalisation is measured by comparing, with the same definitions, what happened before with what happens after: time to close a request, errors and corrections, share of operations done through self-service, data quality, response times and satisfaction of those who use the system. Without a baseline taken before launch, every saving declared afterwards remains an estimate.

Time saved

The formula is simple: (minutes per case before minus minutes after) × cases in the period. The baseline is obtained by timing a sample of real cases, including those with exceptions, and not from the estimate of whoever handles them. To be decided before starting: what is done with the time freed, for example more checks, less overtime, capacity for another process. The HR Innovation Practice Observatory of the Polytechnic University of Milan (Politecnico di Milano), in its 2026 Research, reports that 44% of Italian workers use AI, with an average saving of about 30 minutes a day, and that only 9% of organisations manage the time saved in a structured way. These are data on the use of AI and not on HR digitalisation in general, but the problem is the same: time freed without a destination is dispersed.

Errors and rework

You measure the share of cases corrected after closure and the time spent correcting them (formula in the table). Examples: payslips corrected, clock-ins fixed by hand, expense reports rejected and sent back. A warning that avoids arguments: when a system starts recording corrections, the rate may rise in the first months, because previously errors passed through without leaving a trace. For this reason the “before” too must be counted with the same criterion, on a sample of past cases.

Request cycle time

This is the time that passes from the request to closure. You read the median and not the average, by type of request, because a few blocked cases distort the average. It shows where the bottleneck is, often waiting for an approval and not the office's work. Typical cases: the absence request (attendance, working hours and absences) or the reimbursement of an expense report, from the expense to the money being credited to the account (expense reports and business trips).

Self-service adoption

Self-service adoption (definition in section 4) is read on two numbers: requests entered directly by the employee over total requests, and users who have used the service at least once in the period over enabled users. The parallel channel matters too: as long as a substantial share of requests still arrives by email to HR, self-service is active but not adopted. For the design see the section on People-Centric HR.

Data quality and completeness

You measure completeness (records with all mandatory fields / active records × 100), duplicates and timeliness: the days that pass between an event, such as a change of site or contract, and its update in the employee record. The fields and owners are those of the data dictionary in the section on HR analytics.

Employee experience and internal SLAs

An internal SLA is the HR service's commitment to close each type of request within a given time; the indicator is the share of requests closed within that time. Experience is gathered with a short question at the closure of the case, on a fixed scale, always reporting the response rate next to the score: an average score calculated on a few respondents says little.

A before-and-after comparison

Example with fictitious data: six months of requests to change bank details, which used to arrive by email at three sites and then moved to self-service with an HR spot check. The numbers show how to read the table and do not indicate an expected result.

The 110 hours are hours freed. They become a saving only if someone has decided beforehand how to reinvest them, for example in checking data before the month-end close.

13. How to choose HR software

HR software is chosen starting from the processes to be covered and the systems that remain in the company, and then fifteen criteria are evaluated, each with a test to run in the demo on your own data and not on the vendor's. Weights and scores are fixed before seeing the demos, with a group that includes HR, IT and at least one manager. The list is an EcosAgile working model, not a standard, and applies to any product.

The fifteen criteria and the test to ask for

1. Functional coverage of the processes. Test: have three of your real processes run in the demo from start to finish, exceptions included.
2. Configurability. Test: ask them to change an approval flow or a field in front of you, and who can do it (the administrator or the vendor).
3. Modularity. Test: ask what can be activated on its own and what requires other modules.
4. Data quality and model. Test: record a contract change with a future effective date and see what history and reporting show.
5. API and integrations. Test: ask for the documentation and a real example of an exchange with payroll: direction, frequency, error handling (see cloud, integrations and architecture).
6. User experience and mobile. Test: have a real employee enter a request from a phone, without instructions, and observe where they get stuck.
7. Security and privacy. Test: ask for controller and processor roles, sub-processors, measures adopted, breach procedure and certifications with body, scope and expiry (see security, privacy and governance).
8. Roles and permissions. Test: create a manager profile that sees only their own area and check every screen.
9. Traceability. Test: change a piece of data and ask where you can read who, when and the previous value, and for how long.
10. Local support and language. Test: read the interface and documentation in Italian; ask about support channels, hours and response times and how collective agreements are handled.
11. Ability to evolve and frequency of updates. Test: ask for the release notes of the last twelve months and how an update is tested before it reaches production.
12. Data migration. Test: load a real extract, even a dirty one, and read the error report; ask who does what.
13. Exit and portability. Test: ask for a complete trial export and what happens at the end of the contract.
14. AI governance. Test: ask which functions use AI, on which data, whether they can be switched off and how human oversight and logs are guaranteed. Selection and management of workers are among the high-risk cases (Annex III, point 4, of Regulation (EU) 2024/1689, from 2 December 2027): see AI in HR processes.
15. Total cost of ownership. Test: have all the items listed over the horizon you have decided (licence, launch, migration, integrations, training, internal maintenance time) and compare them with the current cost of manual work.

On security, certifications are evidence to be read, starting with scope and expiry. A copy of the certificate is requested, in addition to the declaration (ISO/IEC 27001, 27017 and 27018 are described in the section Security, privacy and governance).

Modular suite, all-in-one or specialist

These are three architectures, and none wins on principle. For those starting from two or three processes knowing they will add others, a modular suite reduces the risk of redoing the employee record at every step. For those with a single critical process and the rest already stable, the specialist product is enough. The name of the category (HRIS, HRMS, HCM) says little: the acronyms overlap, as the section on HRIS, HRMS and HCM explains.

How weights and scores are assigned

1. The evaluation group (HR, IT, a manager, whoever looks after privacy) separates the mandatory requirements, to be passed or to exclude a product, from those to be weighted.
2. Before the demos, each criterion is assigned a weight from 1 to 5.
3. After each demo, each evaluator gives a score from 0 to 3: 0 absent, 1 partial, 2 present with limits, 3 demonstrated on your own data.
4. The evidence is noted down: what was seen, not what was promised.
5. Weighted score = weight × score; the results are summed and the gaps between evaluators are discussed.

Example with fictitious data: a scorecard with four criteria out of fifteen and three anonymous products. Each cell shows the score and, in brackets, the weighted value. The maximum is 48.

A gap of three points between A and C, or of one between C and B, is not enough on its own to decide. First you look at the mandatory requirements and the evidence noted, then you return to the total. Several independent evaluators make it possible to see where judgements diverge.

How EcosAgile approaches modularity, employee record and payroll is described in the section The EcosAgile approach; API, security and AI are in the “In EcosAgile” boxes of the sections on integrations, AI and security; the most frequent doubts are in the frequently asked questions.

14. The EcosAgile approach

EcosAgile approaches HR digitalisation with a modular suite: you start from the most urgent process and add the others over time, linking them to the data of the employee record. The payroll software of the company or of the payroll firm stays where it is: the suite connects with files or APIs (see “Coexistence with payroll”). Which payroll software packages are already supported should be asked of EcosAgile at the start of the project.

Connectable modules, gradual launch

According to the modules and processes page, the functions are used together or individually, even at later times; the example it gives is that the employee record module is not needed before the development and selection processes. Some processes do, however, read data from the employee record: onboarding presupposes that the person is registered, even with a future date. The order of launch is decided taking this constraint into account; a working model in phases is in the section on how to build a roadmap.

What the modules read from the employee record

Each natural person has a unique identifier, under which the events of the employment relationship and the history of all contracts are recorded. In addition to this, the manuals document some specific links.

The list shows the links between modules, not the entire data architecture.

Coexistence with payroll

From Time come the attendance and absence report and the file for the payroll firm, in the layout indicated by the payroll software vendor, after absences have been justified with the payroll codes. In the opposite direction the firm loads the payslip file, which the system splits and distributes into the employees' folders. Pay changes are imported from file or via API. The payroll consultant can be registered as a third party and view the approved timecards in read-only mode.

Processes with an in-depth article

The modules page also lists selection, training and development, compensation and budget, safety and occupational medicine, general services, timesheet and projects, communication, reporting, self-service for employees and managers, workflow and interfaces.

To understand where to start in your own company you can look at the map of the suite's modules and processes, read the page for EcosAgile People or ask for a targeted demo on the areas of interest.

15. Frequently asked questions