SuccessFactors Data and Analytics

Reporting parity in the move from SuccessFactors to SmartRecruiters: the workstream that always gets scoped last or not at all

Picture the move from SuccessFactors Recruiting to SmartRecruiters. The ATS implementation was a success. The process, tech and change management landed, and the system is ready to go. Data and analytics sits in post-project activities.

Ten months into business as usual, the heads of Talent Acquisition and HR are asking why they cannot see meaningful data from the system.

Eleven months later, your CFO is asking why pipeline velocity by business unit isn't showing up in the new system.

This is the most common post-launch failure mode in SuccessFactors-to-SmartRecruiters projects. The reporting workstream gets scoped late in the proposal, deferred to a phase that never quite arrives, and surfaces as a gap once go-live has happened and the conversation is no longer about scope but about a change request.

Why reporting gets scoped last every time

The scope tells the story:

• No KPIs. A meaningful KPI library is almost never asked for and almost never set up. It gets parked in "Phase 2". The problem is that the way your ATS is configured directly shapes how data and analytics will work when you finally need it.
• Light report training. Training during implementation tends to cover how reporting works, not the value or the insights it should provide the organisation.
• Dashboards out of scope. Dashboards and data visualisation are rarely in scope. If the foundation data is not created correctly during the build, the output cannot be of much value.

The structural causes sit underneath:

• The vagueness of "data parity". SuccessFactors report libraries are large and undocumented. A partner cannot price what it cannot inventory, so "reporting parity" lands in the proposal as a Phase 2 line item with no numbers behind it.
• Buyer attention. TA leaders evaluating proposals focus on the candidate experience, the recruiter workflow, and the integrations. Reporting feels like an IT problem until the executive layer realises it has lost visibility.
• Incentive misalignment. Partners do not lead with reporting because it does not demo well and it is not on the success-criteria list anyone is graded against in the first month after go-live.

Udder is a SmartRecruiters partner, and reporting is one of the two workstreams we see under-delivered most often. The other is integration with SAP HCM and Employee Central. The view below is shaped by how often we have watched this go wrong after launch, including on projects we were not running.

The four definitions of "parity" that are conflated

When a proposal says "reporting parity with SuccessFactors," that phrase covers four different scopes of work. Most partners blur them into one line item.

• Data parity. The foundation data records (candidates, requisitions, applications, notes) are accessible and queryable in the new system. Without data parity, nothing else holds.
• Report parity. The same individual reports exist with the same columns, filters, and outputs. A "Time to Hire by Hiring Manager" report in SuccessFactors maps to an equivalent in SmartRecruiters.
• Dashboard parity. The same dashboards (recruiter, executive, hiring manager) exist with the same visualisations and the same drill-throughs. Different from report parity. Dashboards are what executives actually open.
• Insights parity. The same analyses are possible: cohort analysis, trend reporting, year-on-year comparisons, ad-hoc drill-throughs by business unit. This is the layer where historical SuccessFactors data has to talk to current SmartRecruiters data.

Most partner proposals quote "reporting parity" while pricing only data and report parity. Dashboards and cross-system analytical work are usually out of scope or unspecified.

This matters because the executives who care about reporting (CPO, CFO, hiring manager leadership) consume the dashboard layer. If your dashboards don't survive the move, the post-launch perception is that reporting "doesn't work," even if the underlying reports technically exist.

Most clients don't need 100% of all four layers. A full makeover is a chance to drop the legacy reports nobody opens. The question is which 30 to 40% your function genuinely needs, not which 100% you'd be quoted for.

The 7-question audit to run before the brief goes out

This is the reporting-specific slice of the broader actual-state inventory covered in the [90-day checklist piece]. If you haven't done that broader inventory yet, start there. If you have, run this on top.

• The Talent Acquisition Metrics Framework. Does a TA framework exist, are there agreed KPIs to measure success and provide insights to better decision making. If there are not, start here.
• Inventory the reports actually being used. Skip the full report library and pull last-12-months usage data: which reports were opened, by whom, how often. Most SuccessFactors instances have 80% or more unused reports sitting in their library.
• Map each live report to a stakeholder and a decision. Who runs it, who reads it, what decision does it support? A report with no living consumer is noise, even if it has been running for 4 years.
• Identify the dashboards your executives actually open. These are different from reports. The CPO dashboard, the CFO snapshot, the recruiter morning view. Name them and the audience for each.
• Flag the cross-system analyses you need. Anything that compares historical SuccessFactors data to current SmartRecruiters data after go-live. These usually need a separate solution (middleware, data warehouse, or BI tool), because the systems don't share a native analytics layer.
• Note cadence and audience expectation. Daily, weekly, monthly. Email-delivered or pull-based. The audience expectation defines the rebuild bar more than the underlying complexity does.
• Mark the reports that won't carry. Some SuccessFactors reports rely on data structures that don't exist in SmartRecruiters. Flag these now so they get a substitution proposal, not a rebuild proposal.

Output: a reporting inventory document. One page if your reporting estate is small, three to five pages if it's complex. This document is what turns "reporting parity" from a phase 2 line item into a concrete, priceable workstream.

What good looks like in the proposal that comes back

When you've sent the audit doc with the brief, here's what a proposal that has actually engaged with reporting looks like.

• The proposal references the audit doc by line item. Not a generic "reporting parity included." A line per dashboard, a line per report category, a line per cross-system analysis.
• Parity is split across the four layers. Data, report, dashboard, analytical. Each one is named, scoped, and either included or explicitly excluded.
• Cross-system analytical work is its own workstream. If your audit flagged historical comparisons, the proposal should have a separate line for the middleware or BI solution that enables them. If it doesn't, that work is silently out of scope.
• A rebuild vs. substitution decision is offered per report. Some reports should be rebuilt as-is. Some should be replaced with the SmartRecruiters-native equivalent, which may be better, worse, or just different. The proposal should name which is which, and explain the reasoning where it isn't obvious.
• Reporting is in the go-live success criteria. "Go-live" should be defined as "candidates can apply AND priority dashboards are live." The candidate-side milestone on its own isn't enough.

If the proposals in front of you don't do these things, push back. The information is cheap to add at the proposal stage. Adding it post-signing is a change request.

The post-launch test

The post-launch test of whether reporting got scoped well is simple. In week 4 after go-live, can your CPO open the dashboard they used to open, get the number they used to see, and trust it?

If yes, the reporting workstream was scoped properly.

If not, you're in a change request conversation, often with a budget that has already been committed elsewhere. The 6-question audit costs a week of your team's time. The change request to retrofit reporting costs anywhere from 4 to 12 weeks, depending on the gap.

Need a second pair of eyes on the reporting workstream?

If you want help running the audit, or pressure-testing the reporting section of a proposal you've already received, that's the conversation we're having most often this year with clients moving past discovery. Udder is a SmartRecruiters partner, and reporting is one of the two workstreams where we see projects most often under-deliver. We've got an opinionated view of what good looks like.