Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Best practise for SAP users who leave the company

Former Member
0 Kudos

Hi

Could anyone reccommend a best practise document or give advice on how to deal with SAP user ID's when employee's/contractors/consultants leave? I am the basis admin just starting an SAP implementation and we have no dedicated authorisation team at the moment, so I have been asked to look into this :

Currently we set the validity date in SU01 to the termination date.

We chack there are no background jobs scheduled under that user id, if there are, we change the job owner to a valid user (we try to run all background jobs under an admin account).

We do not delete the user as from an audit point of view I believe it restricts information you can report on and there are implications on change documents etc, so best to lock it with validity dates.

Can anyone advise further?

We are running SAP ECC 5.0 on Windows 2003 64 Bit/MS SQL 2000.

Thanks for any help.

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi,

Different people will tell you different versions of what they believe is best practice, but in my opinion you are already doing reasonably well.

What I prefer is

1. Lock ID & set validity date.

2. Assign user to user group LEAVER or EXPIRED or something similar (helps with reporting) out of SUIM/S_BCE* reports.

3. Delete role assignment (should you need it, the role assignment will be in the change history docs anyway).

4. Check background jobs & act accordingly.

For ease of getting info I prefer not to delete the ID though plenty of people do.

7 REPLIES 7

Former Member
0 Kudos

Hi,

Different people will tell you different versions of what they believe is best practice, but in my opinion you are already doing reasonably well.

What I prefer is

1. Lock ID & set validity date.

2. Assign user to user group LEAVER or EXPIRED or something similar (helps with reporting) out of SUIM/S_BCE* reports.

3. Delete role assignment (should you need it, the role assignment will be in the change history docs anyway).

4. Check background jobs & act accordingly.

For ease of getting info I prefer not to delete the ID though plenty of people do.

0 Kudos

Alex

I fully agree with your approach.

What many people forget is that the LAW in most countries forces you to be able to report on a lot of transactions for at least 7 years. And although this law is based in Financial accounting much transactions in other areas are seen as part of the financial process so it is better to be able to report on all.

One (often overseen) point of this audit trail is to be able to uniquely identify the person who performed the transaction, and that is stored in SU01.

Last info I received on this point is that some companies recently got big fines as they could not produce the transactional data. So whenever there is a debate around this issue one could use this!! Also be aware that when you use archiving the data must be replicable!

0 Kudos

Hi Auke,

Interesting info about the fines, sounds like another weapon in our armoury!

0 Kudos

add that to the 2 companies that lost over €10.000.000 in 2004.

reason poor security design which led to fraud!

Former Member
0 Kudos

Never thought I'd start a debate on company fraud ! 🐵

thanks for all the responses, sounds like I was on the correct approach.

0 Kudos

You were on the right track.

One more thing to remember, some processes in the PM Module cannot be ended if the userid that originated the process is no longer available in the system!

0 Kudos

Hi Auke

We do not use Plant Maintenance where I currently work, so thats not a problem. Funnily enough the role at my last company was to configure PM, what a pain that was !

Paul.