Why customers Love Workday

I've spent a bit of time learning Workday in the past and I've been researching stuff and listening to real customers talking at trade shows and I reckon I've figured out what is making them the darlings of the HR/Pay Industry at present.

Saas model - not unique to Workday, but they are the flag bearers for HR/Pay - it means predictable costs and fewer staff needed to "look after" the application.

Single system for large customers - Many HR directors of multinational organisations appear to be wrestling with numerous HR systems in different parts of the enterprise (even though this is 2012!). They will (and have) trade depth and breadth of functionality for the ability to consolidate on a single system.

Process-centric design.  Workday scored highly for UX (user experience) in recent survey, but the UI (user Interface) isn't outstanding.  I think the reason is that someone sat down and thought about what would make a system appeal to HR business people.

More on UK Payroll Outsourcing

A really interesting debate on a Linkedin group recently threw up another thing to watch out for if your payroll is outsourced or if you are planning to outsource it.

It would appear that the responsibility for ensuring past data is available as required by HMRC (who specify 3 years of past records as a minimum)remains with the employer.

Here are a couple of things to think about -

Are you getting all the relevant data supplied each pay period by your outsourcer?

Are you keeping it?

If you wanted to move provider or take payroll in-house, would you have all the data you needed, or would you need to approach the provider you wish to leave and ask them for help?

PeopleSoft - rumours of my demise are greatly exagerated

For reasons I don't fully understand, it seems to open season on PeopleSoft amongst some commentators and analysts in the HR tech Industry.

Without getting too carried away, and accepting that the lifespan of Peoplesoft and similar systems is clearly finite; and that emerging technologies will replace many PeopleSoft installations, there is still a lot going on in PeopleSoft.

These are some recent tweets from the run up to Oracle World.

Over 14 million employees are served by PeopleSoft worldwide.

57 of the 2012 Fortune 100 are PeopleSoft customers.

PeopleSoft customers are in 54 countries worldwide.

Development of PeopleSoft isn't finished either - this is just one new thing.

HMRC Software Accreditation in the UK

A debate at work prompted me to realise that not everyone is up to date with the HMRC regime - what it did, what it does and who's invloved.

Up until 6th April 2012, Payroll Software providers could use test data from HMRC to run payroll calculations and have the results verified by HMRC.  Those able to prove the calculations correctly were awarded an accreditation from HMRC and could advertise the fact using a special logo and were listed on the HMRC website.

This scheme has now been retired and replaced with a scheme to accredit suppliers able to make RTI submissions.

Just to be clear - although many suppliers chose to gain the accreditation it was never a legal requirement, and I know of several perfectly competent suppliers who never bothered.

5 ways to save Payroll Costs

Don’t do it –  

For anyone needing help and advice on any aspect of performance on a PeopleSoft Oracle Database, I highly recommend David Kurtz.  One of the principles Dave espouses is (I forget who the source is now) that the single best way to reduce complexity and improve performance is not to do something.   

In other words, rather than spend stacks of time and cash creating some hideously complex edifice to carry out calculations in support of a highly complicated payment or deduction – always consider not doing it at all by changing the business process. 

Complex payments/deductions 

The suppliers of many systems trumpet (with justification) that they can address the most labyrinthine of calculations.   

This reminds me of being a young man and marvelling how many car insurance companies advertised they were keen to take on young drivers, even with fast cars.  I thought this was wonderful because everyone had been telling me it would be hard to get insurance.  What I had missed was that the reason all these outfits were so eager was the huge amounts they wanted to charge me. 

Even if you think you can configure the system pretty easily – don’t underestimate the amount of administration that you might need around complex payments and deductions – this may involve the Employee, Manager and HR and Payroll – all of it is non-productive admin. 

Don’t report/interface for others 

Don’t do stuff for other parts of the business at your time/expense 

I’ve lost count of the amount of times Payroll departments have had their implementation project hijacked (usually by finance).  Sometimes another business area sees a payroll project as a good way to get some of the things they’d like but don’t have the budget for. 

Up to a point of course, Payroll has a responsibility to support the rest of the business, but when this begins to extend beyond what’s reasonably expected in order to pay people, questions need to be asked about who is paying and who has a business case. 

  

Don’t automate 

The temptation is to try and automate laborious processes - but wait! If the code/config is costly and the justification dubious, you are just creating something else you need to document and maintain that is costing you, not saving you, even if the Payroll folks are happy because they've dodged some boring work.

Don’t offer 

Don’t offer to split net pay between multiple accounts for payees if you don't have to - again it's an overhead in admin you don't need.  Many people have online banking these days so they can manage their complex affairs on their own time.

  

