* * * * *

Proposed Telephony Process Mapping & Recommendations

(Version 0.9; January 27, 2017)

* * * * *

Table of Contents

I. Introduction.

II. Telephony Process Gaps:

A. Application/Platform Gaps.

B. Process Gaps.

C. Staffing Gaps.

D. Management Actions.

III. Long-term/Proposed Telephony Processes:

A. Textual discussion.

B. Process Maps.

IV. Migration Plan:

A. Short-term – Next six month actions.

B. Medium-term – Seven to twelve month actions.

C. Long-term – Thirteen to eighteen month actions. V. Next Steps.

VI. Appendix:

A. Current Telephony Process Maps (received from the Infrastructure Telephony team).

B. Current Service Now workflow (received from the Service Now Project team team).

3

I. Introduction.

The University of Utah’s Common Infrastructure Services Department (hereafter

“Infrastructure”) has engaged TEKsystems to complete a business-technology process identification and mapping project. Phase I.A was to identify, document, and explain the business and technologies processes within Infrastructure. The joint TEKsystems and Infrastructure team

(hereafter ‘the Team’) developed a methodology to achieve the intended Phase I result. This methodology consisted of a two-step approach. First, the Team through interviews, document review, and other means constructed a list of the High-Level Business-Technology processes within Infrastructure. Those identified were:

• Process 1.0 - Service Request.

• Process 2.0 - Problem Management.

• Process 3.0 - Incident Management.

• Process 4.0 - Customer Service Advocacy.

• Process 5.0 - Method-System Inquiry.

• Process 6.0 - Change Mgmt.

• Process 7.0 - Data Inquiry.

• Process 8.0 - Hire New Non-Infrastructure

team member.

• Process 9.0 - Terminate Non-Infrastructure

team member.

• Process 10.0 - Hire New Infrastructure team

member.

• Process 11.0 - Terminate Infrastructure

team member.

• Process 12.0 - Network Maintenance.

• Process 13.0 - Network Monitoring.

• Process 14.0 - Data Center

Maintenance.

• Process 15.0 - Data Center Monitoring.

• Process 16.0 - Analytics.

• Process 17.0 - Security Monitoring.

• Process 18.0 - UTV Monitoring.

• Process 19.0 - UTV Maintenance.

• Process 20.0 - Engineering Monitoring.

• Process 21.0 - Engineering

Maintenance.

• Process 22.0 - Infrastructure Strategic

Planning.

In fall 2016, the Team determined that one of these business-technology processes deserved a deeper analysis: Process 1.0 - Service Request/Management. In November 2016, the Team was repositioned to look at the proposed processes for customer service requests (including incidents tickets) across the Telephony and Telephony Service Now catalog items. A new work phase with associated tasks was created (Phase I.B) while work on the original Phase I (now Phase I.A) was suspended.

4

In Phase I.B the Team will analyze five Telephony & voice service requests which can be ordered via the current Service Now implementation: The first goal of Phase I.B is to identify the most efficient and proposed way for the Infrastructure group to receive, review, triage, and complete these six service requests. The Team will examine the existing Infrastructure manual tasks and work steps, Service Now automated tasks and work steps, and non-Service Now automated tasks and work steps. To complete this analysis the Team will pursue a bookend strategy as shown in Figure 1.

The Team assumes (and this is a key assumption)

that Service Now and PeopleSoft applications will form the backbone of the University’s enterprise platform for the foreseeable future. The Team’s analysis will focus on the workflow from customer service request origination (via Service Now) through to customer invoicing/chargeback journal entries (via PeopleSoft). Between these bookends the Team will remain platform/software agnostic, focusing on developing the proposed work flow and tasks to go from request through to end billing. The Team will identify gaps/loopholes in the current process and develop recommendations as how to improve the workflow in the short-term and move to the proposed workflow in the long-term. The Team will look at the data and processes associated with the creation of the customer service request and identify gaps/areas for improvement.

• Telephone Add Request.

• Telephone Change/Move Request.

• Telephone Disconnect Request.

• Cable Installation.

• Fiber Order.

Figure 2 - Analysis Framework

Figure 1 - Analysis Framework

5

Some examples include:

• Restrict requestor ability to evade the workflow for a particular service request/request.

• Expand data collection for customer service requests.

• Eliminate multiple entry of identical data/recommend the implementation of scripting to replace manual data entry.

• Ensure more commonality between incidents tickets and service requests. The Team has completed a review and examination of the Telephony data and processes. The Team, in this document, will now move on to examine Telephony-related requests. 6

II. Telephony Gaps:

