Field Tech Admin

Project Engineer: Ruoqi Tian

Computer Science, University of Evansville

Project Sponsor: Christi Cronin, Metronet Inc.

Project Advisor: Dr. Don Roberts

30 April 2016

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 at the company

office, where employees help them look up and update information online. A limited number of

office employees and a 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 provide a

better service experience to subscribers, an online web tool was built. It allows technicians to log

in using their mobile devices, look up information, perform simple operations, and complete a

service run without calling into the office.

ACKNOWLEDGEMENTS

The project engineer would like to express his sincere gratitude to the project sponsor,

Ms. Christi Cronin, for the immeasurable amount of support and guidance she has provided

throughout this project. He would also like to thank his project advisor, Dr. Don Roberts, and

academic advisor, Dr. Deborah Hwang, for their valuable advice. Special recognition is given to

Mr. Jason Funk and Ms. Gail Minnick for their technical support and code reviews. Furthermore,

this project would not have been possible without the ideas and help provided by the members of

MIS team and Field Operations at Metronet.

LIST OF FIGURES

Figure 1: Process Map of a Typical Technician Run

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

Figure 3. Diagram of Data Transfer

Figure 4: Initial Dashboard Interface Layout

Figure 5: Improved Dashboard Interface Layout

Figure 6. Process Map of Implementing and Testing Each Functionality

Figure 7. Field Tech Admin Interface on Tablets

Figure 8. Screenshots of Spatial Lookup

Figure 9. Screenshot of Previous Notes Lookup

Figure 10. Screenshot of Services Lookup

Figure 11. Screenshot of ONT Lookup

Figure 12. Implementation Progress of Functionalities

LIST OF TABLES

Table 1: Database Schema of Spatial Information

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 information

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 is a web tool that technicians can log into and perform operations on their cell

phones, tablets, and laptops. It allows technicians to customize their own homepages by adding

functionalities that are most important, resizing them, and organizing them. This web tool takes

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

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

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

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

functionality, such as subscriber information lookup, equipment swaps, or terminal box

activation, etc. Also, the web tool is a web platform that 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 can add functionalities by adding corresponding front-end screen, middleware, and

back-end scripts, without modifying the main dashboard platform.

PROBLEM STATEMENT

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

Although fiber broadband is the fastest internet available, to provide quality services, it is still

required that a great number of field technicians to go to the customers for services such as

installation, maintenance and repair. Normally, to perform some common actions, field

technicians must 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.

Departments with a Queue shown in Green

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) and provides the

customer ID, so the TTU specialist who picks up the phone call can turn up information that the

technician does not have access to, such as services or billing information. Also, it usually

happens that a technician calls Repair if there is any error that he or she cannot deal with, or any

equipment swap is to be recorded. For both TTU and Repair, there will be queues because there

are multiple technicians calling in. Additionally, a technician would call Dispatch for work

assignments and sometimes Storefront for equipment-related issues.

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.

Not only is the time of field technicians wasted, technicians waiting in the queue and talking to

the office specialists results a negative customer experience. Based on above data and facts, the

project sponsor believes that the current solution, which is technicians calling into the office, is

not sufficient, and that developing a web-tool for field technicians to complete simple operations

themselves is a necessary part of solving this problem.

SPECIFICATIONS

Interface Requirements

To gather requirements and determine specifications of Field Tech Admin, a survey

containing 8 questions was sent to the technicians and accepted responses from 4 Oct. 2016 to 14

Oct. 2016. 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 question 8 of the

survey, 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. Foundation 6 is used for the front-end

interface of Field Tech Admin. Foundation is one of the most advanced front-end responsive

design framework that comes with HTML, CSS, and JavaScript [3].

Connection Requirement

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

remotely and safely. Since there already exists a company-wide user database, the same

credentials can be used for multiple applications, Field Tech Admin takes advantage of the user

credential system so it can be accessed by technicians using their company usernames and

passwords. However, Field Tech Admin is an external web application so that it can be accessed

by technicians through any network considering the difficulty of connecting to the Metronet

VPN.

To access Field Tech Admin web tool, a technician should enter the URL on a web

browser. After logging in, a technician is 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.

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

Also, Field Tech Admin utilizes the back-end libraries written in Perl. As a web tool that

benefits the company, Field Tech Admin also takes advantage of the proprietary code

frameworks of Metronet. During conference call with Metronet employees, two web

frameworks, named ISR and VES, were introduced as having similar requirements and

specifications as Field Tech Admin. As shown in figure 2, ISR and VES both have “dashboard”

interface and support responsive web design. The source code of the two web tools are very

helpful for implementation of Field Tech Admin.

Functionality Requirements

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 is 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 information lookups

Equipment, ONT, STB operations is on the interface of Field Tech Admin. It is helpful that there

