User account requests

[Flip]

Hello all,
I'm going through a lot of information now to change our business processes to become ITIL compliant.
One topic I just cannot find any information about is what to do with requests regarding user accounts; creating new, changing details, changing access permissions, deleting accounts.
This is a typical part of IT so I would want to see it explicitly mentioned in our processes. Is it so typical that it is a service request? Would it be considered a change because it changes the CMDB (linking user to new system that he gets access to)? Or an incident because it is actually not changing the functionality of any system?
The closest topic I can find is "password reset". This is also a call regarding a change to someone's account. But this doesn't really change anything. I did see many opinions that SRs could be handled using the IM process. If more people will confirm that, that is what I will propose and we could also incorporate all other user account requests in there.

Regards,
Philip.

[Ed]

hi Flip

we have these kind of requests set up as Standard Changes as they are low risk, able to be proceduralised, and the steps followed are the same each time. Your Change Manager can then pre-authorise the Service Desk/ Sys-Admin team to action them without anything more than notification that said change has taken place.

From my perspective as a Change Manager, I want to see that a change has taken place, but do not need to invoke the full Change procedure every time 'housekeeping tasks' like these are performed.

I hope this helps.

Regards

Ed

[Flip]

Thanks, Ed. Good to know that it is possible.
Now I'm really curious because there seem to be 2 camps; the UserAdmin=IM, and UserAdmin=CM camp. Why is it so ambiguous? Isn't there even a best practice around it?
Or better yet; if some kind of an authority says "It's this..." then I'll just flaunt that and the discussion should be over.

Regards,
Philip.

[rjp]

Flip,

don't just look at it as a definition problem. Consider it also in terms of:

What overall objectives the activity is supporting.
What the trigger for the activity is.
What management controls need to be applied, eg. where and why managers may need to intervene.
Where the activity needs to be reported - in which stats it should be included.

From the point of view of definition alone it does seem to be a little ambiguous where these account activities go.

But they are responding to a disruption to a clients access to a Service or potential wiat for access to a service, and the activity is directed to getting the user operational asap.

So trigger and objective = Incident Management.

They don't require approval (well the should not). No new class of CI is created. No existing class of CI is altered. There are no capacity or availability issues, no risk assessments to do, and no requirement for forward schedulling.

There is however an imperitive that the activity be undertaken within a certain time frame, and lapse should trigger supervisory attention.

So management controls are looking decidedly Incident Management.

As to reporting well that naturally follows out of the activity described above and you will want to include this activity in the reports disclosing the effectiveness of your Service Desk and the IM process.

So to the final ambiguity: Configuration management. Isn't adding or deleting an account altering your infrastrucutre (and therfore your CMDB)? I would be very surprised if most CMDBs had individual accounts in scope. But let's say they are.

The request for access to the service, (create an account) or even removal (delete an account) is still a service request. If this is in scope of configuration management then the way the service request is met is be raising a standard RFC.

Personally I think that's overdoing it a bit, but that would be the straight up and down by the book way of doing it.

[MonkeyWrinkles]

Just wondering, we get requests in "bulk" at times for new user accounts where there are 15+ accounts.

For you all, do you (A) create 1 ticket for this request of 15 accounts, or (B) create 15 tickets for this request. Again, assuming it was one person asking for these accounts on behalf of the others.

What works for you?

[Ed]

Hi Monkeywrinkles

We create one ticket as it is in effect one request and one Release note against the Standard Change.

Regards

Ed