Measurement unit to estimate job role maintenance effort

[Former Member]

Hi all,

Can anyone share some ideas or experience in this case: In system ERP2005, developer provide all job role menu tcode, org level values and authorization object values, job role administrator only need to follow all provided information to create job role, generate profile and create transport.

The question is what measurement unit should be used to estimate job role administrator effort. My first idea is number of authorization objects, e.g. S_TCODE, S_DEVELOP, S_DATASET....

Thanks in advance.

[Former Member]

Well we work for a client where we get our effort estimates approved from the client before making the role changes. The measure we use is the number of tcodes to be added to a role or number of roles to be maintained.

Although, the effort estimate is provided based on experience and I agree with you the efforts should vary depending on the number of authorization objects that may get populated on the adding a tcode.

But, measuring efforts on such minute details would be a tough task.

[Former Member]

>

> Well we work for a client where we get our effort estimates approved from the client before making the role changes. The measure we use is the number of tcodes to be added to a role or number of roles to be maintained. 
> Although, the effort estimate is provided based on experience and I agree with you the efforts should vary depending on the number of authorization objects that may get populated on the adding a tcode.
> But, measuring efforts on such minute details would be a tough task.

Hi Subramaniam,

Thanks for sharing your experience. I think depend on number of authorization objects is a good idea because some job roles have no transaction assigned in menu.

Regards,

Donald

[Former Member]

How about number of...

Standard authorizations.

Maintained authorizations.

Disabled authorizations.

Changed authorizations.

Manually authorizations.

... and some sort of premium / penalty for number of:

Authorizations are green.

Authorizations are yellow.

... with increasing effort in the same order.

Just a thought

Julius

[Former Member]

>

> How about number of...
> 
> Standard authorizations.
> Maintained authorizations.
> Disabled authorizations.
> Changed authorizations.
> Manually authorizations.
> 
> ... and some sort of premium / penalty for number of:
> 
> Authorizations are green.
> Authorizations are yellow.
> 
> ... with increasing effort in the same order.
> 
> Just a thought 
> Julius

How about a reduction in costs for "*" values

[Former Member]

> How about a reduction in costs for "*" values

That, and if anything is found in the BIS field which is not in the value range of the data element or check table, then the one-armed-bandit cuts your hand off for free...

Cheers,

Julius

[Former Member]

>

> How about number of...
> 
> Standard authorizations.
> Maintained authorizations.
> Disabled authorizations.
> Changed authorizations.
> Manually authorizations.
> 
> ... and some sort of premium / penalty for number of:
> 
> Authorizations are green.
> Authorizations are yellow.
> 
> ... with increasing effort in the same order.
> 
> Just a thought 
> Julius

Hi Julius,

Thanks for your suggestion. In our case, developer knows all the required authorization objects before pass it to job role admin, therefore the effort of admin is minimal.

Regards,

Donald

[Former Member]

> Thanks for your suggestion. In our case, developer knows all the required authorization objects before pass it to job role admin, therefore the effort of admin is minimal.

Yep, but it might only be a minimal effort this time is what I was trying to emphasize.

Does the developer document these values they know in SU24, or in an email only? There is a big difference down the line for someone else who opens the role for maintenance and want to know where the heck the field values are coming from.

Cheers,

Julius

[Former Member]

>

> > Thanks for your suggestion.  In our case, developer knows all the required authorization objects before pass it to job role admin, therefore the effort of admin is minimal.
> Yep, but it might only be a minimal effort this time is what I was trying to emphasize.
> 
> Does the developer document these values they know in SU24, or in an email only? There is a big difference down the line for someone else who opens the role for maintenance and want to know where the heck the field values are coming from.
> 
> Cheers,
> Julius

I'm the developer and will maintain the job role at sandbox system, test the job role and then document every object field value. After collect and pass the information to "Job Role Admin", the job role will be manufactured and profile generated accordingly.

[Former Member]

It is still not clear to me where this information from the developer is being documented though.

There are different ways of building roles, and some are more maintenance intensive and error prone than others...

Take a look on the authorizations tab of such a "manufactured" role in PFCG. Which status do the authorizations have? (standard, maintained, changed, manually)

Cheers,

Julius