Re: Comments on the HR Draft

[Mark H Smith]

Derek Neighbors wrote

> All comments are about section 2.1.7 Business Object Definitions...
>
> class hire: (i dont know if this is the best name for this class)
> all xxxxx_codes should really be codes that point to lookup classes like
> status.  About what about people that come back, this is good question, I
think
> we might want a rehire date or break the hiring portion out so it can
> be 'revolving thing'.

I'm not quite clear here, but in principle I agree it would be good to make
the re-hire process as streamlined as possible, avoiding rekeying of data
wherever possible.

> class contract:
> I keep seeing reference to 'posts' what is this?  Like title? Postion?...
> As far as contract details and jobcode/title there is a LOT more to it,
> but I think maybe that is teh posts module?

I'm thinking the 'Posts' module should be re-titled 'Organizational Planning
' (Alan Clifford suggested this, which I feel is clearer). Post equals
jobcode/title, so if 'Job' is more widely understood than 'Post', lets go
with 'Job'. I'll revise the proposal to reflect this. Yes I agree there is a
lot more to Job than what is in the draft Personnel module so far, and yes I
would expect job data to be held in a Job Class to be described in the
'Organizational Planning' module. Job data (Job Title, Job Hours, Job
Minimum Qualifications, etc) can exist independently of the employee, as
when a job is vacant. But I've come across some employers (small ones
typically) for whom setting up an organizational structure with departments
and jobs is overkill. They would prefer just to give a person/contract a job
title, and leave it at that. So in the draft proposal I was trying to cater
for both the small and simple employer, and the big and complex employer.
The downside to my suggested approach is that the same data (e.g. job title)
could be held in two different Classes, the Contract and the Job. Perhaps
there's a better way to provide flexibility/ease of use?

> class former_emp:
> Since you are capturing this data, do you want to include pay information
> from last job?  And would you limit this to a single former employer?  or
> during the hire process would you catalog all the data during reference
> checking?  If so would you want to list who you talked to at that company
> and when and what they had to say about the employee. (i realize that this
> might be a separate module like 'recruiting' or something)  Just throwing
> out the idea...

My understanding is that Payroll will definitely want pay info from the last
job, especially total tax paid this tax year. But Payroll normally don't
need pay info from jobs before the last employer. For HR, details from
previous employers might be very useful, so I would agree it should be
catered for. I'm assuming this former employer data would be keyed in  as
part of the recruitment process, but might be wanted by HR after recruitment
is complete. The HR package is going to have a lot of Classes that are used
by different modules (e.g. 'person' will be used by all of them, and each
will extend it with new data items). I suppose the best way to get a clear
overview is to draft out the key Classes in the whole package at once,
rather than try a module by module approach. So I'll attempt that, in a high
level, requirements only format, which the Business Object Definitions can
then be developed from.

Mark H Smith
Email: address@hidden