5 Replies Latest reply on Aug 18, 2016 6:30 PM by Donna

    How are you implementing change?

    ccrispin Apprentice

      We have recently rolled out service requests and incidents and are now looking to roll out change.

      I am trying to get my head around who exactly should be logging the change requests, what role they would use and if utilising self service is an option.


      Initially I thought utilising self service for the submission of change requests would be the best option, then any staff member could request a change. Though after looking at how to give self service users access to change it appears that a self service based request form would be limited with no rich functionality such as the risk tab.


      Without using self service I would need to give any staff needing to submit a change request, another role. I thought service desk analyst would be suitable but change is not fully enabled for this role. Then I started thinking about giving these staff change manager role but really think that is over the top.


      I understand I can adjust a role or create a new one to suit our requirements. I am just a little confused how front range/HEAT think change should work OOTB. Do they think only a change manager should submit changes, or that all changes from technicians would come from incidents and problems?

      Im interested to know what paths you all have taken in terms of who submits changes and what role they use to do this. Any other hints and tips would be great also

        • 1. Re: How are you implementing change?
          stapletj@tbh.net Apprentice

          I'm still in the planning phases of rolling out change, but my workflow sketch has all RFCs come from either incidents or service requests.

          2 of 2 people found this helpful
          • 2. Re: How are you implementing change?
            davidjohnson Apprentice

            We are also in the planning for configuring change (expected roll-out in Q1 '17).  We will replace an in-house developed change mgmt. system with HEAT SM.  I agree most RFCs would originate from service requests and incidents.  You could also have a RFC triggered by an event.  For example, a disk volume fills to a threshold value which alerts the Storage team to create a RFC to increase the space allocated.


            I don't think the Change Manager role should be the only one to submit changes.  I believe that the support staff doing the work should create the change.  The originating service request, incident or event should provide the necessary data for the support team to create the change.  If not, adjust the Q&A in the service request or the data collection for the incident to provide greater clarity.

            • 3. Re: How are you implementing change?

              We did exactly the same thing in April of this year.  We went from a home built program to Heat for change.  This was more of a business decision for us.  We have an IT role that all IT folks can use for changes.  That role has access to the Change workspace. We have two forms for changes. One for them and one for the Change team.  We can then control what fields they can see or have access to.  As far as whom creates the changes, it depends. Your company might want Project Managers doing this for projects, or team leads, key developers, or everyone.  Unfortunately, our company has historically not had changes originate from just service requests or incidents so we created an option to let users have the ability and handle it via company roles and responsibilities. It's probably a backwards approach, and not ideal. But we provided enough "shock and awe" that we didn't want to radically change everything at once. We are linking changes to things, but they aren't necessary originating from the other workspaces yet. 


              And this was OOTB. However, we are far from out of the box now.

              • 4. Re: How are you implementing change?
                rcarins@cssdelivers.com Apprentice

                Hi Charles,


                As far as how Change works out of the box, it's setup so SDA role can create a change request from Incident or SR, but as you've probably found they can only fill out a subset of the field, it's then the change manager roles responsibility to complete the change request and submit it for approval.


                This hasn't worked for most customers I've implemented heat for, usually in my experience a 2nd / 3rd level technician would have the SDA role and they'd normally fill out the change (including some new fields we create for the Implementation/Test/Backout plan). The easiest way to do this is to change which layout the SDA role uses, to the same one the change manager role uses (it's just called 'Change' OOTB).




                • 5. Re: How are you implementing change?
                  Donna Apprentice

                  Based on what you have said, I'd create one or two Request Offerings that allow your Self Service user to make RFC.  Going as far as adding a category for this.  ServiceDesk can then ask for any obvious clarification and pass the ticket to the relevant team for evaluation.  Potentially you could add a field the Self Service user can see the change number as well and add a little functionality for ServiceDesk Analyst.


                  thats my thoughts anyway