Case Study: District Mileage

OVERVIEW

For technicians in a school district, countless hours are wasted each month driving here and there to fix problems. Most districts have their own mileage sheets which have to be manually entered which in some cases can take hours. Often, trips are either forgotten and never logged (bad for the technician) or they are accidentally duplicated (bad for the district). By migrating the locations and mileages to SQL and using a minimal, mobile friendly UI, I was able to allow people to easily track their mileage and print it out monthly. This freed up hours for technicians so they could better service their locations, while at the same time drastically reducing incorrect mileages. This saves districts time and money across many avenues and allows students to be better supported.

ALLOW ME TO GIVE SOME CONTEXT

The slow adoption of new technologies which help bring efficiencies means that there are plenty of processes which still require manual entry. This is the case with managing mileage in a lot of school districts.

THE CHALLENGE

The major challenge faced here was that human error causes incorrect mileages to be logged in addition to the time it takes to manually log each trip.

I wanted to resolve this manual entry and bring about a more efficient way to track mileage that brought benefits throughout the organization.

THE PROCESS AND INSIGHT

When I started this project I was working as a technician so I saw first hand a lot of the struggle with existing processes and the inefficiencies and errors that they presented. Because of that I knew I had to meet a few expectations:

• Ease of use - it had to be very simple
• Availability - it had to be easily accessible from any device
• Ease of submission - it had to eliminate any further work before submission short of signing the paper.

With those three things in mind I started designing. I chose the Laravel framework for handling all server side things and making the data easily accessible with Eloquent. I used twitter bootstrap for the frontend side of things so I could get it up and running quickly. This allowed me to get an interface up and going that met all the requirements above.

EASE OF USE

It was just one form for submitting mileage. The first ’trip’ required the most effort: choosing 2 locations (from prefilled dropdowns), picking a date and clicking submit. After the first trip is entered the user just has to select from one drop-down (because the last trips ’ending location’, becomes the current trips ‘starting location’) and submit their trip. Very easy.

AVAILABILITY

It was a web application with twitter bootstrap so it was mobile ready and available on anything with an internet connection.

EASE OF SUBMISSION

By utilizing an Excel library to build the worksheet which gets emailed to the user, when the user emailed their mileage to themselves all of the required information and functions were already present. They just had to print it, sign it and turn it in.

THE RESULTS

This application allowed technicians to save hours of time (on average around a 2 hour savings per month) and drastically reduced the amount of unlogged/forgotten trips. It also reduced the amount of duplicate trips and the amount of incorrect mileages being logged. The exact cost savings per district varies depending on how many resources are typically assigned to the task of verifying the mileage, checking for duplicates and analyzing the sheets submitted. Overall however, the savings are across the board. Those who receive the sheets created by the application no longer have to search out incorrect mileages and can focus more on validating the trips and/or spending that saved time elsewhere. This increased efficiencies across the board in each department! Because of the overwhelming success there were other departments who wanted to get involved (despite traveling less) because it was just so intuitive, easy and quick to use.

ADDITIONAL REFLECTIONS

This application meets the needs for people who have pre-mapped to and from locations - but there are instances where technicians travel beyond the pre-mapped destinations. I’m currently working on building an additional feature to allow an easy entry of ‘custom’ routes for users.