All writing

sap · successfactors · hr-data · ai · digital-transformation · 2026

Lockheed Martin's SuccessFactors Go-Live Reminded Me Why Clean Data Beats Clever AI Every Time

Lockheed Martin's HR transformation shows that AI in enterprise systems fails without solid data foundations first. Lessons that apply well beyond HR.

Lockheed Martin's SuccessFactors Go-Live Reminded Me Why Clean Data Beats Clever AI Every Time

Scoring failed — and that two-word outcome tells you everything about where most enterprise AI projects actually break down.

I came across this piece on Lockheed Martin's SAP SuccessFactors go-live and it stopped me mid-scroll. Not because it's about HR and I work in warehouse management — but because the failure pattern described is identical to what I've seen derail EWM rollouts, and honestly, any SAP implementation where someone decided AI features were the headline act.

The story is worth reading on its own terms. But here's what I took from it.

The Problem Isn't the AI — It's the Sequence

Lockheed Martin's team discovered that activating AI-driven HR scoring capabilities before the underlying data was properly structured and validated produced results nobody could trust. The model ran. Numbers came out. But those numbers were based on inconsistent, incomplete, or incorrectly mapped HR data — so the scoring was effectively noise dressed up as insight.

This is a sequencing problem, not a technology problem.

It doesn't matter how good the algorithm is if the data feeding it was migrated in a hurry, never cleansed properly, or carries the legacy assumptions of five different legacy systems. The AI has nothing real to work with.

In EWM terms, I've seen the same pattern with labour management. You configure LM reporting, set up indirect labour tasks, get excited about productivity dashboards — and then realize the master data underneath (work center assignments, task types, handling unit weights) hasn't been validated. The dashboard runs. The numbers look official. And then someone notices that a warehouse worker is apparently completing tasks in negative time, because the reference data is wrong.

Garbage in, confident-looking garbage out.

Data Migration Is Still the Hardest Part of Any SAP Project

There's a recurring temptation on large SAP programmes to treat data migration as a background workstream — the thing the data team handles while everyone else does the "real" configuration. That temptation almost always costs you time later.

What Lockheed's experience illustrates is that for AI-adjacent features specifically, this gamble is worse than usual. Traditional SAP configuration is at least transparent — you can see a wrong value in a transaction and trace it. A misconfigured AI feature fails less visibly. The output looks plausible. You have to know what correct looks like to spot that it isn't.

The article points to SuccessFactors' AI capabilities as genuinely useful — but only once the foundational HR data (employee records, org structures, position management) is clean, consistent, and properly mapped. That's not a criticism of the AI. That's just how it works.

What "Data First" Actually Means in Practice

Saying "data first" is easy. Doing it on a programme with executive pressure to show AI features at go-live is harder. A few things that actually help:

Define what good looks like before migration starts. Not just field mappings — actual business rules. If an employee record doesn't have a valid cost center, what happens? If a position is unfilled, does it still generate a score? These questions need answers before the data lands in the system, not after.

Run your AI features in parallel on test data first. If you have a scoring model or a productivity metric that uses ML logic, run it against your migrated test data during UAT and ask the business to sanity-check the outputs. Not just "does it run" — but "do these results make sense to someone who knows these people or these processes."

Accept that some features need to wait. This is the uncomfortable one. If the data isn't ready to support a feature, that feature doesn't go live on day one. Pushing it anyway to hit a demo target is how you lose credibility with the business users who were supposed to trust the new system.

This Applies Everywhere SAP Is Adding AI

SAP is pushing AI capabilities across the board — into EWM, into SuccessFactors, into procurement, into finance. Some of it is genuinely useful. But the Lockheed story is a useful reminder that these features don't float above the data layer. They depend on it completely.

Before asking "how do we activate this AI feature," the more useful question is: "is the data this feature will consume actually trustworthy right now?"

If you can't answer yes to that, you already know what comes next.

Scoring fails.


If you're working through a similar challenge — in HR, in EWM, or anywhere else in the SAP stack — I'm writing about this kind of thing regularly at markus-mildner.com. Worth a look if this resonated.