Jump to content

Raising a Change ...


Steve Giller
 Share

Recommended Posts

Hi Folks,

We're looking into using Change Management - maybe not "properly" but we want to give it a go. It's not something we've ever done so we're totally starting from scratch.

I'm basically stuck at the first hurdle; how does one actually raise a change?
If I start with what we ideally want and then you can tell me why I'm going about it all wrong ...

The two things we're wanting to treat as changes as a starting point are: IT - website blocking/unblocking, and Facilities - Rom setups. In both cases it's because we schedule these and want to use the calendar for visibility.

I can't see a way to raise a change through the service portal - and from the live portal you can just raise a change, not specify if it's IT or Facilities.
I can log a request and set a Task to raise a change from it, but I can't see how to get the details (customer, site, summary etc.) from the Request to the Change without re-entering everything.

All help will be gratefully accepted.

Link to comment
Share on other sites

Hello there

Great news you want to expand into Change Management, in my experience it is straight forward once you have ironed out your process, it is just deciding how you want it to work. 

Changes cannot be raised from the Service Portal firstly, only Incidents (something is broken) or Service Requests (something is wanted). Change is an internal process that may address one or many Incidents or Service Requests, but it will always be driven by the internal team rather than the end users. 

Firstly you will need your change process configured in the BPM of the admin tool. Once you have these (can be one for both IT and facilities, or separate processes - whichever works best for you). Then you will need a service to drive these changes through. You will already have a request catalogue, so it is up to you whether you would like changes created against the same services that you currently offer, or via a new service. If you already have a facilities service for example, then you can set up the change process to run underneath that service via the service configuration -> request config -> Change, and this will run in parallel with any existing Incident / Request processes that may already be configured.

So to answer your specific points it will be the service that distinguishes between IT and Facilities (that is the way I would recommend anyway) and then if you have different processes / teams involved then the changes will be clearly partitioned. In terms of scheduling the change form has an extra analyst action at the top (next to the resolve button) to schedule the change. Once a change has been scheduled in there then it will appear in the Change calendar. 

Each analyst that will be logging changes, resolving changes, and viewing the change calendar will need the appropriate rights added to their analyst profile if they are not there already, these will all begin with Change in the roles section of the analyst profile to make it simple.

Once you have got this far then you can start experimenting with other additional features such as the boards for an always up to date birds eye view of all the changes currently in play, or a change workspace to push out key updates automatically to interested parties.

I have attached my Change Process as an example, which you are welcome to import into your BPM in the admin portal and use as a template for your process(es) moving forward. 

Lots of information there, but give it a try and let us know how you get on. 

Thanks

 

change-process.bpm (2).txt

Link to comment
Share on other sites

That's a really good process - we're nowhere near that level of complexity yet, but it's great to have something to work towards.
My only real issue is while it could be argued that our requirements could be met be a Service Request (certainly in the case of the Facilities one) that doesn't give access to a calendar, which is highly desirable to avoid over-committal of resources (as they can be shared across sites.)

I currently have a request come in and from this a change is manually raised - but the details are in the call and the team raising it aren't happy about copying the information across, and the team actioning it aren't really savvy enough to flick between a change and its linked call(s) - coupled with the fact that they work from Mobiles which makes swapping about more awkward.

Any tips on how to (at least partly) overcome these kind of obstacles?

Link to comment
Share on other sites

Firstly for the people working from mobiles it may be easier for them to be assigned activities from the process rather than the overall request, this will mean that there is no need to switch between linked requests etc. and the parent request details can be passed through to the tasks so that they can still see the customer, site, summary, etc. as well as any progressive capture answers that may be required for that particular task without having to switch between linked requests - everything you need for that bit can be found here: https://wiki.hornbill.com/index.php/Request_Variables

In terms of passing the detail through to the change via a linked request without needing to rekey everything - this will only be possible using the same request variables method details above and passing everything required into the summary and description field of the main request at the moment. It is an interesting point and one of the product owners may have a comment about this, but the way I can see of getting that detail across would involve a node in the process to get request information, and then setting whichever variables you want to pass through to append to the existing request description so that when a linked request is raised all of that detail will then be in the summary and description fields, and automatically copied across.

As long as it is set within the update node to append = yes nothing will be overwritten, and all the question and answer values as well as the request details (customer, site, etc.) will all remain where they are, but copied into the request description too.

I have drawn and attached a 5 second process to try and highlight what I mean because it isn't as easy as i thought it would be to articulate :mellow:

You could have a task in the existing process asking the owner of the request if they need to raise a linked change, and then a decision node to say if the answer is yes then add these variables to the description, and then another task to the owner to complete when the linked request has been raised so the existing process can carry on / go on hold / update a board/workspace if applicable...

 

pass-through-details-example.bpm.txt

Link to comment
Share on other sites

I understand this part - the problem I have is that nothing is passing to the raised Change apart from the Customer - the Site is incorrect (the Customer site is populated not the Site linked to the Parent call) and the Summary & Description are blank.

The Change was raised using the Link tab and the Raise new linked request -> Change option.

Screenshot 2017-03-17 10.24.07.png

Screenshot 2017-03-17 10.18.54.png

Note: Just for clarity - the actual process for the Change works fine, generates tasks, appears on the Calendar and moves around boards - I just want to avoid having to re-enter the data (which will all be in the Summary/Description) or have the requirement that it has to be raised by an analyst.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...