In this section gaps between the current workflow versus the proposed workflow for Telephony will be examined and discussed. Gaps have been divided into three areas: Application/Platform Gaps, Process Gaps, and Staffing Gaps. In addition, several items have been identified that require management review and possible decisioning. Each of these will be examined and reviewed in their own sections below. A. Application/Platform Gaps:

The following are the identified Application/Platform gaps that may prevent the Infrastructure Telephony team moving from their current workflows to the proposed workflow. Please note there is some overlap and dependencies between these application/platform gaps and recommendations with the process gaps.

• Creation of non-Telephony team tasks within Service Now - Currently, Telephony team members can only create Service Now tasks for the Telephony team; all other task creation is blocked. It is recommended that Service Now be enhanced to allow for the Telephony team to create tasks related to a Telephony service order and assign them to other Infrastructure teams

(e.g., Pathway Engineering team).

• Create a Service Now catalog item for contact centers - Currently, the Service Now catalog does not allow a user/department to request the set up or other actions for a University contact center. It is recommended that Service Now be enhanced to include a catalog item for all Contact Center related activities and requests.

• Limited use of Service Now workflow - Currently, while some workflows have been provided to the Service Now team, much of the Telephony workflow is executed and monitored outside of the Service Now platform. In addition, there exists no workflows for Telephony 7

maintenance tasks and incidents/problem reporting and remediation. It is recommended that the Telephony workflows, in the short-term, be fully and correctly documented for all service requests, maintenance work, and incident/problem tickets and then incorporated into Service Now. In the longer-term, the Service Now workflows should be updated with the changes as proposed in the proposed Telephony workflow process maps contained in Section III.B of this document.

• Lack of facilities Telephony specifications/diagrams - Currently, there is no single centralized wiring/facilities configuration management database. Instead, to the extent that this information exists, it is dispersed among many digitized and paper files. However, these files do not provide adequate or timely information to Telephony (or other) technicians related to the existing or proposed wiring capabilities of the workspace requesting Telephony services. Hence, when a Telephony service is requested, assumptions have to be made about the physical configuration of the workspace or the technician needs to visit the proposed service location. Occasionally, assumptions made about the physical location are wrong, and then this requires a Service Now service request to be generated for the Pathways Engineering team to “wire” the workspace. This introduces significant delays into the timeline for the delivery of services to the end customer and may cause the Telephony team, and the Infrastructure department, to miss their service level agreements.

It is recommended that, either as part of the Service Now project or via a separate platform all relevant facilities blueprints and schematics are cataloged and then are contained in a central, online data store that is easily available to Telephony technicians, Telephony management, the Pathways Engineering, and Infrastructure leadership. 8

• Re-configuration for phone moves/re-assignments - Currently, there is no single, centralized Telephony configuration management database. Instead, to the extent that this information exists, it is dispersed among many digitized and paper files. However, these files do not provide adequate or timely information to Telephony (or other) technicians related to the

“ownership,” capabilities, and calling privileges associated with each handset and phone number. Hence, when a phone number is moved/reassigned the new user may not have the needed device capabilities and/or correct calling privileges that are required for their role at the University. It is recommended that either as part of the Service Now Phase III project, or via a separate platform, all relevant Telephony configuration, ownership, and capabilities are contained in a central, online data store that is easily available to Telephony technicians, Telephony management, the Pathways Engineering, and Infrastructure leadership.

• Use of a Web Form to report Telephony incidents - Currently, the Hospital Help Desk relies upon an Intranet form for customers to log Telephony incidents and problems. Recently the Infrastructure (hereafter the “Campus”) Help Desk also adopted this use of an Intranet form. The Campus Help Desk then transfers the data into Service Now to create a Service Now incident ticket. This results in duplicative data entry, reliance upon a form that lies outside of the Service Now environment and could result in data integrity/transposition errors as the information is converted from the form into a Service Now ticket.

It is recommended that all use of these Intranet forms be discontinued and all customers be required to enter their Telephony incident report directly into Service Now. Education for the end customers may be required here as it appears that many customers are unaware of the full capabilities of Service Now.

9

• Ability to change orders/tickets - The ability to change Telephony service requests, maintenance tickets, and incident tickets within Service Now should be limited to only Telephony team members and leaders.

• Work notes viewing restrictions - The ability to view the work notes attached to a Telephony service request, maintenance, and/or incident tickets within Service Now should be limited to only Telephony team members and leaders. Also, the ability to add to previously entered comments should be added to Service Now. Last, while Service Now permits the addition/deletion of attachments, there is no logging of these changes. Service Now should be enhanced to provide this attachment logging.

