Reporting relationships in Umana

1. Introduction

In real business, reporting relationships are complicated, and terminology varies from one organization to another.

Umana recognizes two kinds of reporting relationships:

a. Manager / Superior

The employee’s "manager" or “superior” is the person who gives the employee his reviews, possibly determines his salary, and can hire or fire him. A manager has final responsibility for his employees’ work and well-being. The manager has final say (unless there is a grievance) about what the employee does.

The terms Manager and Superior and even Boss are in common usage and are roughly equivalent. We use them interchangeably in this documentation. The employee "reports to" his manager.

In Umana, an employee only has one manager. The employee’s manager is typically the head of his department.

• This 1-to-1 relationship between managers and department is important in Umana. That's because when an employee works in a different department, he only specifies the department where he worked. From that Umana needs to be able to infer the manager who may need to approve the time worked.

b. Coordinator

In a large department the manager may need help, and can assign one or more coordinators. (Some companies use the term "team leaders", or even supervisors. This last term is confusing and we will try to avoid it here.)

• Sometimes coordinators are assigned (by the manager) for specific groups of employees; in this case the same employee always has the same coordinator.

• Other times coordinators might be assigned by shift or day of the week: such as a day-shift coordinator, a night-shift-coordinator; a weekend coordinator; in this case a coordinator may be responsible for all the employees under that manager.

A coordinator typically has fewer access rights in Umana. For example, a coordinator can correct a time-sheet and recommend that it be approved, but normally the final approval requires the manager.

Using positions or not

Reporting relationships in Umana differ depending on whether you use positions.

• ALL Umana clients use the table of JOBS. (A job describes the kind of work the employee does.)

• Only SOME Umana users use the positions module. (A position is a specific chair occupied by a single person.)

Umana is unique (as software goes) in that the use of positions is optional. It is even possible to use positions for some employee groups and not others.

Positions also have their own reporting hierarchy: one position reports to another.

• For employees occupying a position, Umana uses the position hierarchy to determine the employee reporting hierarchy.

• For other employees, not occupying a position (this means all employees if you are not using positions), the reporting relationship is between employees.

Different modules

Each employee has his manager; let’s call this his default manager. But you may need to use a different manager in a specific module in Umana. For example, you may want your org. chart to show a different manager than the one used for the timesheet.

How to override by module is explained in a section below.

2. Specifying the manager without positions

When not using positions, effectively you need to specify the manager of each employee. The manager of each employee is another employee.

Look at the example here. Imagine that this is a little piece of your full organization chart. So the question is, how do you specify this employee hierarchy in Umana?

• In hierarchies and other tree structures (like org charts), you only need to specify the direct (immediate) manager (parent) of each employee. The rest of the structure falls out mathematically. So in the example below, you only need to specify that:
      Marc Tom
      Tom Big Cheese
  Umana can figure out that Big Cheese is the grandparent of Marc

There are two ways to do this: Bottom-up, or Top-down

• Bottom-up: You go to each employee (Marc, Bob, and Pierre) and you enter in each of their files (in the employment history window) that they report to Tom.
  (See the left side on the screen image shown.)

• Top-down: You go to the Tom’s dossier and you specify that he is manager of all employees in the department (where Marc and Bob and Pierre work). (See the right side of the screen image shown below.)

Neither method is complicated, but there are nuances, and pros and cons. You will probably end up using both methods together.

• Bottom-up has precedence. If top-down implies that Tom is Bob’s manager (Bob works in a department that Tom manages), but in Bob’s file you specify that his manager is someone else, say Joe, then the manager is Joe – whatever is specified in Bob’s file. Tom would be the default manager, which you are overriding to be Joe. Bottom-up wins.

In the image below, when Default value is checked it means that the top-down method is being used, and the name shown above it is the supervisor that the top-down implies – or if you are using position, that the position hierarchy implies.

Specifying using bottom-up

The bottom-up specification has priority. It overrides any other specification.

Using the bottom-up approach, here is how you would specify that Marc works for Tom.

1. Go to Marc’s employment history, and add a new movement (with an as-of date, if this is a real-world change) or modify the existing one (if this is a data correction).

2. Select the MISC tab.

