The last decade has seen a drop in public transport mode-share across all Indian cities. The fear-mongering about the coronavirus spread further dented the appeal of city bus services. However, when the services were gradually reinstated, ridership in most city bus systems rebounded to 65-95% of the pre-lockdown levels despite many educational and workplaces still not operational. This is both an indicator of resilience and also of how integral the bus service is to the lives of many citizens.
The question now is how to transform the urban transportation landscape to at least recover the lost ground over the last 10 years. Top-most on every urban passenger’s travel decision making is (a) Reliability of bus service, (b) Affordability, and followed by (c) Accessibility. While the comfort of travel is also important, it falls much lower in the order of what is desirable.
Thus, switching buses to ‘electric’ (or ‘CNG’) from other fuels doesn’t do a thing to improve public transport. Yet, such technologies increase the cost of providing service. If the public transport mode-share continues to fall, as it did in the past decade, buses, even if electric, will run empty and add to congestion; thus increasing the overall emissions from transport.
Let us see what it takes to improve the critical aspects of travel decision making:
Both infrastructure and policy changes are not within the domain of the transit agencies. Knowing that the most significant gains in reducing costs and increasing ridership are only possible with technology solutions, transit STUs/SPVs started investing in Intelligent Transport Systems (ITS).
In the past decade, transit agencies across the country spent Rs.1000+ crore ($150+ million) in procuring ITS with the objectives of achieving service reliability and efficiency. Yet, all this expense proved to be in vain. Even today, none of the 40+ cities using ITS have been able to:
ITS deployments not only failed in value addition but also failed in reliably capturing essential operational parameters, because of which bus operators continued to keep manual records as was always done. Thus, instead of solving existing challenges, ITS deployments rather increased the cost of operations and also the workload of bus operators. The rapidly declining public transport ridership attests to this fact.
Some of the key reasons for such failure are:
a) Flawed Procurement Process: The key to ITS is the software back-end that captures, stores and processes data from the various hardware components. Moreover, developing robust software requires detailed documentation of the processes, defining performance indicators, methods of analysis, etc. However, tender documents focus on defining the hardware, leaving the intelligence functions and performance criterion extremely subjective and weak. Hence, what finally gets delivered is expensive IT hardware with large-size video walls and data storage systems in the control center.
b) Multi-disciplinary Problem: Another key challenge is in bridging the chasm between technology developers and transit agencies. Transit agencies are unable to imagine the possibilities that technology can bring. At the same time, software developers are unaware of the various use cases and scenarios in bus operations to be factored into the development. What then ends up being deployed is a common-minimum solution that tries to mimic the routine manual methods of work happening at the transit agency. After the deployment, transit agencies become aware of the limitations that ITS imposes on the ad-hoc decision-making that happens quite frequently, thus resulting in frustration.
The end result of this compartmentalized, non-iterative approach is that the analytical outputs go missing. In most cases, the base data itself is inaccessible. This problem has been identified and documented way back in 2014 in the Bus Karo – Case Studies, and yet, the same mistakes have been repeated several times all across the country. The need is to modify the very procurement/development methodology of the ITS solution for public transit.
A problem such as this one, having complex processes, integrating with many hardware components, varying methods of financial operations requires a thorough understanding of practices, defining of standard operating procedures, and performance indicators, in order to develop a technology that will not only recover its cost but also deliver value many times over. Such an enterprise seems beyond the capacity of individual transit agencies that are already ailing.
So, here is what we know:
The problem that seems as unfathomable as this can indeed be overcome with a simple approach – disengage the software and hardware portions of the ITS tender. This approach involves:
a) Development and hosting of an overarching Transit Operations Management & Intelligence software centrally at the national level, under a Special Purpose Vehicle with the MoHUA or MoRTH or MEITy. This division will be in charge of:
b) Procurement, deployment and maintenance of hardware (GPS, ticketing, control centre, etc.) as needed by the individual transit agencies, following the specifications and integration developed by the central agency.
This approach resolves the various issues currently faced in deploying ITS for transit and ensures a framework for continuous improvement that can be rolled out across the country instantly. It resolves the issue of duplicate spending in various cities and ensures state-of-the-art management and the availability of performance tools and open data for fuelling further innovation.
Ever since the JnNURM bus funding scheme, there has been one or the other central government program floated to support transit agencies, albeit insufficient and inconsistent. Initially, funding was directed to the purchase of buses. The next round extended financing for support infrastructure. In the absence of performance metrics from individual cities, the distribution of funds was mostly based on political and demographic considerations. Thus, a significant resource was spent ineffectively. However, now, there is consensus that funding has to extend to the operational viability gap and that it should be based on performance outcomes on-ground. Thus, developing a central infrastructure for capturing various data, analysing performance and identifying service quality improvements to bring efficiency becomes inevitable.
Undertaking such an enterprise (central software development) may cost just about Rs. 20 – 30 crore ($3 – 4 million) over a period of 18 to 24 months. The ongoing costs of maintaining the system and improvements will be minuscule of the benefits derived once rolled out.
It will be worthwhile here to learn from the experience of the rollout of the Unified Payments Interface (UPI) regime in the banking sector. It may be noted that the Mastercard and Visa networks for payments existed in India for decades. However, the advent of the UPI completely transformed the digital transactions space like never before, even transcending the urban-rural and literate-illiterate divide. Not just the ease of use, it also cut the transaction costs from about 2+% MDR to near-zero with the UPI.
This method of centrally hosted SPV, on the lines of the National Payments Corporation of India (NPCI) and possibly christened as the Universal Public Transport Interface (UPTI), can be a game-changer for public transport in India. Moreover, unlike the UPI, the UTPI can be extended for use by peer-nations in Asia and Africa facing similar challenges. Thus, a small innovation can bring in significantly big returns on investment.
An effective ITS can transform the public transport sector, reducing cost of provisioning transport by at least 10% and also multiply bus ridership. Even if just considering the top 10 cities in India, it translates to annual savings of Rs. 1,200 crore ($160 million – assuming 30k bus fleet), improving travel convenience of over 20 million passengers every day, and so much more in intangible positive externalities. This outcome may seem overwhelming for an ailing sector, and yet, this outcome is just the tip of the iceberg.