7 Replies Latest reply on Mar 28, 2016 5:29 AM by chooi

    Approach to implementation of the Self Service Catalog

    louise.piper@it.ox.ac.uk Apprentice

      We're launching our Service Catalog in the New Year so I'd be really keen to link up with people to gain a little insight into how you approached your implementation, challenges you faced, recommendations on quick wins and things to avoid.


      HEAT Cloud Support tell us that there is a real mix of customers who use Export/Import to implement and update their Request Offerings, and those who use the Project/Package functionality. I'd be interested to hear how people manage this in practical terms. For example, do you create and publish centrally or do Service Owners create their own offerings? What are the challenges you face in doing this?


      I'm more than happy to discuss offline if you'd prefer, so please feel free to contact me direct if you wish: [email protected]

        • 1. Re: Approach to implementation of the Self Service Catalog
          SusanJS Specialist

          We are also getting ready to launch Service Catalog, but we're going to be starting very small as I know we will be flooded with requests for offerings.  We considered opening up Service Owner roles, but the fact that they would need access to workflows would get tricky.  I was advised by HEAT Software PSO that the Service Owner role really needs to stay with Admins because of that fact so I would be interested to know what others are doing with this as well.

          1 of 1 people found this helpful
          • 2. Re: Approach to implementation of the Self Service Catalog
            chris1 Apprentice

            We have been working with request offerings in the Service Catalog for a little while now. We have learned quite a bit in this time and I believe there is still a lot to learn. Request Offerings can be pretty tricky. I don't think I would open it beyond Admins. We have often ended up having to create supporting forms or pick lists, it also helps to have admin knowledge to understand the things that need to be handled within the request versus at the form level.

            Here are some things that I have learned.


            Here is our current stance on moving items into production:

            1) Brand new items will be exported and imported.

            2) Future items should be moved through the use of packages. Importing an updated item and renaming can cause alot of confusion in the already existing item.

            NOTE: It is likely that Importing a new Service request will prevent the creation of the appropriate escalation schedule for the item. I found this out just recently and I am working with support to resolve.


            I recommend that you set the Service Catalog to Show all items rather than Popular items. While the Catalog is small this will ensure that they are all visible without the need to sort through the Categories. As it grows larger, you can reconsider.

            When we began we created a Generic Request. This allowed us to get our users use to using the Service Catalog while we built it out. This has been helpful, but at times it has hurt a little as it has caught some items that probably shouldn't have been created as a request.  


            When considering access requests I recommend looking at building one item to handle all of the applications versus creating one for each application. Remember people will likely need to request access outside of the onboarding process.


            When you begin building items. Keep it simple. The first version that you create will probably never be the version you publish in production. I usually ask for a document to help me understand what they are looking for along with some sort of flow chart. I then build what I think they are asking for and show it to them. That gives us a much better place to start the conversation. Most of these items will end up taking a little longer to get into production than you expect. There is a lot of design and redesign as people first get used to the capabilities of the tool.

            4 of 4 people found this helpful
            • 3. Re: Approach to implementation of the Self Service Catalog

              We went live with Service Catalog back in February 2015. Prior to using HEAT cloud, we had 30 +  web forms that routed to different teams based on service requested.

              All new and existing service catalog offerings are done by a group of Admins.

              I would strongly advise using the import/export feature. Build in staging and export to Production. We only use the project/package functionality for very complex changes to the environment because it does require your production tenant have downtime that you schedule with the Heat Operation Team.


              I also noticed an issue with escalation schedules not creating recently when importing. I also get this when doing a copy from within Production. I also will be working with support to resolve, perhaps it's an issue with the latest release.

              3 of 3 people found this helpful
              • 4. Re: Approach to implementation of the Self Service Catalog
                chooi Apprentice

                Hey Chris, How do you  set the Service Catalog to Show all items rather than Popular items?

                • 5. Re: Approach to implementation of the Self Service Catalog
                  chris1 Apprentice

                  Open "Configure application

                  Next navigate to "Roles and Permissions" and select the SelfService Role.

                  Click "Top Level Tabs" and then click "Service Catalog"

                  Finally update the Default Category to be "All Categories" under the Navigation settings:

                  1 of 1 people found this helpful
                  • 6. Re: Approach to implementation of the Self Service Catalog

                    We have approximately 260 offerings used to manage workload across the company spread across 45 teams. I always hoped to allow users to create there own catalog items but in practice with this amount of teams I've found this is always going to be very difficult. Aside from the organisation of the categories somebody really needs to sit back and advise on best practice and offer solutions. When we went live a year ago I also managed to break the whole service catalog with one of the configurations I added - I wouldn't be able to put this kind of responsibility on a non technical user.


                    From a service management point of view the service catalog should be reviewed regularly to fine tune and cut out 'deadwood'. Left to their own devices I think it could get in a state and ultimately lose its value.


                    With regards to designing they will need to understand how to design the form which in itself isn't fiddly but sometimes has reliance on admin jobs (like adding attachments), then theres the workflows which do require admin knowledge unless its a simple Start - Update - Stop and finally theres the OUs which need to be understood (which ones whould it be shown to?).


                    My approach is to retain responsibility but let them design and play a part in the build. I have my own forms setup in the service catalog to manage my workload as an Admin Team function - one of these is to create a new request offering. In the form I ask for specific information (see below) which will help me setup the forms and I can generally create them fairly quickly (other than the push).


                    I've tried to use the import before but found it conflicts with projects - If I create a form and export/import it, in the background metadata has been created which if you then try and push conflicts because it already exists. The obvious answer is to not package these transactions but this is easier said than done when you forget to change projects.


                    2 of 2 people found this helpful