Coriza
“We Had to Change Everything”: Leading Business Transformation in PNG with SAP and Coriza

“We Had to Change Everything”: Leading Business Transformation in PNG with SAP and Coriza

by | Sep 29, 2025 | Blog Post, Case Study, CFO, CIO, Cross Industry, Financial Controller, Manufacturing, Program Manager, SAP S/4HANA Cloud, Warehouse Manager

Running a market-leading business in Papua New Guinea is not for the faint-hearted.

by Simon Barstow – General Manager Dulux PNG

 

At Dulux PNG, we manufacture and distribute paints, coatings, and chemicals across some of the most complex and challenging terrains in the world. Our teams operate in a fast-paced, resource-constrained environment, and we take immense pride in doing it well.

But a few years ago, it became clear that we couldn’t keep going the way we were. Our systems were outdated, our processes manual and error prone, and our people didn’t trust the ERP platform. Each department kept its own spreadsheets, and decisions were made in a silo rather than based on validated information.

We didn’t just need better software, we needed to fundamentally rethink how the business operated.

When I joined Dulux PNG, our ERP system wasn’t designed for manufacturing or commercial use, didn’t support remote sales, and offered zero visibility into procurement, production costs, or sales performance.

Everything from warehouse picking to delivery tracking was done manually. I still remember customers saying they couldn’t pay invoices because they hadn’t received the delivery docket, which meant we had to go digging through boxes to find it.

That kind of inefficiency wasn’t sustainable, not for our people, not for our customers, and certainly not for our future.

 

Download our eBook

The Impact of the Systems and Partners You Choose

Since DuluxGroup uses SAP globally, it made sense for us to align from a platform perspective. But implementing SAP in Papua New Guinea is not a simple copy-paste. Our business environment is unique, fast-moving, hands-on, and full of operational nuances that don’t exist in a typical corporate playbook. We needed more than a system, we needed a partner who could navigate that reality with us.

I was looking for a team that wouldn’t just deploy technology, but one that would embed themselves in our business. A team willing to listen, challenge our assumptions, and work alongside us to build something sustainable for the long term. We didn’t need a vendor, we needed a true partner.

That’s exactly what we found in Coriza.

From the beginning, they were clear, honest, and deeply engaged. They didn’t try to impress with buzzwords or over promise outcomes. Instead, they asked hard questions, pushed us to rethink old habits, and helped us focus on what would truly drive value. That kind of straight talk, and their commitment to understanding our context, was invaluable.

 

Fixing the Foundations: Data, Process and People

Before we could move forward, we had to understand exactly where our processes were hitting a wall. That meant starting with a full health check across every core function: finance, warehousing, procurement, sales, and beyond. We looked at how transactions flowed, where handoffs stalled, and how data was being captured, shared, or lost along the way. It quickly became clear that our problems weren’t isolated. They were systemic.

Once we had that baseline, we went straight to the heart of it: the data. Poor-quality data was undermining everything: product codes were inconsistent, pricing data was duplicated, vendor records had gaps. Cleaning up our master data was no small job, but it was essential. Once that work was done, I could finally look at a report and know it reflected the truth.

With better data came the chance to revisit how our processes actually worked. We didn’t just want to replicate old habits in a new system. We mapped out how we wanted things to run, using SAP’s standard capabilities as the reference point. That forced us to rethink how quotes got created, how inventory moved, and how approvals were managed. In many cases, simplifying our processes created efficiencies we hadn’t even been aiming for.

And of course, none of it would stick without our people. This wasn’t just about learning to click the right buttons. We spent time explaining why the changes mattered, showing how their work connected to business outcomes, and giving them space to ask questions and test things out. It wasn’t always smooth, but gradually, people stopped seeing SAP as an obstacle and started seeing it as a tool they could trust.

One of the biggest turning points came when team members who had previously avoided SAP started coming to us saying, “I’m still doing this in Excel, how do I move it into SAP?” That shift, from resistance to ownership, was when I knew the culture was changing.

The Results: Faster, Smarter, More Agile

The transformation has been significant.

  • We now close our books on Day 1. The finance team has live, clean data and no longer needs to spend days chasing adjustments.
  • Quotes that used to take 4–5 days now go out in 24 hours. Our sales teams can act quickly, and our customers notice the difference.
  • Warehouse operations are dramatically faster. Bin locations mean our teams pick, pack, and move without wasting time.
  • OTIF is now over 95%. That’s a major boost to customer satisfaction.
  • We’re nearly fully paperless. This isn’t just about efficiency, it’s a big win for sustainability too.

And the biggest shift? We now run the business based on facts, not assumptions. Decisions are made with real-time data at our fingertips, giving us the confidence to act quickly and accurately. Whether it’s approving a purchase order, reviewing a sales pipeline, or assessing performance, we know we’re working from a single, trusted source of truth. I travel often, but even from a plane I can review quotes, approve POs, and stay in control. That visibility changes everything.

Lessons from the Journey

Looking back, here’s what I’d tell anyone starting a similar transformation:

  1. Avoid customisation wherever possible. Sticking to SAP’s standard features keeps the system simpler, cheaper to run, and easier to upgrade. The more you customise, the more you introduce long-term complexity and cost.
  2. Get your data right. Clean, consistent data is the foundation for everything.
  3. Choose a partner who tells you the truth. You want people who know your business and aren’t afraid to challenge you.
  4. Empower your team. The system only works if your people believe in it and take ownership.
  5. Treat it as a journey. We’re still improving, still digitising, and still finding ways to get better.

Where We’re Headed

We’ve laid a solid foundation, but we’re not finished. Next, we’re building out reporting dashboards, expanding forecasting capabilities, and digitising the last of our manual workflows.