• Closed Requests/Tickets notes - Currently, once the service request and incident ticket is closed, no additional or comments data can be entered or tracked. This should be modified so that Telephony Leadership can enter and add comments after the request or ticket is closed.

• New service request fields - A number of data fields should be added to the service request and incident ticket forms within Service Now. These include, but are not limited to: o Labor hours incurred (see below for more details). o Materials request (see below for more details).

o Alternative/additional team assignment.

o Wait state/status (e.g., waiting on vendor, waiting on customer, waiting for other).

• Create new tasks for Telephony team members – New tasks to be added into the service request, incident, and maintenance requests/orders include, but are not limited to: o Parts/materials ordering.

o Pinnacle ticket created/MAC number issued.

o Permitting (if needed).

• Add workflow for maintenance tickets and incident requests/orders - Currently, Service Now workflow only somewhat exists for service requests. The Service Now workflow needs to be developed and inputted into Service Now for maintenance work and incidents. 10

• Eliminate pre-orders – Currently in the current billing platform (Pinnacle) an order can be created as a pre-order. This allows for the request/creation of the MAC number. It is recommended that pre-orders be eliminated and replaced with a new request status code for the service request, maintenance ticket, and incident ticket that show the Service Now item is in a “planning status.” Service Now should drive the creation of any billing entry or line item.

• Cancelled orders - The ability for a customer to cancel a service request or incident ticket is to be maintained. However, the cancelation of a service request or incident ticket should generate an electronic communication to the Telephony team. In addition, the canceled request or ticket should allow for the collection and tracking of any labor or material costs that were incurred by the Telephony team prior to receiving notice that the request or ticket has been canceled. Canceled orders should also allow for the entry of comments by the Telephony Leadership after the request/ticket is canceled.

• Closing an order - Currently, a Service Now service request or incident report is closed by the Telephony team upon completion of the job. However, comments should still be allowed to be entered into the order by Telephony Leadership. Also, the closing of the request or ticket should be dependent upon the Telephony technician either returning excess material to the warehouse or disposing of them as salvage/scrap with an associated update in the materials panel.

• Standard costing - Currently, billing for Telephony services, including monthly Telco carrier charges, is complicated, confusing, and heavily manual in nature. It is suggested, as for the Pathways Engineering team, that a simplified billing and chargeback scheme be developed. This could include simplified Telephony usage plans as well as an easy to read/understand consolidated

(one bill) cost for all adds/moves/removes Telephony service requests that includes costs for both the Telephony and Pathways Engineering teams’ labor and materials. 11

One approach could be the creation of a standard costing metric for small Telephony service moves/removes/adds service requests. Based upon a determination by Infrastructure leadership, all Telephony service orders that are classified as a small request would be charged at a standard labor and time cost to the customer through PeopleSoft. Actual labor and materials costs would be tracked, but not presented to the customer. These actual costs would be used by the Telephony team to monitor efforts and plan for the following year’s standard costing rates.

• Materials checkout/pick list - Add a checkbox/popup form that allows the Telephony team member to systematically request job materials from the warehouse. Currently this is a pen and paper action. This checkbox form would allow the Telephony technician to select and request the materials required for a service request, maintenance ticket, and incident ticket. This form would be reviewed and approved by Telephony Leadership and then transmitted electronically (via an API or a simple email) to the warehouse team so that materials can be set aside for the service request or other ticket. The technician would then pick up the materials from the warehouse, the warehouse would check a flag in Service Now that showed that the materials have been picked up by the technician, and the billing data should be stored by the warehouse team for an eventual billing journal entry within PeopleSoft.

• Returned materials - At the end of some Telephony orders and tickets, there may be leftover or unused materials. Depending upon the amount of material left over, they are either assigned to salvage/scrap or returned to the warehouse. If returned to the warehouse, the technician should complete the returned materials section within the Service Now materials form and have it approved by the warehouse team. The warehouse team then appropriately adjusts the billing information to be sent to the customer. Telephony Leadership currently performs a Q and A check 12

on the amount of materials used/returned related to a Telephony job. This will continue in the future, albeit now enabled by the Service Now platform.

• Insight into inventory levels - The Telephony team should have access into the warehouse inventory applications(s) at the time materials are being selected for the request/ticket. This would allow for the Telephony team to determine if additional quantities of material should be ordered for the job as early in the process as possible.

• Scripts - Several scripts should be written to eliminate duplicate data entry. While the focus of these script recommendations is for the Telephony team, additional opportunities to automate data entry/systems interactions also exist for the warehouse team: o Create a script that takes information from Service Now and creates an order in Pinnacle and receives back from Pinnacle the MAC number.