Write it down 

Document payment rules so you can be consistent and avoid costly litigation.

RTI - Updated technical packs

Update to EDI technical packs for 2013/14 Real Time Information submissions, to apply from April 2013

http://www.hmrc.gov.uk/softwaredevelopers/rti/edi-rti.htm

On configuration, customisation and work estimates

Working on a particularly tricky bit of configuration led me to consideration of a few issues.

Configuration

Because customising systems brings cost accountants (and others) out in a cold sweat, we’ve all learned to prefer configurable systems. Great in theory, and fabulous where we’re dealing with data and rules which are a known quantity – for example, addresses (I know there’s a few years debate to be had on that but bear with me).

However, for more complex business rules and workflows there’s a point where the distinction is more blurred. Sure, configuration of the rules means you can realistically expect that they will work when you get a new release of software; but you’ll still need to determine if the new release allows you to improve the configuration you have.

It’s true that your config lives in metadata, but when you get into the more involved business rules (payroll calculations, absence rules), yours are likely unique. Even if two organisations have identical rules, the flexibility of the system may have allowed them to get the same results by two totally different routes in config. Some of this configuration is in fact tantamount to custom code – it just lives in a more controlled environment.

So what’s the point? 
Well there are two really One is about the permanent battle I have with trying my best to provide estimates for initial config and changes to calculation rules. And the other is about the differences between customisation and configuration.

On the first point – give some thought to this Are our rules complex? Most organisations tend to answer no to this, most are wrong.

Are our rules unique? As above, Most organisations tend to answer no to this, most are wrong.

Who else uses this software and have they done this already? Did they have help? Who from? The more complex and unique the requirements, the fewer other users and smaller the talent pool of configurers, the more unpredictable the implementation or change process will be.

It will be harder, even for a highly experienced person to estimate work that they haven’t done before. On the second point – don’t assume that the word “configuration” is an automatic route to pain-free implementation and maintenance.

If the system you buy/use has functional limitations that a clever config expert can work around to make your rules and calculations work, that’s great, but it’s not that distant from custom code.

How is PS Global Payroll formula metadata stored?

There are two main tables

PS_GP_FORMULA and

PS_GP_FORMULA_DTL


The DTL record has a row for each line of the formula.

There are a few useful things you can do in Query or SQL – like finding which formulas reference a given element, or looking for where a particular error/warning is called from (as in this bit of SQL I begged off a person of superior intellect):

SELECT
B.PIN_NM,B.DESCR,A.PIN_NUM,A.FRML_FLD2_DEC_VAL,A.FRML_FLD1_DEC_VAL,Z.FRM
L_FLD2_DEC_VAL,Z.FRML_FLD1_DEC_VAL

FROM PS_GP_FORMULA_DTL A ,PS_GP_FORMULA_DTL Z ,PS_GP_PIN B
WHERE A.PIN_NUM = Z.PIN_NUM
and A.EFFDT = Z.EFFDT
AND A.PIN_NUM=B.PIN_NUM
AND ((A.FRML_FLD2_DAT_TYP='4'
AND A.FRML_FLD2_DEC_VAL='301')
OR
(A.FRML_FLD1_DAT_TYP='4'
AND A.FRML_FLD1_DEC_VAL='301'))
AND((Z.FRML_FLD2_DAT_TYP='4'
AND Z.FRML_FLD2_DEC_VAL='21008 ')
OR
(Z.FRML_FLD1_DAT_TYP='4'
AND Z.FRML_FLD1_DEC_VAL='21008 '))

(The references to 21008 and 301 need to be amended with the appropriate message set number and message as appropriate)

You can also (if you are brave and have suitable access), do some manipulation of the formula content.

There is a vague rumour that PeopleSoft had an in-house text based editor for GP formulas at some point – but they were too frightened of it to allow it out into the wild. It would be great if some enterprising technical person could write something one day – but it will probably never happen. Even an AppEngine that could take a text file as input and parse it into appropriate formula rows would be good and would speed up creation and amendment of formulas immensely. Oh well – I can dream.

Most times if you are making changes, you will want to start out with the last version of the formula you had – however, you may wish to “rip and replace” – which you can do with SQL like this (or similar)


delete from PS_GP_FORMULA_DTL where PIN_NUM =101283 AND EFFDT ='2012-01-01 00:00:00.000' AND SEQ_NUM5 >1

Warning – don’t use this unless you really know what you’re doing and don’t come crying to me if you’ve destroyed the only copy of that 4000 line formula you wrote – you have been warned!