Not sure if this will help but we thought long and hard about how to organize ours at the top most level. I've expanded Access and Desktop Services to give you an idea of our second tiers, some of them break down even further. My original idea was to make sure that the top levels were Major Business services and tie them together in the CI and mark them as down or up when one of their "Child CI's" was selected in an Incident that was deemed to be an outage.
This is our Service Catalog which was built around several test sessions with a small group of End Users.
I would construct mine in a structure like this. List your main topic (Software, Hardware, etc..) then get more granular within that. Makes it easier for end users to understand and search. This is how I do mine as well.
Thanks for replying both of you. I'm starting to get a better idea.
The bit I can't get my head round is if say I define a top level of
Then below that I have a service e.g. Theatres System and then I can define a request process against that to request access.
But once the user has access where would I then link a request process to ask for extra access?
when I look at the service window it only has an option for one request cycle
but I am thinking of active directory as a service, so firstly they might want to request a user account, then they might want to request access to specific files and folders
would I have to define Active Directory - New User as a service with a request process
and Active Directory - Folder Access as a service with a different request process
i'm sure it all makes sense when you have it up and running, but with just the OOTB stuff I'm just not sure
In our specific case, we used the HR module for the Active Directory user object creation, then another process for the actual onboarding. We used this with LPM and roundtrip automation to automagically create the user accounts based off the details the user entered about the person. Then there was an onboarding process in the HR module we also used for the official notifications that went out to our company managers about new employees.
We then used the Request Management module for all the other "IT Service" requests, but we made a collection of the Request business object on the Human Resources Activity business object. That way we could create requests off of the initial new employee request and send those out in tandem with all the other requests that are apart of a new hire. We mainly made use of bundle requests with pre-defined access role (Financial Anaylst, Residential Underwriters, Human Resources Rep., etc...) that were just bundles of Service Catalog entries. These would contain all the folder shares user groups, softwares, hardware needs, etc... that the new employee would need. We mostly used the OOTB processes for access, hardware, and software and added the automation piece for a lot of them. It makes for a pretty quick New Employee process.
I think you need to determine if you want people to select what they need inside the Service Catalog only or trigger service catalog requests in some other separate process. Starting new employees is a BIG process that requires a lot of thought(atleast in our case anyway). We debated sending people to the service catalog when they started someone for all their requirements but there are way too many to have people navigate through the catalog and ask for 20 or 30 individual services after starting someone...
Hello everyone, I have found this thred useful as I am just in the process of drafting my Service Catalogue. I know this is cheeky but I am wondering is anyone would be happy to share the full breakdown of their Service Catalogue? I would be particularly interested in the structure of a Local Authority Service Catalogue.
Many thanks for you help - this is just as I was looking. I appreciate you taking the time to reply to me.