Talk:Projects/Human Capital Management/Employee Information Management/Functional Specification

Contents 1 Comments from PJU (March 19 2009) 1.1 Logical data model 1.2 Security 1.3 Mandatory fields 1.4 Terminology= 1.5 Cards 1.6 Search / Reporting 1.7 Grid 1.8 PJU's answers to Open Discussion Items

Comments from PJU (March 19 2009)

Logical data model

• Can you please add a logical data model description in the form of an ER diagram or a class diagram? This should be added in the Technical Requirements section.
• Is Team the same as Organization? If not, why?
• Are we sure that storing Nationality in Country is a good idea? What about employees that work in a country different than the country of their nationality? Would the HR manager be interested in searching for employees that work in a given country and have a certain nationality? With the current design, this is possible using locations, but it is a difficult query with the current Openbravo technology since the information is on two different tabs.
• Are we sure that doing effectivity date using just a Effective Date field is enough? Wouldn't it be better to have, for each record Effective From and Effective To? This would be more difficult to manage on insert and update (whenever a record is entered or modified you need to automatically modify the previous record as well to avoid overlapping or gaps) but makes using the data a lot simpler as it is much easier to find the record active as of a given date.
• How do you record the fact that a person stopped working? What happens when an employee leaves the company?
• How do you query for all the people that are currently employed? We should not be leveraging the Active flag since the semantic of the Active flag in Openbravo is "the record does not exist". A past employee should have the Active flag set but should also clearly be distinguished from a current employee.
• There is an inconsistency in the current Openbravo data model, since in the Employee tab there is a Supervisor field, while in this design the Manager is derived from the team. I like this design best but how do we deal with this inconsistency? At the very least, it should be documented and the Supevisor field in the business partner window should be obsoleted.
• How do you model a team hierarchy (i.e. team A is made of team B and C, etc.)?

Security

The specification of this area is missing. The requirements are:

• An HR manager should be able to view and edit records for departments that they are responsible for
• HR managers should not be able to delete records (perhaps we want to give delete privileges to some sort of superuser)
• Managers should have read only access to the full records of the employees that report to them.
• Employees should have full access to their own record.

It is not clear to me how this can be achieved in the current specification. One possibility to create three copies of the window with different security access.

Mandatory fields

• I believe that the following additional fields should be mandatory:
  • Employee tab
    • Last Name
    • Known As

Terminology=

• Please use consistent capitalization rules for fields:
• Employee tab
  • • Social Security Code instead of Social security code (should it be named more generically as National Fiscal ID?)
    • Birth Place instead of Birth place (should it be Place of Birth?)
    • Birth Date instead of Birth date (should it be Date of Birth?)
    • Highest Education Level instead of Highest education level (perhaps Education Level is enough)
  • Contact tab
    • Business Contact instead of business contact (this field should be checked by default, alternatively, you can rename it to Private and leave it unchecked by reversing the semantics)
  • Location/Address tab
    • Business Contact instead of business contact (see above)
  • Job Information
    • Standard Hours instead of Standar hours (there is also a typo there)
  • etc. (there are more violations, please review everything)
• Why do we have a Creditor region in the Employee tab? If we use it for expense reporting, I would rename it to Expense Reimbursement Information.
• Do we really need that? Which HR organization using different forms of payment and payment terms per employee? Shouldn't that information be at a different level (like the organization)?
• Do we need Pricelist there? Why?
• Is Relative the right term?
• In the Relative tab, we should be consistent with the Employee tab and have the following fields: First Name, Middle Name, Last Name and Known As. Also, we should be using Birth Date (or Date of Birth) instead of Birthday. What about Place of Birth, Nationality, ID/Passport and National Fiscal ID?

Cards

• The Employee view shown for every employee in the company is not very useful.
  • At the very least you need to add the manager
  • Additionally, it should be hierarchical in nature. From an employee, you should be able to see the manager and the team members and navigate to them. From a manager, you should be able to see the direct reports, the manager of the manager and the peers and navigate to them.
  • Ideally, you would present this with an Organization Chart look and feel.
• I propose to call these views Employee Cards
• The Employee Card for HR Manager and Supervisor should include the actual salary and not only the salary category.
• How do you print them?

Search / Reporting

• In general, this specification lacks the description of the search functionality (for each window you should add the corresponding search window and make sure that is complete enough)
• In general, this specification lacks the description of what reports, if any, are included.

Grid

When deciding which fields you want to include in the grid, please balance two considerations:

• In the grid view, you want the most important information to be visible without the need of horizontal scrolling. This means that the essential fields should be to the left of the grid and that you need to be very careful in selecting which fields that are displayed on top of the Edit view also appears in the grid view.
• The other important usage of the grid is exporting to XLS. In that case, you want to have as much information as possible. Because of that, you should include all the fields as long as they do not conflict with the previous goal. This means that fields that appear to the bottom of the Edit view can be safely added to the grid.

