Change Request - Customer (Contact) not displayed

[Martyn Houghton]

When we log a Change Request against an Contact (external customer) the customer information is not displayed in the request screen, only the name of the analyst who raised the request in the 'Raised by' section.

We used Change Requests for our external customers to control changes to their systems we host for them, but it appears the 'Change Request' screen seems to have been formatted just for internal use or am I missing something?

 

Cheers

Martyn

 

[Gerry]

Martyn,

Following ITIL strictly..... change requests are not in themselves really requests - they are changes that are typically made to resolve one or more problems or known errors.  This is why a change does not directly have a customer at the moment.  This of course does not work in all scenarios when a customer can request a change.  I hope one of the SM experts will give you further clarification on this, but thats my understanding. 

Gerry

[Guest]

Hi Martyn,

As Gerry mentions, we don't currently employ the concept of a customer directly raising the Change Request itself. One of the ways that we recommend (and that a number of our other customers employ) is that external customers can submit a "Request For Change" - which, for example, is a Service Request that could have its own Service or Catalog Item and its own workflow (which could also be requested on the Service/Customer Portals). 

If this Request For Change is approved (you could build authorisation into the workflow if necessary), then an actual Change Request would be raised by an Application User - or "Change Requestor" - and the process continues from there. You can close the original Service Request and link it to the Change for reference. 

On top of this, you could also add the "affected" customer(s) as connections on the Change Request, so you have a quick view of the customers and interested parties, and could quickly email them all with any updates during the Change Process if required. 

Kind Regards,

Bob

[Martyn Houghton]

I think the distinguishing factor for us is that we (Change Requester) raise change requests against a customer (external contact/organisation) record when a change needs to be made to the customer hosted system. Changes only relate to a single customer. Most the change requests will be raised from incidents where a analyst needs to make a change to a hosted environment to resolve an issue.

We then report on all the change requests on a monthly basis along with incidents to the each hosted customers as part of their service management, but by who raised them. This process we use already in Support Works.

At the moment, even though we capture the customer details as part of progressive capture the system is ignoring this and setting the customer details in the h_itsm_requests table to the person who raised it, i.e. the Analyst. This is a major restriction and issue for us, as this breaks the context of the change request and renders the change request call type unusable. 

The workaround suggests seems to be more aimed as RFC's for software changes, where they may be common with a number of customers, rather than managing environment/infrastructure changes which affect a specific customer etc. Raising a Service Request in order to then raise a change request seems a bit odd along with adding connections in order to identify the related customer.

Cheers

Martyn

 

 

[James Ainsworth]

I'm going to try not to get too entangled in ITIL and best practice other than to say that many areas in Service Manager started with ITIL in mind and from there built on to provide the flexibility needed by our customers.  By the sound of it, what needs solving is that ability to report on a customer and show which requests, of any type, that are linked to them.

What we are trying to solve with having the "Raised by" instead of the customer is that it give an internal reference point for either the CAB or the engineer facilitating the change to go back to.  As a result of an incident being raised a change may be requested to fix something.  This request will generally come from the incident owner, problem management, or possibly someone who has been brought into review the incident because of a particular area of expertise.  These will generally be the people referenced against the "Raised by".

The Connections feature was added as a way to manage the connection to the customers.   Some may only have one customer linked, but others will find that a change may impact or provide something for multiple customers.  The Connections allows for both scenarios where as the "Raised by" is only ever a single person.

Some of the progressive capture forms are specific to certain types of requests.  It is not always obvious where each form can be used.  The Customer Search progressive capture form is primarily for Incidents and Service Requests. We have a planned change for a new progressive capture form to add Connections when raising a Change or a Problem, however we may find that the Customer search could be made to accommodate this when used with Changes and Problems.

James

 

 

[Martyn Houghton]

James

I think the fundamental issue is that the system is forcing the duplication of the Request Creator information and applying it Customer details on the request. From an internal change request focus, I can see the reasoning for linking it to only the request creator and then using the connections to link to affected customers (akin to linking a problem to multiple related incidents), but from an external focus where the change requests relates to specific organisation this does not really add up. 

You will not be able to locate/filter change requests on the Request List by organisations and similarly in reports and dashboards, plus in the future you will not be able to display change requests on the customer portal that relate to the customer's organisation.

In terms of best practice this should recommend the best/default approach, but not limit the capability of the system, as this is something that is simple in Support Works, where you have the option to raise against any contact type, whether it is an internal or external one.

From looking at the underlying system request table, these does appear to be a fairly contained and minor change to provide a configuration option to allow change requests to be linked to customers and not the request creator. If I take my example change request I used in my original post and then update the h_fk_user_id, h_container_id and h_customer_type by data via database direct to the correct details which would have been selected in the progressive capture using the customer search node, the change request is then correctly linked to the customer and organisation.

