Open for Voting

Management of ITIL's Request for Change (RFC's)

WHD's existing "Approval" process has some useful benefits; however, it also has some severe limitations with regards to change management in an ITIL framework. One obvious example is that a RFC number should be separate from a Service Request/Problem/Incident number.

In the previous forums for WHD there was discussion (http://forums.webhelpdesk.com/forums/comments.php?DiscussionID=77) going regarding separating out the Approval process from the ticket management function even including a mock-up screenshots. Depending on how this was implemented in the code it could be a configuration option selected by the Administrator of which functionality was enabled the exiting one, or an ITIL style one. In some cases it might even be useful to have both styles enabled depending on an organization's business logic.

Paraphrasing some of the discussion from the other forum the current approval process does not fully implement the RFC process. What this means is that basically an RFC is submitted and issued a number. This RFC is then reviewed and approved/disapproved, etc. This part of the process the exiting "Approval" process engine could be adjusted to work well for. However, the next part relates to implementing ITIL's "Standard Change" a service request "Request Type" template is created that is cross linked to the pre-approved "Standard RFC". In this way as long as the pre-approved "Standard RFC" exists no further formal review needs to be done on a per ticket basis. When a ticket is opened and the appropriate "Request Type" is selected the related RFC's "implementation" details are then visible from the service request ticket and then the tech only needs to enter in the specific details needed for that specific request.

What would work better from an ITIL perspective would be to separate the "Approval" process engine from the "Ticket" section (Service Requests, Incidents, Problems) and create a entirely separate section that increments its own number scheme (RFC 1, 2, 3...). Using the "Approval" process on this would provide the ability to create & managed RFCs very easily. Maybe change the "Approval" tab name to "Change Management" or the like. Then add some sub-tab's underneath that for "Pending RFC's", "Standard RFC's", "Closed RFC's" or something.

In the perfect world RFC's can be cross-linked with other RFC's (historical reference, dependencies, etc), Assets (track changes done to a device), and Tickets (service requests, etc.) this allows for easy management of cause-and-event related failures, etc.

There is a ton of other discussion points that were brought up and looking at some of the other request that have already been (re)submitted here on Thwack it looks like the whole approval process still has areas for improvement.

Existing "Approval" related requests in Thwack

1. ALLOW APPROVAL VOTES TO BE CHANGED BY APPROVERS (http://thwack.solarwinds.com/ideas/1908)

2. TICKET APPROVAL FROM TECHNICIAN INTERFACE (http://thwack.solarwinds.com/ideas/1905

3. APPROVALS IMPROVEMENTS (http://thwack.solarwinds.com/ideas/1897

FormerIdeaCreator

  • Just for the sake of completeness adding another link to a post requesting "Change Management" features:

    Going on almost 10 years since this feature was originally requested back in Feb. '09...

    <sigh>

  • Yes.   Many times over to this post.    There are currently 3 available options for a ticket type (Incident, Problem, Service Request), and those are "not able to be changed or modified" according to tech support.   We were trying to add a 4th option of "Change Request", which is not the same as a service request, at least not in our system.   We were also looking to possibly add "Project" to this list as we have a process to size our requests for new services to determine if the scope of the request meets the criteria to be categorized as a project and thus assigned to a project manager.  

    We worked around this by simply creating different request types for each type of ticket.   But, where this causes problems, is that now we have very deep sub-category lists under each request type.   Our sub-categories are 3 or 4 layers deep depending on the request type, and because of this, there are 200+ sub-categories total.   Now multiply that times the number of request types and we have over 1000 sub-categories.    If we were able to modify the ticket type, or at least add another one to it, we could make the ticket creation process much more user and tech friendly.   When we purchased WHD we were told that we were able to "fully customize" all the fields and categories.   That clearly is NOT the case.

  • A few more years and this feature still isn't present... <sigh>

    When thinking about workflow processes one thing to keep in mind is that there are valid reasons for having both a work "approval" process (e.g. you need a dept. manager's approval to purchase a replacement computer for one of their employees) and a change management process. Trying to use either one as a means of managing the other is just a convoluted nightmare. This is not an either this, or that scenario. This is a case where the solution should have both features available.

    The changes associated with the existing "work" approval process are a nice refinement to the product; however, it still doesn't address the underlining need to add a dedicated Change Management process to this solution.

  • Friends,

    we have many many features requests for change management, approvals, approval boards, UI for changes etc. Some smaller some bigger and I'm wondering about priorities, what is blocking you most? There are some obvious features topping the list like Ticket Approval from Technician Interface or On-Demand Approval Process, but I'd like to put it into context. What other improvements would make biggest difference for you?


    I list change management feature requests we track in the attached survey and I'd like to ask you not only rank them so we understand which are most important for you, but also please do let us know why in the comments. What problems you are not able to solve now by not having given feature and if you are how do you solve it now? How do you workaround it?

    button-3.png

    Thanks, Peter

    PS. Sorry about cross-posting, need more inputs!

SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 195,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.

SolarWinds Customer Success Center Certification Media Vault Link Accounts
About THWACK Blogs For Government Edit Settings Free Tools & Trials
Legal Documents Terms of Use Privacy California Privacy Rights Security Information
©2024 SolarWinds Worldwide, LLC. All Rights Reserved.