Self-Indulgent End Of Year Update

Time for an overdue update.  On a personal level, I am very happy to have become an employee of Workday.

I am still taking an interest in UK Payroll, Absence and HR issues, although my role is more a global one relating to Absence.

I won't therefore be blogging any further in relation to PeopleSoft.  I have to wave goodbye to the Software product that's been paying my mortgage for the last 15ish years, but happily not to all of the friends and colleagues I've met.  Quite a few former PeopleSoft folk have, like me, turned up at Workday and I intend to stay in touch with those who haven't and are still working with PeopleSoft

To anyone still working with PeopleSoft - I salute you and have fond memories of my "PeopleSoft days".

Merry Christmas and Happy New Year (Happy holidays if you prefer) to one and all.

More on Court Orders - Direct Earnings Attachments

Not strictly a Court Order at all, but -

There's a new type of order for employers to operate.

Only announced towards the end of last year, these are due to begin a pilot in April.  The orders are going to be operated by the Department for Work and Pensions (DWP).

So where are all the details? Weeeelll, apparently the DWP will be publishing a guide on their website soon.

Sadly for everyone, the timescales are a bit challenging for anyone wanting their payroll software package to calculate and prioritise the orders automatically.

The timing could be better, given the advent of RTI, the recent changes to the requirements for reporting of other orders demanded by CMEC (which replaced CSA) - although CMEC is apparently now called Child Maintenance Group, presumably on the grounds that they hadn't had a name change for a few months.

All that said, the requirements don't look too onerous - and there's a chance that an employer may never see one of these orders at all.

HMRC Demands for Underpayment

Following my previous post, it seems that concerns were raised at the Customer User Group. HMRC has issued a formal response, published (for members) on the CIPP website. So far so good - but the response seems to lay all the "blame" on employers or their agents - for example;

Duplicate (or too few) employment records held by HMRC:

If the employment records held by HMRC contain duplicate employments,
and therefore do not match the employment records held by the
employer, it's likely that we will be expecting the employer to pay
more than is actually due. We have published guidance about avoiding
the creation of duplicate employments to software developers and in
our pilot employer updates.

This of course, is fine up to a point, but neither employers nor software providers or payroll bureaux are creating duplicate records on purpose to cause problems.

I'm hoping that HMRC will make an effort to find out what the source of the issues is and offer some help in sorting it out. I hope they won't be looking for a way to try and complain they are being sent bad data (even if strictly speaking they are) - because a lot of people have spent a huge amount of time and cash trying to comply with their requirements.

Not many payroll people are also systems experts so some of these issues are not immediately transparent to them - I suspect the same is true for many in HMRC - but it's no good HMRC just saying "you're wrong" if a new system seems to be doing unexpected things. Clearly, as I alluded to in my first posting, if you are suddenly "underpaying" by a significant amount that is worthy of further investigation and not just a demand to "pay up"

Fingers crossed.  Like all postings here - this is a purely personal view.

RTI Worries - one serious, one not

In the RTI "news" recently have been two issues - the number of "hashes" that don't match, and HMRC sending outrageous demands for underpaid tax to employers in the RTI pilot.

Without revisiting all the comment I've read on this (hand there's been plenty on Linkedin), I offer my personal opinion for what it's worth:

The hashing issues - the hash was supposed to ensure that HMRC could match the source of the payment to its destination.  It was a nice theory but flawed for a number of reasons.  The best thing would be to forget it - but that may not happen.  I assume no-one will want to admit it doesn't really work, and there may be a future for it if anyone resurrects the idea of HMRC doing our deductions.

The Demands for payment - this is serious for two reasons - it shows that HMRC don't seem to be "joined-up" in the sense of wondering how an Organisation (in one example) could suddenly owe an extra £60k in tax despite having paid over everything their (respected in the Industry) software told them to.  They seem to have simply picked up the phone to ask for the £60k

The second reason is that there's apparently a bit of a mess up in the way HMRC deals with people who have more than one job with the same employer - it isn't totally clear yet what this issue is, but it looks serious, given the numbers of people who do this.

Interesting times for a payroll systems geek like me.

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!

CMEC Changes

The changes CMEC is demanding from payroll software providers have now reappeared on their website.
Oracle said at a previous UK user group meeting that the Court Order Functionality in PeopleSoft GP will be rewritten in 9.2, but these changes are required prior to that.

Oracle, PeopleSoft and RTI

Oracle held some meetings with customers on their approach to RTI during October. If you are a PeopleSoft GP customer in the UK or using UK extensions, I hope you were able to get along and hear the word.

HMRC on Data Quality

Apparently Employers have been sending HMRC duff data in returns such as employees called Mr X. It looks as if HMRC are concerned about the quality of data they hold, as well they might be, in advance of RTI.

