CRs on SSD

Open discussion about the Alloy Navigator 6 Web Portals

CRs on SSD

Postby pgerner on Tue Jan 12, 2010 9:59 pm

Hi,

the new web portals are really nicely improved, our whole team was impressed.

However I was sad to see that the end users are still not able to raise change requests on the SSD. It was something I really missed in v5 and hoping that it'll be introduced in v6.

I had a discussion previously about this with Alloy support. We ended up that there are cases when end users has to differ between this two, but currently there are only some 'dirty' ways to do so (submit everything as incident but use the category field to mark as CR and escalate by the tech as a CR, or use the mail connector to raise the CR), in every case the end user lacks the possibility to follow the lifecycle of his ticket.

Is there any specific reason to leave it out from the SSD?
Are we the only ones facing this issue with AN?

Peter
pgerner
Junior
 
Posts: 8
Joined: Wed Sep 17, 2003 7:05 am

Re: CRs on SSD

Postby pille on Wed Jan 13, 2010 3:22 pm

pgerner wrote:Is there any specific reason to leave it out from the SSD?


Yes. I guess what's important is to define what a change request is to us.

Change Requests are an IT function that end users do not have the scope of knowledge to deal with. It should be used for requests regarding changes that could negatively impact your ability to provide service. For instance, change to an inhouse financial application, replacing a network switch, rolling out software, upgrading your production email service. They aren't for computer order requests or software installation requests.

We believe that if you want to have an end user request a change to your environment it should come through as an incident type = request. This way IT can determine if it should even be considered to be a change request and you can keep end users updated by having the Change Request (if there is one related to the incident) update the Incident.

If the end user is heavily involved in the change management process, they should probably be a technician. Or if they aren't involved enough to be a technician and they do have enough scope to request changes, I would have them submit them via email and generate emails to them to advise of the status, but this part of course is a choice.

As far as Computer, Software, Move Requests, etc. These should be submitted as an Incident Type = Request. This falls under Request Management in our opinion. Not Change Management.

This should be in line with ITIL which is what we based the design on.

What are your thoughts?
Contact Technical Services directly:
support@alloy-software.com
http://support.alloy-software.com

Paul Ille
Alloy Software
Maximize your IT Universe
Follow us on Twitter: http://twitter.com/alloysoftware
Image
User avatar
pille
Alloy Software
 
Posts: 473
Joined: Thu Aug 11, 2005 3:11 pm
Location: New Jersey, USA

Re: CRs on SSD

Postby VTBanker on Wed Jan 13, 2010 5:13 pm

pille wrote:What are your thoughts?


I was always looking for the same option pgerner was but I agree with Paul that it would fit ITIL process. Perhaps on option in the incident to convert or copy to a CR that would create the CR with the same information and relate it to the Incident in one grand swoop. We have a fair amount of requests that end up being CR and are just to lazy to create a new CR from scratch.
User avatar
VTBanker
Senior
 
Posts: 43
Joined: Mon May 17, 2004 3:46 pm
Location: Morrisville, Vermont

Re: CRs on SSD

Postby pille on Wed Jan 13, 2010 6:11 pm

VTBanker wrote:Perhaps on option in the incident to convert or copy to a CR that would create the CR with the same information and relate it to the Incident in one grand swoop.


Then you'll like the things you see when you further into the new workflow. You can do this now :)
Contact Technical Services directly:
support@alloy-software.com
http://support.alloy-software.com

Paul Ille
Alloy Software
Maximize your IT Universe
Follow us on Twitter: http://twitter.com/alloysoftware
Image
User avatar
pille
Alloy Software
 
Posts: 473
Joined: Thu Aug 11, 2005 3:11 pm
Location: New Jersey, USA

Re: CRs on SSD

Postby pgerner on Wed Jan 13, 2010 11:30 pm

OK I have to admit I'm not an ITIL expert :)

For me incident is when something doesn't work as it's expected; something what was already in production and was working on a given way and for some reason it stopped or changed. This should be handled with priority and the operation must target the recovery of the original (operational) state ASAP. It does not need any decision making (to restore the functionality or not) in the majority of the cases.