already exist libraries for remote reset in the back-end. Spatial information lookups is also 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 greatly helps

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. He also confirmed that all the information mentioned above

was safe to be retrieved through Field Tech Admin.

DESIGN APPROACH

Dataflow

Figure 3. Diagram of Data Transfer

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

are being used, Field Tech Admin follows 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 of a functionality consists of at least one HTML template, a CSS

stylesheet, a JavaScript script, and a Perl library. The screen interacts with the front-end Perl

library using AJAX. Instead of hard coding all AJAX commands, the project engineer used

AJAX package from Metronet core library, which is a library that is shared by all web

applications. The middleware follows SOAP, which is a protocol specification for exchanging

structured information in the implementation of web services in computer networks. Its purpose

is to induce extensibility, neutrality and independence [5]. In the case of Field Tech Admin, to

transfer data between front-end and back-end servers, middleware files are used to wrap the data

using multiple layers of protocol. Middleware files are normally in .wsdl or .xsd formats. Like

front-end libraries, back-end libraries are in Perl. Also, back-end libraries use functions from

Metronet core library. Front-end libraries are different from back-end libraries because front-end

libraries focus on input data validation, error reporting, and formatting data to return to front-end

screens, but most importantly, they only deal with the small amount of data that is returned

through middleware from back-end libraries. On the other hand, the back-end libraries interact

with multiple databases using SQL and format data to return to front-end.

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

tool utilizes 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 [4]. For development and test purposes, TST1 is used so that unnecessary

data modification can be avoided.

System Setup

There are multiple Ubuntu servers being used at Metronet for purposes such as

development, testing, and production. The initial implementation of Field Tech Admin is on the

development servers, where the basic configurations of Apache Server are set for other web

applications that are already on the servers. There are development servers for both front-end and

back-end, so security is guaranteed. Setting up the space for Field Tech Admin included creating

the configuration file, adding a pre-compiling script, and creating a namespace of Perl libraries

for Field Tech Admin.

The setup of the back-end is easier than front-end because there is no need to combine

interface templates with corresponding libraries. There is no front-end view on the back-end. The

major work is to create middleware files where datatypes for different functionalities can be

added and to create the handlers for middleware calls that are built inside of the back-end

libraries.

A good setting for bug reports and alerts can save much time during the development of

Field Tech Admin. The front-end debugging for JavaScript is based on the console function of

Google Chrome Web Browser. The debugging for both front-end and back-end Perl libraries

utilized error log files along with error reports generated. When a database-related error take

place, an error report generated by a core utility functionality is sent to the project engineer as an

attachment to an email.

It is important to mention that, during the process of development, only test databases can

be accessed. At Metronet, multiple Oracle databases are used for storing data such as customer

information, construction information, and equipment information. There are copies of each of

them for development purpose. The project engineer only used development databases during the

implementation.

Interface

The dashboard is an HTML based web page. Each functionality is in a small window,

where technicians can perform operations such as entering subscriber IDs for information and so

on. The front-end of each specific functionality makes web service calls using the middleware to

transfer data with the back-end. The back-end libraries interact with databases for this specific.

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

Figure 4: Initial Dashboard Interface Layout

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

information, shows various options, and lets technicians customize tabs. Figure 4 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 can add, remove, resize, and rearrange

functionalities.

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

be able to customize his or her Dashboard/Landing Page to show the most important content.

Also, since Field Tech Admin is used and maintained after the senior project, it must be scalable

to additional features in the future.

Figure 5: Improved Dashboard Interface Layout

During a conference call with the 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 added to homepages in replacement of “Add”, “remove”, “drag”,

and “settings” buttons (they become sub-buttons under the menu button). The username is

displayed in a drop-down window with mouse over action on computer view, and it is 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 can rearrange the Dashboard by changing the order of functionalities under

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

have the same size. It is possible that technicians can resize the functionality windows in the

future.

Functionality Implementation and Testing

Figure 6. Process Map of Implementing and Testing Each Functionality

After creating the main interface for the Dashboard, functionalities were added. The

process of adding all functionalities are similar. Figure 6 is a diagram of the process of adding a

new functionality to Field Tech Admin. Before adding any functionality, a phone conference

regarding the input data required and the output format must be held between the project

engineer, the project sponsor, and the Field Operations supervisors. After determining the input

data required and the output format, the front-end interface of this functionality was

implemented, along with the JavaScript, CSS, and front-end library. When it gets to the

middleware part, a research is necessary before creating a new middleware. Because of the

existence of multiple web applications at Metronet, a great number of well-developed

middleware and back-end files are already created. Searching and using existing middleware and

back-end libraries greatly reduces the code size, helped the project engineer finish the

implementation of the functionality more efficiently, and make the fix and update easier in the

future. If an existing middleware and back-end libraries are found, the project engineer only