With Coriza as our long-term partner, I’m confident we’ll get there.

SAP and Coriza haven’t just modernised our systems, they’ve helped us become faster, more resilient, and more in control. We’re leading the market in PNG, and we’re only just getting started.

More Resources

AI for SAP: Joule or Copilot — What CFOs and Business Leaders Need to Know

AI for SAP: Joule or Copilot — What CFOs and Business Leaders Need to Know

by | Sep 29, 2025 | AI & Automation, Blog Post, CFO, CHRO, CIO, Consumer Products, Cross Industry, Demand Planner, Distribution, Finance Leadership, Financial Controller, HRIS Manager, Manufacturing, Professional Services, Program Manager, SAP S/4HANA Cloud, Warehouse Manager

Most executives no longer ask whether AI makes a difference. We have all seen how quickly a draft board paper or customer email can appear on screen. What once took hours now takes minutes. The question has shifted. It is no longer “does AI help?” It is “where do we apply it, and how do we apply it safely?

For organisations that run SAP and Microsoft 365, the practical conversation almost always comes down to two names: SAP Joule and Microsoft Copilot.

There are plenty of other AI products in the market. ChatGPT, Gemini and Grok are all part of the landscape. But for CFOs and CIOs leading organisations built on SAP, and with Microsoft 365 as the productivity backbone, the real decision point is whether to adopt Joule, Copilot, or both.This article explains what each option offers, why they matter for finance and operations leaders, and what questions you should be asking before you take the next step.

 

Why This Matters Now

Most executives no longer ask whether AI makes a difference. We have all seen how quickly a draft board paper or customer email can appear on screen. What once took hours now takes minutes. The question has shifted. It is no longer “does AI help?” It is “where do we apply it, and how do we apply it safely?

For organisations that run SAP and Microsoft 365, the practical conversation almost always comes down to two names: SAP Joule and Microsoft Copilot.

There are plenty of other AI products in the market. ChatGPT, Gemini and Grok are all part of the landscape. But for CFOs and CIOs leading organisations built on SAP, and with Microsoft 365 as the productivity backbone, the real decision point is whether to adopt Joule, Copilot, or both.This article explains what each option offers, why they matter for finance and operations leaders, and what questions you should be asking before you take the next step.

 

SAP Joule: AI inside the ERP

SAP Joule is not an add-on. It is built into SAP’s cloud applications, including S/4HANA Cloud and SuccessFactors. That means it already understands SAP’s data models, transactions, and authorisations.

Think of it as a native assistant. Ask Joule why a purchase order is blocked, and it will respond using the same rules and data you trust inside SAP. Ask it to provide a summary of supplier performance, and it draws from your live transactional data. There is no need to build connectors or map roles. Joule already knows who you are and what you are allowed to see.

This is its greatest strength. Joule inherits SAP’s governance model. If your role in SAP restricts you from seeing certain data, Joule respects that same rule. SAP has also confirmed that customer data processed by Joule is not used to train external foundation models. For leaders, this offers a level of confidence that consumer AI tools cannot provide.

Joule is also designed to evolve as SAP evolves. SAP has committed to extending Joule’s reach across its portfolio, with new skills and agents arriving over time. That roadmap is important. It means that adopting Joule is not a one-off project. It is a way of ensuring that AI becomes part of how you run SAP, release after release

Microsoft Copilot: AI where your people work

While Joule is embedded in SAP, Microsoft Copilot lives in the tools your teams use every day — Outlook, Excel and Teams. This is where most finance teams spend their time, so the productivity benefit is immediate.

The way it works is straightforward. Copilot connects into SAP using certified APIs. From there, it can bring live data into the Microsoft 365 environment. Ask Copilot in Outlook to prepare a collections email, and it can pull the relevant balances from SAP, merge them with customer details, and draft the email ready for review. Ask Copilot in Excel why operating expenses are above budget, and it can analyse the variance, link to SAP transactions, and draft commentary that you can paste straight into a board pack.

The real advantage of Copilot is that it can combine SAP data with other corporate information managed inside Microsoft 365. That might include policy documents stored in SharePoint, supplier contracts in OneDrive, or communications in Teams. This cross-system capability is powerful because real decisions are rarely made on ERP data alone. Leaders often need context, documents and communication history. Copilot can surface these in one place.

Microsoft has also developed a specific Copilot for Finance. This is designed for finance teams and supports scenarios such as reconciliations, variance analysis and collections. While some of these features are still in preview, the direction is clear: Microsoft is making finance a core focus for Copilot inside Microsoft 365.

Why not just use ChatGPT?

It is a fair question. ChatGPT is quick, flexible and already used by many teams. For some tasks it works well. But when it comes to ERP data, the risks are obvious.

ChatGPT does not enforce SAP authorisations. It does not integrate with Microsoft tenant security. And while consumer versions of ChatGPT may use prompts to improve their models, both SAP and Microsoft have been clear that enterprise data accessed through Joule or Copilot is not used to train foundation models for others.

ChatGPT can generate answers, but it cannot act directly on SAP data. It cannot approve an invoice, prepare a live collections email, or provide commentary linked to transactions in your ERP. That is why organisations serious about AI in finance and operations look to Joule or Copilot. They are designed for enterprise use, with security, governance and auditability in mind.

Security and governance considerations

For most CFOs and CIOs, the attraction of AI is tempered by a single concern: security. Productivity gains are only valuable if they do not compromise compliance or governance.

With Joule, the rules are clear. It inherits SAP’s security model. Authorisations apply and the ERP remains the system of record. With Copilot, governance is handled through Microsoft tenant controls. Data policies and loss-prevention rules set the boundaries for how SAP data is used inside Microsoft 365. In both cases, prompts and actions should be logged so there is always an audit trail.