3. Uncheck the Default value box. It’s on the left side

4. A dialog box will open where you can select Marc’s manager. (Click on the supervisor box above it, if the select-employee window does not open).

5. Click the (save) icon

If you need to reverse it, just create or modify a movement and recheck the Default value box.

Specifying using top-down

The top-down method is like creating a rule that says that all employees in specified department(s) report to the selected person – typically the department manager.

So if Tom were manager of the SALES department, which also included Marc, Bob, and Pierre, you could simply create the rule that all employees in sales report to Tom. Here are the steps:

1. Go to TOM’s employment history. Add a new movement (with an as-of date, if this is a real-world change) or modify the existing one (if this is a data correction).

2. Select the MISC tab.

3. Click on the DEPARTMENT SUPERVISED box. A drop-down selection will open.

4. Check the department(s) that TOM supervises and Click OK.

5. Click the (save) icon

So this makes Tom the manager of everyone in the sales department, but…

But there is a problem: Tom is also in sales, and he can’t be his own manager!

• So you still need to use the bottom-up method to show that Tom’s manager is Big Cheese.

• If you need to make an exception for anyone else in sales, you can do it the same way, because the bottom-up method overrides all others.

Pros and cons : Best practices

Our normal recommendation is: Use top-down where possible; specify exceptions with bottom-up.

Using the bottom-up approach seems simple and precise. So why not use for everyone?

• If you only use the bottom-up method, then you will need to do this for each of Tom’s employees. It is more work.

• What happens when a Tom is replaced by Tony in the sales department? Now you have to go to each of Tom’s old employee’s and create a movement to specify that they work for Tony. If there are only 3 employees as our example above, it’s not a big deal, but what if Tom had 100 employees? And there is no shortcut tool at this point to do that.

The top-down method will not work if managers are not aligned with departments.

It is possible for you to specify multiple managers for the same department. Umana will warn you, but you can still do it. Do not; you can get unpredictable and inconsistent results.

3. Specifying the manager with positions

A position is a theoretical entity – a chair – which may or may not be occupied at some point in time by an employee. Use of positions is optional in Umana.

Each position identifies the position that it reports to – the superior position. This creates a hierarchy of positions. That hierarchy is used to determine the reporting hierarchy of their occupants.

• For more info, see positions: concepts
• The boss(...) function returns the PersId (employee number) of an employee's manager. It works with the positions module as needed.

4. Overriding in a specific module

You may need to override the manager relationship just for one module.

• For example, an employee's manager for the timesheet, might be different from his usual manager, and different from his manager on your published org chart.

• You can do that without positions in the Employment History window. See the positions module for how to do it for positions.

You do this in the employment history window > Misc tab.

5. Coordinators

It is the responsibility of a manager to assign his coordinators. The manager can also sign a replacement for himself and an assistant.

• Coordinators assigned must work for the manager. A designated replacement or assistant does not need to.

Assigning coordinators, replacements, assistants

From the timesheet, select click Designate replacement on the bottom right hand side of the timesheet.

• This will open the Replacement and Assistant window where you can assign someone to replace you as manager when you are absent. This will give that person the rights to approve the timesheet.

• You can also assign an assistant who is a "helper" and can validate and correct the timesheets but cannot give final approval.

The last option lets you designate/modify/or delete a coordinator and the group of employees whom they supervise. It opens the Roles and Responsibilities window, which is used for defining coordinators and other things as well.

• Here you select the person and can specify a date range in which they will act as coordinator. If the date range is left blank there is no time limit.
• Next you choose the employees who will be supervised by this person. Here you choose the dept and other criteria. You also have the option to choose the employees by name.

6. Viewing, Printing, Exporting

Viewing

To view an employee's manager, and whom who manages, and his coordinators

• Go the the employee's Employment history (JOBHIST) work, and look at the MISC tab. There are options look up and down the hierarchy.

Printing

Organization Charts can be printed from Print > Organization.

• You can select a specific manager in the Organization Chart (employees) report to print the list of employees managed by that manager.
• There are separate reports for org. charts of positions

7. Developers tools

BOSS ( ) function

• receives the PERSID (employee number) of an employee
• returns the PERSID of their manager
• (Not available in SQL-server requests)