2 of 2 people found this helpful
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.
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.
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.
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).
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