List of simple changes I would like to MyOracleSupport

Ability to change the main contact
Yes – MyOracleSupport really is MyOracleSupport – it won’t let me go.  This is 2011 – things change, people leave – it is nuts that we have to involve highly skilled Oracle support folks to do this menial task for us when we could do it ourselves.
E-mail notifications
The system sends an email to the main contact (even if they’ve left – see above) whenever an update is made to the SR.  Assuming they are still present, the person then has to log into MOS, go into the case and see what the update is.  My suggestion is to put the update in the e-mail notification to save time.

Also give me an option to turn off the nagging and nag e-mail about Oracle configuration.  I've been at more than one cleint who refuses to use this so stop whining and get over it, Oracle.

Cut down Logging process
In the years I’ve been logging SRs, the step where suggested solutions is offered has never offered anything remotely related to the problem, never mind a solution – either remove this or give us an option to turn it off
Make a description search of every customer’s SRs available
I realise that the full details of an SR are customer confidential, but if it was made clear that the initial description was in the public (or at least customer) domain, everyone would know where they stand and all customers could check if something similar (or that looks similar) has already been raised. (Whisper this bit) In any case, customer information is already shown in the bug data – it’s just not easy to search.  If I were a cynic (which of course I’m not) I might contend that Oracle doesn’t wish customers to know that other customers are reporting issues too.

Who do you think completes your RFP/ITT anyway?

A recent robust debate on Linkedin has prompted me to collate some thoughts I’d had in my head for a while.

I don’t like RFPs/ITTs (insert your Country/Industry/Organisation TLA here).

First a few light-hearted observations from my life in the world of pay and HR software to help illustrate why, then some thought on the nature of ITTs/RFPs .

When you write an ITT (invitation to tender) for a new software system or service, did you ever stop to think about who completes the response when it arrives at the potential supplier?

Having worked for a number of software houses before moving on to concentrate solely on implementations and projects, I’ve seen the ITT process from the other side of the fence.

I used to train end users in a payroll system that was a product of one of the leading suppliers at the time.

On one course I had a group of trainees who made it quite clear they hated the system and felt it didn’t do anything they wanted.

At a coffee break I tried to gently enquire about the selection process. “Oh it took ages” was the response ”but in the end, all the demonstrations melted into one and we couldn’t remember which system did which – but we liked your Salesman the most”. That readjusted my view on the rigour of their selection process and made me more relaxed about why they had bought a system they hated.

One ITT from a government agency said that they had a policy of adopting the very latest technologies – but later on said they wouldn’t use any system that didn’t have five references from other similar agencies available – I wonder which agency they thought was going to be the first?

At the same company I used to get ITTs to respond to as I knew the product pretty well. After a while I reached a few conclusions about ITTs (and responders).

Questions on an ITT about functionality are open to interpretation. In addition; some are just plain silly – like the card they give you to fill in on the plane to the USA that asks if you are entering for the purposes of drug trafficking or terrorism – just as you are unlikely to say yes on that card; who in their right mind is going to say “no” or “does not satisfy” the requirement that their system is “user friendly” ? (I’m not kidding – I have seen this “requirement” on countless ITTs).

You should also bear in mind that no salesperson is going to talk the product down – why would they? Therefore you aren’t all that likely to get many “no” answers from Salespeople responding to an ITT.

If the salesfolk have given the ITT to someone else, then that person’s answers may be shaped by their own position in the Company; take this along with the fact that there is often not a simple yes/no to some questions (and that a perfectly innocent “yes” may still leave you thinking – “well yes it does that but not in the way I wanted/imagined”) and you will see that I think ITTs need to be used with care.

I used to think that those suppliers who just answered “yes” to everything were despicable – but looking back I’m wondering if it wasn’t better to get past the ITT stage and get to talk to the customer about what the product can really do.

I used to complete the ITTs with what I considered to be scrupulous honesty and care – but I now wonder if it was all worth it – apart from keeping food on the table at our house of course. I know that some of my “no” answers got changed to “yes” and there was nothing I could do about it.

We went through a phase of potential customers asking for the ITT to be written into the purchase agreement. I can see the logic (in theory suppliers would tell the truth if it’s contractual) – but when you think of the costs of legal action and the ability of the suppliers’ lawyer to argue questions were answered in good faith, it may seem a little pointless. It’s also not a great way to begin a supplier relationship.

In the end there are few things to think about – top of my list I have to ask this-

What do you hope to achieve from a new Payroll and/or HR System?

Unfortunately, this isn’t always clear – and when it is, the expectation of improvements may be based on a false premise. Very few organisations I’ve ever worked with are prepared to address their business process issues, even though doing so would save a lot of money.

