HRSD Shared Services: What Actually Breaks Six Months After Go-Live
An HR shared services lead at a 3,200-person industrial group in the Ruhr called me in the first week of October. They had gone live on ServiceNow HRSD in mid-March. The project had been clean. Two tiers of case management, Employee Center up, Lifecycle Events wired for onboarding and offboarding, SuccessFactors sitting underneath as the system of record. The go-live metrics were the kind you put in a steering slide. Case volume handled per FTE up eighteen percent. First response time down forty-two percent. Portal adoption at seventy-six percent in the first month.
Six months later the numbers had flattened and the complaints had rotated. The HR business partners were saying the tool felt heavier than the inbox it replaced. The works council was asking pointed questions about who could read what case data. Two of the regional HR managers had started routing sensitive cases back through email because they did not trust the security model. The shared services lead sent me the Employee Center feedback form export and asked a simple question. Why does HRSD get worse at month six.
The answer is boring and specific. The platform is doing what it was configured to do. The configuration was designed for the shape of the HR organisation that existed at the point of discovery, and the HR organisation has moved. HRSD shared services rollouts almost never fail at go-live. They erode through month four, five and six, in three places that are predictable if you know where to look.
The HR Case Management Taxonomy Starts Drifting at Week Twelve
The first erosion is the case taxonomy. At go-live, the HR case management category tree is tight. Three or four top-level categories. Ten to fifteen subcategories. Each one has a documented owner, an SLA, a knowledge article attached, and a routing rule into the right COE. Agents can find the category they need in two clicks. Reporting is clean because every case rolls up to one of the three top-level categories and nothing else.
Then real life happens. A regional HR manager opens a case about a company car policy question and cannot find a category that fits. They pick the closest one and write a long description. The next week another case comes in about the same topic. The agent picks a different closest-fit category. Two weeks in, the tier-one lead asks for a new subcategory. The HRSD admin creates it, usually in a scoped app table, usually without updating the knowledge article, the routing rule, or the SLA. The new subcategory works. It gets copied. By month four there are fifty-two subcategories where there used to be fifteen. Nineteen of them have fewer than three cases ever. Seven of them overlap with existing ones to the point that agents pick between them by habit, not by rule.
The reporting is the first thing to break. The shared services lead opens their monthly dashboard and the top-level categories no longer tell the real story. Half the volume is now in a long tail. The SLA compliance number is held up by a handful of high-volume subcategories and hides the ones where cases sit for days because nobody owns them. The platform cannot tell you this is happening. It is doing exactly what you asked. The erosion is in the taxonomy governance, not the configuration.
The fix is not a cleanup project. The fix is a monthly review ritual, owned by the shared services lead, that looks at three things. New subcategories created in the last thirty days. Subcategories with fewer than five cases in the last ninety days. Subcategories where median time-to-close is more than fifty percent above the top-level category average. Thirty minutes a month. The alternative is a quarterly reset that nobody in HR has time to sit through.
Employee Experience Degrades When Nobody Owns Portal Signal
The second erosion is in the Employee Center. At go-live the catalogue is curated. Twenty to thirty catalogue items covering the real demand curve. Search is tuned. Featured items on the homepage reflect the current moment. Six months in, the portal has started to look like an attic.
Employee experience on an HRSD rollout is not a theme switch. It is a discipline of pruning. Every catalogue item that returns a case into the HR queue is a candidate for the catalogue. Every one of those items that nobody uses is a candidate for removal. In practice, neither side of this ledger gets owned. The HR team adds catalogue items because somebody asked. They do not remove items because removing one feels like admitting it was added for the wrong reason. The search starts to return the wrong top result because the catalogue grew faster than the synonym dictionary. Employees give up and open a general case. Case volume creeps back up. The adoption number holds because people still log in, but the shape of the usage is different and worse.
I pull three reports when I audit this. The catalogue items sorted by submission count, descending. The same list sorted ascending. And the top twenty search terms with their click-through rate. The first two reports tell you what to trim and what to promote. The third one tells you where the search tuning is lying to employees. In the Ruhr case, the top search term last quarter was “parental leave,” the top click-through from that search was a 2022 PDF of the works agreement, and the actual catalogue item for requesting parental leave had been renamed three months earlier to something nobody searched for. The portal was not failing. The signal from the portal to the HR team had failed.
Fixing the employee experience side of a mid-year HRSD rollout is three things. Trim the catalogue by twenty to thirty percent. Rewrite the five highest-volume catalogue item names so they match what employees actually type. Tune the search synonyms against the top twenty query terms from the last ninety days. None of this is a project. It is a half day of work per quarter, done by someone who reports to the shared services lead and not to IT.
HR Security Policies Are Almost Always Wrong by Month Five
The third erosion, and the one with the sharpest consequences, is the HR security policies. ServiceNow HRSD ships a layered security model. Role-based ACLs at the base layer. HR Security Policies on top, applied to sensitive tables like compensation, relations, and medical. Data segregation rules by COE and sometimes by legal entity. At go-live the works council and legal have usually signed off on the model. Six months later nobody has actually tested whether it still works the way the sign-off assumed.
Three things erode the policy stack. First, new HR roles. A benefits specialist in a new region gets added. The admin grants them the HR_basic role because it is quickest. The HR_basic role, through a chain of policy references nobody re-read, lets them see compensation fields on cases they should not see. Nobody notices until the specialist mentions a salary number in a Teams chat and the works council finds out. Second, new case types. A new subcategory, see the first section, inherits the default security from its parent. If the parent was a general enquiries category and the new subcategory handles grievances, the security is wrong from the moment the subcategory exists. Third, acquisitions and reorganisations. A new legal entity comes in, its data gets loaded, the domain separation rules do not get updated at the same tempo, and for two months the new entity’s cases are visible to the wrong HR partners.
The fix here is not a dashboard. The fix is an actual quarterly test. Pick six employee personas across different legal entities, COEs and role combinations. Have an auditor, not the admin, log in as each one and attempt to read fifteen case types the persona should not be able to read. Record the result. Any gap gets fixed inside the sprint. Any pattern of gaps gets escalated to a security review, not a policy tweak. In the Ruhr case this exercise, run against twelve personas, found four policy misconfigurations, two of which had been live for over three months. One of them had exposed compensation data for roughly four hundred cases to a benefits specialist in the wrong region. Nothing had leaked externally. The works council took the finding well because the fix was already in flight by the time they heard about it. That conversation goes very differently if you are telling them about it two weeks after they heard from an employee.
Where to Start, Practically
If you are six months past an HRSD shared services go-live and the numbers are flattening, the three places to start are the taxonomy, the portal, and the security stack. In that order, and this week.
First, pull the case category and subcategory table and count how many subcategories were created in the last ninety days, how many have fewer than five cases ever, and how many have an SLA that does not match their parent. Any number above zero in any of those columns is a decision that needs owning.
Second, export the Employee Center catalogue analytics and compare the top twenty searched terms against the top twenty clicked catalogue items. Where the terms and the clicks do not align, you have an employee experience problem that will keep leaking case volume into the HR queue until it is fixed.
Third, book a half day with your HR security lead and someone neutral to walk six personas through a read test on sensitive case types. If nothing is wrong, the half day is a cheap confidence signal. If something is wrong, you found it before the works council did.
If you want an outside read on where your instance sits against those three dimensions and the twenty or so others that erode an HRSD deployment at this age, the ten-day Instance Health Report is built for exactly this moment. Two weeks, fixed fee, written output, no sales cycle. We also run the same diagnostic for teams planning an HRSD rollout who want to see what they will inherit at month six if they stay on the current trajectory. More on how we work with mid-market HR and IT functions is on the services page.
Mladen Milic runs Milic Media Kft, a boutique ServiceNow consultancy delivering implementation, health audits and HRSD work across the EU. Reach him at mladen@milicmedia.com.