FIELD TECH ADMIN

Project Engineer: Ruoqi Tian

Computer Science, University of Evansville

Project Sponsor: Christi Cronin

Metronet Inc.

Project Advisor: Dr. Don Roberts

ABSTRACT

Metronet is a fiber based telecommunications company, and it provides fiber TV,

internet, and telephone services in multiple cities. To provide services such as installations,

maintenance, etc., many technicians go to subscribers’ houses every day. However, most of the

operations that they perform require them to call into some departments back in the company,

where office employees help them look up and update information online. Limited number of

office employees and huge number of technicians result in the fact that most technicians spend a

long time on both waiting and talking. To improve efficiency of technicians and a better service

experience to subscribers, an online web tool is being built. It will allow technicians to log in

using their mobile devices, look up info, perform simple operations, and eventually complete a

service run without calling into the office.

I. INTRODUCTION

Metronet is a fiber network company located in Evansville, Indiana, and it provides fiber

TV, internet, and telephone services in 25 communities in Indiana area. Like cable TV

companies, Metronet technicians go to subscribers’ homes and offices every day to perform

services, including equipment installations, maintenance, etc. Normally, technicians perform a

lot of tasks that require them to call into company offices, such as subscriber info lookups,

equipment swaps, and work scheduling. The result of a survey shows that the average length of

calls made by technicians is normally more than 5 minutes, and some are even more than 15

minutes. Besides that, to call into TTU/Repair (test and turn up, the department which most

technicians call into), a technician would wait in queues due to the limited number of employees

available at TTU/Repair. With more than 300 hours wasted on technicians waiting and calling

every month, the problem must be solved.

Developing a web tool that runs on technicians’ mobile devices is a solution to this issue.

Field Tech Admin will be a web tool that technicians will log into and perform operations on

their cell phones, tablets, and laptops. It will allow technicians to customize their own

homepages by adding functionalities that are most important, resizing them, and organizing

them. This web tool will take advantage of the structure of existing company-wide background

libraries and databases, allowing efficient debugging and better security.

The design of the web tool is important because a simple and informational interface will

help the technicians to work with more efficiency. After logging into the web tool using their

username/password combinations, they will be taken to a homepage, which is also called a

dashboard. There will be multiple tabs of different sizes on the dashboard. Each tab represents a

functionality, such as subscriber info lookup, equipment swaps, or terminal box activation, etc.

The web tool is also a web platform which is open to adding more functionalities available to

technicians. Because of various functionalities that technicians would like to see, it is not

possible to add all them into Field Tech Admin during the senior project period. In the future,

engineers still will be able to add functionalities by adding corresponding front end screen,

middleware, and backend scripts, without modifying the main dashboard platform.

II. PROBLEM STATEMENT AND BACKGROUND

Metronet is a fiber network company, which provides TV, phone, and network services.

Although fiber broadband is the fastest internet available, the services still requires a great

number of field technicians to go to the customers for services such as installation and repair.

Normally, to perform some common actions, field technicians have to call in, wait in a phone

queue, and have someone in the office perform a function for them so they can continue

working. For every appointment, there are many different steps that could require calling for

assistance and there can be up to 4 different groups [1].

Figure 1: Process Map of a Typical Technician Run

Figure 1 shows a typical service run process. For example, a normal service activity would start

with a technician arriving the location, meeting customer, and gathering equipment. Then the

technician would begin his or her work activity, which might require multiple phone calls. It is

very likely that the technician calls TTU (Test and Turn Up) to get information that he or she

does not have access to, such as billing information. Also, it usually happens that a technician

calls Repair if there is any error that he or she cannot deal with. For both TTU and Repair, there

will be queues because there are multiple technicians calling in.

In their Green Belt project, Metronet employees Christi Cronin and Trey Bowles are

trying to improve the efficiency of field operations by finding out reasons of calls, reducing

number of calls, and reducing average time of calls. According to data from Green Belt Project

