A New Paradigm for SAP SuccessFactors Payroll

One of the curious things in life is that what might appear to be simple, is really more complex than it seems. We can look at the recruiting process, for example: We need to fill a position so we tell HR, they post some ads and work with recruiters to get us a list of candidates, we interview them and hire one. Those in HR know the process is much more detailed and complex than that, but if you’re not the process owner then you don’t really ever get an appreciation for those details and complexity. The same goes for my favorite function – payroll. Most of us look at our bank statement – or get a notification of deposits – and if the pay is about what we expect then we move along. Maybe from time to time we look at our pay statement to see some details on deductions or taxes. Pretty simple.

But then, payroll isn’t so simple. From collecting all the data needed to pay someone, doing the calculations, distributing the results and reporting to banks, accounting and regulatory agencies there are plenty of things that can go wrong. For one employee. Now, in large companies multiply that by, say, 50,000 people getting paid weekly, every two weeks, semi-monthly or monthly. Maybe there are 50 elements of pay in an average person’s pay statement, and pretty soon we need to get 50 to 100 million or more things right every year to successfully deliver payroll to employees, banks, accounting, agencies and so on. And those in payroll know, there’s even more to it than that. Not so simple, right?

So it was with that background that I read Mike Ettling’s comments to Diginomica about “Self Service Payroll:”

We’re thinking about the whole payroll paradigm, which says, ‘Why do you, perhaps, need a payroll department? Why can’t you pay yourself?’ for example.

Why can’t I decide, ‘Hey, I need to get paid, I need some pay this fortnight,’ just click the button and pay myself, trigger my pay ...

These are ideas which are being whiteboarded at the moment.

I’m glad he’s getting creative and rethinking the ‘whole payroll paradigm.’ But this self-service idea of employees paying themselves doesn’t sound so fruitful to me. I know! We’re brainstorming here Steve, don’t evaluate the ideas, but withhold judgment until we get all the options out there! Well my INTJ mind has already evaluated this and determined it’s better to offer personal finance classes to employees than to offer self-service payroll. Let’s move along to what SAP SuccessFactors can do to shift the payroll paradigm. I’ve thought about that already too – you’re welcome.

First, payroll has to be reliable. Don’t deliver software updates that break it. Seriously. I love SAP’s payroll, but even after my almost 25 years working with it, I still don’t trust their updates, notes, and support packs. Customers spend too much time regression testing their systems and reporting (and as often, working around) bugs that could have and should have been caught with basic regression testing done at SAP before it was released. This is a problem that has followed SAP for years, and if the paradigm is going to be re-thought then start here.

Second, payroll systems ought to be simple to configure for simple cases while also having enough sophistication to handle complex customer requirements. My customers always hear from me that one of the most important keys to a good payroll is keeping it simple. I drive simplification in every payroll project, but sometimes we can’t avoid some complexity. SAP’s payroll does a pretty good job at this already, as long as no one has hacked it up by configuring or customizing outside the SAP payroll framework. And that still happens too often (by consultants who never have to live with their mistakes because they move on before they see the impacts in a productive system).

Third, payroll should be easy to use both for employees and for payroll administrators. Maybe the new payroll paradigm will include design-thinking and a hefty dose of empathy for employees and administrators. I hope so. I know SAP’s fairly-new Payroll Control Center aims to ease payroll administration and it’s a good start. But there are so many other things that need to be addressed. I have a set of customizations and configuration that get applied for each new customer to make the system easier to use and administer, because everyone eventually requests that functionality to fill in SAP’s gaps. But it’s all within the existing SAP Payroll framework, which desperately needs to be retooled with ease-of-use in mind.

Fourth, consider all the weaknesses and bolt-ons in the current SAP Payroll system when creating that new paradigm. Concurrent Employment should be built in from the beginning, as well as easily supporting multiple rates of pay per employee. Make payroll adjustments easier to carry out. Deliver some packaged integration for interfacing to various providers. And document the system. I’m sure others have much more to fill this bucket.

Even given all four of these efforts, customers have the responsibility to simplify and streamline their own processes. The best payroll system in the world will still be compromised if a company holds on to complexity. Remember – payroll doesn’t provide any strategic advantage to your company, so make it reliable, efficient and flexible so that it doesn’t get in the way.

