7 Replies Latest reply on Nov 20, 2018 3:25 PM by Matt Hackbart

    Track-It 2018 - Change Management

    Matt Hackbart
      Share:|

      In Track-It 11.4 we have the ability to use a more granular criteria to trigger a change policy. In fact we use a category called 'Change Management' as the final criteria for any software patches/updates that require the approval process that change management delivers. For example, if Jim from Accounting in Chicago emails the help desk about an update to his accounting software, a technician would change that category on the ticket to 'Change Management' which would trigger the policy.

      trackitchangemgmt11.JPG

       

      In 2018, I understand that Type, Subtype, and Category fields in version 11.4 are migrated as Categories. That hierarchy still exists under Categories however, there no way to select the certain level of heirachy (Parent Category, Subcategory, Sub-SubCategory) as the ticket criteria to trigger a change policy.

      trackitchangemgmt.JPG

      Do I need to add custom fields or should we be tackling Change Management in Track-It 2018 from a different angle?

      Thanks,

        • 1. Re: Track-It 2018 - Change Management
          Cris Coffey

          Typically in 11.4 or 2018, certain types of tickets automatically trigger change control without the interaction of a Technician. If you want your Technician to be the one to trigger the change request, they could simply create the Change Request from the green Add New button at the top, then select that change request from within the existing ticket without changing the category.

          • 2. Re: Track-It 2018 - Change Management
            Matt Hackbart

            Thanks, but that appears to involve more steps (time) than it did in 11.4....possible, but a step back.

             

            Is there a way to trigger a change policy when a ticket is created with criteria only when Jim emails about a software update to his accounting software?

            I don't want a change policy when Jim emails about an error with his accounting software.

            (Requestor= Jim, Department=Accounting, Location=Chicago, and Category=Accounting Software)

             

            I doesn't seem wise to have more specific categories. (Accounting Software, Accounting Software-Error, Accounting Software-Update, etc..) but perhaps that would accomplish the same result?

            • 3. Re: Track-It 2018 - Change Management
              Cris Coffey

              Generally the change policy is automatically kicked off when something requiring a change approval is requested by the user. A purchase, a software patch, a change to network permissions, etc. Then those specific Categories have change policies linked to them.

               

              In your case, if you want to kick it off manually, you could add one more level below the items you already have and call it something like “Item Name”-Change, that you select to kick off a change request related to that item.

              • 4. Re: Track-It 2018 - Change Management
                Matt Hackbart

                Cris- Thanks for the reply.

                 

                I understand how a change policy is automatically kicked off. I'm just wondering how to get more granular with the criteria. It seems your examples to kick off a change policy are very broad however our needs are very specific. In 11.4 we used type and subtype but in 2018 I will likely end up having multiple 'categories' with similar item names like "Accounting Software" as well as "Accounting Software-Change", etc...like you mention. This will also affect our reporting since we used to report on specific subtypes.

                 

                Just curious, what was the decision behind merging Type and Subtype into Category?

                 

                Thanks,

                • 5. Re: Track-It 2018 - Change Management
                  Cris Coffey

                  I am sorry Matt, I guess I misunderstood what you were saying. Maybe we can think of another way to do what you need.

                   

                  As for why we decided this, we had numerous customers asking for more than 3 levels of Type/Subtype/Category and easier ways to move those around and fix them once they were already created. Doing that in separate fields would be extremely cumbersome and difficult to use. The Tree approach solves all of those issues.

                   

                  I am sure there is a way to do what you are trying to do. I was trying to give you a way to automatically kick off the change using Categories, similar to what you did in Track-It! 11.4, but that doesn’t seem like it will work for you. You can always create the change requests manually when needed as we discussed before. It is only a few clicks to create the change request and link it to your ticket. That may work better than changing your process and your Categories.

                  • 6. Re: Track-It 2018 - Change Management
                    Russ Jones

                    Matt, for what it's worth, we do very similar to what you are asking for and we use the Priority, Location and a Category for the 'condition' to launch the change approval request from a ticket.  But you can use almost any combination that delivers a unique condition based on the limited fields available in the Change Policy dialogue setup.

                     

                    We do this the opposite of the TrackIT! flow, but it works flawlessly.

                     

                    We do customize our form to include the fields for the Change Request (Approval) number and the Change Request (Approval) status.

                     

                    Our workflow is basically:

                    - create a policy that will launch the approval based on conditions

                         - Some of the conditions will be that the priority = CAB (Change Approval Board) has approved

                         - Some are include more information but we still use the Priority = a 'launch the approval' condition

                         - The matching conditions can then launch to different approval paths based on the matching criteria.

                    We use the location as we are multi-site and different techs or Change Managers would be responsible for setting the priority once a CAB meeting took place.

                     

                    So essentially we:  Work a ticket, update it to match criteria that equals a policy.  Once the fields match the policy, as soon as you save the ticket the policy is applied, the Change Request (Approval Request) then launches and upon approval, the request's status is updated to Approved on the Technician's ticket.

                     

                    Hope this helps,
                    Russ

                     

                     

                     

                    Change Capture.jpg

                    1 of 1 people found this helpful
                    • 7. Re: Track-It 2018 - Change Management
                      Matt Hackbart

                      Russ Jones wrote:

                       

                      So essentially we:  Work a ticket, update it to match criteria that equals a policy.  Once the fields match the policy, as soon as you save the ticket the policy is applied, the Change Request (Approval Request) then launches and upon approval, the request's status is updated to Approved on the Technician's ticket.

                       

                      Hope this helps,
                      Russ

                       

                      Change Capture.jpg

                      Thanks for the feedback.

                       

                      That is exactly the workflow that we currently use with 11.4 that we are trying to duplicate in 2018. Looks like we will just create more descriptive (longer) categories in order to trigger our change policy via the tickets.