There is also the question of ownership. AI that draws on ERP data is not just an IT project. Finance leaders need to be directly involved in shaping use cases, testing outputs, and defining success measures. CIOs bring the technical expertise to manage connectors, security and compliance. CFOs bring the accountability for process integrity and financial outcomes. Both roles must share ownership from the outset.

Data quality and readiness

Another consideration is data quality. AI is only as good as the data it draws from. If your SAP master data is inconsistent, if roles and authorisations are poorly managed, or if your processes rely heavily on manual workarounds, AI will simply amplify those issues.

This is where experience shows that sequencing matters. Organisations that have stabilised their ERP first — cleaned master data, simplified processes, built trust in the system — are better placed to benefit from AI. If those foundations are weak, AI adoption can expose flaws instead of delivering value.

Joule or Copilot? The Practical Answer

So which should you choose? In reality, most organisations will end up using both. Joule is best for AI inside SAP transactions. Copilot is best when SAP data needs to be combined with other information inside Microsoft 365.

For example:

  • A supply chain manager may use Joule to explain why a purchase order is blocked and suggest the next step.
  • The finance team may use Copilot in Outlook to prepare a collections email that merges SAP data with customer contact details.
  • A CFO may use Copilot in Excel to draft board commentary based on SAP variances, while relying on Joule inside SAP to confirm transactional accuracy.

The two products are already being integrated. SAP and Microsoft have announced bi-directional links between Joule and Microsoft 365 Copilot. That means users will increasingly be able to start in either environment and reach into the other.

The choice is not either/or. The real decision is where to start, how to scale, and what guardrails to put in place.

Adoption guardrails: a practical roadmap

Executives need more than a vision. They need to see a disciplined approach. A simple adoption roadmap could look like this:

Phase 1: Identify scenarios (0–30 days)
Start with 2–3 scenarios that matter most to Finance. Collections, variance commentary and reconciliations are common candidates. Define the KPIs you want to influence, such as DSO, close cycle time or audit preparation hours.

Phase 2: Secure governance (30–60 days)

Review SAP roles and authorisations to ensure they are accurate. Configure Microsoft tenant policies, including data loss prevention rules, for Copilot. Establish a process for logging prompts and responses.

Phase 3: Run pilots with Finance ownership (60–90 days)

Deploy Joule or Copilot in the chosen scenarios. Have Finance own the outcomes while IT ensures compliance. Measure progress against the defined KPIs.

Phase 4: Scale carefully (beyond 90 days)

Extend to additional use cases once the first pilots prove reliable. Continue reviewing governance and data quality. Treat AI adoption as a business discipline, not a technology experiment.

This phased approach keeps expectations realistic, avoids technical debt, and demonstrates value early.

What CFOs and CIOs should ask now

Before you commit to a path, ask yourself these questions:

  1. Do we have a clean ERP foundation that AI can build on?
  2. Are our SAP roles and authorisations accurate and enforced?
  3. Do we have Microsoft tenant policies in place to govern the use of SAP data inside Copilot?
  4. Which finance metrics matter most in the next 90 days — cash, close cycle time, audit readiness — and how could AI improve them?
  5. What guardrails will we use to measure and control the impact of AI adoption?

These questions ensure that AI adoption is not just a technology choice but a business discipline.

Act with Intent

AI in SAP is no longer theoretical. Joule and Microsoft Copilot are here now. Each has distinct strengths. Joule is embedded in SAP and designed for in-system intelligence. Copilot is integrated into Microsoft 365 and designed for cross-system context. Together, they cover most use cases CFOs and CIOs face.

The question is not which is better. The question is how to apply them safely, in the right sequence, and with the right guardrails.

At Coriza, we help organisations answer that question. We focus on practical adoption that delivers results in 90 days. Whether it is accelerating cash collections, shortening the close, or strengthening governance, we ensure AI adoption is measurable, secure and aligned with your business.

Book a 30-minute AI Readiness Review with Coriza. We will map out your Joule and Copilot opportunities, review your governance posture, and create a plan that works for your organisation.

 

More Resources

Your ERP Partner Needs the Confidence to Guide, Not Just the Skills to Configure

Your ERP Partner Needs the Confidence to Guide, Not Just the Skills to Configure

by | Sep 20, 2025 | Blog Post, CFO, CHRO, CIO, Consumer Products, Cross Industry, Distribution, Financial Controller, Manufacturing, Professional Services, Program Manager, SAP S/4HANA Cloud, Warehouse Manager

The Hidden Risk in ERP Projects

ERP implementations are among the most complex initiatives an organisation can undertake. They promise new levels of transparency, control, and agility, yet too many still fall short. Projects run over budget, take longer than expected, or fail to deliver the business improvements that executives were counting on.

The problem is not usually the technology. SAP S/4HANA Cloud, SuccessFactors, and other leading ERP platforms are proven, reliable, and scalable. The problem is in how they are implemented.

One of the most overlooked risks is the partner dynamic. Many ERP partners are highly skilled technically, but weaker when it comes to business process advisory. As a result, they fall into a pattern of saying “yes” to client requests. On the surface, this feels safe: the client gets what they ask for, and the partner avoids blame if something later breaks.

But safe is not the same as successful. An ERP partner that cannot challenge assumptions, push back on poor decisions, or guide clients toward fit-to-standard practices leaves the business exposed to failure.

The truth is simple. ERP projects succeed when partners combine technical skills with the confidence and process expertise to guide.

Why Partners Say Yes Too Often