modifies the front-end libraries to make them work together. Otherwise, he creates the

middleware and the back-end.

After implementing each functionality, the project engineer performs unit test, that tests if

a functionality works independently. Then an integration test is performed by the project

engineer and the sponsor to make sure that the newly implemented functionality did not break

the previous functionalities. If a functionality passes both tests, it is ready for code review. After

a loop of code review and fix, the functionality is rolled out to the testing server for user

acceptance testing. In the user acceptance test, field technicians test the functionality and return

feedback. Only when all the problems reported by the users are solved, can the functionality be

rolled out into production.

Table 1: Database Schema of Spatial Information

Spatial information lookup is a simple functionality that was added to the homepage in

early stage of implementation. Spatial information 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 Table 1. Once spatial information lookup functionality is

added to the dashboard, technicians can click on the search bar in the “spatial information

lookup” window and search by entering address information.

RESULTS

Figure 7. Field Tech Admin Interface on Tablets

After more than 150 hours of implementation, all core requirements of Field Tech Admin

have been met, with most of its basic functionalities implemented. Field technicians can use

either their mobile devices or their computers to log into the web tool with their company

usernames and passwords. The screen is responsive, and the sizes of functionalities and the

layout change according to the types of devices that they use. On dashboard, they can use the

first four functionalities that have been implemented.

Figure 8. Screenshots of Spatial Lookup

Spatial information lookup functionality allows field technicians to enter the address of a

subscriber and displays the spatial information of the address. The bar for entering address has an

auto-complete feature utilizing an AJAX call and it displays all address records that match the

key characters that a user enters.

Figure 9. Screenshot of Previous Notes Lookup

Previous notes lookup functionality allows user to enter either a subscriber ID or an

activity ID. If a field technician enters a subscriber ID, notes records of all activities are returned

along with their activity ID’s. If a field technician enters an activity ID, only the notes of that

activity is returned, but the subscriber ID is returned as well.

Figure 10. Screenshot of Services Lookup

Services information lookup allows field technicians to enter a subscriber ID and get all

the current services of this subscriber, including Internet, TV, Phone, subscriber level, and some

other equipment information. Different from other existing functionalities, which are supported

by web service calls and back-end libraries that are explicitly created for them, services

information lookup utilizes existing web service calls along with the back-end libraries.

Figure 11. Screenshot of ONT Lookup

ONT stands for Optimal Network Terminal, which is the equipment that adapts fiber

network signals for home usage. Getting the information of an ONT helps technicians figure out

the problem of a malfunctioning ONT and whether it should be fixed of replaced. The

implementation process of ONT information lookup was close to previous notes lookup but the

data of ONT was retrieved from another database where equipment information was saved.

CONCLUSION

Field Tech Admin with the first 4 functionalities were rolled out from development

server to testing server on 30 April 2017, and all field technicians and supervisors could test it

and return feedbacks to the project engineer. Field Tech Admin is on its way of helping field

technicians get their work done more efficiently.

The next step is to gather feedback and fix any bug that comes up, so the application and

the first 4 functionalities can be rolled out from testing server to production server. It is also

important to keep track on the usage of this web application and calculate the total hours saved

by field technicians using it, therefore the effectiveness of this web application can be known.

Also, knowing the usage of each functionality helps the project engineer better improve all the

functionalities and develop more functionalities in the future.

Figure 12. Implementation Progress of Functionalities

Figure 12 is a list of functionalities to implement that was created during requirement

gathering. All the required functionalities are implemented but the last one. Because equipment

swaps involve modifying multiple entries in the database through back-end libraries, it was

decided to be implemented after the initial rollout of the first 4 functionalities.

Most importantly, as a web application that has great extensibility, Field Technician is

open to adding more functionalities written by different software engineers at Metronet upon

requests by field technician supervisors. The project engineer will keep improving this web

application for even better compatibility with web browsers of different devices.

REFERENCES [1] Christi Cronin, personal communication.

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

[3] Zurb, Foundation. Available at: http://foundation.zurb.com/. Retrieved on 22 April 2017.

[4] Metronet, New Hire Guide – Database.

[5] Wikipedia, SOAP. Available at: https://en.wikipedia.org/wiki/SOAP. Retrieved on 22 April 2017.

BIOGRAPHY The project engineer, Ruoqi Tian, is a software engineer born and raised in Beijing, China. He attended

college at the University of Evansville and graduated as a B.S. in Computer Science with a minor in Mathematics in

May 2017. Tian has strong skills in programming in Perl and good understanding of web application structures. He

has great passion to front-end design as well. Tian served as the chapter secretary at the University of Evansville

Chapter of the Association of Computing Machinery till he graduated. After graduation, Tian decided to become a

Software Engineer at Metronet, Inc. in Evansville, Indiana.

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.