o Create a script that receives the MAC code from the Pinnacle application and populates it within the Service Now service request, maintenance ticket or incident ticket. o Create a script that transmits materials ordering/returns to the warehouse applications and updates Service Now status as appropriate.

o Create a script that closes the Pinnacle ticket when all work in Service Now is finished and any excess materials are received by the warehouse team.

• Block general requests - Direct assignment of a general request should be blocked by Service Now. Instead all general requests should be routed to the Campus Help Desk. The Campus Help Desk would then work with the customer to triage the request, determine the correct Infrastructure team, and then work with the customer to close the general request and open the appropriate Service Now Telephony request.

• Block incident tickets from being directly assigned to teams - Currently, an incident ticket can be directly assigned to an Infrastructure team. This direct assignment should be blocked with all incident tickets being routed to the Campus Help Desk for triage, prioritization, and assignment to the correct Infrastructure team. This also allows one group (the Campus Help Desk) to take an 13

enterprise view of incidents to determine if there is any commonality across tickets causing a need to create a problem ticket.

• Ability to connect related service requests, incident tickets, and problem reports - Service Now should be modified so as to allow the easy association and reporting of related service requests and incident tickets with a problem report. This is especially true for incident tickets which are subsequently turned into problem reports.

• Project Request - Much of the work of the Account Execs involves large construction projects, department moves, or phone service orders involving more than 10 handsets or numbers. It should be confirmed that some form of this capability (i.e., a REQ ticket?) that currently exists within Service Now is sufficient to accomplish this requirement. If this capability does not exist, Service Now should be modified to allow for a project request, created by the Account Exec team. Then individual service requests, incident tickets, or maintenance tickets can be opened in conjunction with this project request. As described above, there is also the need to link together and track all of the Service Now requests and tickets related to the project request.

• Limit creation of problem reports - Problem tickets should not be created organically. Service Now should instead require that first an incident ticket be opened and only upon triage/analysis is a problem report then created. In addition, only Telephony team leadership or the Campus Help Desk should be allowed to open problem tickets and only if it can be related to a Telephony issue(s).

• Enhance Service Now to create an online scheduling tool - Currently, all work scheduling is done outside of the Service Now platform. Telephony service requests within Service Now are routed to the Infrastructure receptionist who engages with the appropriate Telephony team lead and the work is scheduled manually. This makes it difficult for customers, Telephony team 14

members and leaders to access, view, or update the workload and work schedule for service orders and technicians.

• Enhance Service Now to create an online project automation tool - Currently, when Account Execs or service coordinators are asked by a customer for a budget estimate for a future/planned service request, the Infrastructure team member needs to work with a variety of Telephony technicians, experts, and leaders to develop these budget estimates. This is a manually intensive, and labor expensive, effort. An automated job estimating tool within Service Now, while not completely eliminating manual effort or the involvement of experts, should reduce resource demands upon the Telephony team and assist the Account Exec in providing an enhanced degree of customer service.

B. Process Gaps:

The following are the identified process gaps that may prevent the Infrastructure Telephony team moving from their current workflows to the proposed workflow. Please note there is some overlap and dependences between these process gaps and recommendations with the Application/Platform process gaps.

• Limited use of Service Now workflow - Currently, while some workflows have been provided to the Service Now team, much of the Telephony workflow is executed and monitored outside of the Service Now platform. In addition, no workflows exist for Telephony maintenance tasks and incidents/problem reporting and remediation. It is recommended that the Telephony workflows, in the short-term, be fully and correctly documented for all service requests, maintenance work, and incident/problem tickets and then incorporated into Service Now. In the longer-term, the Service Now workflows should be updated with the changes as proposed in the proposed Telephony workflow process maps contained in Section III.B of this document. 15

• Project management challenges/service delivery ownership - Currently, there appears to be a lack of clear ownership over the management of the execution/delivery of Telephony service. With limited, if any, Telephony workflow in Service Now, it is difficult to monitor status and challenges/issues with a Telephony service request. It is recommended that the service coordinators modify their role to act as the project manager for any Telephony service request and utilize Service Now as the tool/platform to support their redefined/expanded role.

• Telephony maintenance plan/strategy - Currently, there is no annual/multi-year maintenance plan in place for Telephony services and equipment provided to University customers by the Telephony team. A Telephony maintenance plan can help the University to avoid the cost of replacing a poorly performing system, minimize the risk of any system downtime, and guarantee a service level to meet your business/customer requirements. A maintenance plan would allow the Telephony team to identify issues before they occur and keep the phone system running smoothly, ensure that faults/potential issues are dealt with according to an agreed schedule, and budget efficiently rather than paying a premium/overtime whenever an issue does occur. It is recommended that as part of the University annual planning and budgeting cycle that a Telephony maintenance plan and strategy be developed and implemented.