This then appears correctly in the Request Screen

 

And then in the Request List

 

The only other alteration that I can see is the reinstatement of the change customer action option on Change Request form, as at the moment even for current change requests you are not able to alter the request creator.

In summary I can see the that using the request creator and connections is viable as an option for internal originated change requests, but it is not applicable or scale able where you are dealing with external customer specific change requests. We are currently logging around 180 change requests a month with it growing as we expand the provision of managed/hosted services to our external customers.

If you want to give me a ring, we can discuss this further.

Cheers

Martyn

 

 

 

 

[Martyn Houghton]

James

Thinking about this further, there is a simple temporary fix that could quite easily be implemented in SM 2.2.28, which is to just enable the change customer option. This would apply to both the original scenario, as at the moment you can not change the creator/customer of a change request, unlike all the other request types.

By re-instating the change customer option, those who wish to stay as it is now, just disable it in the services setup. We can then change the custoemr to the actual customer after it is created via progressive capture. 

Cheers

Martyn

[James Ainsworth]

Hi Martyn,

Our direction with managing customers against changes is using the Connections feature.  We have some upcoming changes which should help assigning customers to a change in progressive capture as a connection.  My concern with putting in a temporary fix is that we will end up with two different places or ways of associating a change with a customer.

Regards,

James  

[Martyn Houghton]

James

I understand you concern, but it is fact already the case by introducing connections as the means of associating a change request rather than the using the owner element of the entity used in the other request types. You can no longer see all your request for an external organisation via the request screen. 

I was referring to enabling the change customer  option as a temporary fix until the full option to either associate a change request to person raising it or capture the customer. 

Similarly we could apply using the connections element of an incident or service request to identify that it affects other customers/organisations, but we still have the ability to link those to an external customer and organisation.

I sorry to go be a pain, but we see this as a fundamental issue and a unnecessary restriction on change requests, when the same restriction does not apply to other requests types using  the two different places or ways of associating a request with a custom and connections.

I think the tool should have the option to configure whether we want to capture the customer in the progressive capture for a change request or for it to be applied to request creator.

In summary, I not asking to remove the option to link to the request creator, just allow for the option to link to a customer if we choose too in the progressive capture.

Cheers

Martyn

[James Ainsworth]

Hi @Martyn Houghton

I just wanted to let you know that in Service Manger build 914 we have a new feature to allow for the association of a primary customer with a change request.  As you had suggested in a previous comment above, you are now able to enable or disable the "Change Customer" action on a change request from within the Service under the "Request Configuration" option.  This will allow you to add a customer to an existing change. If a customer has been added in progressive capture, the customer section will be exposed in the Change Request showing the customer.  An additional option also allows you to remove the customer from within the customer section if one has been added in error.

Regards,

James

[Martyn Houghton]

@James Ainsworth

That's great, we will enable on our services now. Thanks for pursuing this.

Cheers

Martyn

 

[Guest Paul Alexander]

Hi @Martyn Houghton and @James Ainsworth

I realise this is a very old post, but I'm struggling with getting a Prog Capt to work which is using the Co-Worker search form to add the chosen co-worker as the customer of a change request.

Although the co-worker form does show, once someone has been picked the Prog Capt just hangs showing a blank screen and not the next form. 

If the co-worker form is removed from the Prog Capt then the rest of the questions show as expected. 

Looking at the request (above) is there a setting somewhere to allow co-workers to be added as customers of a Change Request? 

thanks

 

[James Ainsworth]

Hi @Paul Alexander

There isn't a setting to enable this.  Adding a customer in the search forms will just add a customer to the change.  Does Progressive Capture hang after selecting the user or after clicking on the Next button on the Search Co-worker form?  Does the same thing happen if you replace the Co-worker search form with the Customer search form?

I will also do some tests to see if I can replicate.

Regards,

James

 

[Guest Paul Alexander]

@James Ainsworth

It hangs as soon as you've selected a co-worker (before i select Next). I've tried changing the co-worker to a customer search and it's still the same.

 

thanks

[James Ainsworth]

Is the Co-worker Search / Customer Search working on other progressive captures?  Is it just the one progressive capture where you are having the issue?

James

[Guest Paul Alexander]

Yes the search works on all other Prog Capt's it's just this one where it doesn't.

 

[James Ainsworth]

I can only think that something has become corrupted in this particular progressive capture flow.  An option might be to recreate from a new, blank progressive capture or you may need to export the problematic progressive capture and send it into support to have a look at.

James

[Guest Paul Alexander]

@James Ainsworth

Thank you....I tried recreating the Capture but that had the same problem

I've now logged a request with support

thanks