It is easy to see why “yes” becomes the default response.

  • Technical focus without process strength: Many consultants know the system inside out but are less confident discussing the client’s broader business operations. If they are not sure how a design choice will impact finance, procurement, or compliance, they default to following instructions.
  • Client-driven safety net: Some partners believe that if the client makes the decision, the responsibility for failure sits with them. If the project under delivers, the partner can say, “We built what you asked for.”
  • Avoiding conflict: ERP projects are stressful and high stakes. It can feel easier to keep clients comfortable than to confront them with hard truths.

The result is an ERP system that mirrors the old world. Legacy processes are rebuilt inside a new platform. Data issues are papered over instead of solved. Customisations proliferate because no one was confident enough to explain why they were unnecessary.

That is how businesses end up with expensive, complex systems that still require workarounds and do not earn the trust of their people.

The Value of Confidence in ERP Delivery

A confident partner does not just configure the system. They guide the business toward practices that are proven, sustainable, and aligned with cloud principles.

  • They challenge assumptions. If a client wants to rebuild an old approval chain that adds no value, they explain why it should be simplified.
  • They protect the long term. By resisting unnecessary customisation, they ensure upgrades remain simple and costs remain low.
  • They strengthen adoption. By showing staff not just how the system works but why processes are changing, they build ownership and trust.
  • They reduce risk. By insisting on data cleansing and fit-to-standard processes, they prevent failure before it happens.

This is not about being combative. It is about bringing the right mix of business process strength and technical expertise so clients can make informed decisions.

Dulux PNG: Transformation Through Guidance

When Coriza partnered with Dulux PNG, the business was struggling. Systems were outdated, processes were manual, and staff did not trust the ERP. Customers even refused to pay invoices because proof-of-delivery documents were missing.

The easy path would have been to say “yes” to every request: rebuild processes as they were, configure around messy data, and hope for the best. Instead, we took the harder path.

  • We told the business their data had to be cleansed and standardised before transformation could succeed.
  • We challenged legacy processes, mapping them back to SAP best practice instead of replicating old inefficiencies.
  • We worked with staff to build ownership, explaining why change mattered and giving them confidence to move work out of spreadsheets and into the system.

The results were significant:

  • Day 1 month-end close instead of weeks of adjustments.
  • Sales quotes in 24 hours instead of 4–5 days.
  • On Time In Full (OTIF) above 95 percent, a direct lift in customer satisfaction.
  • Warehouse operations digitised and accelerated, with bin locations and paperless workflows.

Perhaps the most important shift was cultural. Employees who had avoided SAP began asking how to use it for more of their work. That transformation did not come from saying yes. It came from having the confidence to guide.

Bubs Australia and the Cook Islands: Facing Hard Realities

The same approach shaped our work with other clients.

  • Bubs Australia, a fast-growing FMCG company operating across Australia, the USA, and China, had fragmented systems that slowed order management. We were clear: their patchwork could not scale. By moving to SAP Cloud ERP and integrating with Shopify, they achieved real-time stock visibility, faster order processing, and a unified platform for international growth.
  • The Cook Islands National Superannuation Fund relied on Excel for core finance and procurement. It worked in the short term, but left the organisation exposed to errors and inefficiency. Our position was firm: spreadsheets are not a system of record. By adopting SAP Cloud ERP, the Fund gained real-time bank reconciliation, stronger compliance, and audit-ready reporting.

In both cases, the outcome depended on more than technical configuration. It depended on telling clients the truth about what was holding them back, then guiding them toward best practice.

The Cloud Mindset: Learning from Larger Enterprises

One of the biggest traps in ERP transformation is trying to replicate what came before. Clients ask for custom reports, bespoke workflows, or approval hierarchies designed for another era.

The problem is that cloud ERP is not meant to be a copy of legacy systems. It is built on decades of best practice. The businesses that succeed in the cloud are the ones that embrace that standard.

Larger enterprises that spent decades running heavily customised ERP systems have now made it a priority to simplify. Their common goals are clear:

  • Remove customisations that created complexity and cost.
  • Adopt standard content so the system is easier to run and easier to upgrade.
  • Eliminate technical debt that has been holding them back.

For new adopters of cloud ERP, the lesson is obvious. Do not repeat the mistakes of the past. Do not replicate inefficiencies or build technical debt into your first system. Start clean, adopt standard, and design for the future.

Why Clients Resist Best Practice

If fit-to-standard and clean design are so clearly beneficial, why do many clients resist them?

  • Familiarity: People are comfortable with the way things have always been done, even if those processes are inefficient.
  • Perceived uniqueness: Every organisation believes its processes are different. In reality, most are standard variations already covered in cloud ERP.
  • Fear of change: Simplification feels like losing control, when in fact it creates control by reducing hidden workarounds and errors.

This is where partner confidence matters most. Without it, clients default to old habits and partners fall into the trap of saying yes. With it, the business is guided toward choices that will stand the test of time.

Four Truths Every ERP Project Needs

Across industries and regions, four truths consistently separate successful projects from failed ones:

  • Data is non-negotiable. Clean, consistent master data underpins everything.
  • Customisation kills agility. Stick to SAP standard unless there is a clear, costed business case and an exit plan.
  • People drive adoption. ERP is not just a system change, it is a cultural shift. Teams must understand why the changes matter.
  • Transformation is a journey. Go-live is only a milestone. Continuous improvement is what sustains value.

Manufacturing is at a Crossroads: Why Truth Matters Now

Australian manufacturing illustrates why this matters. The sector contributes just 5.5 percent of GDP, down from double digits in past decades, yet still employs over 930,000 people. Costs are rising, demand is fragile, and churn is high, with 437,000 businesses opened in 2024–25 and 370,000 closed in the same period.

In this environment, transformation is not optional. It is survival.

Yet too many manufacturers still rely on spreadsheets, outdated systems, and manual workarounds. The result is slow reporting, unreliable customer commitments, and cash locked in the wrong inventory.

