Buying stage: diagnosis, finding out what is wrong
Twelve questions will tell you whether your Unit4 HR and payroll configuration is still described by its own documentation, and you can answer every one of them without opening the system. Two questions sit in each of the six areas a formal diagnostic assesses, so a weak pair points straight at the area worth looking at first.
The checks are grouped into the six assessment domains a Unit4 X-Ray works through: configuration drift, defect inventory, control gaps, undocumented architecture, capability deficit and cloud-readiness posture. Each question has three honest answers: yes and it is written down; partly, or not recently; no, or I do not know. None of them asks for a number, a record count or anything you would have to clear before sharing.
The signal is two weak answers inside the same domain. That says the area runs on knowledge nobody has written down, which is a different problem from a system configured wrongly and calls for a different response.
Configuration drift
The two checks
- Can you produce a current, agreed list of the personnel and position attributes and flexi fields in use, each with a named owner?
- When a position or a resource record is changed, is there a record of who authorised the change and why?
The resource master file and the position master file are where a Unit4 HR estate accumulates. Resource types and classes, status and date control, position numbering and legacy reconciliation, position relations and attributes: every one of those was a deliberate choice somebody made on a particular day. So were the flexi field groups on the personnel tabs, added a group at a time for a process that needed them and rarely retired when that process changes.
Drift is not the presence of any of this. It is the absence of a current list with an owner against each item, and the absence of a trail behind the last change. The discipline that prevents it is ordinary: every configuration change leaves a written baseline, an execution record and a post-change validation, so it can still be explained after the person who made it has gone.
Defect inventory
The two checks
- Do you hold one list of open Unit4 HR and payroll faults, each with a root cause recorded rather than a workaround?
- Do absence or payroll errors get carried from one period into the next because nobody can close them?
Workflow is where this is easiest to see. Element type routing, approval chains from line manager to cost-centre approver to HR and payroll, substitutes and proxies: change any of that and the residue shows up as ghost tasks, bypassed approvals and missed routing. Absence carries its own version, where an error nobody can close is still open when the next period opens.
Most teams know their faults. What is usually missing is one list of them, with a root cause recorded against each rather than the workaround that keeps the month running. A workaround is a decision to pay the same cost every period.
Control gaps
The two checks
- Have Unit4 roles and access rights been recertified in the last twelve months, with leavers removed?
- Is there a current segregation-of-duties and approval-limit matrix for Unit4 that somebody owns?
Roles and access across HR, payroll, learning and development, finance and procurement are configured once and then inherited: role-based menu access, third-party user setup, substitutes and proxies, access across production, test and sandbox. Recertification keeps the inheritance honest, and it is the control most often deferred, because nothing visibly breaks when it is.
The second check is about the document rather than the system. A segregation-of-duties and permission matrix maps create, read, update and delete against each role, with the approval limits beside it. Where it cannot be produced on request, the answer to a control question is an opinion rather than a record.
Undocumented architecture
The two checks
- Is there a written procedure set covering the monthly payroll cycle that a new starter could follow?
- Is there a current written picture of the interfaces, alerts and automated tasks around Unit4?
A configured system is not an operable one until the procedure layer exists around it: the monthly payroll playbook, an error catalogue, decision trees and process maps, line-manager guides. The first check is deliberately blunt, because a procedure set that only works for the person who wrote it is a personal note with a document number.
The second covers the edges. Integration interfaces around Unit4 include pension scheme submission files, HMRC gateway submissions, BACS output and applicant tracking feeds, each with its own timing and its own behaviour when it fails. Alerts and automated tasks belong in the same picture: each fires on a condition somebody once defined, and that definition is worth being able to read.
Capability deficit
The two checks
- Can your own team write and run the browser queries, Excelerator templates and reports it needs, without external help?
- Is each year-end and statutory patch proved against a written plan before the live run?
Reporting is the everyday test of whether an organisation can interrogate its own estate. Browser queries for headcount, absence, casework and payroll extracts, Excelerator templates and the standard report set are the working level. SQL written against the Unit4 schema, for correction work and statutory extracts, is the level above. Where none of that sits inside the organisation, routine questions about its own data cannot be answered internally.
Year-end and statutory patches arrive on a fixed calendar, and the written test plan that proves them before the live run is what separates a controlled year-end from a hopeful one.
Cloud-readiness posture
The two checks
- Do you know which Unit4 processes still depend on the smart client, and what the web client equivalent is for each?
- Do data loads and migrations into Unit4 have documented validation and rollback criteria agreed before the load?
Smart client to web client migration is not a switch. It is client-to-client mapping, module-by-module test scripts, landing page configuration, data cleanse and defect remediation ahead of cut-over. An estate that cannot produce the dependency inventory is not yet in a position to scope that work, let alone price it.
The second states a rule that should apply to every load, not only to a migration: validation rules, reconciliation checkpoints and rollback criteria agreed before a single record moves. Agreeing them afterwards is not the same exercise.
Worked example: a payroll review forecast to free 500 administrative hours a year
A local government payroll running several pay entities, including a schools payroll, carried manual effort that had never been mapped end to end. The engagement was an independent system review: workflows mapped, fixes specified, remediation sequenced into a phased roadmap with consultancy estimates, written for an executive audience.
The published result is a forecast saving of 500 administrative hours a year, stated as a forecast because that is what the source says. The part worth taking from it here is the order of work: the review described what the estate actually did before it proposed a single change, which is the order these twelve questions follow.