WORKFLOW - positions and jobs?

[Former Member]

Hi All,

I am new to WORKFLOW and practicing the tutorial of: <b>notification of absence</b>. In this tutorial there is a unit called Organization plan. In that step by step procedure is given for creating: position and job. Can any one explains me why we have to create both position and jobs with an example and what is the inter relation between position and job?

Best Regards

-Satya

[Former Member]

Hi,

In a single word, I can say that the role of POSITION/JOB in Workflows is AGENT DETERMINATION only. I suggest you to go around RULE 168 to get to understand the role of Positions in Workflows.

Regards

<i><b>Raja Sekhar</b></i>

[Former Member]

Most cases, yes - but in this case I would stick to the tutorial to get a full understanding of how org management and workflow hang together. Later in real conditions, I completely agree with Raja.

Regards

Gareth

[Former Member]

Hi Vytla,

This is also one which gets questions in the BIT600 series of courses as well. A job allows us to have an object describing a function generically, and to which we may assign other objects (roles etc). We assign these to a position to give a link between the perceived duties and the position org object (and this is the object to which we assign people).

The short answer is for the purposes of workflow you don't really have to create both, but in the real world a working org structure will contain both (any many many more) org objects. This step gives reality to the tutorial.

The workflow will use your Org plan hierachy (position-->Org unit and backagain) to path your workflow steps. You may (and often do) use a job to determine agents in a workflow or rule. For example:

Personnel Rule: for people who's names start with A-G --> send to those with a job of "People with name A-G", others --> send to job of "People with name G-Z".

Another real world example: In Australian Government, it was common practice in SAP release 3.1I and earlier to assign delegations (that is spending and approval limits) as jobs to positions and have a role looking for chiefs within the hierachy with the specified job. Fortunately (as maintenance was an issue in large organisations) this has been superceded but it is a practical example of how jobs can be used.

Hope this helps.

Regards

Gareth

[Former Member]

Hi !

<b>Position</b> is a '<b>post</b>' occupied by <b>a person</b> in the organizational structure. For e.g. 'Field Supervisor'.

<b>Job</b> is a '<b>functionality</b>' defined by certain characteristics. For e.g. 'Supervisor'. Now in this case supervisor is a 'functionality'. He might be a 'field supervisor' or a 'purchasing supervisor', etc.

Hence while creating a new position we can relate it to a job (like while creating the position of 'field supervisor' we relate it to job 'supervisor') and it inherits the characteristics of the job.

Thanks and regards,

Abir.

(Kindly reward if its helpful)

[KKilhavn]

Just adding a little to Gareth and Abir's excellent explanations;

It is fully possible to create and use an organization plan without Job objects. I believe the usefulness of Job objects in a workflow context is primarily in defining possible agents, and thus adding some authorization control (as you can restrict forwarding of work items to only the possible agents).

In more recent version of SAP it is possible to define possible agents by referencing a role, so the need for a Job object may have been reduced. However, if the organization can be convinced to take the extra effort of defining jobs and assigning them to the positions I think you will have a good basis for creating workflow solutions with inherent security. The job information can probably prove useful also in custom reports. Someone must be interested in knowing how many managers there are in a company - and if you create and maintain your HR structure wisely you can get that information from SAP without having to maintain additional data sources.

[Former Member]

thanks to all

Satya