Separate owners inside one programme
Enterprise HR and admin systems should stay separately owned when the two teams answer to different heads, handle different kinds of sensitive data, and change their processes on different schedules. Separate ownership does not mean separate projects. Run both systems in one programme with written agreements, and let each department own its own records, rules and changes.
The urge to put one person in charge of both is understandable. Requests bounce between HR and admin, and a single owner looks like a cure. In practice, the HR owner ends up approving changes to room booking rules they know little about, or the admin owner gains access to salary and disciplinary records they should never see.
Decision rights, data sensitivity and pace of change
Start with who decides what. If the HR head signs off leave policy and the admin head signs off facility rules, the systems should mirror that split. Ownership follows decision rights.
Data sensitivity is the second test. HR holds identity numbers, bank details, medical notes and performance records. Admin holds landlord agreements, vendor documents, asset registers and booking histories. Both need protection, but the people who need access are different, and a single owner makes access reviews harder to defend.
Pace of change is the third. HR processes move with policy reviews, amendments to the Employment Act and annual cycles such as appraisals. Admin processes move when the company opens a branch, changes landlord or reorganises floors. Tying the two together means one team waits on the other's change window for no good reason.
Symptoms that separate ownership is failing
Separate ownership breaks down when nobody owns the space between the two systems. The symptoms are easy to spot: new joiners arrive without desks, departing staff keep their access cards, the same employee list exists in two places with different spellings, and each team blames the other's system.
None of these is a reason to merge ownership. Each is a reason to write down who owns the handoff. The fix is a small set of agreements, not a reorganisation of reporting lines.
A quick test helps. Pick a recent leaver and trace every record that mentioned them: the HR file, the asset register, the access card list, the parking allocation, the meeting room bookings they owned. If each record was closed by someone who knew it was their job, the boundary works. If any was closed by accident, or not at all, you have found the gap the agreements need to cover.
Agreements the two system owners should sign
Put these in a short document that both heads approve and revisit once a year. Keep it to a couple of pages. If it grows much longer, the teams are designing each other's processes, which defeats the purpose of separate ownership.
- Which system holds the master employee list, and how the other receives name, department and location changes
- Which HR events create work for admin, such as new joiner, transfer, extended leave and exit
- Which admin records refer to employees, such as asset assignments and access cards, and who updates them when a person leaves
- Who can see what across the boundary, written role by role rather than person by person
- How a change to one system's fields or statuses is announced to the other owner before it goes live
- Who resolves a disputed handoff, and the route for raising it to them
Which of the two systems to roll out first
When a company introduces both systems in one programme, HR usually goes first. The employee list, departments, reporting lines and work locations sit in HR, and admin depends on them for asset assignments, access and bookings. Rolling out admin first means building an employee list that will later be thrown away.
There is one common exception. If the admin pain is acute, such as company documents lost during an audit or a licence renewal missed, start admin with document control and contracts, which depend little on people data. Bring in employee-linked admin work, such as assets and access, once HR records are stable.
Draft the boundary agreements before either rollout starts. They are cheaper to write on paper than to retrofit into two live systems.
Scoping the two systems with Fasttrade
BukuHR covers people records, requests and approvals, onboarding and exit. BukuAdmin covers company documents, internal requests, shared calendars and cross-team follow-up. Each can have its own owner. How much data passes between them, and in which direction, is something Fasttrade scopes with both heads in the room, so the agreements above shape the setup rather than the other way round.
Frequently asked questions
Can one person own both the HR and admin systems in a smaller enterprise?
Yes, if one person genuinely holds decision rights over both areas, which is common where a single head of corporate services runs both teams. The risk is access. Make sure admin staff working in the system cannot see HR records they have no reason to view, and record who approves changes to each area even when the approver is the same person.
What is the most common gap between separately owned HR and admin systems?
Employee changes that never reach admin. A transfer, exit or long leave is approved in HR, and admin only finds out when someone complains about a missing desk or an access card that still works. Write down which HR events must trigger an admin request, and check at each joint review that every such event produced one.
Should admin keep its own copy of the employee list?
Admin needs employee names, departments and locations to assign assets and handle bookings, but it should not maintain the list itself. Agree that HR holds the master record and that admin receives changes from it, through a controlled export or an integration scoped during setup. Two lists maintained independently drift apart quickly and nobody can say which is right.
Next step
Explore BukuHR or tell Fasttrade what your team needs.
These articles explain enterprise process design. Product availability and detailed scope are confirmed in conversation.