Transforming Bus Fleet Management with Innovative Solutions: An Interview with Kidus Adugna, Developer of Sheger Mass Transport Service Enterprise’s Fleet Management System – Addis Ababa, Ethiopia

In this interview, we speak with Kidus Adugna, a mechanical engineering graduate and maintenance technician at Sheger Mass Transport Service Enterprise (SMTSE) – A bus agency in Addis Ababa, Ethiopia. Kidus shares his insights on the journey to develop a fleet management system for the agency, the challenges faced during the development and implementation of the system, as well as its features and benefits to the agency and its customers.

DT4A: Could you please introduce yourself and tell us a bit about your journey and what led to your current position working as a maintenance technician/system developer at SMTSE?

Kidus: My name is Kidus Adugna, I’m a Mechanical Engineering graduate from Addis Ababa University. As a student, I also learned programming skills developing a small software which helped me and my peers in putting together our theses. I enjoyed that experience and would find it useful in my career. In 2020, I joined Sheger Mass Transport Service Enterprise as a breakdown maintenance technician, at its Summit Depot. For people who don’t know about SMTSE, it is one of the two public bus transportation providers in Addis Ababa (the other being Anbessa City Bus Service Enterprise). As a maintenance technician, I work to keep the buses in working condition, by providing follow up services and repair. After a year in that role, I realized that diagnosing and fixing our vehicles would be a lot faster if we had their past maintenance history readily available.

DT4A: Together with your colleagues you designed an impressive fleet management system. What inspired you and your colleagues to do it? Please tell us more about the features incorporated in the system and how is it helping the company in managing its fleet?

Kidus: Although SMTSE had the above mentioned data, it was all in analog (paper based) and unclassified. Many of the reports were in Word format, making it difficult for us to quickly access the information we needed every time a vehicle comes to the shop. It was to address this issue that I developed a script to assemble the Word files into a quickly accessible format that could display on our phones.

Suddenly, we had historical data for the past two years. Then new ideas started to flow, what if we could start generating our own data in the new format and have reports automatically generated from it? Could we expand this to other depots? And I worked, in my spare time, to realize those ideas. Gradually, our system grew, and noticing how critical it was becoming to our operations, the technical department officials brought me to HQ to work on it full time. Working with a team of technicians, and with help from our IT personnel on the infrastructure, we added more features, expanded to other depots, figured out how to connect with the vehicles (without purchasing new devices) and added GPS tracking and related features to the mix. It became what it is today, a fleet management system. And I am now working as the developer for the system, continuing to add features and fix bugs.

The platform has now evolved into a web-based centralized system that SMTSE relies on for an increasing number of tasks. It consists of different parts that support different departments in the company. It has Maintenance (for us technicians), Fuel (for fuel related services), Inventory (for spare parts stock management), Tracking (for monitoring operations), Vehicles (managing vehicles related information), and Administration (for human resources, depot information, etc.). Managing this information in one place helps us for example, to provide more efficient preventive maintenance for our vehicles, study fuel consumption to see where most of the fuel is going, purchase spares before running out, and keep the buses working on their designated lines, all of which makes SMTSE more efficient in serving our customers. And we continue to build more parts for more departments.

DT4A:Tell us about the trip planning application and how the application will benefit the bus company and its customers? What would you say will be the biggest benefit to customers/users?

Kidus: The idea for the app came when we were presenting the fleet management system to Addis Ababa’s Transport Bureau. The Bureau strongly felt that the general public would benefit from having access to the kind of real– time data that our tracking features were able to provide. We were able to put together an app that takes the data from the main system and shows relevant information publicly.

Full-blown trip planning apps require you to have data for different modes of transport from different providers. Our app has one data source, the main system – so it’s not there yet, but I’d say it’s a good deal of information for the public. It can currently show bus route information: which stations the bus will stop at, the fare price from a station, and it also has a real time map where you can see active buses and their destinations. Upcoming versions will show a bus’s ETA to a station of your choice – helping users make informed decisions about how they’d like to use our buses. We are populating the routes so it doesn’t currently have complete information but it’s only a matter of feeding it the data—and we’re working on that with our operations personnel. 

DT4A: What were some of the challenges you faced along the way? And how did you overcome them?

Kidus: There were a lot of challenges – particularly around accessing the infrastructure we needed. Although SMTSE was interested in having a system like what it has now, none of the company’s depots had internet – at least not at the technical offices. After management noticed the potential, internet was installed across the depots. Simultaneously, our IT team needed a public-facing IP address for the center (HQ) where we would put our server. The said server was old and not reliable. So, I had to set up a regular desktop computer that I had been using to develop the system to also work as our server. We continued to use this until the Transport Bureau donated the really capable server we’re using now.

