7 Replies Latest reply on Aug 2, 2018 2:51 PM by Cris Coffey

    Change Management

    Patricia Butcheck

      I am brand new to the Change Management CM feature available in TrackIt 11.4. I think I understand the concept, but in practice I'm failing to find practical application. If I may tap into more experienced Admins, I'd like to see if my concepts are sounds, and how the tool can be best implemented for a QC project our team is trying to develop.


      My understanding of the CM concept: If someone asks to change something - the request is submitted to an authority for approval.  Approving, allows the process to be green-lit and to proceed.  Rejecting, denies it. Logs are kept to track this activity / approval, etc.


      My team's TrackIt request:  Use CM as a form of QC on particular (but frequent) complex procedures.  We want certain categories to trigger a 'review' process.  We are OK having the same tech check their teammates work and catch commons human mistakes.  So, if Tech A receives an XYZ request, it triggers a Change Mngt Policy that escalates to three techs (including original tech).  We would like to have the CM review team (consisting of Techs A, B, and C) review the request - QC the details - and approve/improve the procedures related to the original XYZ request.  The goal is to have the team check each other's work and sign off on it.


      Escalations / Oversight Question

      1. First problem: it seems that original Tech can prevent the CM Policy from being applied to ticket
      2. Second problem: It see the original Tech assigned to ticket - and who is also part of the Authorization/Approval list - is able to Authorize their own CM Policy
      3. If Tech A can over-ride the CM procedures and neutralize the CM application per ticket, is there a way to prevent this?
      4. We added Tech A, B & C to the CM Policy as Approver.  We set the policy type to Simultaneous.
        • The concept was that if Tech A triggered a CM Policy, then Tech B & C would receive the CM notification and would review and authorize/decline the CM.
        • If Tech B triggered the CM Policy, then Tech A & C would review and approve, etc.
        • I can see that by having the same techs listed as Approver, I am creating the authorization that I want to prevent - but I don't see a way of automating the CMP to go to differing techs based on who the original assigned technician is
      5. We want to have CMP get distributed to the same team, but exclude the assigned technician as an Approver - forcing the remaining teammates to QC the assigned techs work


      I fear this is probably a lack of imagination on my part. We want to QC each other's work, but I can't see a way to structure this.  If I could set the Type & Subtype to trigger a CM Policy - great. But I can't add the criteria of creating technician to the Policy.  If I could, I Would create 3 CM Policies to escalate to the remaining teammates.


      How would you structure the escalations to allow for team-QC?  Otherwise, the burden of approvals would land on ONE technician/supervisor and create a burden of work on one party.


      Web Portal Only

      Am I correct that the only way to handle change management methods is through the web portal and NOT in the TrackIt Technician Client app?


      Quality Control Goals


      Perhaps using the CM protocols is not the best way to handle our QC objectives.  Do you have recommendations on what can be done?  We want to automate this process as much as possible.  If our HelpDesk receives a particular type of request, we want to have the steps and documentation reviewed by more experienced technicians and have them review / approve  the process.   We don't want the helpdesk to have the ability to prevent this process or to interrupt the flow.


      Thanks in advance for taking the time to read this, and for any advice you can share.


      - Patti

        • 1. Re: Change Management
          Cris Coffey

          Sorry for such a delayed response. I think the complexity and length of your question probably frightened some others away but I will try to assist. I read through everything and I think I understand what you are trying to do.


          To answer a few questions first. Yes I think you have a good grasp on how the CM feature is supposed to work. You can only approve change requests through the web portal because many times, change requests could require approvals of people outside of IT so we dont require a Technician license to be able to approve change requests, just an end user self-service license.


          After reviewing everything, I dont think we can do what you want. There is no way to create a change policy with 3 people as the approvers and purposely exclude the 3rd person who is assigned to the ticket. I can see some ways we might be able to customize our business rules functionality in Track-It! 2018 to account for this but in Track-It! 11.4 it is not really possible if I understand correctly.


          You might be able to use the Business Rules in Track-It! 2018 to create Ticket Assignments and assign them to the 2 other technicians when a ticket is created or modified and it is assigned to the third technician and meets other criteria. In this case you would need 3 different Business Rules to make this happen but that is a possibility. Then the parent Ticket cannot be closed until the other 2 technicians review and close their Assignment Tickets.

          • 2. Re: Change Management
            Patricia Butcheck

            Thank you VERY much for this comprehensive answer. I greatly appreciate it.


            I’m glad to know my understanding is at least on the point.  I feared my new-ness to the topic would expose some simple end-user issues I was missing.


            We are finding the CM protocols to be lacking, at least in the methods that we’d like to adopt.  For example, we are approaching CM as a control mechanism. Therefore, we do not want any tech to ‘turn off’ CM for certain tickets. Yet, our techs can. Thereby bypassing the CM protocols we have in place.   My upper management is asking how I can verify that every change request ticket has received change management approval. And unless I’m missing something – I cannot. Because Tech X can turn off CM protocols when prompted.


            Our attempts to use CM for other QC methods (checking each other’s work) was aspirational.  But I can see how it would be an enhancement request for the way we were trying to employ it.  We certainly could generate rules that apply the 3 tech teams, and make sub tickets for QC purposes. Which is an acceptable work-around.


            My disappointment was in the limited use of CM in TrackIt. We created a top level TYPE called “Change Management” for our helpdesk tickets. We want EVERY ticket that has the Change Management type to require CM protocols.  It seems odd that each analyst can decide at that prompt to bypass those requirements.


            Thank you again for your help in better understanding how we can/cannot use CM in Trackit. I appreciate it.


            Patti Butcheck

            X: 1495

            • 3. Re: Change Management
              Cris Coffey

              Help me understand how the tech can “Bypass” the CM policy. If someone requests the “Change Management” type, the system asks if you are sure you want to do that. If you answer No, the ticket shouldn’t be saved and should be sitting there waiting for further action. The only way around it at that point would be to select a Type field that doesn’t require a change approval, which would be a mis-categorization of the Ticket in your example.


              I would suggest creating types specific to the things that need approvals instead of a generic Change Management one. That way, Technicians have to select the proper type and therefore start the Change process. It would be fairly easy from a records perspective to see if certain techs were selecting incorrect Types just to get around the CM policy.

              • 4. Re: Change Management
                Patricia Butcheck

                You are correct.  I think where management is coming from: There shouldn’t even be a prompt that the helpdesk techs get – they aren’t the individuals who should be making that call.


                We are concerned that individuals who might want to operate under the radar will take this opportunity to alter the ticket to avoid management oversight.


                Your suggestion of managing the ticket practice is valid, but time consuming for management. We just want CM applied when certain criteria is met, and no questions / prompts / options to change that should be given to individual techs at the helpdesk.  Once applied, we want to control what can or cannot happen with tickets. i.e., it can’t be closed until someone signs off on the process.  Whereas now, the ticket with CM policy can be closed by anyone.


                It seems that the change management decision is put into the wrong hands: at the helpdesk level instead of at the management level.   From our perspective, the decision is placed at the wrong hierarchy of IT support.  We would expect that once a CM decision was made, we could apply it to tickets using policies, and then enforce rules to prevent ticket closure, etc.  Right now, much of this can be bypassed at the helpdesk level.


                I hope I explained who we’re approaching this situation clearly.


                Patti Butcheck

                X: 1495

                • 5. Re: Change Management
                  Cris Coffey

                  I agree that it might be nice to provide an option to NOT show a confirmation and just automatically start the process. That sounds like an interesting idea that we can look into for a future release.


                  However, just to reiterate the technician doesn’t decide if they want to use change management or not. The confirmation is simply confirming that you selected the correct Type. The Tech can’t save the ticket without saying Ok to the prompt. The only way they could save the ticket and get around the change process would be to purposely mis-classify the Ticket. Something like that might happen a few times but eventually something bad is going to happen and someone is going to notice. In this type of situation, I am not sure automatically starting the change process is going to help either. Someone who is willing to purposely mis-classify tickets in order to circumvent the process might be kept in check the first time the process starts automatically but after that, they will learn and select a different value the next time. Actually, if they are willing to purposely falsify information, they might not even log a ticket at all.


                  I think what I might do if I had a situation like this, is assign a change policy to every single Type that I have, keep the values to a small number and make that field required. That way, no matter what they select, a change policy gets kicked off and someone gets notified. For less important items, only 1 person is notified, but for more important items, the full approval chain would be notified. Or, I might consider turning on all the email notifications for newly created tickets and creating distribution groups including a supervisor to make sure everyone knows what is getting logged.


                  Interesting issue for sure and good discussion. Hope some of these suggestions are helpful and I thank you for the idea of not prompting. We will take a look at that for a future release.

                  • 6. Re: Change Management
                    Patricia Butcheck

                    This has been a great dialog on the topic. I cannot slight your points at all; you are right. If there is intentional mis-classifying, there could be outright suppression of the matter.  For us, we realized that the CM controls were very loose.


                    What we would assume would be the process via TrackIt:  Ticket criteria is assigned to trigger a CM. CM is instantly applied (no prompting) and proper individuals/teams are notified. The CM then applies controls to the ticket that cannot be over-written by the helpdesk technicians: such as NOT closing while a CM is engaged.  This was the basic assumption of the purpose of CM: ensuring protocols were applied and could not be removed with management intervention.  Once CM was satisfied and marked with Approved/Declined, then the status of the ticket would return to normal, allowing for resolution & closing, etc.


                    With this assumed-logic in place, we found TrackIt interferes with our workflow. First, the helpdesk staff is prompted – as if they get to choose if a CM should be applied. Which we do not want. I get your point, if they learn and want to avoid CM, they’ll mis-categorize the ticket, or NOT log a ticket. I concede the point that bad agents will be bad agents.  But we were baffled why there would be a prompt? They aren’t the decision maker – and that was the core of my confusion. This is a management tool, not an optional service.


                    Plus, while a ticket has a CM actively applied, helpdesk techs can close the ticket (and again, get a  prompt if they’re sure) and override the controls.


                    From my perspective: the weight of decisions and actions is set at the helpdesk level. I want those controls set to the management level.  The burden shifts to managers verifying tickets and re-training helpdesk staff to NOT close tickets without approval, etc.  But if this is where the burden of work is being shifted, the question becomes…. Why use CM? If they have to review tickets and retrain techs, we don’t need to use CM to achieve that. We could just search for ticket types and do a review.  TrackIt isn’t providing a solution or active controls for management to utilize. It is only generating emails.  We are asking: why bother using TrackIt CM at all?


                    My questions started with open awareness that I lacked experience using it, and hoped I was using it wrong or missing an administrative tool that would help me better meet our needs.


                    That being said: we have had great discussions which should have been a phone conversation. ☺  But I am deeply grateful for your feedback and alternative solutions. It helps be better understand what the developers were thinking and see which methods we wish to adopt. If you do want to re-think CM methodology, it would be good to think of active controls that could be applied and could not be overwritten without CM resolution or Administrator intervention.


                    Patti Butcheck

                    X: 1495

                    • 7. Re: Change Management
                      Cris Coffey

                      I agree. This is a great discussion. I did some testing today after reading through your message and I have some good news.


                      In Track-It! 2018, there are 2 things I think you will like. 1. Users cannot close tickets if there is an open change request and 2. You can restrict certain users from being able to close tickets at all if you like. These two things will be helpful for you when controlling your workflow.


                      That said, we do still have the prompt that informs them that they are about to start a change process, which again I believe doesn’t stop an honest worker from doing the right thing, but to your point, should have the option to be disabled. We will certainly look into adding something like that in the near future.


                      Let us know if you have any other questions.