CR is when you want to change the way something works or implement a new feature. It has to be managed in a completely different way: it has to be approved, scheduled, tested, etc.

If we take your example (change an inhouse financial application), what supposed to be the workflow? If I have to answer, for me the finance team need to request the change (they know the reason and they have the need) by raising a CR. It not supposed to be an incident, as basically there's no problem with the application, it works fine, simply it lacks a feature. Probably the change has to be made in 6 months time. Then the IT team approves the request (no negative impact on other things, etc.), schedules it (according to their availability and the priorities), probably makes a staging test (which is to be confirmed by the requester) and implements the change (which is to be confirmed again by the requester).

So I think end users might raise change request and invoved in them without being technicians.

I'm not telling you that it cannot work on the way you described; especially with these workflows you can make a sophisticated way to handle them differently. What I'm asking, if the application provides multiple ways to decide how you want to manage the workflow, shouldn't it be a possibility to raise other kind of tickets on the SSD? Even in the application logic it is possible to do so (by email, by workflow), but not on the SSD interface. This seems to be a limitation without real justification for me, especially as I suppose the change would require minimalistic development, the required code already exist for the tech portal, just need to remove a fair portion of actions available for the techs but not end users.
pgerner
Junior
 
Posts: 8
Joined: Wed Sep 17, 2003 7:05 am

Re: CRs on SSD

Postby eliaslynch on Thu Jan 14, 2010 6:38 pm

pgerner wrote:OK I have to admit I'm not an ITIL expert :)


Let me admit I'm not either hehe

pgerner wrote:If we take your example (change an inhouse financial application), what supposed to be the workflow? If I have to answer, for me the finance team need to request the change (they know the reason and they have the need) by raising a CR. It not supposed to be an incident, as basically there's no problem with the application, it works fine, simply it lacks a feature.


The word scope does it for me. If they don't have that scope, they shouldn't be making change requests. Example, does someone in this finance team understand the full ramifications of what they are changing? If so they are a developer/technician in Navigator.

but there's a fine line which the amount of trouble we all want to go through as IT people to control things like this.
--------
Elias
User avatar
eliaslynch
Senior
 
Posts: 212
Joined: Wed Jul 09, 2008 7:03 pm

Re: CRs on SSD

Postby pgerner on Fri Jan 15, 2010 12:15 am

Of course they won't be able. They request the change only, this is why the CR has to be approved (by the techs who are able to judge it).