The app, at its core, is web-based, meaning it requires a web browser. We felt that it would be a little easier for our audience if it was available as an application. One of the DT4A Innovation Challenge winners, AddisMap helped us build a version of the app for Android and with WRI’s help we were able to set up a Google Play account to host the app, and now it’s ready to publish.

Accessing a basemap on which we overlay/superimpose our data was a challenge as well. Google Maps is a paid service so it was out of the question. Fortunately, OpenStreetMap provides an open basemap and AddisMap has a server for it that we were able to use for our system and app.

A challenge we still haven’t been able to overcome is power outages. We don’t yet have a UPS that can support the new server because it’s big. We’re hoping we’ll purchase one soon.

These are the technical challenges—but there were also other challenges while working with people. Some were reluctant to embrace the change; but through time, we we’ve been able to get more and more people on board. Staff trainings are also a challenge: many people are not able to take time away from their work to attend trainings, and some might not see its value. SMTSE is being merged with Anbassa right now into a new organization: the Addis Ababa City Bus Service Enterprise. The merger and the possibility of staff being reshuffled makes people ask, what’s the value of taking this training if I may not be working at my current position tomorrow? So until the merger is finalized, we are not training people.

DT4A: What are the basic needs/requirements for developing an application like yours? What are the most critical components that are required? Can you share the insights you’ve gained from your experience?

Kidus: Well, the components fall into two groups: hardware and software. In the hardware section, there is the server, which is a computer that is capable of handling multiple connections from different devices. The capacity you need will depend on the number of devices that you need the server to communicate with and how much work it must do for each one. Surprisingly, to start off, you can get it working with a machine without high specs. We started with a 4GB RAM Core I3 computer and at the time, we had connected about 70 vehicles to it. Granted, we only had a few users and we didn’t have that many features. Other hardware you’ll need are the devices on the vehicles for communicating with a server. In our case, the vehicles already had Mobile Digital Video Recording (MDVR) devices that were very capable of the tasks we needed them to do. Of course, both the server and the vehicles will require an internet connection.

In the software group we have the main server application for communicating with each vehicle and processing the vehicle’s messages, storing data for later reports, communicating vehicle messages to humans in a comprehensible way, understanding and executing commands like registering a new refuel entry, creating a maintenance order or generating reports.  It goes without saying that communication with humans should be done in a secure way as well. Users should not be able to access things they don’t have permissions for. My recommendation for the people looking to set up a platform like ours is to use open-source software because they’re secure, easier to learn and more accessible, and have big communities. Open-source software is more convenient as they are aware of other products in their areas and try to integrate well, as opposed to commercial ones who often try to create their own ecosystems.

DT4A: Do you have any plans to expand or enhance the fleet management system and trip planning application?

Kidus: We are starting to work on new features like detecting whether a vehicle is on its designated route or not, whether it’s inside a geofence, counting how many rounds a vehicle goes on a route, etc. After the upcoming merger with Anbessa City Bus Service Enterprise, we’ll be incorporating their data meaning, once we finish, data for all the buses and routes in the city will be included in the app! We’re also planning on exposing a GTFS interface so that other developers can build apps based on our data. We are currently waiting for approval from INSA (Information Network Security Administration) to publicly launch the app.

DT4A: Do you have any advice that you would like to share with others who may be considering developing a similar application in the transportation industry? What are some key considerations or best practices that they should keep in mind?

Kidus: Start with what you have. It may be small but that doesn’t mean it will remain small forever. We had no idea that our system would become what it is today; we just needed something to solve a simple problem.

After that, lessons will be learned, requirements will grow and so will the available resources. It’s also important, to understand that most people want to help, so let them. One person’s idea may be good but when combined with others’, it becomes great. And communication is key. Sharing information, however small it seems, is important because someone else is going to build on that and it may gradually become an important resource. Technically, performance matters. Don’t get comfortable with the initial performance of what you build- because as it grows, it will probably have to do more work and become slower. Don’t let that happen. Your interface matters too.  It’s easy to focus on the functionality and forget about what it looks like. If it’s a place where people will spend a sizeable amount of their time, it has to look good, or they will dread using it. Also do your best to assist the user with the information you have—so they will have to do only what the system doesn’t know or can’t predict. For example, if staff wants to order a service for a vehicle, they should not be required to write much about the vehicle, just a plate number is enough, because your system already has the other information.