Re: User authority controls -- MIDRANGE-L

When I started here, they used the concept of naming a user profile by
the job type.  I converted to using names a few years ago and everyone
has loved it.  Besides matching the network & email naming, it just
makes life easier.   Can you remember who RMBY11 (Retail Merchandise
Buyer #11) is?  I can't, but I can easily know who SSMITH is.

As to job changes....  we run a SQL report over the HR transaction
database nightly.  We look for job code changes and cost center changes
and match the name to user profiles.  If we get a hit, we take
appropriate action.  The job change may have no effect on their access
or we may disable the profile if they've moved, say, from Merchandise to
Foods - particularly important for Time & Attendance access.

BTW... we also run a daily termination list and match it to user
profiles (iSeries and network) and disable those.

We review both manually since there is a good possibility of false
positives - SSMITH user profile may be Sally Smith but it was Sam Smith
who left the company.  I hope to improve the process by adding a
notation for computer access to the HR record to eliminate the false
positives - track it like we do special licenses, company issued
property, etc.

mcunning@xxxxxxx 03/16/2007 8:30:15 AM >>>

We have a good handle on authority setup for new employees and on
removing authority for  employees who are leaving. What we struggle with
are those employees who change jobs within the college. Sometimes those
are people leaving one department and going to another, sometimes those
are people just getting a title change. Our HR office is very good at
telling us who new hires are and who is leaving but not so good at jobs
changers. I am curious to know how you handle these people from an
authority control perspective. One idea we had was to look for any title
changes and treat them as if they left the college and are coming back
in as a new employee. Disable their account and revoke all authority
then grant just the base level of authority to the new job until we hear
from that persons new supervisor. Of course this then requires going
into all the systems where mcunning has an account and disabling it.
Another thought was to stop creating accounts based on someone's name
but use their position instead. So my userid would not be MCUNNING but
ITSDIR. ITSDIR is granted authority not MCUNNING. When MCUNNING changes
jobs the ITSDIR account would be disabled and my new job account would
be enabled. When the new ITSDIR comes on board we reactivate that
account. We use to use this method a long time ago but our users
revolted because it is sometimes very hard to turn a title into 10
characters and have it make sense. Try coming up with 10 characters for
Director or Desktop  Computing/Academic Computing/Media Services.