Summary, field technicians make approximately 3000 calls a month to the Repair and TTU call

queues during customer appointments. The average length of the calls is around 6 minutes,

excluding the time the technician is on hold. Each month, this causes over 300 hours (1.875

FTEs) of wait time for technicians and customers. In addition, the time that repair is spending on

resolving issues that may not be necessary [2]. Appendix A lists some sample calls with reasons.

It is easy to notice that many of them are simple issues and that there are a lot of similar issues.

Cronin and Bowles believe that developing a web-tool for field technicians to complete simple

operations themselves as a necessary part of solving this problem.

III. REQUIREMENTS AND SPECIFICATIONS

Requirements

Metronet has a company-wide web services template. As with many of the web tools that

are being used, Field Tech Admin will follow Metronet Web Framework and Web Services

Architecture. It uses model-view-controller (MVC) architecture and has “front end”,

“middleware”, and “back end”. A “front end” screen consists of an HTML template, a CSS

stylesheet, a JavaScript script with jQuery. The “front end” interacts with Middleware using

AJAX. Middleware library files should be implemented in Perl so they can associate with

Metronet Web Service Description Language (WSDL) files. It is normal for multiple Metronet

web tools to share the same “back end” library written in Perl because of its great compatibility

to “front end” files written in HTML, JavaScript, and middleware WSDL files. Field Tech

Admin will take advantage the “back end” library as well.

As a part of requirement gathering, a survey was sent to the technicians and accepted

responses from Oct. 4th to Oct. 14th. There are 8 questions about requirements and specifications

of Field Tech Admin. During the 10 days when the survey was open, 22 technicians completed

the survey with detailed responses. Part of the summary of the responses is in Appendix B.

It is important that technicians have access to Field Tech Admin using their mobile

devices anytime, especially during a service run. According to the responses of 8, technicians use

all kinds of different devices, including iPhone, iPad, Android Phone, Android Tablet, and Dell

Laptop. Field Tech Admin, which runs on web browsers, must be able to fit different screen

sizes with responsive design.

Security is also very important for a web tool, because users need to be able to log into it

remotely and safely. Considering the fact that there already exists a company-wide user database

and same credentials can be used for multiple applications, Field Tech Admin also will take

advantage of the user credential system so it can be accessed by technicians using their company

usernames and passwords. However, Field Tech Admin will be an external web application so

that it can be accessed by technicians through any network considering the difficulty of

connecting to Metronet VPN.

Specifications

To make the most of the flexibility of the web tool interface, each field technician can

customize his or her Dashboard/Landing Page to show the most important content. Also, since

Field Tech Admin will be used and maintained after the senior project, it must be scalable to

additional features in the future.

Question 4, 5, 6, and 7 in the survey helped gather requirements by asking technicians to

list their common reasons to call in multiple departments and what they would like to see on

their dashboard of the web tool. As noted in the problem statement, TTU (Test and Turn up, the

department where subscriber information will be turned up and returned to technicians) and

repair are the department they call in the most. According to the responses of question 4,

following are the major reasons of calling:

- Equipment swaps

- ONT Activation and status/lookup (ONT: Optical Network Terminal Box. The DVR,

router, and VEN plug into the ONT. TTU can reset the ONT remotely.)

- STB resets (STB: Set top box. Device within customer home/location that allows

customer to connect to service. Only for video service.)

- Spatial info lookups

Equipment, ONT, STB operations will be definitely on the interface of Field Tech Admin. It is

helpful that there already exist libraries for remote reset in the “back end”. Spatial info lookups

also will be a part of the interface. The only web tool that technicians currently have access to is

called ETA and it is a work scheduling system. Through question 6, we learned that there are

many functions that were not available in ETA but the technicians would like to see, including:

- Unassigned work bucket

- Timeline

- Mac activation

- Previous order notes/history

- Internet speed tiers