The truth is straightforward:

  • Excel is not ERP.
  • Manual processes do not scale.
  • Siloed data kills transparency.

The Dulux PNG story shows what happens when these truths are accepted. Month-end closes fall to Day 1, customer reliability improves, and decisions are made on real-time data. That is the payoff of choosing a partner with the confidence to guide.

What Executives Should Demand from Their ERP Partners

For CFOs, CIOs, and COOs, the choice of partner can make or break transformation. The right partner should:

  • Challenge assumptions and explain alternatives.
  • Insist on cleansing and standardising data before configuration.
  • Resist unnecessary customisation and protect the long term.
  • Stand by business outcomes, not just technical go-live.

These are the hallmarks of a partner that has both technical strength and business process confidence.

More Resources

Avoiding SAP SuccessFactors Data Migration Failures: A Strategic Guide

Avoiding SAP SuccessFactors Data Migration Failures: A Strategic Guide

by | Jul 1, 2025 | Blog Post, CFO, CHRO, CIO, Cross Industry, Data Migration, HRIS Manager, Program Manager

Why SuccessFactors Data Migration Fails Before It Starts

For most HRIS leads and program sponsors, SAP SuccessFactors data migration starts with a spreadsheet.

And every failed SuccessFactors migration starts the same way: someone fills out the spreadsheet, thinking that’s the job.

But weeks later, the load fails. SIT is delayed. Payroll testing stalls. And suddenly, that supposedly simple spreadsheet becomes the symbol of a much larger issue, one that was never really about the spreadsheet at all.

This is the story of how SuccessFactors projects get blindsided by data. And why it keeps happening.

Download our eBook

Why SAP SuccessFactors Data Migration Fails Before It Starts

SAP provides load templates for every SuccessFactors object. That’s not the problem.

The problem is that these templates look deceptively straightforward, and that gives internal teams and sponsors a false sense of confidence.

What’s not visible in the spreadsheet:

  • Dependencies across configuration, job data, and pay structures
  • Fields governed by SuccessFactors-specific logic and validation rules
  • Transformation challenges from legacy, unstructured data
  • A need for formal ownership, version control, and mock-load rehearsal
  • Org structure design often evolves during the project, introducing new hierarchies, roles, or cost centre models that legacy data simply wasn’t built to support

What starts as a “fill in the blanks” task quickly becomes a source of risk the project was never resourced to manage.

What Happens When Your Mock Load Fails

Coriza is often called into projects where mock loads have already failed, or SIT has slipped due to reconciliation issues. The patterns are clear:

  • Teams assume the templates are the process
  • No one owns key decisions about mapping or validation
  • Mock loads are treated as technical checks, not structured rehearsals

In one case, the data team believed they were ready, until pay groups failed validation and test teams had to manually backfill records just to keep moving. In another, business units interpreted mapping requirements differently, resulting in inconsistent files that couldn’t be reconciled.

By the time the problem shows up, the fix is never just technical. It’s structural.

Why Implementation Partners Can’t Own Your SuccessFactors Data

What they won’t do, unless explicitly contracted, is:

  • Profile your legacy data for risk and gaps
  • Design transformation logic across inconsistent business rules
  • Define the validation process or sign-off governance
  • Assign data ownership or build a reconciliation framework
  • Sequence mock loads against program gates like UAT or PPR1

More importantly, they can’t and won’t own the data outcome. That responsibility always sits with the business. While partners may provide technical support and tooling, they typically won’t have time to sit with each business unit, interpret data definitions, or guide internal decision-making. Their role is to load what you give them, not to validate whether it’s correct, complete, or aligned to business rules.

That work? It falls to you. And most internal teams aren’t set up for it.

A spreadsheet is an artefact. A migration strategy is what makes it usable.
Without a documented process, tooling, sequencing, ownership, and validation, templates just capture errors in a more organised format.

Your implementation partner will configure the system and provide load templates.

SuccessFactors Data Migration Requires Strategy, Not Just a Spreadsheet

What looks like a spreadsheet task is actually a full-scale delivery stream. It requires:

  • Resourcing: SMEs with time to engage and authority to decide
  • Sequencing: Activities aligned to configuration and testing milestones
  • Governance: Named owners, validators, and decision checkpoints
  • Tooling: Trackers, DOMDs, validation scripts, and audit controls

Without this structure, projects fall behind quietly, then all at once.

How Coriza Helps Prevent SAP SuccessFactors Migration Failures

At Coriza, we specialise in data migration for SAP environments, including SuccessFactors.

Our framework supports clients across all stages, from readiness planning to full-cycle migration and reconciliation. We don’t just fill out templates, we help you build the governance, tooling, and structure that protects your go-live.

Whether you need targeted support for mock loads or an end-to-end migration partner, we bring the experience and frameworks that reduce rework, delays, and downstream risk.

Download Our Full SAP SuccessFactors Data Migration Playbook

Coriza’s new eBook, Why Data Migration is the Silent Risk in SAP SuccessFactors Projects, dives deep into:

  • Why so many projects fail at the first mock load
  • The governance and tooling most programs overlook
  • How to build a load-ready data stream without overloading your SMEs
  • What “clean data” really means in SuccessFactors
  • The playbook our clients use to avoid rework, delays, and payroll failures

Download the full eBook
👉Here

Q&A

What causes data migration failure in SAP SuccessFactors projects?

Failure typically stems from late mobilisation of the data team, unclear ownership, relying too heavily on the implementation partner, or underestimating the complexity of mapping legacy data to SuccessFactors. Without a structured strategy and early accountability, errors cascade through every cycle.

What are early warning signs of a data migration at risk?

Watch for:

  • Delays in receiving or validating source data

  • No clear rules for data transformation

  • Repeated rework during test cycles

  • Business users disengaged from validation
    These are red flags that migration may fail under pressure during UAT or go-live.

