PARIS
Although the bulk of the upcoming HR-technology projects deal with the various components of what goes by the name of talent management, by far the largest number of current HR systems still deal with good old payroll. Such a focus makes sense since you may decide to eschew compensating adequately your workforce, or recruiting them effectively, or training them in line with your company's objectives but there is no way you can avoid paying them.
With the pace of globalization showing no sign of abating most companies find themselves operating across several countries which brings to the fore the need to manage their workforce as part of a single HR system. Most multinationals have been doing just this for a good decade now: two thirds of them have a global HR system of record for all their employees from which they send the relevant data to other HR systems such as learning, time management, benefits and, primus inter pares, payroll.
Traditionally payroll has been managed via a local vendor, either outsourced or in-house, but in the last few years the proportion of large, global companies deciding to use a single, global payroll system (even if not necessarily on a single instance) has grown quite substantially. New vendors, purporting to deliver the Holy Grail of a true global payroll system, have appeared on the landscape muddying the waters of what can be done, what can only be dreamed of and what is pure fantasy.
I have spent a good portion of the past 15 years either implementing payrolls, helping end-user organizations select a new payroll system or, as part of the vendor community (especially now-defunct PeopleSoft and pre-Fusion Oracle) developing a global payroll. In my book, "High-Tech Planet", I describe the fun associated with making a business case for a global payroll.
Assuming you have decided to run your own payroll inhouse (versus outsourcing it in full or in some countries-but I will discuss this as well further below) and regardless of whether you want to do so with an on-premise system or a hosted (SaaS) one, there are basically five ways to go about it based on:
- Funding: Who will pay for it? Sure, ultimately you the customer will end up paying for it, but there are ways to go about it. The vendor can fund this out of its general licensing revenue or you the customer can pick the tab directly.
- Build: Usually he who pays for it builds it, but this is not necessarily always the case as a player (say, a subsidiary) can contract out to the development organization to do it.
- Support/maintenance: This is a key issue and again it is not always an easy decision, the builder is not always the maintainer.
-Ownership: Some of the prior issues will determine, and be determined by, who actually owns the localized payroll.
Having defined some of the key criteria and remembering what it means to have a localized payroll (if you have not done so, please read my post on the five pillars of a "glocal" HR system: http://bit.ly/eRqx5J) here are the five ways you can run your global payroll system. (And, yes, I know, my mind seems to work in fives, probably the remnant of a childhood spent using my fingers to count.)
Tier 1: The truly global payroll
Tier 2: The half-baked payroll
HR software vendors are anything if not resourceful. If the Corporate Development organization for reasons I explained at length in my book, does not want to fund a localized payroll for some countries that are key to you, chances are that your vendor's country manager of, say, Nigeria or Thailand or Tunisia (assuming you are in contact with them), will tell you that they would fund it themselves and contract out to Development to build the required features. You can thus end up with a product developed by your vendor following their development guidelines, on their codeline, with their own people responsible for developing other parts of the standard product. For all intents and purposes, it sounds and feels like the Tier 1 solution, except that it ain't. First of all, once they've built and delivered it, Development won't touch it with a ten-foot pole. The subsidiary, sometimes under constant prodding from you, will have to finance it and if the local market does not warrant it (you were a one-off case) you may wait a long time for that statutory report on overtime pay required by the government of Brazil. And, of course, there is no guarantee that any new off-the-shelf release of the core HR system and payroll (Tier 1) delivered by the vendor will be compatible with this Tier-2 product.
Tier 3: The partner-built payroll
This is a variant of Tier 2 whereby, since Corporate Development doesn't want to have anything to do with the local payroll (either directly or indirectly, "hey, we don't even have time to build what we committed to"), a local partner is enlisted to replace Development. The great advantage here is that the partner, usually a local payroll vendor, knows the country requirements quite well since they have been developing their own system for a long time: they therefore have the knowledge, people and resources to develop the localized layer of rules, processes and reports that you need for countries X, Y or Z.
All they need to do is get trained on the core payroll engine, understand the global vendor's development guidelines and they can get you the country extension you wanted in a faster turnaround your global vendor could never dream of. Who will pay for this? you may ask. Well, it all depends on the relationship between the global vendor's subsidiary and the local vendor: sometimes there is a true partnership whereby they split the licensing revenue or the local payroll vendor gets royalties. (You will not believe how much frequent-flyer mileage I accrued traveling across several time zones and meeting countless payroll vendors to fix these issues) As a customer you need to understand the intricacies of such deals to ensure proper and speedy maintenance. Also, what happens if the local vendor bows out of the agreement? Will the global vendor's subsidiary pick it up as a Tier 2 solution? Will the global vendor accept to productize it and bring this local payroll into the standard product (make it a Tier 1 solution)? What about the compatibility issue with new releases of the global system? Since the global and local products will be on separate release schedules (and sometimes technology stacks) serious issues might arise.
Tier 4: The project payroll
If neither of the previous works, usually because as a customer you represent too small a market share for the vendor to get involved even at the local level through a partnership with a local vendor or by having the product financed by the subsidiary, you can still build the local extension as part of your implementation. Your own people can do it, especially if they have experience working with the vendor, know the tools well, especially the core payroll engine. Or your system integrator (SI) could do it for you, especially if, as is likely, they have experience implementing that payroll or even building out localized versions: and like all SI's they would love to do it for you, in exchange for fat, cascading consulting fees. A third option would be to use the consulting arm of your vendor to build it for you, on a T&M basis. The advantage of the latter is that it may minimize risks associated with such a project, if only because you can assume that as part of the vendor's organization they would know the product better than your own folks or an SI. Whatever the option of this solution, you the customer as the owner and funder of this solution will still be responsible for its support and maintenance. Tough decision to make, but well worth it if the country under consideration is a key one with many employees and user experience, analytics and integration issues demand a similar payroll be used for that country as for the other ones.
Tier 5: The third-party payroll
When all else fails, then you are left with only one solution: create an interface between (a) either your HR system of record or your global payroll (there are pros and cons to do either, I will discuss that in another post) and (b) either a local legacy payroll or, more likely, an established local payroll vendor's solutions for the countries where you do business. It could be either an ADP-like outsourced payroll or the myriad third-party payroll systems which, in spite of the global vendors' growing market share, still rule the roost all over the world and which your local team will have to install and use. If you're lucky, maybe that such an interface has already been built by your vendor. For instance, most of the ERP vendors (SAP, Oracle and PeopleSoft or "SOP") have built such an interface (goes by various names, Payroll Interface or ADP Connector) where, in a nutshell, they already map HR data (employee details, compensation, organization, contract, absence data etc.) to selected payroll systems. Just make sure you understand what is really covered and who will maintain such an interface. In some cases where the interface is too light (what I call a marketing interface rather than a true product one) you might as well build your interface yourself. Especially when the number of local payroll vendors is huge and there is little chance of your global vendor to have built standard interfaces to all of them.
It is noteworthy to keep in mind that when "SOP" vendors start localizing their offering they do it on a module-by-module basis, meaning that they first release a localized HR Administration system (contract types, national identifier, address format etc.) and only then (there can be a lag of several years between the two) the payroll rules (earnings, deductions, gross-to-net calculation etc.) In order to optimize a Tier-5 solution, you may want to check which of the vendors has the most localized HR Admin modules as this will help lessen the need to build such features prior to their use by a payroll interface.
One tantalizing thought is the extent to which a pure SaaS vendor (such as Workday) can meet the needs of large multinational companies since in a SaaS model the payroll sits on a vendor's data center and is accessed remotely by users. It is therefore hard to envisage how Tiers 2-4 solutions can be done with such a system. Could it be that a global payroll system will be hampered by SaaS? So far the jury is still out as there is no vendor that has yet come up with a SaaS-based multi-country payroll. This probably explains why Workday has been quite slow at expanding its country footprint and few members, if any, of its growing customer base are using its payroll outside North America. But if a true SaaS vendor manages to enhance its configuration options to the level needed to quickly build local payrolls and/or add new payrolls quickly to its standard offering, then it will truly revolutionize the oldest of HR functions.
*A list of how various global vendors fare in terms of HR and payroll localization is available from www.AhmedLimam.com\ Vendor Localization Footprint (excerpt -Google Docs sign-on may be required.) Please note that the Tier-4 description therein is somewhat different from the five-pronged approach presented here since the Vendor Localization Footprint report does not by definition cover the Tier-5 solution presented in this post.
This is the blog of Ahmed Limam, providing insight and intelligence on international business and technology, HR, politics, travels, movies, history, literature and any other human endeavor worth bothering about. IMPORTANT: All posts are my intellectual property and cannot be (re)used/quoted without my written permission and clear attribution.
Subscribe to:
Post Comments (Atom)
why don't more people know you man? you are brilliant!!!
ReplyDeleteAbout another post - unless you were joking about SAP guys taking your advice on SuccessFactors,wasn't your piece a tad arrogant? Do you really think that incumbents in paradigm shift situations get screwed because of lack of awareness on what needs to be done?
Thanks for the "brilliant" comment, and as for the "tad arrogant" label, well, I don't know. We all have our defects, so if mine is to be arrogant, I may have to accept it. But I guess I'd rather be arrogant and right than modest and wrong. Don't you agree?
ReplyDeleteNow, to your question. To use your terms, incumbent vendors eventually get "screwed" when they don't rise to the challenge of a new circumstances. By "get screwed" I mean start losing mind share and market share. We are already seeing that with SAP and Oracle whose customers are looking with kinder eyes to SaaS vendors. Of course, this is a long-term trend, so these two giants will not be wiped out over night, but when they become a mere shadow of who they were you will probably be able to trace it to these early developments.
And of course, even if they were to be "aware on what needs to be done" as you say, it could all fail at the execution stage. All large companies suffer from deeply ingrained ways of doing things, have their own culture, believe they know better than others and like an ocean liner are hard to turn around. So, even if they embarked on the right strategy, a big if, they could still fail by being unable to execute it.
What i do not understood is in fact how you are now not really much
ReplyDeletemore smartly-appreciated than you might be now.
You are very intelligent. You understand thus significantly on the subject of this
subject, made me in my opinion imagine it from numerous various angles.
Its like women and men don't seem to be involved unless it is
something to do with Girl gaga! Your individual stuffs nice.
At all times handle it up!