There is no doubt that adding these functions to the interface of Field Tech Admin will greatly

help the technicians. In a meeting on Nov. 2nd, 2016, the manager of TTU and Repair Mike

Sibrel confirmed from a TTU/Repair perspective that those are common reasons techs call in and

can help reduce that number of calls, as building agreement between TTU/Repair (the

department that will benefit from this project) and MIS (the department sponsoring this project).

He also confirmed that all the information mentioned above was safe to be retrieved through

Field Tech Admin.

IV. DESIGN APPROACH

System Overview

To access Field Tech Admin web tool, a technician will have to enter the URL on a web

browser. After logging in, a technician will be taken to the home page, which is also called the

dashboard. Dashboard is the main interface of the web tool, which is supposed to provide

information tabs and functional buttons. Since Field Tech Admin allows technicians to log in

without VPN, a high-security structure is required. The dashboard is an HTML based web page.

Each functionality will be in a small window, where technicians can perform operations such as

entering subscriber IDs for information and so on. As shown on Figure 2, The front end of each

specific functionality will make web service calls using AJAX to the middleware. The

middleware will interact with libraries for this specific functionality as well as all public libraries

on the server. Most importantly, the database cannot be accessed through front end.

Figure 2: Web Call Flow and Data Transfer

Functional Decomposition

The dashboard is the most important component of Field Tech Admin because it provides

information, shows various options, and lets technicians customize tabs.

Figure 3: Initial Dashboard Interface Layout

Figure 3 is the initial design of the dashboard interface of Field Tech Admin. The computer

version of interface is on the left and the mobile version is on the right. There are four buttons on

the top of the screen. With the initial design of the home page, technicians will be able to add,

remove, resize, and rearrange functionalities.

During a conference call with sponsor on Nov. 29th, 2016, some potential issues of the

initial design of home page was discussed. To achieve a simple and clean interface, a

“hamburger” menu button was to be added to homepages in replacement of “Add”, “remove”,

“drag”, and “settings” buttons (they become sub-buttons under the menu button). Username will

be displayed in a drop-down window with mouse over action on computer view, and it will be

always displayed on mobile view. Another issue was the difficulty of implementation of

dragging and moving functionalities around on a mobile phone interface due to various types and

sizes of screens. Technicians still will be able to rearrange by changing the order of

functionalities under the menu button. As shown in Figure 4, in the early stage of

implementation, most functionalities will have the same size. It is possible that technicians will

be able to resize the functionality windows in the future.

Figure 4: Improved Dashboard Interface Layout

Spatial info lookup is a simple functionality that can be added to the homepage in early

stage of implementation. Spatial info is a special string containing spatial code that helps

technicians locate the terminals of subscribers, and it can be queried from the company database

of which schema is shown in figure 5. Once spatial info lookup functionality is added to the

dashboard, technicians will be able to click on the search bar in the “spatial info lookup” window

and search by entering address information. Normally, this simple operation requires them to call

into TTU, which takes several minutes. Through Field Tech Admin, they can retrieve the

information through one click. The implementation of this functionality will involve frontend

info display, AJAX web service call, and programming database in the backend querying data

from the company database powered by Oracle.

Figure 5: Database Schema of Spatial Info

The level of difficulty for implementation of functionalities such as unassigned work

bucket, previous notes lookup, and timeline is close to spatial info lookup because they only

involve retrieving data, thus can be implemented in a similar pattern. Functionalities such as

equipment swaps, ONT activation, and Mac activation are more complicated because they

require data modification.

Third-Party Subsystems

Most functionalities of Field Tech Admin will involve retrieving or modifying data. This

web tool will utilize the company commercial database of Metronet powered by Oracle. There

are multiple databases being used for different purposes. The most used database is called QCC1,

and it keeps track of subscriber data, including general data, service information, billing

information, transactions, and Billing Data Model. There are four development copies of QCC1,

named TST1 – TST4 [3]. For development and test purposes, TST1 will be used so that

