Wednesday, July 20, 2011
A five-tier approach to a multi-country payroll project
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.
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.