How These Estates Fail

Workforce estates fail in recognisable ways, and almost all of them are at a boundary.

Identity mastered nowhere

Symptom: a person missing from a report, hours on the wrong name, a payment to a leaver — investigated separately as unrelated incidents.

Correction: one master, referenced by identifier everywhere.

Reference data maintained four times

Symptom: totals that do not reconcile, explained as timing every period.

Correction: one master per dimension with an owner, and effective dating.

The same rule in two systems

Symptom: double-counted or under-counted overtime, surviving for years.

Correction: a rule register with one owner per rule.

No reconciliation

Symptom: errors found by employees rather than by the organisation.

Correction: four comparisons, monthly, before the pay run.

Nobody owns the chain

Symptom: a cross-module question that takes three weeks and ends in a manual correction.

Correction: a named person with time and the authority to convene the module owners.

Upgrades uncoordinated

Symptom: a broken join discovered in a pay run, a week after a release.

Correction: a pre-upgrade check, a post-upgrade reconciliation, and no two modules upgrading in one week.

Manual steps undocumented

Symptom: the pay run depends on three people being available.

Correction: a register with owners and deputies, and automation of the ones that change numbers.

Payroll join built last

Symptom: a project nine months in with nothing usable and the hardest work remaining.

Correction: build the joins in order of consequence, payroll first among them.

Agency workers with no route

Symptom: invoices approved against memory, headcount that does not reconcile.

Correction: the fifth join, from time capture to invoice approval.

The common thread

Every one is a boundary problem presented as a module problem, which is why replacing a module rarely fixes any of them.

And every one is visible in a reconciliation that takes an hour a month.

Diagnose before replacing

The check that prevents an expensive mistake.

Run the four reconciliations and see which fails.

Check the rule register for the calculation in dispute.

Ask the daily users what they actually work around.

A fortnight, and it frequently shows that the module everyone blames is downstream of the one causing the problem.

Follow the difficult record

Use the service operation example to frame one representative case. The useful evidence is the record created when a value is corrected, approved and exported.