Help Desk Outsourcing Empowers Change Management Strategy

Man pointing his finger clicking a button reading Change Management

In order to offer an ITIL compliant help desk outsourcing solution, Managed Services Providers must leverage an ITSM platform that includes change management capabilities. Doing so enables organizations to propose, review, approve, implement and verify changes efficiently while minimizing risks to their IT infrastructure.  Branching steps, priority tagging, and integration with the Configuration Management Database (CMDB) allow changes to be enacted according to defined business rules and policies thus ensuring adherence to configuration standards. A thoroughly built out change management process includes the following:

  • Develop a workflow with approval branching for normal or emergency change requests including assessment, impact analysis, and post-implementation review.
  • Create web forms for the submission and update of change requests. During the discovery and implementation process of a new help desk outsourcing solution, the MSP works with internal IT management to determine whether or not suggested changes can be submitted by all end users or is limited to relevant technical staff.
  • Establish Change Advisory Board (CAB) and emergency CAB membership for designated IT staff members. Typical members include the CTO, Help Desk Manager, procurement director, network engineers, desktop technicians, or any authorized personnel with the subject matter expertise specific to the proposed change or a stake in its successful implementation. Once the approval process is formally integrated with an automated email notification system that routes to the authorized IT staff, there is little room for ambiguity in terms of ownership and status of the proposed change.
  • Integrate with the CMDB and Configuration Items (CIs). In most cases, the client management team prefers to handle the creation and maintenance of CIs within the CMDB, because categorization tends to be dictated by internal departments, proprietary applications, assets, or processes. That being said, help desk supervisors and staff should give feedback regarding unique incidents that have not yet been assigned CIs either during the documentation process or at operational review meetings. If too many have blank entries, trend and root cause analysis may suffer due to imprecise reporting and metrics.
  • Enable access to ad-hoc reports allowing user-defined queries of key change request information. Rather than tie up senior management resources to relay status updates on pending change requests, putting such queries in the hands of the users themselves minimizes internal costs while disseminating pertinent information quickly.
  • Of course, no matter what forms are developed during a new help desk implementation, change management capabilities should not be limited to those initially established fields and rules. As with the change management process, the tools used to impact changes cannot themselves remain rigid and permanent. Accordingly, custom workflows should also be developed as needed in order to evolve with the introduction of new technology, shifting organizational structure, and updated processes.

Rather than fighting fires or tolerating inefficient resolution workarounds indefinitely, a carefully executed change management strategy should always be on the IT support horizon. So once the root cause of an incident is identified, problem management may submit a request for change, recommend a permanent fix for the underlying cause. Only if a permanent solution is not yet possible or rejected by the client’s Change Advisory Board, should the help desk assist in the development of a workaround for use in restoring service and minimizing the impact of associated incidents. In such instances, the production and maintenance of the Known Error Database (KEDB) are one of the most important outputs of the problem management process. The KEDB is accessed in the incident management process by both administrative staff and end users to more rapidly identify and resolve incidents that have an underlying problem as the root cause. Unlike the knowledge base that houses resolution procedures for ongoing issues, the KEDB is the repository of workarounds for transient problems pending a permanent fix, often involving a change to one or more CIs. As an industry best practice, the help desk typically keeps both databases separate because the KEDB will need to be purged of obsolete data once the change has been approved and implemented and the known error no longer recurs. Consequently, for each known error that’s eliminated from the help desk equation, there is a reduction in associated contact volume and, in the process, lower operational costs.  That’s the sort of change even a CFO can appreciate.