Mobility as a Service, better known as MaaS, for all its four-words-made-into-one, is actually not one service or one application. Full blown MaaS will be made of several distinct and separate moving parts and in its wake, the technology driving today’s transportation providers will morph into something entirely different. But before we go there, let’s discuss what MaaS is.
Is MaaS a Passenger App?
Most people tend to think of the end result that passengers expect: one seamless optimized trip, with as many transit modes as required, with one payment and one interface. They are thinking about something that isn’t that different from the directions we use today in Google Maps - walk to a station, take a bus, disembark, take a scooter. The next step is tying this ability to a unified payment - the ability to subscribe to all the different modes of transportation required to make their trip, regardless of whether the mode is a taxi, bus, scooter, ride-hail or train. Some cities have been experimenting with this offering - showing taxis on public-transit-trip-planning apps, or showing bus or train tickets or options on a ride hailing app (there is a large policy question here - do we want private companies offering MaaS with the risk of shortchanging mass transit, but this question belongs elsewhere). Fewer cities have attempted to cover the payment question as well, offering one subscription payment to cover all transit options offered in the app. Yet even this doesn’t cover all applications that come into the fray when we think of MaaS - we would also want to provide unified customer service to people using MaaS, regardless of the mode. You’re starting to get the picture - MaaS, at least from the transportation provider’s point of view, is a story of interconnectivity. Different modes are connected into one trip, many payments are connected into one subscription and the customer service angle is also unified into one.
MaaS is Real-time
Yet MaaS is more than that - it requires all information presented to the customer to be real-time and reliable. The app can tell where the customer is in real time, and can also tell where other services are and what their availability is - from a taxi ride to a nearby scooter, and perhaps even be able to tell, using AVL, whether the bus is truly around the corner rather than infer from a pre-published timetable that it may be around the corner and maybe not.
Up to now we counted three types of apps that connect to to the cloud and present real-time information - the application used by the passenger, the subscription/payment management elements (what trips is the passenger entitled to under their subscription, etc.) and the specific apps relating to the available transportation modes - the scooter app, the ride-hailing app, etc.
This is where it gets interesting. Most of the apps we’ve described so far contain a strong real-time element (which explains while they all inter-communicate on the cloud). The passenger trip-planning app checks the passenger’s location in real time, connects to the subscription/payment gateway to check the real-time status of the payments. The scooter, taxi and ride-hailing app also show real time data and can even create a specific ride for the passenger. This connectivity works both ways - scooter and ride-hailing companies can understand the demand for their services and adjust their offerings accordingly.
But What About Mass Transit? Is it Real-time and Connected?
It’s true that mass transit publishes timetables so that applications such as Moovit can use it, and sometimes shows real-time data to passengers, through a variety of interfaces and protocols, yet the core operations of mass transit are “shielded” from the cloud. It isn’t connected and no real-time data comes in. For their core planning and scheduling operations, as well as dispatching and driver management, most transit providers use older legacy systems that do not reside on the cloud and are, therefore, the opposite of what was described above: they are not interconnected and they do not consume real-time data.
Being Cloud-Native Matters, Even Today
You may be reading this and thinking that MaaS is a long time away and conclude that there is no need to hurry and use cloud-native (or even cloud-based) applications. However, this isn’t true. Cloud-native applications can fire up the cloud to get the processing power required for the heavy-duty schedule optimization work that all transit providers need to do. This means that transit providers can quickly check multiple scheduling scenarios, save money and offer drivers better options in terms of duty and roster quality. Cloud-native applications can also allow remote work and collaboration between people that aren’t located in the same office, a feature that seems basic to most people but isn’t simple at all in old-fashioned transit software.
Cloud-native also means Software-as-a-Service, and SaaS platforms offer many more benefits. First of all, there are little to no IT costs, since all IT-related work is done by the provider. More importantly, software upgrades and fixes are done automatically to the cloud by the software provider - this is important since most transit providers are hobbled by long and expensive software cycles that cost much and require extensive efforts that disrupt work.
SaaS-MaaS
Now that we’ve concluded that moving to a SaaS model makes sense today, the question is whether it will be beneficial in the future days of MaaS. We believe it will. Not just because mass transit data will be communicated in real time to passengers and providers of other transportation modes. It will be beneficial because transit providers can also use the two way communication with passenger data in real time. Instead of simply sending the fixed timetables of their fixed-route service, they will be able to use real-time data to adjust their fixed-route services, offering a service that better meets demand, just like the scooter and ride hailing providers. No one knows what this change to the fixed bus model will be and how these services will be offered in the future - but staying behind and remaining disconnected with old, on-premise software doesn’t seem to be a good option for the long run.
-----------------------------------------------------------------------
Amos Haggiag is CEO and co-founder of Optibus.