Back to self-service payroll. We could build a service that automatically pays a mid-period advance to an employee, on demand, via Fiori. I don’t think it’s that difficult to do with the current SAP payroll software. So build it and deliver it if you want, SAP SuccessFactors. But also keep the four points above in mind because they will deliver a payroll system that really does set a new paradigm: reliable, capable, easy to use and full-featured.

Share
up
55 users have voted.

There are 8 Comments

Good thoughts Steve. Hopefully developers will take note!!

up
33 users have voted.

Very thoughtful comments Steve. All points are spot on. SAP needs to improve quality of service packs and allow us to focus on customer needs vs worrying about the system breaking. SAP also needs to take some of this customization we do for every client and make it standard in the system.

up
25 users have voted.

Of course we (SAP-SF) also the goal of improving quality of updates (i.e., not breaking anything), and reducing implementation time by pre-delivering more configurations. This goes double for payroll in the cloud (i.e., Employee Central Payroll (ECP)) as we take on a greater share of the pain vs. on-premise (e.g., by applying updates & notes for customers)! I would be happy to engage with you on any ideas you might have related to these topics.
To remind you of some things that first come to my mind which we did in the past years (most a very long ago) to improve quality:
• Restricted what can go into a Support Package (SP)
• Prevented Developers from releasing their own changes into a SP – i.e., implemented a 4-eye principle
• Created the concept of Country Legal Change (CLC) packages so that you can take only legal changes for the country you are interested in now
• Increased automated and manual test cases. We even made some automated test available to customers
• Invited more customers to test new releases with us using customer data
Would you have other concrete ideas? Do you see some areas as more problematic than others (some place for us to concentrate)?
Regarding pre-delivering more configurations. We did also invest here with model company entries and Rapid Deployment Solutions (RDS) albeit I find it very difficult to come up with one set of configuration because payroll seems to be so customer specific and country specific. I think we really streamlined the US tax process with our integrations of BSI SaaS into the Employee Central Payroll (ECP) solution. Again, I would be happy to take ideas from you on customization you do for all customers that you think could be applied to all customers. We are working on an update to the Employee Central Payroll (ECP) RDS now so input could be useful.
And, yes, we are considering how to engineer out or mitigate all the traditional pain points with Next Generation Payroll. We also agree with Steve’s approach to keep it simple, stick to the standard, especially when moving to the cloud but as we are all painfully aware, it’s not always possible to achieve 100%.

up
31 users have voted.

Hi Robert - thanks for your insights on this; I'll follow up with a more detailed email and maybe we can talk about it in the future. I think there is a lot for SAP/SF to learn from getting experiences from consultants who have worked with the product and customers for a long time. Maybe we can leverage the SAP Mentors for this too.

There is frustration when things that have always worked, just break. Like US tax amounts not changing in cross-year retros, GTLI imputed income on retirees going to wagetype /BU1, online W-2s stopped working for some of my customers this year... it's sort of a constant hum of corrections fixing other corrections. It seems like those errors would have been found in regression testing. Software development isn't my specialty so I don't know exactly what is going wrong, but it is frustrating when these things break - things that always just worked. In a customer environment we can re-run whole payrolls and compare the results, before and after, to catch a lot of these things (which we do, during support packs).

 

up
25 users have voted.

please re-read article BEFORE publishing it :

typo like :

I need some pay this fortnight,

(fortnight instead of for tonight)

are awful to read

up
25 users have voted.

Hi Phillippe - that quote is straight from the Diginomica article; I don't change or spell-check quotes.

up
25 users have voted.

We might also allow for the idea he really meant "fortnight", a space of 14 days, or the end of a common bi-weekly pay period - especially knowing that Mike hails from the UK.

up
27 users have voted.

The biggest challenge with payroll systems is that one size does not fit all. Because of country or even local rules as well as company policy, paying a group of individuals is often a unique event. Building and maintaining rules for hundreds of situations for a global company is complex and costly. But it is also a critically important function to get right. If there is a paradigm shift that is needed, it is to provide one cloud-based tool that comes pre-packaged with the basics each country, allows a user to answer guided questions to set it up and then collects data from the processes into a standard database for reporting. Now that would be a paradigm shift.

up
29 users have voted.

Add new comment