unnecessary data modification can be avoided.

As a tool used by employees of Metronet, Field Tech Admin will run on Metronet server

and use the domain provided by sponsor.

Also, as mentioned in the last section, Field Tech Admin will use the backend libraries

written in Perl. As a web tool that will benefit the company, Field Tech Admin will also take

advantage of the proprietary code frameworks of Metronet. During conference call with

Metronet employees, two web frameworks, named ISR and VES, were introduced for having

similar requirements and specifications as Field Tech Admin. As shown in figure 6, ISR and

VES both have “dashboard” interface and support responsive web design. The source code of the

two web tools will be very helpful for implementation of Field Tech Admin.

Figure 6: Interfaces of ISR (left) and VES (right)

V. DESIGN EVALUATION

The ultimate goals of the project is that technician will not have to call in TTU/Repair

after using Field Tech Admin. Other surveys will be conducted for getting information average

calls per month for technicians.

Dashboard: By the time Field Tech Admin is rolled out, technicians will be able to log

into the web tool using either computers or mobile devices without VPN. Each technician will be

able to add and remove functionalities using the menu button.

Unassigned work bucket, Timeline, Previous order notes, Internet speed tiers, ONT

lookups: These functionalities will be added to the homepage, each in a window. Since only data

retrieve is involved, these functionalities will be implemented first. Data will all be retrieved

from company commercial database.

Equipment swaps, ONT Activation, STB reset, Mac Activation: As mentioned in design

approach section, these functionalities will be implemented after the other ones are implemented

and tested, due to more complicated data modification.

Conclusion

The project engineer, Ruoqi Tian, is believed to be qualified to design, implement, and

test this project. Tian has been an MIS intern since May 2016 and has over six months of

experience working with Metronet MIS team under project sponsor, Christi Cronin. During his

work at Metronet, Tian has written, fixed, and rolled out over 20 Perl scripts, which ensured

high-level Perl programming skill. Tian also helped maintain several web tools by fixing

frontend files, and backend libraries, gaining strong ability of programming in HTML,

JavaScript, and jQuery, as well as sufficient experience with company-wide web frameworks.

The sponsor of this project, Christi Cronin, is the supervisor of Tian. Cronin has over

thirteen years of experience working at Metronet and she masters Perl and other programming

languages. As one of the initial designers, Christi is also very familiar with Metronet web

frameworks and willing to provide any assistance. Since Tian directly reports to Christi,

communication between project engineer and sponsor is frequent. The mandatory weekly touch

base also ensures that engineer can ask any question about the project and that sponsor is always

updated on the progress of the project.

The implementation of Field Tech Admin will kick off in mid December 2016. The

interface implementation and testing will take approximately 150 hour. Starting in January 2017,

functionalities will be added into the interface while fixing the interface because more problems

will come up as functionalities are added.

Following is a schedule of future work of the implementation of the project:

December – 30 hours 13th – 16th Design docs, homepage

implementation

January - 40 hours 2nd – 6th, 9th – 13th Homepage implementation

16th – 20th, 23rd – 27th Spatial info, Previous notes

February – 40 hours 30th – 3rd, 6th – 10th Previous notes, ONT lookups

13th – 17th, 20th – 24th Unassigned bucket, timeline

March - 40 hours

27th – 3rd, 6th – 10th (if functionalities above

completed) equipment swap,

ONT activation 13th – 17th, 20th – 24th

VI. REFERENCES

[1] Christi Cronin, personal communication.

[2] Christi Cronin and Trey Bowles, Green Belt Six Sigma Project Summary submitted on Aug.

1st, 2016.

[3] Metronet, New Hire Guide – Database.

APPENDIX A

The above spreadsheet lists all 14 TTU (Test and Turn Up) calls made by technicians on a single

day. “ONT issue” is the reason of 5 calls and “Triple play issue” is the reason of 6 calls.