Why can't we rely on the partner to ensure data readiness?

Because the partner expects load-ready data to be provided in the templates they’ve issued. It is your organisation’s responsibility to populate those templates with clean, complete, and validated data.

The partner is primarily focused on delivering the functional and technical scope of the system — on time and on budget. Data preparation is generally out of scope and rests with the client.

Only your business understands the meaning, history, and compliance context of HR and payroll data. The partner can migrate it, but they can’t assess its fitness for purpose or sign off on its accuracy.
If you wait for them to raise concerns, it’s already too late — their role is to facilitate delivery, not to own accountability.

What can sponsors do to avoid data migration failure?
  • Mobilise data leadership early — not just a tech lead, but a business-side sponsor with decision-making authority.
  • Make data part of governance — include it in every steering committee and risk review.
  • Resist the “leave it to the partner” mindset — because no partner can own what they can’t sign off.
  • Invest in rehearsal cycles — failure in test is a gift; failing at go-live is a disaster.

    More resources

    Your Best Practice Guide to SAP SuccessFactors Data Migration

    Your Best Practice Guide to SAP SuccessFactors Data Migration

    by | Jun 27, 2025 | Blog Post, CFO, CHRO, CIO, Cross Industry, Data Migration, HRIS Manager, Program Manager

    Why Every Sponsor Needs to Care About Data Migration

    In SAP SuccessFactors projects, teams are often focused on transformation outcomes: improved experience, efficiency, better process alignment, accurate, actionable analytics. Yet the accuracy and integrity of data is what underpins every transformation outcome – and it’s often forgotten until it’s too late.

    Let’s take a typical scenario. A sponsor greenlights the project and assigns a program lead. Data is considered a tactical stream – so it’s assigned to internal HR and IT teams. The system integrator provides templates for data input, but internal teams are buried in BAU and design workshops. Mock 1 approaches, and the load fails. Fields are missing, structures are misaligned, and the system integrator escalates the issue. Suddenly, a six-week catch-up effort begins, derailing confidence and stretching already overloaded resources. What’s worse, without a repeatable process and clear project resources accountable for the data stream, Mock 2 approaches rapidly and compounds the risk. Now it’s a red item on the project risk register, with leadership asking why this wasn’t flagged earlier.

    This is avoidable. But only when sponsors understand that data migration is not just a backend activity – it’s a foundational part of ensuring the platform delivers as intended.

    Sponsors don’t need to be data architects. But they do need to be informed, engaged, and ready to act early – because decisions made in the very early weeks can make or break the implementation.

    Download our eBook-

    The Hidden Workstream that can Make or Break Your SAP SuccessFactorsProject. here

    What Sponsors Often Miss

    We’ve seen well-intentioned sponsors fall into these common traps:

     

    • “We’ve been given all the load templates – it’s just a case of populating them.”
      This is one of the most common misconceptions. Populating load templates isn’t a simple task. It involves interpreting the requirements, extracting from multiple legacy sources, cleaning and cleansing inconsistent or outdated data, transforming it into the new data structures, reconciling totals across systems, resolving gaps, and iterating through multiple rounds of validation and reconciliation. It requires time, process discipline, and support – not assumptions.
    • “The system integrator will manage it.”
      Unless explicitly included in contract negotiations, SI partners typically only provide load templates and technical execution. It is your responsibility to source the data and provide it to the project, load ready. They don’t cleanse, structure, or validate your legacy data.
    • “Our HR or IT team can own it.”
      HR and IT are critical stakeholders – but they often lack the capacity, methodology, and tools to lead a complex data stream. HR teams are closest to the business rules and operational detail, but they’re already spread thin across design workshops, communications, and managing business-as-usual. IT teams can assist with system access, data extracts, and infrastructure, but they often lack context around the HR data, field definitions, and global policy nuances. Without a dedicated data lead, structured framework, and accountability, the data stream drifts. The result is reactive firefighting during mock cycles and escalating tension between delivery partners. Sponsors must resist the temptation to ‘assign data to HR and IT’ and instead ensure it is treated as a distinct and resourced stream of work.
    • “We’ll deal with data after design.”
      Unfortunately, data issues often emerge during design and testing. Waiting until build puts you behind before you’ve started.

    The Role of an Informed Sponsor

    You don’t need to write data rules or clean spreadsheets. But your leadership is critical in the following ways:

    Ensure there is a data migration strategy

    Sponsors should expect the data team to work from a clear and structured migration strategy that defines how data will be extracted, cleansed, transformed, validated, and loaded across each mock cycle. If your internal team doesn’t have one, ask your implementation partner if they can provide a baseline template. A documented approach helps avoid missed steps, enables progress tracking, and creates consistency across cycles. Without it, you’re relying on ad hoc decisions – which inevitably lead to rework and delays.

    This should be the first action a sponsor takes when engaging with the data stream. Before assigning roles or setting timelines, ensure the team knows how they intend to approach the migration – not just technically, but operationally. A strategy brings clarity, structure, and repeatability to a stream that otherwise risks becoming reactive.

    Approve dedicated resourcing

    Many projects underestimate how much time is required for data readiness. SMEs must extract, map, cleanse, and validate data while participating in design and maintaining BAU. Sponsors who proactively assign and protect these resources help prevent backlogs that otherwise surface late in testing.

    Support timeline realism

    Compressed data timelines are one of the most common failure points. Sponsors can challenge unrealistic assumptions and support a timeline that allows for at least two mock loads, including early simulations. This also creates space to uncover structural issues that often get missed in design.

    Clarify accountability

    Data sign-off isn’t always straightforward – especially in global programs. Sponsors help by defining who owns what (e.g., local vs. global, HR vs. payroll), how decisions will be made, and what success criteria apply. This avoids late-stage conflicts and streamlines go/no-go decisions.

    Where sponsor involvement matters most

    Here’s when sponsors are most needed during the migration stream:

    Phase Sponsor Role
    Pre-Project / Readiness Approve and fund a dedicated data readiness phase
    Design Support global/local model decisions and early data scoping
    Build & Validate Reinforce SME resourcing and monitor progress checkpoints
    Mock Testing Ensure sign-off accountability is in place
    Go-Live Prep Support cutover planning, data reconciliation, and privacy oversight

    Why SAP SuccessFactors Data Migration Needs its Own Workstream

    Treating data migration as a technical task misses its true nature: it’s a business-critical, cross-functional, and time-bound initiative that directly affects user trust and go-live integrity.

    Data needs its own:

    • Leadership (a data migration lead or external readiness partner)
    • Methodology (profiling, mapping, rule transformation, reconciliation)
    • Governance (decision rights, sign-off roles, change control)
    • Schedule (mock cycles, dry runs, cutover planning)
    • Controls (security, privacy, access management)

    Programs that assign this as a part-time task to already-busy SMEs often find themselves slipping behind without a clear way to recover. Sponsors should expect – and demand – that data migration is treated with the same seriousness as testing, change, and integration.

    7 Risks Sponsors Need to Know About

    We often hear: “Our HR SMEs can prepare the data.”
    This is often a red flag. Here’s why:

    1. HR SMEs are already stretched
      In one program, HR leads were managing change, communications, and policy reviews. Data work fell through the cracks until Mock 1 exposed major gaps – forcing a three-week delay.
    2. They don’t know the SuccessFactors data model
      SSF introduces new structures – like job classification or dynamic security groups. Without upfront guidance, HR teams can’t reliably map legacy fields into SSF’s requirements.
    3. SIs expect finished data, not guidance
      One sponsor assumed the SI would “help clean the data.” In reality, the SI rejected loads that didn’t match template specs, causing friction and emergency meetings to realign expectations.
    4. Data migration is a specialised discipline
      It requires profiling tools, structured cleansing cycles, transformation rules, and repeatable cutover rehearsal. Sponsors should treat it like testing or change – not an ad hoc admin task.
    5. IT support does not equal data leadership
      IT teams often help with extracts and environments but lack context on HR processes. We’ve seen migrations stall because IT couldn’t interpret legacy job codes or contract rules.
    6. Mock 1 often exposes unpreparedness
      In almost every project, Mock 1 is the wake-up call. The sponsor’s job is to ensure the team is already simulating loads and reconciling outputs before formal cycles begin.
    7. Security and privacy are real concerns
      In one public sector project, access to HR and payroll data was loosely managed in early stages. Once auditors became involved, retroactive controls had to be imposed – costing time and credibility.

    Essential Questions Every Sponsor Should be Able to Answer

    1. Do we know who owns each domain of HR data?
    2. Have we profiled our legacy data for quality, completeness, and alignment?
    3. Who is managing the data stream, and what framework are they using?
    4. Have we planned for secure handling of sensitive HR/payroll data?
    5. What happens if our data isn’t ready for Mock 1 or cut-over?
    6. Do we have a clear migration strategy?
    7. Have we established a repeatable method to extract, cleanse, and transform the data to support each mock load?
    8. Can we track and audit the data migration process to monitor progress and identify risks early?

    These questions often surface too late. Being able to answer them with confidence ahead of time is what separates well-governed projects from high-stress recoveries.

    Set the Tone From the Top

    Data migration success doesn’t come from technical wizardry – it comes from leadership foresight. When sponsors recognize that data underpins every other success factor in an SAP SuccessFactors project, they create the conditions for progress, not panic. From ensuring early strategy to assigning accountable roles and protecting timelines, your engagement sets the tone.

    Data doesn’t clean or load itself. Nor will it conform to best practices without structure, resources, and governance. As a sponsor, you don’t need to know every field in a load template. But you do need to ensure that the team is treating data migration as a first-class workstream – one that has a plan, a leader, and the time to execute.

    Do this, and you’ll not only reduce risk – you’ll drive confidence, clarity, and the outcomes your transformation set out to achieve.

    Q&A

    Why does SAP SuccessFactors data migration need a dedicated strategy?

    Because data migration is not just a technical task—it directly affects employee experience, payroll accuracy, compliance, and go-live readiness. Treating it as an IT handover or end-of-project task is one of the most common failure points. A dedicated strategy ensures alignment between business, system design, and data execution.

    What is the sponsor’s role in data migration success?

    The sponsor’s role is to:

    • Elevate data as a strategic workstream

    • Resource the data team early

    • Ensure ownership and accountability is clearly assigned

    • Challenge assumptions that the partner or IT team will “handle it”
      Sponsors must champion the business value of clean, timely, validated data.

    When should the data migration team be mobilised?

    Immediately. Waiting until test cycles start is a critical mistake. Data cleansing, mapping, and transformation take time. Mobilising the data team from project kickoff allows issues to be discovered and solved before they become blockers.

    What does a best practice data migration approach look like?

    Best practice means:

    • Clear data ownership across business units

    • Early alignment on scope, rules, and templates

    • Multiple test cycles and rehearsals

    • Tight coordination with configuration and cutover planning

    • Strong governance and proactive issue management
      It’s not just about tools—it’s about disciplined execution, early.

    More Resources

    Who Owns the Data in SAP SuccessFactors Projects – And Why It Matters

    Who Owns the Data in SAP SuccessFactors Projects – And Why It Matters

    by | Jun 20, 2025 | Blog Post, CFO, CHRO, CIO, Cross Industry, Data Migration, HRIS Manager, Program Manager

    The Governance Gap That Sinks SAP SuccessFactors Projects

    A 2021 SAPinsider Benchmark Report found that 67% of SAP SuccessFactors implementation teams identified data accuracy, consistency, and completeness as the most significant challenge to project success. Source: SAPinsider Benchmark Report, ‘HR Technology and Solution Adoption,’ 2021.

    But the problem is not just about cleansing, accuracy or legacy formatting. It is about ownership. Across multiple client projects, we have been called in, in the lead-up to Mock 1 data loads, when data is either on a critical path or has been raised by the Steering Committee as a key project risk. In nearly every case, the root cause is the same. No one formally owns the data stream, or at least not early enough to prevent issues before they escalate.

    Download our eBook

    Why Data Ownership Fails in SAP SuccessFactors Projects

    Everyone agrees data is important. HR relies on accuracy, payroll depends on completeness, and IT takes care of the extraction. The implementation partner loads the finished files, while SMEs are pulled in as needed to help with mapping. Validation typically falls to whoever has time.

    In theory, it sounds collaborative. In practice, it creates a lack of clear ownership—and the results are all too familiar:

    • Mapping stalls while teams try to understand data definitions
    • Load files are assembled inconsistently and are incomplete
    • only a small percentage of data is load ready and there are serious quality issues.
    • SMEs push back because they are time-crunched and validation responsibilities were never clearly defined
    • Testers scramble to fix structural issues they can’t explain

    Eventually, program leadership discovers what should have been obvious. You can outsource configuration. You cannot outsource ownership.

    What Strong Data Ownership Looks Like in Practice in SAP SuccessFactors

    Owning the data stream does not mean doing it all internally. It means creating a structure where decision-making is clear, issues are visible, and accountability is embedded.

    That structure must include:

    • Named data owners for each object, with business context and authority
    • Validators responsible for sign-off at each mock load cycle
    • A clear RACI that covers mapping, cleansing, transformation, and load readiness
    • Documented entry and exit criteria for every test cycle
    • Tooling that tracks version history, error logs, cleansing actions, and approvals

    This is not just governance for governance’s sake. It is the difference between:

    • Fixing a mapping error in cycle 1 versus discovering it in payroll rehearsal
    • A reconciled UAT load versus a last-minute data scramble
    • Go-live confidence versus executive escalation

    Why Implementation Partners Can’t Own Your Data

    Most implementation partners are not contracted to manage the data stream. Even if data is in scope for the partner, they cannot define your business logic or validate your data.

    They are responsible for building and configuring the new system. They are not responsible for transforming your legacy data into that system’s structures. They will generally expect load ready data in the format they have provided and in the timeline they expect it, multiple times thought the project.

    They will generally not:

    • Own the business meaning of your fields
    • Have the capacity to walk your SMEs through the data definitions required by SuccessFactors
    • Define which job codes collapse or split
    • Map old hierarchies into new org structures
    • Validate what counts as an active employee record

    These are business decisions that require context, judgment, and formal ownership. Without clear accountability and sign-off, the project quietly absorbs risk. Issues surface too late, responsibilities become unclear, effort is duplicated, and data quality inevitably declines.

    How to Structure Data Governance for SAP SuccessFactors

    At Coriza, we work with clients to build a governance model that de-risks the data stream and embeds accountability.

    That model includes:

    • Data stream formally integrated and accounted for within the RACI
    • Standing checkpoints for mapping, validation, and reconciliation
    • Central tooling for Data Object Mapping Documents (DOMDs), load logs, validation reports, and issue tracking
    • Entry and exit criteria for every mock load
    • A lead who owns the data stream from start to finish

    We make ownership visible. We make quality trackable. We make sign-off predictable. Success in SAP SuccessFactors projects depends not only on the data being loaded, but on having the right people making the right decisions about that data throughout the process.

    Don't Wait for the First Mock Load to Reveal the Gaps.

    Download the full eBook: here

    Our eBook, Why Data Migration is the Silent Risk in SAP SuccessFactors Projects, walks through:

    • What most teams miss when they plan their data stream
    • How to build a governance model that drives quality
    • The tools and roles required for successful mock loads
    • Why clean data is not the same as ready data
    • What it takes to protect your test cycles and go-live readiness

     

    Q&A

    Who should own HR and payroll data in a SuccessFactors project?

    The HR and Payroll business units must own the data. They are accountable for ensuring it’s accurate, complete, and compliant. Since they must sign off before go-live, they need full ownership.
    IT can facilitate the process, but cannot own the data. The implementation partner cannot legally or operationally approve the data either.

    Why can’t IT or the implementation partner own the data?

    • IT can facilitate extraction, transformation, and technical validation, but they don’t understand the full business context (e.g. how leave types, awards, or historical records impact operations and compliance).

    • Implementation partners may map and move the data, but they don’t have legal or operational accountability.
      Only the business can determine whether the data is complete, fit for purpose, and compliant—especially for payroll.

    What happens when data ownership isn’t clearly established?

    It leads to confusion, finger-pointing, and missed responsibilities. Data defects may go unchallenged, sign-off gets delayed, and critical errors may only surface late in testing—or worse, after go-live. Without clear ownership:

    • No one takes full accountability for cleansing or validation

    • Risk escalations may be ignored or disputed

    • Testing and sign-off become pro forma rather than meaningful

    How do you establish data ownership early and clearly?

    • Assign named data owners for each major domain (e.g. employee master, compensation, time, org structure)

    • Ensure those individuals are empowered to review, escalate, and sign off

    • Document and communicate responsibilities from the start—this should be part of the data migration strategy and project governance

    • Reinforce that IT and the partner are supporting roles, not decision-makers

    More Resources