A new system won’t solve a problem like payroll receiving late notification of events like an employee leaving. A slick system may make it easier to notify all the relevant parties, but if no-one enters the data in the first place, it’s a waste of cash.

You won’t get all your requirements. No off the shelf product or service is going to do everything you heart desires all the time – cars don’t, houses don’t, mobile phones don’t why should Payroll software?

Even if you did, get a “yes” to all your requirements – how do you know that how the system does things in a way that is going to actually suit you?

In any case, the first two points are largely academic because the truth is – you don’t know your requirements.

This is a question of degree; from organisations with a twenty year old legacy payroll system and no supporting documentation on how payments are actually calculated, to those with huge volumes of documentation about how payments are calculated and what process to follow to book time off, no organisation has a proper handle on it all.

Even if you do today; by tomorrow it has changed.

Just because it’s written down somewhere doesn’t mean anyone has ever read it or that staff members actually do it that way. By the time you have written the requirements down (or more likely done a copy and paste from a few other documents that no-one reads) they are at least partially out of date and inaccurate.

Providers don’t want to say “no”. Unless you are a notoriously scary organisation, most suppliers want your business, so they will do anything they can to justify a “yes” or “met” or whatever is on your ITT.

So with all that in mind, what can an ITT be useful for, and what’s a better way to get a system that will meet the organisation’s needs?

ITTs/RFPs can be good for qualifying suppliers – if your organisation has rules (most large ones do seem to) about the kinds of suppliers it deals with, then you can weed out suppliers that you can’t consider.

Similarly, for determining which general products and services a potential supplier might be able to offer, the ITT/RFP can determine this – for example, if you wish to take the system totally off-premise and a supplier doesn’t offer this, you can discount them.

For functionality, I am an advocate of a process advocated by Naomi Bloom here and a similar variant of which I have seen in use by Accenture. In short, the process involves determining some key functions that the business depends upon and writing scripts for them (I am summarising hugely for the sake of brevity). These can be used to examine not only what a product’s capabilities are but also the manner in which they are accomplished.

More Legislation - but Blink and You'll Miss it - CMEC

One of the many onerous duties that payroll departments perform on behalf of government agencies is the collection of money due for child maintenance or court orders. Needless to say, there is a set of arcane and labyrinthine rules to be followed.

The consequences of not deducting a court order can appear severe - a summons can be issued naming the payroll manager personally and demanding they appear and explain why. Thankfully this is rare.

Since everyone seems to recognise that the CSA hasn't really been working out, a new agency has been created. It's called CMEC. As such agencies do, they have decided that they want to make some changes to what is required of employers - and since many employers use payroll software, the implication is that the software providers will need to make changes.

CMEC published what they called "Business Requirements" on their site some time in July. Unfortunately I missed it at the time. Since then they have removed the document that had the requirements in from their website without explanation.

With any luck the requirements will be back soon. In brief they cover some new admin rules and a new method of reporting data - all to be in place by April 2011. They have apparently promised that the final requirements will be available to software providers by October this year.

Bonanza for Outsourcers?

Recent UK Government initiatives like RTI and Pensions Auto-Enrolment, coupled with a gathering momentum in US HR thinking (which tends to arrive here 12-18 months later) is leading me to see a potential future in which a much higher portion of Pension and Payroll Processing is outsourced.

The received wisdom in the US (and here) amongst many HR, finance and other business people seems to be that Payroll is not a function that has the potential to offer strategic advantage. It's a generic thing that can be done by outsiders without affecting the way the business operates or your "Employer Brand". I don't agree - but who cares what I think - that seems to be the way the wind is blowing.

Add to this the fact that in trying to simplify things, the Government is of course making them more complex, and you might forgive business people for running into the open arms of the outsourcers.

I hope I'm wrong about this - and I would encourage any organisation thinking of outsourcing to be very cautious and thorough as I've seen some examples where it didn't provide any of the intended benefits - but I can see a move to outsourcers in the future.

Pensions Auto-Enrolment

There is a lot of stuff on the net about this and how it’s a major change. For once, you do need to believe (some of) the hype.

It is a big deal and it will have an impact on Pensions and Payroll administration.

The requirement is that employers will soon need to enrol employees into a pension scheme as the name suggests, automatically. So far so good, but as with all things legislative, there’s a degree of complexity. For one thing, there’s a requirement to check earnings each period and determine if they are above or below a threshold.

In short, the requirements are going to affect both pensions and payroll administration functions and any systems they use.
Every employer needs to be thinking about how they will approach this – even if it’s just to pick up the phone to suppliers and ask “what are you doing about this”.