Simply Complex   (Thu Oct 18 2007)

I know we're saying that we want to simplify HR, but there's no getting the way from the fact that we've got a lot of complex issues to deal with.

One came up this evening.

I've been working on the initial entry of a new employee's data. What I want is for Accelerate to check the employee's grade, contract status, nationality, family status, and hiring point. Then, in the background, the correct benefits package is automatically assigned. For example, when someone's on a full-time contract and they're hired from overseas, the company policy may be to pay for vacation airline tickets back to the hiring-point. (Well, that's what we do in the Gulf - wanna join?) The frequency of ticket issue and the fare-class will probably be dependent on the employee's grade.

None of this is too difficult. We simply set up a series of tables with all the information we need. In the Grades table, we define the standard package the number of vacation days per year, whether overtime is paid, the frequency of vacation tickets for those eligible, etc. Each job has a grade, so when we assign the employee to a job, all the information we need is ready to be carried into a Benefits table. There's a little background filtering and data juggling, just to make sure the employee is really eligible for each benefit; and in a couple of micro-seconds the whole package for the employee has been set up.

It needs to be checked of course. So Accelerate takes you to a check-form (actually a series of check-forms) to make sure that everything's been added correctly, and to allow you to modify the data where there are exceptions. There are always exceptions. This is HR!

But then it occurred to me. What if someone changed from being a full-time contracted employee to someone supplied by a contractor? Or more likely perhaps, the other way round - we like this person so much that we want to have him here forever.

OK, then we simply go to the benefits forms and change all the allowances. Don't we?

No, that's not the way it's supposed to be. If we're aiming for simplicity, then all of that ought to happen automatically, as soon as the contract status changes. Or the grade. Or the nationality ( - yes that happens too).

But unfortunately it's not as simple as that. The airline tickets - yes we'd certainly want to stop those if our employee went off to seek his fortune with a sub-contractor. But what about overtime? Most businesses wouldn't pay overtime to sub-contracted staff - there'd be a fixed hourly rate. But some would. And the arrangements might be different from case to case. It might be the same for paid sickness.

I thought about it for two cups of coffee, and finally decided to ... do nothing. After over 10 years of working on HR database design, there are still issues like this where I'm still not sure of the best approach. Because HR is complex.

It's an issue I'll probably have to address in the end because it goes against the grain to leave a process manual that feels like it ought to be automatic. But now is not the time. I have a working HR database to get ready by the end of January, and if I get snared up in the fine detail at this stage, I won't have a prayer. What I've already done works, so it's time to move on.

And this shows you something about my design method - it's iterative. In the first iteration, the job is to make sure that all the key processes are working properly. Then it'll be time to go back and work on some of the minor issues. Then to work on the page design. Then to improve the code. Then to incorporate your suggestions. Not necessarily in that order.

It's called permanent beta And in the land of Web 2.0, it's a good thing.

POSTSCRIPT: Had another cup of coffee, and I've got the answer. Yes we do need to automate the process. After all that's exactly what we do when people join. So why not when their status changes? I just need to make sure that the user is warned that changes are going to happen - and perhaps give the option to change nothing.

But I'm still not going to do it now. Seems like it should be iteration 3. Or 7. Or 195.

Filed under: HR