On the opposite way, approval mechanism exist only for the CRs (perfectly, as it makes sense only for the CR, there's nothing to approve on an incident).

But let's stay on the idea: they open an incident (request type) for the change. What happens to this incident? Normally techs decide if it makes sense or not. How do you follow this process in AN? You might make all hustle-bustle by adding activities like 'DBA is OK' 'Sysadmin is OK' 'Security asks if...' ? Good luck to follow... or you convert/escalate it to a CR. And poof, the user is not able to follow the ticket on the SSD anymore, but has to rely on the notification mails you send.

I think the line between an end-user and tech is not decided by the fact he is able or not raise CRs (anyway, if a CR is raised it doesn't mean that it'll be implemented as well, right?), but what he can do with the tickets. Normally end user can raise tickets only. Techs can be assigned to tickets, add activities, participate in CR approval, reject them, resolve them, etc etc etc.

But again, it's up to you if you prefer your end users to raise or not CRs; my question is still the same: if the application supports the possibility for this scenario by email, why it isn't support by web??
pgerner
Junior
 
Posts: 8
Joined: Wed Sep 17, 2003 7:05 am

Re: CRs on SSD

Postby pille on Mon Jan 18, 2010 2:14 pm

pgerner wrote:if the application supports the possibility for this scenario by email, why it isn't support by web??


Email is always supported due the need to have the mail connector process email updates to all ticket types. Because email is supported for CRs it doesn't mean it was meant for 'ssp customers'. It doesn't change the design point of view that CRs are for use as an internal IT function.

What you have here is an interpretation of ITIL and sometimes ITIL can be so vague that it's interpretation has a lot of flex in it. I'm going to look into specifically what ITIL says and I'll add to the discussion when I have time.

I can see both sides of the discussion.

I urge anyone else with an opinion on this to continue the discussion in the meantime.
Contact Technical Services directly:
support@alloy-software.com
http://support.alloy-software.com

Paul Ille
Alloy Software
Maximize your IT Universe
Follow us on Twitter: http://twitter.com/alloysoftware
Image
User avatar
pille
Alloy Software
 
Posts: 473
Joined: Thu Aug 11, 2005 3:11 pm
Location: New Jersey, USA

Re: CRs on SSD

Postby pille on Tue Mar 23, 2010 12:39 pm

Alright, sorry for the late reply, but I've been so dang busy as of late. I took a look at a few sources and had some discussions about it.

ITIL uses the word 'initiator' when talking about who submits a change request. They don't define who this person is in terms of role. Over at Wikipedia, for what it's worth, they say one of the five sources of a change request would be system enhancement requests from users. In additional I found several sources stating that the requester should be technical and then also that there's no need for them to be technical. And then, as we talked about earlier, Alloy's interpretation to this point has been that the requester of a change request should be technical.

The different points made during discussion were some of the same I had already made. The word tossed around was translation.

By translation it's meant to say that a typical user will not have the ability to put a 'request' into 'change request' form. They may have a request, but a change request must have much deeper details including justification, alternatives, scope, etc. Yes, these things can be filled out by a technical person later on, but the lack of these things may lead to a very messy change request process. You'll surely see many change requests that lack requirements, etc. At some point the change request process may be overrun with bogus requests that never should have been opened in the first place and that will lead to more work.

Our recommendation is that, in cases like our finance application example, you have a team lead. That team lead is a manager or a super user. This person knows both the ins and outs of what they're requesting and they understand the general scope at least. This person may receive requests from others on their team, but they use their better, more informed, judgement to determine which requests should be made to IT. This team lead or manager may also be someone who signs off on changes made to systems/processes they oversee. This person would either be a technician or they would be involved with change requests via email using the mail connector and/or business logic for communication.

In my talks I didn't get a feeling of change on this topic, but I would encourage anyone who feels this approach is wrong to send an email over to support to request a change. We heavily rely on customer feedback on topics like this.
Contact Technical Services directly:
support@alloy-software.com
http://support.alloy-software.com

Paul Ille
Alloy Software
Maximize your IT Universe
Follow us on Twitter: http://twitter.com/alloysoftware
Image
User avatar
pille
Alloy Software
 
Posts: 473
Joined: Thu Aug 11, 2005 3:11 pm
Location: New Jersey, USA

Re: CRs on SSD

Postby ICT Tebodin on Mon Jan 31, 2011 5:10 am

Peter, Paul,

Both your point of views make sense to me. The processes in our company were like the ones you describe Peter.

For me in the end the practical side is the most important. We have implemented Alloy and want to work with it the best way we can. We might change our processes a little if it means we get what we want in the end!

I am trying to implement our processes (Incidents, CR's) in the SSP the best way I can, using the Alloy point of view. In our company users may have a change request issued, if we implement this in the SSP as an incident, the most important thing to have is the approval the end-user needs to have from his/her boss.

When the boss approves the incident (CR), then the Technician gets involved (via a change request linked to the incident???) to further handle the change request.

The basic idea is that an end-user can have a need for a e.g. software program and issues a ticket in the SSP to request this. For me the most practical would be that the end-user chooses from a list who needs to give approval for this and submits the incident.

How does an approval cycle like this fits into your (ITIL/Alloy/Business process) thoughts on this?
User avatar
ICT Tebodin
Senior
 
Posts: 30
Joined: Tue Oct 13, 2009 8:56 am
Location: Netherlands


Return to Alloy Navigator 6 Web Portal Discussion

Who is online

Users browsing this forum: No registered users and 1 guest