← Back to insights
Insight

UKG vs Workday vs Oracle HCM for public utilities: how to decide

A vendor-neutral decision framework for public utilities weighing UKG, Workday, and Oracle HCM. No winner and no product score. What to verify in writing, in scripted demos, and in a ten-year cost.

A public utility that puts UKG, Workday, and Oracle HCM on the same shortlist does not need a winner declared in an article. It needs a way to make the vendors answer the same questions, in writing and in a scripted demonstration, against the utility’s own payroll, schedules, and bargaining rules.

This is a decision framework. It does not score the products. It does not say what any of them can or cannot do. Capability is what the proposal and the demonstration establish for your scope. If a sentence here sounds like a product claim, ignore the sentence and ask the vendor.

The advisory practice behind the questions is HRIS and HCM advisory. The workforce context for electric, water, gas, and fiber is the utilities page. Named utility HCM work we publish is Infor CloudSuite at Rancho California Water District. UKG, Workday, and Oracle HCM are not claimed on this site as utility engagements. The framework still applies when those three are the field in front of you.

Caliber vendor knowledge base listing HCM products, with client names blurred
The vendor knowledge base in Caliber, before a utility asks every logo the same questions. Client names are blurred. This article does not rank the products.

Start from the work, not the logo

Write the requirements before you know which logo is easier to demo. A utility is often one employer across several service lines. Line, plant, customer service, and finance share a payroll and do not share a schedule. The requirements catalogue has to say so. The method is the same one in what to get right before the RFP.

Until that catalogue exists, a demonstration is a tour. After it exists, a demonstration is a test.

What to verify in writing

Ask each vendor for a written response, on the same questions, before anyone scores a room.

Scope inside the proposal. Which of core HR, payroll administration, benefits administration, time and labor, scheduling, leave, employee and manager self-service, compensation, performance, recruiting, learning, health and safety, and certifications are in the proposal, which are a partner, and which are “on the roadmap.” Treat a partner as a separate contract with its own price and its own interface.

Ten-year cost. Ask for a ten-year cost that states what is included and what is not: subscription, implementation, integrations, environments, storage, the hours your staff will spend, parallel running, and the cost of the system you still have to pay for until cutover. Do not accept a single number with no boundary. Do not compare two numbers that count different things. The point of the ten-year view is to stop a low implementation quote from hiding a high run cost, or the reverse.

Integrations. Require a line for each system you actually run: finance, timekeeping, ATS, LMS, compensation software, surveys, the internal directory, badging, benefit-vendor EDI, and safety training. Direction of the data, who builds it, who maintains it, and whether it is in the quoted scope.

Data conversion and records. What converts, what archives, how long each side is retained, and who reconciles differences. Retiree and pension data, if you have them, are a requirements line. Surviving spouses and dependents who stay on benefits are a population, not a footnote.

Parallel payroll. How many parallel cycles are in the statement of work, who explains a difference, and what “accept” means before the first live payroll. If parallel payroll is “available” but not in the work plan, it is not in the project.

Independence of the people helping you read the responses. If the firm interpreting the written answers also implements one of the products, or is paid when one of them wins, the reading is not yours. How to test that is in why your HRIS consultant should not also be your implementer.

Scripted demonstrations

Give every vendor the same script, built from your requirements, with your data shapes and your rules. A sample company in a vendor tenant will not surface a bargaining-unit differential, a call-out, or a retiree who is still on your medical plan.

Run at least these scenarios, and score the transcript, not the slide:

Payroll complexity. A cycle that includes retro pay, a special pay, a garnishment, and a correction after the cycle has closed. Use your pay codes. Ask the vendor to show the audit trail a payroll manager would hand an auditor.

Union rules. One bargaining unit, or several, matching your agreements. A leave rule, a pay rule, and a seniority rule that differ by unit. If you have one union, the script is that agreement, not a generic “union” checkbox. If you have more than one, the script has to show both without a workaround that lives in a spreadsheet.

Scheduling. On-call, call-out, shift differential, and a 24/7 rotation if you run one. The person clicking should be able to explain the result to a supervisor who was not in the room. Office-hours scheduling is not a substitute.

Retiree benefits. An employee who retires, a surviving spouse or dependent who remains covered, and the file that would go to a benefit carrier. Eligibility has to be visible. The EDI (or the file format your carrier actually accepts) has to be named.

Integrations, live or specified. For each critical interface, either a working pass with your file layout or a written specification that says who builds it. A diagram labeled “we integrate with everything” does not count.

Employee and manager self-service. A manager who approves time, sees a certification that is about to expire, and cannot approve a change the bargaining agreement forbids. Self-service that only works for HR staff is a portal, not manager self-service.

Keep the scoring rubric written before the first demonstration. Change it only in the open, and apply the change to every vendor. Do not publish a score you would not show a losing proposer.

Caliber payroll requirements list with criticality ratings
Payroll requirements covering represented and non-represented pay schedules, each with a criticality rating.

Caliber is the requirements platform Avèro uses to keep that script attached to the requirement it tests.

How to decide

Decide on the written record, not on which demonstration felt smoother.

  1. Throw out any proposal that will not answer scope, ten-year cost, integrations, conversion, and parallel payroll in writing.
  2. Score the scripted demonstrations against the requirements you wrote, with the same rubric for each vendor.
  3. Put the ten-year costs on one page, with the same inclusions. Where a vendor’s number excludes something another vendor included, normalize it or label it. Do not invent a savings figure to close the gap.
  4. Name the residual risks: bargaining rules that did not fit cleanly, interfaces that are still a promise, data you cannot convert, a support end date on the incumbent that the timeline does not actually beat.
  5. Recommend the platform whose residual risk the utility can carry, at a cost the board can see. If two platforms both carry it, say so. A tie is a legitimate finding. A preference you cannot tie to a requirement is not.

Avèro’s fee does not change with the logo. We hold no reseller agreements, no implementation partnerships, and no referral fees, and we do not implement software. If you want that tested, ask it in writing. The same question belongs in front of every firm in the process, including us.

If you are choosing among these platforms, or you are not sure you should be choosing yet, write to us.

Next step

Tell us where you are.

A sentence is enough. You’ll hear back within one working day. If we can’t help, we’ll say so.