• “Dead” phones and numbers - Currently, when a phone/phone number is removed from use it is unclear if the associated phone number is consistently deleted from the service provider inventory (e.g., CenturyLink). This can result in the University being billed for phone numbers which are now longer in use. It is recommended that processes be improved so that when a phone handset and number is removed from service notice is provided to the service provider. In addition, an annual audit of the phone directory be undertaken to ensure that the University is only being billed for phone numbers in service and billed correctly to the using department and team. 16

• Re-configuration for phone moves/re-assignments - Currently, there is no single, centralized Telephony configuration management database. Instead to the extent that this information exists, it is dispersed among many digitized and paper files. However, these files do not provide adequate or timely information to Telephony (or other) technicians related to the

‘ownership’, capabilities, and calling privileges associated with each handset and phone number. Hence, when a phone number is moved/reassigned the new user may not have the needed device capabilities and/or correct calling privileges that are required for their role at the University. It is recommended that either as part of the Service Now Phase III project, or via a separate platform, all relevant Telephony configuration, ownership, and capabilities are contained in a central, online data store that is easily available to Telephony technicians, Telephony management, the Pathways Engineering team, and Infrastructure leadership.

• Outdated re-billing Telephony rates - Currently, the Telephony team receives invoices from CenturyLink and other Telephony service providers, ‘bursts’ the usage portion of the bills, and then charges the Telephony usage back to the originating departments and organizations. However, the re-bill rates have not changed in many years and most likely reflects an imbalance between the actual costs incurred by the University and the amount contributed to those cost by the originating departments and teams. It is recommended that these re-billing rates be evaluated and recalculated to properly reflect current costs and usage. In addition, an annual review of the re-billing rates should be implemented as part of the University annual planning and budgeting cycle.

• Use of a Web Form to report Telephony incidents - Currently, the Hospital Help Desk relies upon an Intranet form for customers to log Telephony incidents and problems. Recently the Infrastructure (hereafter the “Campus”) Help Desk also adopted this use of an Intranet form. The 17

Campus Help Desk then transfers the data into Service Now to create a Service Now incident ticket. This results in duplicative data entry, reliance upon a form that lies outside of the Service Now environment and could result in data integrity/transposition errors as the information is converted from the form into a Service Now ticket.

It is recommended that all use of these Intranet forms be discontinued and all customers be required to enter their Telephony incident report directly into Service Now. Education for the end customers may be required here as it appears that many customers are unaware of the full capabilities of Service Now.

• Project orders - There is a need for Account Executives and Infrastructure in general to be able to create and track Infrastructure work related to a large construction effort or departmental move. The creation of a project order (perhaps using the REQ feature) within Service Now would alleviate these issues.

• Cancelled service requests - Currently, there can be a time lag between when a service request is created and the Infrastructure team engages with the requestor. However, if this time lag is significant there is the change that the customer will have changed their mind or canceled the order. The process needs to be changed such that cancellation of a service order generates an electronic notice to the Telephony team. In addition, pre-work and planning might have been undertaken for the service request before it was canceled. These costs need to be collected and tracked.

• General service requests - In today’s environment a user can create a general request and have it directly assigned to an Infrastructure team. However, no workflow exists within Service Now for a general request. In addition, if a general request is reassigned to an Infrastructure team, the reassignment does not trigger the workflow for Telephony service request. It is recommended 18

that a general request is always forwarded to the Campus Help Desk which triages the request, works with customer to close the general service request, and then helps the customer open a specific service order based upon the Service Now catalog.

• Maintenance ticket - Maintenance of Telephony assets is a routine activity conducted over several years, within an annual maintenance plan. Maintenance tickets should be treated as a special form of service request, opened by the leadership of the Telephony team. All labor and materials costs should be collected and reported.

• Incident tickets - Today an incident ticket can be created by any University campus or hospital user. However, instead of directly assigning an incident ticket to an Infrastructure team, all incidents tickets should get routed to the Campus Help Desk for triage and assignment. The Campus Help Desk is the Infrastructure team best positioned to look across the enterprise and see if incidents are related and if that should result in the creation of problem report.

• Problem reports - The creation of a problem report initiates the involvement of the IRT and possible the Emergency Change Advisory Board (ECAB). In today’s world, a problem report can be opened on its own account. It

Contact this candidate