Applying this to the Employee tab, I would also add the following fields to the grid:

• Marital Status
• Education Level
• Notes
• Active
• Form of payment
• Payment term

PJU's answers to Open Discussion Items

FIELD ISSUES

• Which of them are required - See comments above. Else is fine.
• Which of them are shown in grid - See comments above
• Which role has access to each of them - E
• Fields not included in the proposal: - I am OK with not having these. See note on Intern/Freelance
  • Sales Representative | Operator | Vendor
  • Driver's License No
  • Bonus / Stock Options / Seniority
  • Legal Category / Quotation group/ Contract code (Spanish Localization)
  • Contract Category
  • Expiration Dates
  • Waive data protection
  • Military status
  • Intern / Freelance ... in contract type? - Yes, this is a contract type.
  • Medical info: insurance, etc.
• Fields included in the proposal:
  • tax id = DNI, etc.? - We have ID / Passport for DNI and National Fiscal ID; that should be fine.
  • Social security code = medical insurance? - No, Social Security Code is the same as National Fiscal ID. If I am not mistaken, currently in Spain the National Fiscal ID (NIF) is the same number as the DNI but that is only because two different agencies have decided to use the same number. Semantically, they are different and in many other countries they are.
  • URL: Header vs Contact type - Contact type. Not a major requirement.
  • Birthplace: should it be a pop-up with city + region + country? - Free text is fine.
  • Team vs. Department - Big issue. see note above.
    • Area/Department/Team -> Create a subtree to manage all this? - See note above.
  • Supervisor vs Manager - Big issue. See note above.
  • Job vs. Position - Correct. Alternatively you could use the terminology Career Path (for professor vs developer vs accountant) and Position (developer, senior developer, etc.). This requires to model the career paths, which is currently not part of the specification.
    • Job: Professor, developer, accountant, etc.
    • Position: Assistant Professor, Senior Software Developer, etc.
  • Job & Salary Cat.& Org Mapping: Name for this relation? - Not sure I understand.
  • Effective date: As start date on actual legal entity - job - sal.cat -salary combination - Not sure I understand.
  • BIC vs. SWIFT - They are the same thing (SWIFT is the US name for BIC)
  • Main/Default/Preferred - Main is fine. Alternatively you can use Primary.
  • BP Location and Bank review. Location is fine. Bank is great if you can do it like that but I do not think that radio buttons are allowed in Openbravo. You might want to consider making Domestic / International a drop down list that drives the layout of the subsequent region (that is possible). For Bank you might want to consider adding a "Account Nickname" field to allow people to specify a user friendly name (something like "Primary checking" or "Spouse account" or "The account where savings are put", or anything else) for the bank account (it can be defaulted from the account number and replaced if needed).

HISTORIC INFORMATION

• Which fields are being tracked - All.
• Only keep end date - See note above. I recommend date ranges for query efficiency (data is written once and read many times).
• Different approach:
  • a) When record is saved -> read only.
  • b) When a field is modified -> create a new record. (I would go for this)
• Department issue -> Managers kept -> Can not open new with default data. Bad usability - Not sure I understand

TECHNICAL ISSUES

• Conflict with actual salary category tracking - Not sure I understand
  • Need of operator field + cost
• Manage employees inserted from BP window: will there be any inconsistency when accessing them from employee window? - Need to analyze this.
• New nationality vs. reuse country - See note above
• Names mapping:
  • 'Know as' could be created automatically concatenation the previous ones, but at the same time, could be editable. Mandatory? - Yes.
  • Mapping? -> Name2 = know as; Name = name; Surname new column. - Known as need to be a new field, I think.
• Business Partner Category (c_bp_group_id) - This needs to be a configuration option. As part of the setup, you should let implementor specify the category to be used for employees and automatically assign it.
  • Keep it with default standard value
  • Create new 'EMP' and set it as default for employees
  • Implement job as Business partner category -> problem with historic information
• Bank tab - Discuss this with RMO.
  • Different approach: New table or add columns.
  • Radio Buttons in generated windows (Bank) - not possible; see above.
• Read-only fields -> duplicated columns. Need to update all the time.

ROLES

• Divide HR into more roles.
• Is there HR that can see info for every org? - Yes, the HR director for the whole enterprise.
• Ex-supervisor
  • Which information is available for them? The job information of that "period", can they access the employee header? (There is no header "for the period").

TEAM

• Is supervisor mandatory? It will not be possible to enter departments when there is no employee in the application. - Good point. Yes, a team will need to have a manager, which introduces this issue. This must be solved. Perhaps an option is that you should be able to assign employees to a team only if a manager is present in the team. We should also track changes to the manager of a team (it would be good to see who was the manager at a given time in the past). The other issue is what I mentioned above: we need a hierarchy of departments.